Roadmapping GNOME

Yesterday I mentioned GNOME’s time-based releases. But what about aims?

The RoadMap

We can aim for features while still doing time-based releases. The time-based schedule just releases whatever features are ready on time. If people feel there’s now a lack of long-term vision, well that’s not caused by our current release process. On the contrary, now that we don’t have to worry about how to release stuff when it’s ready, we are free to worry about what we want to actually implement.

Over the last two years, we’ve tried to do this via the RoadMap on the wiki. It’s been better than nothing, and it’s gradually getting better. I’m glad that Lucas Rocha is pushing it again, so we shouldn’t stop that effort. But I don’t think it’s working out quite as hoped. I wonder why this is. I can guess at these reasons:

  • Not enough awareness:
    People don’t know it’s there, and people forget that it’s there. We’ve had the same problem with the ReleaseNotes pages, which list features already done, which should be easier. How could we dramatically improve this?
  • Not enough agreement:
    Naturally there are some differences of agreement about how to achieve things. For instance, dependence on Mono splits us down the middle. But there’s no harm in stating what different large groups are working on, even if they appear to be working towards similar goals.
    And I think there’s plenty that we do agree on, even at the technical level. For instance, increased use of Avahi and Telepathy.
  • Implementation takes time:
    We often know what kind of features we want, but we can’t be sure about which implementations will be best for that. The more important it is, the more cautious we are about locking ourselves into technologies that might not be good enough. I think we need to list them as candidates anyway, and provide some criteria for eventual acceptance. And we need to be patient because good work does take time. But if we list them, there’s more chance that people will work on them.
  • Reluctance to lead:
    The road map would probably be more coherent if it was regularly updated by particular people, as part of our schedule, rather than being occasionally updated by whoever looks at the wiki. It’s best to get the plans directly from the maintainers, but they aren’t all doing that now, and that isn’t providing a coherent plan across modules.
    We’d have to be very careful because there is at least a perceived risk that this could be hijacked by someone who didn’t represent the consensus, pushing their own agenda, or it could fail under someone unreliable. We’d have to be very careful to stick to what we agree on, and be diplomatic about what we don’t agree on, much as the release-team is when deciding on new modules. And we’d need to demand that it gets done regularly.
    I find this scary but it’s probably worth a try.

However, I absolutely do not believe that you can point at our mailing lists and say that we lack decisiveness because there is too much discussion. Discussion and open development are valuable quality controls to us, and should not be scape-goats for real disagreement and lack of diplomacy. That’s the same knee-jerk reaction that assumes that open source could never get anything done. We know that’s wrong.


As a start, I’d like to see sane people suggesting their own medium-term road maps for GNOME, with some expected implementation details. This should not include wild vague silver-bullet notions with no connection to reality and no awareness of past mistakes. It should include things that are genuinely useful to users, admins, and developers, rather than change for the sake of change or buzzword compliance. This should be stuff that we would like to do and that we are fairly sure we can do, and that we are probably working on now.

And I’d be happy to see different plans, aiming at different target markets, or different plans based on clearly different implementations. Just keep it positive and fun and let the good stuff show through . If enough people do this then we should be able to pull out the best pieces to make some attractive shared visions.

I seem to remember Havoc and others doing this around the GNOME 2.0 time. So who are the new Havocs? I know we have a few.

9 thoughts on “Roadmapping GNOME

  1. Dude, good points! I’m already working with Vincent (and the release team) to have a clear roadmapping process to address those issues for the next releases. I hope we’ll have an announcement in the next days. :-)

  2. Regarding the lack of decisiveness or the perceived lack of decisiveness: I follow the mailing lists pretty close and I get the feeling that GNOME is not the type of project with a so called strong leader.

    Maybe that’s why people regard the GNOME project as lacking decisiveness?

    It seems to me that there is a tendency towards consensus, almost so that consensus is more important than doing something. That is how I see, not necessarily like it is.

    Hopefully, GNOME will not become like Debian is today.

  3. “I’d like to see sane people suggesting their own medium-term road maps for GNOME, with some expected implementation details” — cool. This is what we were calling for on the last LugRadio episode, which prompted Dave Neary’s post in which you and I disagreed on whether there was decisiveness or not. I completely agree that discussion (and indeed precisely that sort of disagreement!) is great; the idea of someone standing up and laying out their plan, as you’re also asking for, is (I think) pretty important too. At the moment there’s not a clear direction (at least there isn’t as far as I can see), and it’s for want of people stating a direction. Let’s hope lots of people take your advice and start talking about where and how *they* want Gnome to go.

  4. It would be nice if you guys had a page where people could suggest ideas/annoyances/features/etc that they want, and other users can vote on them if they wish. Make it username/password based so there isn’t abuse and make clear rules saying that ideas can be deleted if they are unrealistic or stupid etc. It would give gnome developers a good idea on what the average gnome users wants. I think it’s hard for developers to come down the the users level sometimes, this would help bridge that gap.

  5. Abbas, we have bugzilla. Yes, it’s not that friendly because it’s huge, but a general “annoyances” page would be just as huge if it was actually used. That’s because software is always more complicated than our optimistic expectations. I’m afraid that such a page would create false expectations and disappointment, because we could not deal with bugs on a web page as well as we can via bugzilla.

    It’s also well understood that user voting doesn’t give useful input. Without understanding, votes are wasted. For instance, people tend to vote for options to turn off features that don’t work perfectly, instead of voting to fix the features.

  6. The largest problem is that most of the people making the roadmap
    – have very broad view of world
    – don’t know the users at all
    – have no ability of thinking out-of-the-box
    – are too conservative
    – have no frigging idea how to build a PRODUCT

Comments are closed.