This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex

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:

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:

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:

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.

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


2024-10-23 11:48