Yesterday I mentioned GNOME’s time-based releases. But what about aims?
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.