Top-level Projects for Upstream

One of my favorite ways to abuse the openSUSE Build Service is to link the packages I want to use into my home project. This is remarkably convenient but it wastes CPU cycles and disk space. It's generally considered A Bad Thing™. But there are some good reasons why I do it and some ways openSUSE could change so that I won't need to.

Executive Summary: Let upstream projects have their own top-level projects.

Currently it's very difficult to get a top-level build service project created. You file a bug saying that you want one and they close the bug WONT-FIX. It's a win-win. There's a desire inside SUSE to keep the top-level as clean as possible. The solution, from their point of view, is to limit top-level to categories. People who think categories are a good thing need to read Everything is Miscellaneous by David Weinberger, or at least watch the Google Tech Talk. The result is massive projects like GNOME:Community.

GNOME:Community is not all bad but it has some fundamental problems, most prominently that there are often at least a few packages there which are older than the packages on your system. The underlying cause of this is that there are too many packages and not enough people interested in maintaining them. In some cases someone volunteers to maintain a package and does a fine job for a while but then loses interest and the package stagnates.

On the other end of the spectrum we find projects like Banshee. The Banshee developers maintain their own build service project. When they have a release they will update their packages because they want to be able to publish a 1-click link. If I add the Banshee repository I will always have the latest version and I won't get any fluff I don't need. This is the right way to do it. I would like to see top-level projects for every major project that wants to participate in openSUSE. There should be top-level projects for Pidgin (well, purple anyway), F-Spot, GIMP, Ekiga, etc. That way I can choose to get the latest GIMP without getting the latest F-Spot if I want to and I know that it's maintained by people who care about it and are committed to quality.

Not every piece of software should have it's own top-level project, of course. Some are closely related to each other such that it doesn't make sense to keep them separate: Pidgin and Finch, for instance, or Firefox and Thunderbird. Others share a release schedule and have interdependencies that would prevent them from splitting up effectively, like GNOME. These should be brought under a single project, but this is not strange because they are already under a single upstream project (GNOME, Mozilla, etc.).

Many upstream projects do not distribute binaries. When they do it's often just the Windows and Mac binaries because it can be difficult or expensive to build your own. openSUSE could be the place to get binaries of your favorite software, but not if we try to pigeonhole them into someone else's project. It's a risk for GIMP to advertise that high quality binaries of 2.6 are available from openSUSE if adding the repository is also going to upgrade your Tomboy.

It's also difficult to properly categorize a project. Suppose there were a slick new open source file-sharing application and we put it under file-sharing but a year down the road it gets an instant-messaging feature and this feature becomes the feature people really like about it. Should we move it to an IM category? What about a nice DAAP server. Does it go under multimedia or file-sharing? Let's toss out categories right now and make decent use of tags instead. The technology is already there, tags have been an underused feature of OBS since the beginning.

Making OBS more appealing to upstream projects is good for everyone. Upstream gets a release build system and a network of willing mirrors for free. openSUSE gets free publicity and better coordination with upstream. Users get repositories they know are well maintained by people who care about the project without any extra fluff they don't want or need.

Comments !