[draft] Planning for GNOME 3.0

[Vincent Untz <vuntz gnome org>]

Hey all,

Here's a draft of a mail about GNOME 3.0 to send to devel-announce-list.
I sent a earlier draft this morning to some of you already (there were
many notes that needed to be changed in sentences, though, so I didn't
want to make this too public).

FWIW, we need to publish the 2.27 schedule ASAP, and since the 2.27
schedule is directly linked to the 2.29 one (both will be published at
the same time) and to GNOME 3.0, Andre wanted hard to have some GNOME
3.0 stuff to explain the context and the plans. That's the goal of this
text.

Quick action is required since Andre wants to launch everything tonight
;-)

(btw, we can probably add a few links here and there to the text; we
just need to find them, so if someone has some free time...)

Thanks,

Vincent

-- 
Les gens heureux ne sont pas pressés.

Subject: Planning for GNOME 3.0

During the first few months of 2008, a few release team members discussed here and there about the state of GNOME. This was nothing official, and it could actually have been considered as some friends talking together about things they deeply care about. There were thoughts that GNOME could stay with the 2.x branch for a very long time given our solid development methods, but that it was not the future that our community wants to see happening. Because of lack of excitement. Because of lack of vision. Slowly, a plan started to emerge. It evolved, changed, was trimmed a bit, made more solid. We started discussing with a few more people, got more feedback. And then, at GUADEC, the release team proposed an initial plan to the community that would lead the project to GNOME 3.0. Quite some time passed; actually, too much time passed because too many people were busy with other things. But it's never too late to do the right thing, so let's really be serious about GNOME 3.0 now!

Let's first diverge a bit and discuss the lack of vision. If you look closely at our community, it'd be wrong to say that people are lacking a vision; but the project as a whole does indeed have this issue. What we are missing is people blessing one specific vision and making it official, giving goals to the community so we can all work together in the same direction. This is part of what the release team should do, and although many of us weren't there, we believe this is something that the release team did in the 2.0 days. The reason of why the release team stopped doing this is simple: it just happened that with our six months development cycle, the big plans became less and less important because everything (community, development process, etc.) was just working very well. But we've now reached a point where our next steps should be moving to another level, and those next steps require important decisions. That's the job of the release team. Please note that release team members don't have to be the ones who have the vision; they "just" have to be the voice of the community.

