Three Point Zero

A wedding and honeymoon have kept me away from this conversation so far. My apologies if I’m beating a dead horse here, but I’ve got to weigh in.

Three point zero without compelling new features is suicide.

If we release a 2.x Gnome as 3.0, we will get close to zero positive press coverage. Forum dwellers will declare Gnome a dead-end, even those that normally defend our small evolutionary releases. Users won’t bother trying it, if they stick with Gnome at all. Potential new developers will become disillusioned with what they perceive to be a boring project. Sulfur will rain from tke sky. Demons will possess our household pets. Disco will make a comeback. Tragedy of tragedies.

If I were some sort of release manager, I would solicit ideas and set a plan. This requires leadership. Somebody has to be willing to say “the buck stops here”. And the community has to be willing to listen to that somebody. Here’s a rough outline of how to set this into motion:

Brainstorming:
Ask the community for ideas. We’re not looking for solid plans here. We want people to toss about all those crazy ideas they’ve had brewing in their heads. Don’t worry about feasibility at this stage. Just write what you’re thinking. Maybe include some ASCII-art mockups.

While we’re at it, get those incredible designers of ours to GIMP together some mockups of how future Gnome should look. Use your imagination. Stir things up. Go wild.

Discussion:
We all come back down to Earth and start discussing these ideas. The whole community is involved in this. We discuss what we like and what we dislike. We talk about feasibility. Developers start talking about plans for how to implement the ideas we like. Yes, we’ll get some bike-shedding. That’s inevitable in a community as big and diverse as ours. But since we have a heroic somebody (or somebodies) to make real decisions, it’s OK. Let people get their thoughts in.

Evaluation:
The release managers make decisions on the ideas. Put everything into one of three categories: Yes, Maybe, and No. The Yes projects are those we write our schedule around. The Maybe projects would be nice, but we’re not going to wait for them. Collect concrete plans from maintainers and developers about how they’re going to do the things they do. Get time estimates. Set a schedule based on those time estimates. Make a decision. This is the part where the community needs to suck it up and recognize that, without somebody making decisions, we won’t get anywhere.

Hacking:
We all make branches and hack away. If you’ve got big things to do for 3.0, leave trunk for continued 2.x development, make a gnome-3-0 branch, and go wild. Hey, this is the part we do best. Enjoy the thrill of hacking on exciting new features. Feel young again.

Brainstorming needs to last at least a month.  Discussion should last another two or three months after that.  And the hacking phase needs at least a year.  If we time it right, we could have a little over a year and take advantage of two Summers of Code.  When we set the schedule, we should set a firm cutoff for new features, but set a slushy 3.0 release timeframe.  Once we’ve hit the freeze, we can re-evaluate things to see how long it will take to get a solid 3.0.  The last thing we want is a 3.0 that’s not really ready.  After all the alphas and betas, make a “developer preview” release that’s almost a 3.0.  Then give everybody a bit more time to polish, document, and translate.

Then, of course, there’s the question of what kind of ideas we’re looking for.  The question is not “Can we technically do this in 2.x?”  The question should be “Does this kick enough ass to justify calling it 3.0?”  Here are some examples:

Platform Enhancements:
Things that offer our developers cool new ways to develop applications.  Havoc talked before about basing GTK+ on a scene-graph system.  Even if that could be done in 2.x, it’s so wicked cool that it deserves the point-oh buzz.  How about an embedded scripting framework?  Or a powerful declarative interface language?  Combine those last two and you could have a really awesome rapid development framework.

Cool New Features:
We’re looking for features that provide a real and obvious enhancement to the user experience.  One possibility I’ve heard lately is a blingy unified desklet/applet system.  If I sat and thought long enough, I’m sure I could come up with others.  Fortunately, the community will gladly provide ideas if you ask them.  We’re a creative bunch.

 Pervasive Ideas:
There’s no shortage of new paradigm ideas in our community.  How about web services integration?  For any given application, it’s just some neat new feature.  But if we do it to 90% of our applications, it’s serious buzz material.  Then you have various projects that are working on people-oriented interfaces.  Lots of buzz, but it needs drive to push it throughout the desktop.  Semantic desktop.  Task-oriented interfaces.  Natural language interfaces.  Whatever.  Have a grand vision?  Sell us on it.

We have some extremely talented hackers in our communities.  We have some incredible designers.  We have the world’s best translation teams.  And we have a lively community of users and enthusiasts with some really great ideas.  What we need is direction, and direction requires leadership.

Creative Commons Attribution 3.0 United States
This work by Shaun McCance is licensed under a Creative Commons Attribution 3.0 United States.