FOSDEM: Collaboration (or the lack thereof) between distributions

The Free and Open Source Developers' European Meeting (FOSDEM) is an interesting event. Entry is free, so there is no way to know how many people show up - except that the number is clearly large. The organization sometimes seems chaotic, the rooms packed beyond their capacity, and the hallways are often impassible. With over a dozen tracks running simultaneously, choosing what to see can be a challenge. But all the right people tend to attend, and a great deal of work and valuable discussion happens. As an example, consider the various distribution-related sessions described below which, as a whole, combine to give a good picture of what the distributors are concerned about.

Distribution collaboration manifesto. One session which arguably didn't live up to its potential was the "distribution collaboration manifesto." It did, however, let us see Debian leader Stefano Zacchiroli, Fedora leader Jared Smith, and openSUSE community manager Jos Poortvliet together on the same stage.

The discussion wandered around the topics of how nice it would be to cooperate more, cooperative application installer work, and making better use of the distributions list on freedesktop.org. It was friendly, but somewhat lacking in specifics.

Downstream packaging collaboration. A more focused session was led by Hans de Goede and Michal Hrušecký of Red Hat and openSUSE, respectively. According to Hans, packaging software is not normally a difficult task. When one is dealing with less-than-optimal upstreams, though, things get harder. One must make sure that the entire package is freely licensed; ancillary files (like artwork) can often be problematic. The package must be tweaked for filesystem hierarchy standard compliance, integration with distribution policies (including writing man pages if needed), fixing build problems, getting rid of bundled libraries, and fixing the occasional bug.

That's all just part of a packager's job, but, Hans asked, what should be done with the results of that work? The obvious thing to do is to send it back upstream, and to educate the upstream project about problems like bundled libraries. But what happens if the upstream is unresponsive - or if there is no functioning upstream at all? This situation arises more often than one might expect, especially with games, it seems. Assuming that the code itself is still worth shipping, it would make sense for distributors to work together to provide a working upstream for this kind of project.

Again, specific suggestions were relatively scarce, but Hans did say that having a set of package-specific email aliases at freedesktop.org would be useful. For any given problematic package (xaw3d was one such listed), packagers at each distribution could subscribe to the appropriate list to discuss the work they have done. The list would also receive commit notifications from each distributor's version control system, so everybody could see changes being made by other distributors, comment on them, and, perhaps, pick them up as well.

Michal talked about setting up a mechanism designed specifically to let packagers share patches. He seemed to envision a shared directory somewhere where packagers would put their specific changes; subsequent discussion made it clear that some people, at least, would rather see some sort of source code management system used. Michal also called for the adoption of a set of conventions for patch metadata to describe the purpose of the patch, who shipped it, etc. Bdale Garbee suggested from the audience that what people really seem to want is a set of simple pointers to everybody's git repositories. He added that anybody who is a package maintainer and does not know who his or her counterparts are in other distributions is failing at the job and needs to go out and start meeting people.

Forking is difficult. A rather different approach to collaboration - and the lack thereof - could be found in a session led by Anne Nicolas and Michael Scherer. Anne and Michael are two of the founders of the Mageia distribution, which is a fork of Mandriva. According to Anne, Mandriva was built on a good foundation and with a great "users first" policy, but, when things started to go bad, it was a "disturbing experience." From that experience Mageia was born.

Mageia is built on the principles of "people first" and trust in the community. The distribution wants to make life as easy as possible for both users and packagers. Actually getting there is proving to be a challenge, though, with every step on the way taking far longer than had been expected. There is now a legal association in place, though, and an initial pass at a design for project governance has been done. The build system is mostly ready, and training of packagers is underway.

In the process, the developers have found that simply forking an established distribution is a lot of work. It has taken about three months to get a base set of 4100 packages ready. As they do this job, they are trying to make the job of changing the name and the look of the distribution easier for the next group that has to take it on. That should improve life for anybody who might, down the road, choose to fork Mageia; it is also aimed at making the creation of Mageia derivatives easier.

The first Mageia alpha will, with luck, be released on February 15. Current plans are to make the first stable release on June 1. June is also the target for having the full organization and governance mechanism in place. This governance is expected to be made up of around ten teams, an elected council and an elected board.

The other challenge that the Mageia developers are facing is that of creating an "economic model" which will support the work going forward. From the discussion, it seems that the main source of income at the moment is donations and T-shirts, which is unlikely to sustain a serious effort in the long term.

Fixing Gentoo. Finally, Petteri Räty led a session on the reform and future of Gentoo. Contrary to what some people may think, the Gentoo distribution is alive and well with some 235 developers maintaining packages. That said, there are some issues which need attention.

Many of these problems are organizational; the project's meta-structure has been neglected over the years. There is little accountability for people working in specific roles. Nobody can really say what Gentoo projects are ongoing, and which of those are really alive. Nobody really knows what to do about dead projects either. The relationship between the Gentoo Council and the Gentoo Foundation is not particularly clear. And there is an unfortunate split between Gentoo's users and its developers. Mentoring for new developers is in short supply.

There are plans to reinvigorate Gentoo's meta-structure project, giving it the responsibility of tracking the other outstanding projects. That should give some visibility into what is going on. The current corporate structure was described as a "two-headed monster" that needs to be straightened out. To that end, the Gentoo Foundation is finally getting close to its US 501c(3) status, making it an official nonprofit organization. The Foundation is expected to handle legal issues and the distribution's "intellectual property," while the council will be charged with technical leadership.

In summary: it seems that the Gentoo project has a number of challenges to overcome, but the project remains strong and people are working on addressing the issues.

Conclusion: the FOSDEM cross-distro track included far more talks than are listed here; there's only so many that your editor was able to attend. It's clear that the conference served as a valuable meeting point for developers who are often working independently of each other. Linux distributors are, at one level, highly competitive with each other. But they are all based on the work of one community. If they can do more of their work at the community level, that will give each distributor more time to work on the things which makes their project special. The discussions at FOSDEM can only have helped to increase understanding and collaboration across distributions, and that must be a good thing.

---

(Log in to post comments)