I asked people to write up their realistic visions for GNOME. So here’s the part that I find most inspiring. Sorry if this seems like a mad rant – it seems sensible and feasible to me.

Obviously I am personally interested in directly giving end users what they want, both because I write software for users, and because I hope users can drive demand from the actual decision makers. That’s not an argument against other GNOME marketing strategies. It’s just a statement of what I myself am able to be motivated about. People should go ahead with whatever they see clearly.

To make most of the following happen just requires work, and perfection of existing stuff. It’s not something that I’m likely to work on much myself, but it feels like we could agree that we want it.

GNOME Is People

• A contacts panel applet lists people with whom I most often communicate, with pictures of their faces. A search entry helps me to find other people, in my local list of people, and in lists on the internet.
  • This isn’t a separate application. It’s right up front. There’s a little picture of my face on the panel, and clicking it shows me a list of other people, with their faces.
  • gossip-telepathy‘s various experimental panel applets are already going in this direction.
  • Update: Gimmie is also partly there. I had no idea that it could be a panel applet on a regular GNOME panel. And you can change the preferences so it shows just the People menu. I’d like it to use telepathy and e-d-s, or generally something that can be shared across applications. It uses Gaim at the moment, which is understandable as a short-term hack.
  • The faces thing really makes a difference to the experience. And let’s call them hackergotchis. It’s our word so let’s make this our feature.
  • We would need some automatic way to make a hackergotchi from any random picture. The least the user would have to do is sometimes identify a square region of a photograph. It would rarely be perfect, but it would be good enough.
  • When these people are on my local network, that’s obvious. Avahi makes this possible. File-sharing with these people is easy and actually works without any configuration.
  • Optionally, this could integrate with a corporate contacts server, such as an LDAP server, but this really has to work without any central administration.
• Every mention of a person is a way to contact the person via a variety of methods, and a way to view the history of my communication with that person. I can easily see what groups that person is in, both groups I have defined, and groups that people have defined on the internet.
  • If I have one way of contacting the person (email, IM, etc), my system can discover all of the other ways of contacting that person (email, IM, skype, SIP, blog, etc), either automatically, periodically, or on request. This would require some kind of standard, maybe a vcard would do.
  • There’s an über-simple way to back this up, ideally to an internet service. Otherwise, I will lose it when doing upgrades and reinstalls. This backup should be frequent and automatic, so I don’t have to think about it until I need it.
  • Ideally this would integrate with the various social networking sites such as LinkedIn, Xing (OpenBC), Facebook, Orkut. Most of them will be too greedy to risk offering the advantage of the freedom-to-leave, speeding their own demise, but we should give them the chance. If none of them do it, we can live without them.
• The applet needs to be on the panel by default. A notification needs to encourage people to use it, with some very easy way to register yourself, so that people can ask to add themselves to your list. It needs to be useful quickly. Let the system administrators remove it if they don’t like it, but don’t force regular users to find it and add it.
• Without adoption of standards, this might not work with all computer users in the world, but it can be made to work between all GNOME users, and probably all Linux users. That alone would be an attractive scenario. I’d be happy to hear about how Linux is the social desktop.

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.

Vision

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.

I recently had the opportunity to proof-read Martin Michlmayr‘s PhD thesis on release management in large open source projects. Martin is an ex Debian project leader, so he has personal experience. His research confirms what I believe to be true about the benefits of a time-based schedule rather than a feature-based schedule, based on GNOME’s release planning:

• Coordination: This allows sub-teams to coordinate their work, by specifying certain times when it’s most appropriate for them to do their work, and preventing them from interfering with each other.
• Decentralization: This coordination happens without much central coordination, because the schedule is known and reliable.
• Quality: This allows more features to be released in a suitable state over the long term, without finished features having to wait for not-yet-ready features.
• Modularity: This encourages us to question the suitability and stability of individual features rather than attempting to judge only the whole as all or nothing, and allows us to create a whole out of parts that are ready. The schedule encourages major long-term changes to happen in branches without disrupting regular development.
• Iterative Development: This keeps quality under control, because the difference between releases is small.

(This are my wordings of my favorites after reading his text. For accuracy, read his actual conclusions when they are online.)

Update: His PhD is now online.

It’s obviously easier to get detailed evidence from open source projects, so he must restrict his conclusions, but I think the conclusions apply equally well to software projects in general. Given any two large projects, with existing sub-teams of developers, pay alone is not a sufficient factor to achieve a feature-based schedule on time, given all the other things that can and do go wrong. It’s easy to feel that it should be, but reality isn’t what it should be, and time-based schedules are all about managing reality. Blame doesn’t get things done. So I think a time-based schedule is the best way to make your developers release software, regardless of how you acquired those developers.

Of course, you decide which of these releases to actually release to the public.

Note also that I think the GNOME schedule could do with more occasional adjustment to emphasize different needs at different times, such as sometimes having a longer stabilization phase, or a longer features phase. But the adjustments would have to be small, because we need to be careful about breaking our stride. I’ll post more about features-based planning tomorrow.

I’m not fan of the repetitive high-word-count form of most academic texts, but Martin does a good job of getting the ideas across, based on specific studies and interviews, with some good quotes. He has just started blogging some of it, and I suspect that this will be more direct than the thesis itself. I hope he keeps blogging it, particularly his conclusions, but here’s some links into what he has online so far:

• Introduction
• Project Summaries:
  • Debian
  • GCC
  • GNOME
  • Linux Kernel
  • OpenOffice.org
  • Plone
  • X.org