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 Hruecký 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
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.
to post comments)