Just booked my flights to Istambul. I’ll stay at the Golden Horn Hotel (Sirkeci). I’m sure I’ll have an amazing time at GUADEC. Yay!
Ok, now that I’ve already made my point about our great achievements, it’s time to talk about the big questions. I ended up writing too much, sorry :-P I won’t discuss about solutions or practical actions in this post because (obviously, I don’t have all the answers and) I prefer to separately talk about solutions and practical actions in another post. I’ll try to bring the topics that have been looping in my head (for a quite long time already) with regards to our beloved project. They overlap in many ways with the opinion of some people who have already commented on the “decadence“.
One the most important steps on the process of finding a good solution for a problem is to define the problem. People have different expectations and perspectives about GNOME and hence they define the “decadence” and, consequently, the possible solutions, in different ways. First of all, a more fundamental question: do we have a problem? We already have a great desktop environment for the current standards and demands. So, what is “wrong” here? From what I can see, the problem can be defined in terms of three aspects: Audience, Position and Process. All those have something to do with the fact that GNOME is getting “out of sync” with… something. I fully agree with Rodney, Havoc, Mikkel and others here: the whole desktop concept itself is some sort of dead-end (even though we could be innovating much more in this area) and is, in a certain way, getting outdated (considering the new ways people have been using technology nowadays). Because of that, I think it’s quite dangerous to exclusively stick with the “desktop” goal because we may be missing a lot of opportunities (and even get into an actual decadence situation) in the near future if we keep doing the same things in the exact same way. (One might argue that we already have GNOME Mobile and all. However, I’d say that this is not enough because 1) the mobile front has been done in a kind of “marginal” way inside the project 2) “mobile” is just one among many possible paths). So, yes, we do need to open GNOME for a whole new range of possibilities in a consistent way but first we need to create the right environment for innovation.
Anyway, let me talk about each part of this problem. Those might sound a little abstract sometimes but, in my opinion, they summarize the big questions we need to answer now.
Audience is about who we’re targetting and, consequently, the fundamental definition and goals of GNOME. I’ve just said that we already have a great desktop. However, we can see quite often people complaining about the lack of innovation, the need for new apps and more eye-candy, and so on. Consequently, we have quite often those endless discussions about the future of GNOME and where we should be heading towards: 3D desktop? Online desktop? Corporate desktop? Topaz? The thing is: everyone is right in a way. Why? Because we don’t have a clearly-defined audience (something that Havoc said 3 years ago).
- Is it doable to stick only with development a desktop environment in GNOME?
- Which kind of desktop do we aim to develop? A corporate type? A media experience type? Something else? Do we really have to choose?
- Are we responding properly to the demand for the creation of custom user experiences (for distros, mobile devices, online services, etc) with a consistent, productive and powerful software platform?
About 1 and 3, yes, we have GNOME Mobile – which aims to provide a standard architecture and platform that can be used by companies to develop GNOME-based mobile devices. But how strongly does GNOME Mobile define GNOME as a whole? There are some good lessons we can take from GNOME Mobile in terms of development process and organization (more on that in the next post). It’s pretty clear that the strongest point of connection between GNOME Mobile and GNOME is our platform. However, GNOME Mobile is not working as integrated as it should inside GNOME because we still define us as a “desktop project”. So, my short answers to those questions are:
- No, we should expand the definition and goals of GNOME to embrace the diversity of ways people are (and will be) using technology today (and in the near future).
- I don’t think we need to choose. What we need is to clearly define and maybe separate different products around different GNOME audiences.
- No, I think we’re not properly organized to provide a powerful platform for different user experiences because, as I said, we still define ourselves as a “desktop project”. In my opinion, the platform should be the core of GNOME and GNOME Mobile should be closer and share more inside the major activities of the project.
The Audience issues presented above have a tight connection with the relationship between GNOME and distributors. That takes me to the Position issues.
Position is about where we place GNOME in the innovation ecosystem. So far, the relationship between GNOME and distributors is so that we release our official modules (organized inside the desktop, platform, admin, devtools and bindings suites) and distributors adapt and package those modules to integrate in their systems. Normally, they also add a bunch of modules that were (fully or partially) developed with GNOME platform but are not officially part of GNOME suites. Then, when everything is integrated and stable, distributors release their products with GNOME. This model has two interesting aspects.
The first one is: GNOME is invisible to users. From end-users perspective, they are using Ubuntu, Fedora, openSUSE, Foresight, Debian, Gentoo, (add-your-favorite-distro-here) on their personal computers, not GNOME. (Note that I’m not talking about geeky users but about real end-users who don’t know much about technology). This is (and will be) even stronger on consumer products using GNOME platform such as internet tablets, cell phones, PDAs, etc. To verify that, just pretend you’re just an end-user and have a look at the websites of most of desktop distros: they talk about desktop but rarely mention GNOME. (Note that I’m not making any judgements about this here. I’m trying to just bring the fact to the table).
The second aspect is that distributors redefine the user experience. Most of distributors change in some way the default GNOME desktop to fit and integrate nicely with their products. openSUSE has a completely different panel layout and use gnome-main-menu. Most of distros use Firefox instead of Epiphany. Latest releases of the major desktop distros ship with Compiz by default instead of Metacity. Also, they integrate desktop modules that are not directly provided by GNOME: Pidgin for instant messaging, Rhythmbox or Banshee for music management, F-Spot or GThumb for photo management, Beagle or Tracker for desktop search, and the long list continues.
So, based on those aspects, what can we say? First: even with our current development process where we release suites of official modules to distributors, it’s not clear inside GNOME whether we are “user experience definers” or “component providers for custom user experiences”. Currently, we’re defining most of the desktop user experience through our official modules. However, because of the way we define our final product (the suites of official modules) there are certain areas where we simply don’t reach an agreement (more on that later). Why haven’t we ever chosen a “official” music player? Why no photo management app in the desktop? Gimmie or gnome-main-menu or just keep the menu bar? Why is there so much discussion around the inclusion of Empathy? The fact is, for some reason, there are certain topics around the user experience that we just prefer to not decide about. This makes us stay in a unclear position: we kind of define the experience – but only on certain topics (this has a lot to do with the lack of a defined audience and our development process). That brings me the following questions:
- Should GNOME be a “user experience definer” or “component provider”? Do we need to choose?
- Does the GNOME decisions about the official modules really matter? If so, at what level?
My answers to those questions are:
- We should be component providers – but in a special way. In my opinion, we should platformize the user experience in a way that our modules can be easily reused in different contexts or products. In practice, this means: providing highly configurable and pluggable core components; well-defined services D-Bus APIs so that we easily replace compliant implementations with same interface; refreshed toolkit which embeds sexy UI elements and interactions; and more. In order to properly be component providers, we would need to provide a super-powerful platform though. Yes, that would be a big challenge (more on that in the next post).
- Yes, our module decisions matter. But they only *really* matter if they are related either to platform or to the “core” desktop components (panel, session, nautilus, keyring, settings daemon, capplets, etc).
So, in reality, the ecosystem around GNOME is demanding a lot of flexibility in the platform and desktop – specially from stakeholders producing mobile devices and other custom user experiences based on GNOME. We need to clarify our position and goals inside this ecosystem so that we can embrace all the great possibilities we have inside our community. We should redefine GNOME as a platform for intuitive and exciting user experience with several reference products for different audiences around it. In order to redefine the project, we need to rethink the way we do things. Let’s talk about the Process problem.
Process is about how we do things. As I said in my last post, the same process that brings so many benefits is the one that’s making GNOME stall somehow. Why? Because our current process is organized around the fact that we’re in deep maintenance mode. Actually, in a way, we’ve been in maintainance mode since the 2.0 release. The main problem with this mode is that all decisions in GNOME are done based the tacit assumption that we should never break anything (as if the maintenance mode is a given). This brings a very good feeling that everything is stable and predictable most the time. And that’s very true actually. However, having stability (in sense of “no big changes so everything works, cool”) for a too long period is boooooring and brings all the problems of Audience and Position (because with technology, everything gets outdated very quickly). Let me talk about some aspects of this maintenance mode in GNOME
The first one is that we don’t have a “big picture” to base our decisions on 2.x. Yes, we are basically “adding or replacing stuff” in the same good old stack for quite some time already. The problem here is: the big picture of 2.x is kind of “done”, “given”. We’re basically in passive mode, just waiting for contributors to decide to propose and include random modules in one of our suites. Some people may argue that we’re constantly improving the platform and desktop by revamping certain components every now and then and that shows we’re moving the project forward. In my opinion, this is not entirely true. Yes, we’ve been doing some nice improvements in 2.x but the requirement to never break anything (associated with the Audience and Position problems) almost completely blocks innovation inside GNOME and very often moves the cool innovation work to distributors side (because they can break and change anything as they want anyway). And, unfortunately, many times we end up not being able to accept distros’ innovation work because we can’t break anything. Note that I’m not saying that stability is bad. My point here is that we should have official long-term break points in GNOME. That would be an enforcement for the community to rethink the big picture from time to time (and not wait for some magic “vision” to change the direction of the project).
The second aspect is the decision making problem. In our current organization of the development process, no one has the official role of deciding about the general direction of the project. Some people say we have a problem of leadership in GNOME. This is partially true. We have the core contributors who are the ones who define the project’s direction in practice. So, we have leaders. However, this leadership is quite fragmented and doesn’t have any official position in our development process. Therefore, the real problem is in the process: the release team is responsible for maintaining the correctness and coherence of the development but not for defining the content. There’s no one in charge of getting the big picture and proposing a development agenda. We need to accept the fact that we need domain/suite maintainers who are responsible for proposing and having the last word about the content and roadmap for certain domains/suites. The recent Roadmap process was a nice achievement on spreading the word (inside and outside our community) about what we’re doing. Not enough to drive the project to a new direction because we’re in maintainance mode after all.
Lastly, the maintenance mode involves a specific definition of our suites and hence the way we deal with third-party applications. The current definition of our suites is too closed and not so flexible. There’s a large amount of apps being developed based on our platform that are simply ignored by us. Of course, there’s is a lot of crappy stuff our there but, on the other hand, there’s a good number of high-quality GNOME-based horizontal and vertical apps (photo managers, media managers, recipes managers, book collection managers, stock managers, web widgets, sexy panel replacements, etc) that we don’t keep close to us in any way. Because of that, we miss the opportunity to get more contributors and all the potential sinergy that those apps could bring to GNOME and our distributors. We need to provide a more clear and interesting place for high-quality third-party apps in GNOME. Those apps are an important part of our innovation ecosystem.
So, from my perspective, considering those three aspects of the problem (Audience, Position and Process), a good solution for it should involve:
- Expading the definition and goals of GNOME in order to embrace the diversity around us;
- Defining clear audiences for our products;
- Redefining the position of GNOME inside our ecosystem so that we bring innovation inside through a powerful platform;
- Rethinking the development process so that we can: a) have an efficient decision-making chain b) “think from scratch” and break things from time to time c) bring third-party development closer to us.
Also, it’s pretty clear to me (and I know other people agree with me) that GNOME 3.0 should not be just “a next generation desktop” but a new way of defining, organizing and developing GNOME. I’m pretty confident that if we do it properly, innovation will naturally take place. Yes, I know that there are big challenges involved here in terms of resources and community consensus. But those are part of any big change. One of the goals of this post is also to try to propose a (kind of) well-defined set of topics for this “decadence” discussion.
I know that dealing with all questions brought here involves a huge amount of work. However, if we manage to respond in practice at least to a good part of those, I would be extremely happy. :-) Therefore, it’s quite important that we take the opportunity brought by this discussion to draw some concrete proposals for GNOME 3.0. In my opinion, the Release Team has an important role on the coordination of the discussions about the needed process changes and the GNOME Foundation Board should support the community by sponsoring hackfests, bringing advisory board members to actively participate on this discussion, and much more. Coincidentaly, I’m part of both (yay!) and I’ll do my best (together with my fellow release team and board members and the community in general) to make this happen. Honestly, I don’t know yet when I’m gonna write the next post about possible solutions and practical actions because, just like my evil twin, I’m still “still working with some great people on expressing our opinion in a understandable way”. I’m sure GUADEC will be a great opportunity to boost this discussion.
If you read all this, you’re my hero! Thanks! :-)
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.