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 general impression that GNOME is lacking a 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. In the pre-2.x days, the community accepted as a whole one specific vision, and such an explicit blessing wasn't needed. But during the 2.x cycle, with our six months schedules, it appeared that everything (community, development process, etc.) was just working very well, and as the vision got more and more fulfilled, the long-term plans became less important as we focused on polishing our desktop. But we've now reached a point where our next steps should be moving to another level, and those next steps require important decisions. This is part of what the Release Team should do. Please note that Release Team members don't have to be the ones who have the vision; we "just" have to be the voice of the community.

(As a sidenote, the roadmap process that we tried to re-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:

• Revamp our 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.

Changing our 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, like GNOME Zeitgeist): 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 simply should.

These two ideas can form the basis of an overhauled GNOME user experience; they are not the only changes that we can and will do, but they definitely are the most advanced projects to help us move forward in terms of user experience. The GNOME Shell and the GNOME Zeitgeist projects are indeed already well underway, with working code and strong development going on for nearly six months. This means the effort is not about starting those projects, but about first completing them so that people can work daily with them, and then polishing them.

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. However, it's worth noting that distributors and other community members using GNOME to build enterprise products will most certainly help maintain the GNOME 2.x shell for quite some time, and the project will support that to the greatest reasonable extent.

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;

• include new exciting technologies that we're starting to see used in our desktop. Some obvious examples are 3D effects (with Clutter) and geolocalization (with GeoClue and libchamplain).

• 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.

The work that has been done on GObject introspection will also deeply change the way GNOME development can be done; we've already started to see how it can be leveraged in GNOME Shell, and the fact that it can bring new popular languages like Javascript to GNOME is a huge benefit.

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 use 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: a GTK+ Theming API hackfest was held in February, where 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.
• People: the telepathy framework has nicely progressed over the last few years and it's offering great perspectives to integrate instant messaging, and more generally, interaction with people in other applications. With some focus, it could contribute to make GNOME a social desktop where you do not only work on documents, but where you also really interact with your friends.
• Mobile: the GNOME Mobile platform was first introduced in GNOME 2.24, and it helped make our presence in the mobile world visible. A lot of the changes that are planned around the platform are of direct interest to The Mobile Team.

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, which created some controversy; having a community-wide focus should limit those controversies, and hence the regressions as felt by the community.

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. All of our time-based releases are also quality-based releases: if the QA Team feels a release should be delayed, then it will be delayed. In the context of 3.0, this is something that we should be ready to diagnose early on during the 2.29 development cycle and we should not be afraid of keeping GNOME 2.30 as 2.30 and waiting for GNOME 2.32 for the 3.0 release, for example. 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

You can already check out the schedule for the 2.27 and 2.29 development cycles: it contains some concrete steps and deadlines that will help keep our work focused to make GNOME 3.0 a reality.

As already mentioned, this is an ambitious plan and it will only be realized if everybody comes out and helps. Companies can contribute a lot -- for instance, the GNOME Shell effort is doing great thanks to Red Hat's involvement. But GNOME wouldn't even exist without all of the volunteers who are passionate about the project. It's because this passion is so strong that we can build such a plan!

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.

The GNOME Release Team