On projects and their goals

The Subversion project recently posted a "vision and roadmap proposal" describing where this popular source code management system can be expected to go in the future. The Subversion developers have made some clear decisions; these include not even trying to compete in the distributed version control system space, a reworked storage layer, rename tracking, better conflict handling, and more. The mission of the Subversion project is not to chase after the flashier distributed systems which are displacing it in a number of contexts; instead, Subversion will exist to serve the needs of users who feel the need for a simple tool with a centralized repository.

This announcement drew well over 100 comments on LWN, and similar numbers elsewhere. Quite a few of them were of the "here's a nickel, get a real SCM" variety; it seems that many see Subversion as old, unfashionable, and past its expiration date. Others were critical of Subversion's users, claiming that there's no reason why they couldn't move to a proper distributed system like all of the cool people have. Quite a few people, it seems, would be happy to see Subversion curl up and die; others think that the decision not to pursue distributed features will cause that to happen.

But there are plenty of distributed version control systems out there, a few of which have accumulated substantial user and developer communities. The Subversion developers are right to believe that they would be hard put to create a credible offering in that "market" at this point; they would have to create something which is demonstrably better than the existing systems, bearing in mind that those systems are improving quickly. Beyond that, there truly are large numbers of Subversion users who are mostly happy with what they have. Those users may have "look into distributed version control" on their long-term to-do lists, but, meanwhile, they have projects to manage. They are best served by a plan which calls for improvements in the Subversion they are using now.

Subversion is mature software. There will certainly be no shortage of things which can be improved in it, but its period of rapid development may be well behind it. There is nothing wrong with the developers saying so; in fact, there is much to commend there. Developers looking for fast-moving, distributed systems have a variety of offerings to choose from. Subversion, instead, will focus on what it does best: better serving the users that it has now. It seems entirely likely that there will be quite a few of them for some time yet.

[PULL QUOTE: Here, instead, we're told that users like the way things are now, and that trying to make changes is a mistake. END QUOTE] A very different discussion has surrounded the minor user interface changes planned for the upcoming Ubuntu 10.04 release. Here, instead, we're told that users like the way things are now, and that trying to make changes is a mistake. It's tempting to throw all of the complaints into the "bike shed" category, but this is a shed that Ubuntu users will be staring at all day long. These changes risk creating gratuitous differences between distributions and causing confusion in users who are used to finding their window buttons in a different place. Might not it be better to leave well enough alone?

Note the difference, though: while there is probably limited scope for innovations in the problem space that Subversion has chosen for itself, anybody who tries to argue that our desktop system usability problems have been solved will face a skeptical audience indeed. We have come a long way, but "usability" as a problem in general is far from solved. It makes sense to be conducting experiments in this area, especially for a distribution like Ubuntu, which has always had a focus on desktop usability. Other Ubuntu experiments - less intrusive desktop notifications, for example - have found their way into other distributions as well.

This line of reasoning can be taken farther: we desperately need more experimentation with usability in the free software space. We have spent years trying to catch up to proprietary alternatives; this work, for the most part, is done. At this point, we can focus with trying to match usability changes made by others, or we can try to come up with interesting new stuff of our own. Your editor clearly prefers the latter.

Given the scale of the problem, the biggest complaint with moving window buttons to the left might well be: why spend so much time and energy on such little things? We're not at the stage where we work for months to yield a 1% improvement; it's time to be a bit more bold. Projects like MeeGo seem much more interesting in this regard; those developers are seriously trying to rethink how specific groups of users will use their computers in the future. Android, too, has done some interesting work toward the creation of finger-friendly interfaces. And so on. That is the kind of experimentation we need to have.

Two other criticisms have been aimed at the Ubuntu changes: that user interface changes require the participation of human-computer interaction experts, and the top-down decision mechanism is not particularly community-oriented. On the first charge your editor - who made human-computer interaction the focus of his Master's degree work - has a bit of sympathy. But that claim also sounds vaguely reminiscent of the SCO Group's assertion that the Linux community could never have come up with an enterprise-class server operating system on its own; one should never underestimate what our community can do. In the end, the real key to usability is to pay attention to the users. Free software developers have a high degree of access to their users; those who take advantage of that access will have a higher chance of creating successful interfaces.

Beyond that, we do also have usability experts in our community.

On the second charge: undoubtedly Mark Shuttleworth's ability to direct Ubuntu by decree will be irksome to some. The "behind closed doors" nature of some Ubuntu development is also annoying and detrimental to the creation of a true developer community. On the other hand, it's a rare distribution which makes these decisions in a democratic way; even Debian doesn't hold general resolutions on window button placement. There comes a time when it's best to make the decision and move on; individual users can always fix things they don't like.

In summary: Ubuntu could certainly be more open about the changes it is trying to make and, perhaps, more open-minded about accepting input from its user community. But Ubuntu's work toward improving usability is desperately needed, and any interaction changes are certain to upset some users. Even if the specific change in question is not necessarily the best, experimenting with this kind of change needs to be done, regardless of the inevitable complaints.

More generally, every project has to have some idea of the problem it is trying to solve. In some ways, that's a far more important part of a project than any specific body of code or any specific developer. One of the best things about free software is that it's alive; it will evolve and, with any luck, be better tomorrow. A project's goals say a lot about how it can be expected to evolve. In your editor's opinion, both Subversion and Ubuntu have set worthwhile goals, and both seem to be trying to work toward those goals. These are good things; our community is richer for the existence of both.