Category: roadmap

I promissed myself to write this series of blog posts a long time ago but now that Andy talked about GNOME’s decadence just before GUADEC, I thought it’s the right time to write this. :-)

I totally agree with Federico when he wrote on our Annual Report 2007 that GNOME has achieved its original goal. We reached a point where we have a desktop environment that “Just Works” for most of common tasks on a personal computer. However, it’s been some time already that having a desktop environment that just works is not being “enough” for our community and GNOME as a project. The symptoms of this collective “agony” show up every now and then in form of a bunch of random ideas about how to re-think the whole interaction model of GNOME, endless discussions about our 6-month development cycles, the urge to deprecate certain jurassic libraries, long conversations about the definition of GNOME itself, harsh comments about GNOME not having a clear direction, lack of leadership inside the community, and many many others. Those topics have been around for a long time (just Google them and you’ll find quite a lot of old threads on GNOME mailing lists) but we haven’t been able to translate them into a clear direction for the project. In my opinion, this has a strong relation with how we’ve been organizing ourselves since GNOME 2 release and the more fundamental goals of the project.

So, is GNOME in a state of decadence? Yes! Is it a bad thing? Not necessarely. It depends on how we react to this situation from now on. Why? Because what is in decadence is not GNOME itself (we are a great project with the coolest community!) but the current form of GNOME. Before going straight to the nasty problems and some of the core aspects of the current situation,  I’d like to first talk about the most important achievements of our community so far which, in my opinion, we should be really proud of and try to keep in some way. Those achievements are beyond the more obvious one of having developed a great desktop environment and development platform. They have more to do with the way we do things.  They might be obvious for a lot of people in GNOME but I think it’s important to mention them anyway.

The first and more important achievement of GNOME is our community. We managed to agregate, through the more than 10 years of project, hundreds of extremely talented and generous contributors. Not only that, we have also consolidated a very positive and welcoming atmosphere inside the community which makes it a very nice group to belong, have fun and hack on cool software. Another important aspect of our community is its diversity. We have volunteers, employed developers, companies and non-profit organizations from all around the world, working together in the same ecosystem. Additionaly, we have a relatively large user base which helps us to improve our software everyday. We gained trust from highly relevant stakeholders who use, develop, extend and deploy our software stack in contexts ranging from social inclusion projects to large public/private corporations. From my perspective, our community managed to grow and mature so much through the years because of our development process and the some fundamental principles that tacitly (and sometimes explicitly) defines GNOME software. That brings me to the next two important achievements of GNOME: development process and usability culture.

Even though I wasn’t there (I started to contribute to GNOME in 2004), it’s pretty clear that the GNOME 2 release was a moment of important changes in the community and the development process itself. The release team was founded to coordinate the development process and turn the collective work inside GNOME into a saner thing. Since then, we’ve learnt a lot. The general guidelines have evolved in such a way that nowadays we have a mature, stable and predictable development process which is relatively easy to understand,  efficient on the coordination of contributors with different levels of engagement and availability and scalable enough to deal with hundreds of software components. The efficiency and scalability doesn’t come from nowhere: they come from the fact that we develop software in a distributed way. GNOME developers dedicate their time to improve specific domains inside the project. Our collaboration dynamics is set in such way that individuals can have a lot of influence in GNOME in relatively short time. Unfortunately, the same development process and collaboration dynamics that bring so many benefits to GNOME also have some serious drawbacks (which I’ll talk about later).

Lastly, in my opinion, the usability culture inside GNOME is one of the most important assets of our community. We care about the users. There’s an implicit urge (explicitly expressed in our UI guidelines) among contributors that every piece of user interface should be as much intuitive as possible. We can easily recognize what has been done in a GNOMEy way or not. There’s a relatively clear understanding inside the community of how things should be done that is passed forward to new contributors everyday. Considering the distributed nature of our development process, having stabilished such a culture in GNOME is a great achievement! Even though this usability culture is something that strongly defines the way we do things everyday in GNOME, I think we haven’t taken full advantage of that as a way to re-define the direction of the project. Again, more on that later. :-)

I’m sure people will have different opinions about those achievements, what’s more relevant, what’s irrelevant, etc. That’s great. The bottom line here is to recognize that we’ve been doing a great job. Really. Those are achievements that we should try to maintain, improve and adapt depending on our needs. There are big challenges ahead though. Next post: the nasty problems and the urgent need to change.