(As a sidenote, the roadmap process that we tried to establish two years ago was a first attempt to fix this. Unfortunately, it turned out that we were missing the most important side of things: a project-wide roadmap. This is because a collection of individual roadmaps isn't enough to create a project-wide roadmap.)

So let's go to the core topic and discuss what the GNOME 3.0 effort should be. We propose the following list of areas to focus our efforts on:

Note about how long-term goals are how we handle things now

 - Evolution of the User Experience
 - Streamlining of the Platform
 - Promotion of GNOME

There are also other potential areas that are worth exploring if there is enough interest from the community.

From a release management perspective, there are various questions that are raised in the GNOME 3.0 context. We definitely need a plan to organize the development (see below for details on it), but we might also want to take this opportunity to rethink how we ship GNOME: are the module sets still the best way to deliver GNOME? There is no obvious answer to this, but the way we will present GNOME in the future will certainly have an impact on this.

*Evolution of the User Experience*

When talking with some great people at GUADEC about GNOME 3.0, one concern that came more than once was that it would be an error to do GNOME 3.0 without any big user-visible change. While some of us didn't necessarily agree with this concern, it was still a fairly valid one. But it turns out that if you tell the community that there's something after 2.x, then the community will stop vaguely thinking about future ideas and start working on concrete plans.

It seems pretty clear now that there are two important ideas that can have a real positive impact on the user experience:

 - GNOME Shell: the shell idea is not just about changing the panel and the window manager. It's about changing the way you start an activity and how you switch between two different activities. Or more generally, how you manage your different activities on the desktop.

 - Changing the way we access documents (via a journal): having to deal with a filesystem in their daily work is not what makes users happy -- on the contrary, they generally just want to access their documents and not to browse their hard disk. Providing new solutions to this problem (using timelines, tags, bookmarks, etc.) is something that has been of interest in our community for a long time, but we never completely jumped in. We simple should.
 
There's one obvious question related to those potential changes: what will happen to the old way of doing things? For example, will we still make the GNOME Panel available if, for some reason, people are not immediately happy with GNOME Shell? There's no obvious answer to this, and this will have to be discussed. Some of us believe that it would be a good thing to keep providing the old elements for a limited time, to ease the migration. That being said, doing that would obviously take some development resources and slow down work on what should be the future. Not an easy choice, of course.

*Streamlining of the Platform*

Since GNOME 2.0 was released in 2002, there have been quite some changes in our developer platform: new APIs have landed and some other APIs have been deprecated. There are even some platform libraries that are now nearly unused. This just creates some confusion and does not make the life of developers easy. Since we want applications to be developed for GNOME, this is an issue that we should fix.

Hence, it makes perfect sense to rework our platform and try to clarify it for newcomers. Here are some steps that should be considered:

 - move all of the deprecated libraries out of the platform, so people stop using them in new code;
 - create a staging area in the platform for libraries that aim to be in our platform but do not offer enough guarantees at the moment (like GStreamer): this will send a clear message on what should be used;
 - rework the way we present the platform to also integrate some of the external dependencies: while, say, D-Bus or Avahi are external dependencies, they are definitely what we want developers to use. And it's easy to be more explicit about this.
 - move the bindings closer to the platform when we talk about bindings, to make them even more visible and attract developers from all languages.

All this has of course an impact on our applications: we will have to port the code away from all deprecated APIs, but also prepare our applications to be ready for forthcoming changes, like GTK+ 3.0. This is luckily a task that we can easily quantify and the progress can be tracked on a simple web page.

*Promotion of GNOME*

Our community has historically been strong on the development side, but we have always struggled to promote GNOME. That's because this is certainly no easy task. Our user base has however grown significantly since our project started, and we failed to recruit people that could have helped here. GNOME 3.0 is an opportunity to change this and attract contributors that can help forge the communication around the GNOME project. The promotion of the project is definitely part of what makes a good release, and the marketing team can contribute a lot to the success of 3.0.

Of course, an obvious goal for the promotion of GNOME in this context would be preparing the 3.0 release and the messaging around this release. After highlighting the changes done specifically for 3.0, one other immediate idea is to simply show the progress the GNOME project has made since GNOME 2.0: GNOME 2.10 could arguably have been named 3.0 when compared to 2.0, and the same goes for 2.20. This could serve as a basis for work on explaining why our evolutionary approach in development works well.

One common issue that often came up when discussing how to promote GNOME was that promoting the desktop as a whole is difficult. But there's no need to do that. We can instead focus our messaging around the GNOME experience: the basic GNOME experience simply is the GNOME Shell; but users actually do not use just the basic desktop, and they launch applications. We've never explained why the applications developed for GNOME are good; we've never really put those applications under the spotlight. For instance, why shouldn't we put on the front page of the GNOME website a clearly labeled message about a good music manager? We wouldn't have to choose between Rhythmbox or Banshee: we can promote both, since both are good in different ways, and both are good examples of the GNOME experience.

This leads us to a third item: relaunch our website. While our current website is known for being broken in various different ways from a communication point of view, we've not been able to deliver the new version that would fix things. Fixing the website is a large task, but we should not give up on this: the GNOME website is a core part of the GNOME identity, and we cannot ignore the current issues. This happened because of lack of manpower, but the good news is that there are web developers that are fond of GNOME and just don't know they can help the project.

And the fact that web developers can play an important role is also valid for all of our users. As of now, we are not really empowering users to promote GNOME: what should a user do if he wanted to do so? We all know how some viral communication can benefit a project like ours, so the solution is simple: let's give ourselves a chance to make this happen!

*Other Potential Areas*

The areas presented above are actually not a big surprise to anybody following the GNOME development and are fairly obvious choices. However there are other candidates that would help make GNOME 3.0 a success. Those potential focus areas simply need people to step up so we can be sure expectations can be met.

 - Desktop Testing: with the recent creation of the Desktop Testing Team, this topic becomes more and more visible. We can innovate there, and we actually should: we helped show the way in the free software world when it comes to usability and accessibility, and there is no reason for us not aiming at a similar experience for desktop testing.

 - Art: with the recent GTK+ Theming API hackfest, some good consensus was reached on how theming should be done in the future. This gives us a new opportunity for an updated look and feel. This can happen with the help from artists: if we have artists and coders working together, with the coders knowing the needs from artists, then there is no doubt that the result will simply rock.

 - Mobile: the mobile team could do something if they want. Make the mobile platform more attractive. Simplify the communication around it.

*Organizing the Development*

We need to define a clear timeline for the development, with a schedule that will let us check that the development is on the right path. The end goal is simple: we want to deliver GNOME 3.0 by the time of 2.30 release. This makes sense for various reasons: from a technical perspective, the timing is good for the integration of new technologies or projects (GNOME Shell, for example); from a messaging point of view, the evolution from 2.30 to 3.0 is logical and easy to understand. It's worth pointing out that if you compare GNOME 2.26 with GNOME 2.0, it's actually quite surprising to see that we have still kept a 2.x version numbering while we could be at 3.x, or even 4.x. Making GNOME 2.30 a 3.0 version is of course still an ambitious goal, but we can achieve it thanks to what we learnt in the past.

The development methods we have adopted during GNOME 2.x are overall good methods and the community has become used to them. For example, contributors understand the reasons behind the freezes we have and try their best to respect those freezes. This is not something that should be changed because we now have an opportunity to try something else; on the contrary, those methods will make our path to 3.0 easier. Some regressions were pointed out during the past few cycles: those should not be ignored and we believe part of the reasons why they happened is that only a subpart of our community was trying to move forward; having a community-wide focus should limit the number of regressions.

The six months cycle is now part of our culture and has an impact on the free software ecosystem, with distributions basing their schedule on our schedule. Trying to change this crucial element of our release management, which works quite well, would certainly not help us in any way. Therefore, we will keep six months-based schedules. But having project-wide and long-term goals require some adaptation. GNOME 2.28 will not be an independent release or a destination in itself, but it will be a logical step towards GNOME 2.30, and therefore GNOME 3.0.

Of course, we should be prepared to consider the fact that GNOME 2.30 might not be good enough for us to call it 3.0. This is something that we should be ready to diagnose early on during the 2.29 development cycle and if we feel strong about it, we should not be afraid of keeping GNOME 2.30 as 2.30 and waiting for GNOME 2.32 for the 3.0 release. That being said, we want the community to try as hard as possible to make "GNOME 2.30 = GNOME 3.0" a success.

On a more general note, overlaying a long-term development cycle (3 years for example) with project-wide goals, on top of our six months development schedules is something we want to keep after GNOME 3.0.

*Conclusion*

We're getting there. We strongly believe that all this can make a good plan for GNOME. Sure, it's not perfect. And there will be disagreements and issues along the road. But it is the way forward.