Dumbness of Crowds and GNOME 3.0

I wrote last year:

I’m more and more convinced that we’re not going to get to 3.0 as an organization- we’re too afraid to fail (for reasonable reasons), we have too few resources, we are too enamored with planning,etc., etc.- I’m now fairly convinced that 3.0 is most likely to happen when someone goes out, experiments, probably fails, but get people interested in their experiment (and maybe their failure) and gets momentum about finishing the experiment and turning it into reality. That experimentation will light a fire under GNOME’s ass and encourage new blood as well.

Kathy Sierra writes (draws) today:

It is Kathy, so of course, read the whole thing.

Note that the structure of the law (really, most the structure of most institutions) makes this very difficult. It is perhaps easier* for software developers to do this kind of individual, world-impacting innovation than in any other field, so go out there and take advantage of it- stop talking about GNOME 3.0, start prototyping the ideas that will be GNOME 3.0, and people will follow.
* subject to the need for servers if you’re doing web dev.

9 thoughts on “Dumbness of Crowds and GNOME 3.0”

  1. Her article can also be interpreted as we will not get to GNOME 3.0 without a BDFL type leader somewhere in the project.

    Personally these are the sentiments I agree with.

    Subset of GNOME community who will hack on something 3.0ish with full knowledge it wont be used in GNOME 3.0 – 3%

    Subset of GNOME community who will hack on something 3.0ish that is follwoing some approximate direction from a BFDL where their idea might actually end up in GNOME 3.0 – 9%

    Both small percentages but one is 3x larger. Why? Its not the blogosphere – its the egosphere. Many people blog and hack for the recognition and community acclaim.

    Conclusion. If a BFDL gives people a direction to hack towards there will be a stampede to get there, because there will be critical accalim to be awarded. With no top down direction people will mill about writing (yet another) iPod organising software text editor etc.

  2. I notice the chart is prominently lacking a ‘usefulness’ edge.

    I also didn’t see the methodology of the research that derived the charts. I am willing to take a guess that it was from the old ‘pull something out of your ass’ school. :)

  3. John: sure, but the only way to get a BDFL that people will follow is for that person to lead by doing. We can’t just have the board say ‘Steve Foo is the BDFL’- Steve Foo has to earn the position, and the only way to do that is by, well, doing.

  4. Luis,
    I agree, but more practically the choice of an appropriate BDFL is between what, 6-10 people?. I think the cost of that choice (organisational overhead, perhaps some community disagreement, chance of missed targets) is small, relative to the benefits.

    Hypothetically I would ask a non (hardout) coder like Jeff Waugh. If you dont want to call them a BDFL then call them a Topaz navigator or something. By being a non-core coder they could adress everyone without seen as questioning.

    As a new contributor working on an application that I hope solves some Topaz problems it has affected how I have approached contributing. For example I was more inclined to make an application than I was to contribute to some piece of core infrastructure. Why? Because the perception of the gnome stack is that it is slow moving and only incremental improvements and bug fixes will get in. Perhaps we are a victim of the “incremental updates are good” midset.

    I firmly believe that if there was a goal/s set by a BDFL-type-person, for example, “GNOME 3.0 will support saving sessions to file so that you can save and restore the tasks you are working on” than I would go and attempt to make more intrusive changes into gnome core. Because otherwise the perception is that such “desktop wide” more intrusive type changes will never make it in because they do not adhere to some yet-undefined grand unified 3.0 plan. There are a hell of a lof of cool patches languishing in buglzilla that will never get in because they do not fit with this non coherant future vision.

    GNOME has built a community around people that like and believe the same thing. That community and momentum is now in a holding pattern. Ubuntu built a community by giving them a goal and working the community towards it. I firmly believe that if GNOME doesnt get a figurehead to appoint some hypothetical goal then we will be in this same holding pattern in 18 months time saying “community people need to hack demos to show us stuff”.

    It has been >12 months since it was suggested that Topaz should be something). Practically I would say the current approach of waiting has not worked. Lets try something new?

    (note that in general my comments are aimed at exciting the younger newer GNOME hackers, not al of us can rewrite a new gnomevfs layer (like alex)!. All of my suggestions are about getting GNOME 3.0 to “walk before it can run”, and my predictions is that those first steps will be implemented by the fresher hackers working towards a plan, trying to get some acclaim for themselves in this world)

  5. Wouldn’t be a start to agree on a GNOME 3.0 mission statement? A couple of paragraphs defining the goal and the framework so the fresher hackers have some backed pointers to maximize their ego/exposure.

    We don’t need to get into deep planning loops to agree on a first version of this mission statement: what are the issues or opportunities that won’t be satisfied by the 2.x series and need a 3.0? The most relevant are enough.

    Clearing some doubts would be useful as well:
    – GNOME 3.0 implies GTK 3.0 yes or not (if yes, what does it mean)?
    – GNOME 3.0 implies a new desktop metaphor yes or not (if yes, what does it mean)?
    – GNOME 3.0 implies new methodologies or ways to organize the teams/community yes or not (if yes, what does it mean)?

    I haven’t followed the Topaz discussion, I’m sure there are many big doubts around that at least we could discuss aiming to agree upon.

    Once we have this mission statement let’s check if there are individuals / projects / companies with an interest in making this happen. If we reach this point it will be obvious who are the core people leading this effort. And hopefully we will start being in a point of no return.

  6. I’m constantly amazed by the GNOME 3.0 discussion in the community.

    I really wonder why people have what is basically a crisis in confidence in the current system with GNOME, when it’s turning out regular releases like clockwork, and (as far as I know) no good code has been turned away for being “too big a change” – the issue with 3.0 isn’t one of delivery, but one of design.

    Compare this to another successful project with the same issue – the Linux kernel. Will there ever be a Linux 3.0? Or will we be stuck on 2.6 *forever*?

    In the case of Linux, though, no-one seems to care. A version number is just that – a number. What counts is the code and innovation.

    There shouldn’t be this continual hand-wringing about how we get to 3.0. We should be strong enough to say that right now, 3.0 doesn’t matter.

  7. John, I think the call for GNOME 3 / Topaz is largely based on misconceptions.

    Enthusiasts are always itching for the bleeding edge, the clean break (that is probably also the source of so many misunderstandings between GNOME and OSNews). But, how many of the 145 GNOME modules listed by “jhbuild list” would really have to be broken for a different Desktop experience? The panel, the desktop (nautilus) and the window manager (metacity)? Or do you think some (wo)manpower will magically appear on the scene rewriting stuff like evolution or gedit? Hardly. Most of the infrastructure can be used for GNOME3 as is.

    Many people heavily involved with gnome are probably suffering from trained incapacity. What is so wrong with admitting a lack of ideas*) and giving fresh blood the possibility to do something completely new?

    *) Likely also caused by a lack of time to work on new ideas.

    Also you say
    > (note that in general my comments are aimed at exciting the younger
    > newer GNOME hackers, not al of us can rewrite a new gnomevfs layer
    > (like alex)!.
    You must understand that there is only so much room for hobbyists (referring to skills, rather than time or affiliation) to work on core modules. Do you really think somebody who is writing the Nth text editor or Mth music player would be capable to invent a new desktop metaphor under the “dictate” of a BDFL (Something usability experts have been failed in more than a decade)?

    Also what’s wrong core gnome people admitting they don’t have a vision for something better than the current desktop metaphor proven for over 20 years? And yes, many usability professionals have been trying something new but apparently a “breakthrough” that would /require/ throwing away what we know as GNOME now has not been made yet.

    In short, most people’s current visions can be implemented using the available libraries. A notable exception may be the OLPC’s “sugar” UI. But even most of sugar is based on existing libraries like cairo, (py)gtk, etc. Sugar is “just” the icing on many manyears of work, yet done by fulltime paid usability folks and developers (and an increasing crowd of volunteers). It’s just not as easy leapfrogging evolution.

    AbiWord developer

Comments are closed.