Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Mark Shuttleworth <mark@xxxxxxxxxx>]

Martin Owens wrote:

Hello Mark,

On Wed, 2009-10-21 at 11:09 +0100, Mark Shuttleworth wrote:
  

First, we get much better collaboration and communication,
    

Do we? The first thing I've noticed from this experimental opinionated
stance is a tendency to alienate and frustrate people who want to
collaborate.

Yes and no.

Sometimes folks actually want to push their own ideas, and think that's collaboration. That's not going to work here, because we have a core driver already.

There is lots to be done around that core, and this list is one way people can participate in that.

 There are people who will give up their personal visions
for yours without lots of hard data, but most of those are called
employees...
  

Not really. Employees aren't serfs. But it's true that we have more opportunity to reach a common understanding in areas where we have higher-bandwidth interaction.

and much better testing, if everyone is looking at the same
experience.
    

Testing and experience can be brought about by standardisation of
configuration at testing time.
  

The famous "many eyes" do their testing all day, every day, on the system they are running. They don't generally setup and run default configurations to test just for fun.

We found this with Ubuntu itself - we reduced the default application
install set to a single app for each major function
    

The key here is 'distribution default'. I will congratulate you on the
decision to prevent choice paralysis in normal users, insisting upon a
single application per function at distribution time is the right
choice. But this is development, this is upstream, that logic may not be
relevant.

Ah, right, the old "WE are above the default, WE are smarter, WE can have it any way we want". Sure you can. Just not here ;-)

 I notice that you don't insist upon one application per
function available in the repositories or launchpad PPAs.
  

Of course not. Nor would I resist there being many branches of notify-osd. But I will resist calls for "this should be an option".

I've done it before on this list, and will do it again, because it's a common meme in open source. Creating an option is a way of avoiding social tension - "we don't have to either agree or consent, we can just create an option". It's a figleaf for a failure either to reach consensus or to accept that someone may take a decision that has detractors.

Of course, that's not ALWAYS true. But it is generally the case, and in this case it REALLY is the case.

One of the great failings of the community approach is that it
attracts folks who like to customise the environment to the point
where it is "perfect for them", at which point they stop caring about
the environment that the typical user sees.
    

Why is the consumer grade user more important to design development than
creative experimental people? This fight against the creative ecosystem
can only be destructive.

Why is this a fight against creative, experimental people? There is still lots of room for experimentation and creativity. But we will not ship an obtuse, anything goes, highly configurable experience.

 I believe it will drive people away, hurt
upstreams, a number of side streams and limited sections of downstream.
  

What does that mean exactly? I think you're mouthing off because you don't like the idea of having to go with something you don't personally like occasionally.

But I have no data on that, that's just from my own principles of
inclusion and experience in trying to do the hard job of bringing
together conflicting ideas.
  

If you have deep experience of that you'll understand what I mean when I say you cannot always include everybody if you want a decisive and exciting result. You can aim to include everyone if you are comfortable taking a very long time to produce something that is hard to use and ultimately not exciting.

In Ayatana, we'll take an opinionated stance, and we'll apply some
common principles to the design process,
    

This principle isn't common,

This willingness to be decisive isn't common, no. By common principles I meant that we will focus on specific areas of the experience, bring some specific principles to bear, and live with the results.

 it's something I haven't seen in any other
projects, even the ones that I would aspire to with regards to design
and vision.
  

Such as?

Can you tell me what the metrics that you'll be using to see the
results?
  

Whether or not non-computer-specialist people continue to embrace and enjoy Ubuntu. And whether computer specialists continue to do the same.

I have no interest whatsoever in making it possible for anybody to
have any environment they want - we already have that.
    

Hmm, I can't actually believe you would say that. It sounds so,
authoritarian. To dictate what is in the best interest of the masses and
removing the choices of those who aren't believers in the one true
vision.

It certainly doesn't sound like "I am because of my community", it
sounds like "I am because of what Mark likes to see". Scary in a way.
  

Take a good look at Ubuntu. We find the best people and empower them to take hard decisions. That's how we got Upstart. It's how we got One CD. It's how we got most of the really great things about the community, including functional forums and IRC, and polite mailing lists.

Don't think that Ubuntu is built on equality of the producers. It is not. It's built on empowering the best people to lead and take decisions.

You don't have to look very far to find projects with similar goals to Ubuntu that don't have the guts or the willpower to take the same approach. You can see for yourself the consequences - paralysis, indecisiveness, slowness, complexity.

If you're reacting to the fact that right now I'm a driving force in this, understand that the role will shift onto the shoulders of others as that capability in Ubuntu and Canonical matures. It's been that way with many things.

I'm interested in driving forwards to build a default out of the box
experience which is as good as we can make it for the new, consumer
user. 
    

So am I, Fixing Bug #1 is top priority. End users (not just customers)
are where my empathy has always been.
  

Super.

If representatives of Fedora or Debian were to come here and provide
upstream patches to express the options they wanted to include in their
distributions default configuration; Would the project accept them with
the stated principle?
  

In general, no. If the ideas they express are better, but the metrics we can bring to bear (including the view of the people to whom the design leadership has been given) then those patches can be included without options, the default behaviour will be improved for all. If they just create options for options sake, no. That creates complexity and cruft in code. Go and look at the consequences of that, it's all around you. Poor testing, poor quality, poor consistency.

Mark

Attachment: signature.asc
Description: OpenPGP digital signature