Debian and Ubuntu have a set of official membership roles that can be granted to
regular contributors. Those roles come with rights that enable the
contributors to do their work and to participate in the project governance
(elections and other official decision-making processes). It's also a way
for the distributions to acknowledge the work done: most contributors are
proud of the status they reached.
The membership structure plays an important role in the development
of a distribution: it defines the kind of contributors that
are welcome in the project, it sets expectations of the project towards
its contributors and defines their rights. In the end, this shapes
the project's ability to recruit new contributors to keep the project
alive and kicking.
This article introduces the existing statuses in Debian and Ubuntu, and
defines the — sometimes confusing — jargon associated with
The Debian case
Debian only has two types of official members: Debian Developers
(DD) and Debian Maintainers (DM). The rights of the developers
are codified in the Debian Constitution
while those of the maintainers have been defined in a
general resolution of
2007. The Debian Maintainer status is still mostly documented in
a wiki page. The
integration of this new status in Debian's official processes has been
slow to come largely because it was introduced — at that time —
without enough negotiation with the involved parties.
Nowadays, it is preferred that people get the DM status before applying for DD.
DM is a very limited role: maintainers can only upload packages that
already have their name on them (either in the Maintainer or Uploaders field)
and a specific flag (DM-Upload-Allowed: yes) that only Debian Developers
can add. They have no other rights and limited access to Debian's
Besides those official roles, there are also maintainers of packages
that have no official status within Debian except that they are listed in
the "Maintainer" field of the package. They are doing the
maintenance work but all uploads are done by a Debian Developer
after verification of the work done (this is called "sponsorship" and is
the only way to start with official packaging work). Once the
DD trusts the maintainer, the developer will typically ask the maintainer
to apply for DM status in order to be relieved from the sponsorship work.
In the end, that makes three different kind of package maintainers and a
lot of confusion when you discuss membership issues... in particular when
Maintainer process is the path that you follow to become
a Debian Developer. Don't be fooled by the names when reading Debian's
Developer roles in Ubuntu
Ubuntu has had, from the start, an official Ubuntu
Member status that includes all contributors: developers of course,
but also documentation writers, artists, translators, etc.
This status notably grants the right to vote in elections of the Community
Council, the right to participate on Planet Ubuntu, and an @ubuntu.com email
the situation is more complicated: the wiki page lists no less than five
different statuses. Initially, developers were split between Ubuntu Core
Developers and the MOTU (Masters Of The Universe). The
latter were responsible of the universe/multiverse sections of the archive
while the former also had upload rights for the main/restricted sections.
But, inspired by the Debian Maintainers concept and facing concrete
problems in terms of archive management, they changed their infrastructure
to offer more fine-grained control of package uploads.
Ubuntu can now grant upload permissions on a package-per-package basis, but it can also
delegate the right to grant upload permissions with the same granularity.
This lead to the new Per-Package Uploader status, which is simply
an Ubuntu Member with upload rights on a limited set of packages
where they have a specific expertise. The more generic Ubuntu
Developers status now encompasses members of various development
teams that have been delegated the right to manage
upload permissions on a (usually large) package set (the current teams
are Ubuntu Desktop, Mythbuntu, Kubuntu, and Edubuntu). Those teams can
define their own policy to add new members provided they follow the basic
rules defined by the Developer Membership Board (see this wiki
Ubuntu Contributing Developer is an intermediate status
for someone who is not yet ready for one of the other developer statuses
but who has still shown enough commitment to be an Ubuntu Member.
All those statuses can be obtained
in a similar way: you prepare a wiki page listing your past
contributions, you collect testimonials from existing members that you
have worked with, you add yourself in the agenda of the next meeting of
the board (or council) that grants the status that you seek, and you
attend the meeting. The members of the board will decide whether you are
ready for the status (or not) based on what you provided in the wiki,
based on your answers during the meeting (and on a mailing-list for
developers), and based on what others have to say about you.
The most important boards are usually elected by the
community while others are commonly appointed by the community
council. Those governance bodies include Canonical employees but not as
many as one would expect: two out of eight in the Developer
Membership Board, two out of eight in the Community Council, but
all six members of the Technical Board.
The last figure is not surprising given that the members of the technical
board are appointed by Mark Shuttleworth. The community does not get to
choose, it can only approve the choice by a confirmation vote. The founder
of the distribution clearly wants to keep control on the technical
directions of the project. He's also the only person to have a permanent
seat on both the Community Council and the Technical Board.
Comparison of the statuses between Debian and Ubuntu
The following table summarizes the rights given to each developer role in
the two projects (Put the mouse over the abbreviations to know what they
are referring to).
|Package maintenance via sponsorship||Y||N/A||Y||Y||Y||N/A
|Official email alias||-||Y||Y||Y||Y||Y
|Participate in votes for
|Participate in votes for
|Upload rights restricted to pre-approved packages||Y||-||-||Y||-||-
|Upload rights restricted to a section of the
|Unlimited upload rights||-||Y||-||-||-||Y
|Number of contributors (as of 2010-07-27)||117||904||462||27||85||63
Please note that the number of contributors are not 100% accurate for Ubuntu.
A contributor can have multiple statuses (direct membership to a launchpad group)
granted over time (while gaining experience). The problem has been mostly avoided
by calculating differences between number of members of the various groups but
it's not perfect and it can't be: some MOTU are also PPU for packages in main
and it's legitimate (but I only counted them as MOTU and not as PPU).
Another limitation is that members of some administrative teams are included
indirectly in many teams and thus appear in the count while they should
Anyway, this simple table makes it obvious that Ubuntu's structure offers
a broader choice of statuses. They acknowledge the work of all contributors
from the start while still giving the most critical rights only to those
who have proven that they deserve them. Despite this difference, Debian still has a
significant advantage in terms of number of developers. That number does
not tell the whole story though: the Ubuntu contributors include many
Canonical employees (e.g. 36 out of 63 core developers have a
@canonical.com email registered on their launchpad account) that are
likely to spend more time working on the distribution than the average
Debian member. But even if comparing person-hours would be a challenging
thought experiment, in practice it's of not much interest if both projects
continue to cooperate and more and more of the contributions flow in
Debian is aware of the shortcomings of its structure. Changes
to better accommodate non-packagers have been discussed several times
already. The last
efforts in that direction were unfortunately perceived as a
solution ready to go rather than a proposal to be discussed, and the
project got quickly buried by a general
resolution (GR). Even if that resolution invited for further discussion
and a new proposal, the truth is that when someone's initiative is
"corrected" by way of GR, it usually kills any motivation to go
On the Ubuntu side, the infrastructural changes were completed recently
and they don't expect any further change in the near future. They
do plan, however, to expand usage of those new features so that more
teams benefit from the possibility to control upload rights on packages
that are relevant to them, and so that more individuals developers apply to
become Per-Package Uploaders on packages that they know very well.
On the Debian side, a recent discussion on
the debian-project list brought back
the topic of the bad
terminology and it was agreed that the "New Maintainer
process" should be renamed into something else ("New Developer process"
has been suggested). But Christoph Berg — Debian Account Manager and hence
heavily involved in the New Maintainer Team — suggested
that Debian would be better off implementing the long-awaited membership changes
before trying to update all the documentation. It would certainly
imply some more vocabulary updates. Later in the discussion, he confirmed
that membership reform is at the top of the TODO list of the new
maintainer team (just after the rewrite of the nm.debian.org website).
What can be expected from this reform? The following answers are my own
guesses based on my experience of Debian, but the project hasn't decided
First of all: a new status for contributors who are not packagers.
The tricky part will be defining the process to follow and the rights
Changes to the technical implementation of the DM status. The
current implementation does not allow to give upload rights to a single
DM if two are listed as Uploaders of the same package (and both might not have
the same experience for that package). Furthermore, it suffers from annoying
restrictions like the inability to upload new binary packages.
A change of the Debian constitution to integrate those new statuses is
Other more invasive changes have been proposed like replacing the NM
process by a simple designation from other DD, but it's unlikely to happen. The NM
process can already be greatly simplified by the application manager if the
applicant can show good testimonials from other developers and if he has a
track record of real contributions (e.g. as witnessed by changelog
entries in Debian packages).
Almost two years have elapsed since the previous efforts in that
direction, the new maintainer team has recruited new members and is in a
general better shape. DebConf is approaching (August 1-7) and has
traditionally been a good place to discuss important reforms. Hopefully,
the next episode of this saga will have a better outcome.
Comments (13 posted)
Time for yet another MeeGo 1.0 release announcement
: this time they have produced the first version of the "in-vehicle infotainment" version of the distribution. "As part of this release, we are including a sample IVI Home Screen and taskbar, using the included Qt framework, and designed with Automotive Center Console HMI requirements in mind. We have also included some automotive specific middleware components and a few sample applications, including sample navigation program (Navit) and a sample dialer application (BT-HFP Dialer) which uses Bluetooth and a paired phone.
Comments (none posted)
The 1.0 release of the Jolicloud netbook-oriented distribution has been announced
It has various new features which will doubtless appeal to certain classes
"As you may have seen, we've made some changes to the Stream, making
it a more social app-sharing experience. Now, in Jolicloud 1.0, you can
'like' apps, which will show up in your Stream. It will also list the app
in your 'Favorite Apps'. Don't forget to use this new feature - it's
helpful for other users to figure out what the most popular apps are in our
growing App Center.
Comments (8 posted)
I think it would be good to have a [strategy] proposal focusing on end user products, on something aunt Tilly can work with. openSUSE could be a distribution aiming for polish, the final touch. Working on creating a great end user product. And both the Gnome and KDE people would be able to work with it, as would the Apache team, the Kernel team and all others in the community!
-- Jos Poortvliet
Comments (none posted)
The North American FUDCon (Fedora Users and Developers Conference) for 2011
will be held in Tempe, Arizona January 29-31, 2011. "Our last North
American FUDCon was in Toronto, Canada. The year previous it was in
Boston, MA. We always encourage feedback from the contributors, and the
one answer that popped up more often than any other was, 'Let's go
somewhere warm this coming winter!'
Full Story (comments: none)
Red Hat Enterprise Linux
Red Hat has announced that Red Hat Enterprise Linux 3 will receive another
3 months of support before it reaches its end of life. "In
accordance with the Red Hat Enterprise Linux Errata Support Policy, the
regular 7 year life-cycle of Red Hat Enterprise Linux 3 will end on October
31, 2010. After this date, Red Hat will discontinue the regular
subscription services for Red Hat Enterprise Linux 3. Therefore, new bug
fix, enhancement, and security errata updates, as well as technical support
services will no longer be available.
Full Story (comments: 3)
The H reports from the Illumos announcement
; Illumos will be a all-free downstream derivative of OpenSolaris. "Illumos is endorsed and supported by Nexenta, Joyent, Greenviolet, Belenix, Schillix, Berlios and Everycity in its efforts to create a freely available SunOS derivative. [Garrett] D'Amore emphasises that Illumos is not a fork, but the work being done will empower the community to fork if needed in the future. He believes the project already has the critical mass necessary to sustain the engineering effort needed.
Comments (62 posted)
Newsletters and articles of interest
Comments (none posted)
Page editor: Rebecca Sobol
Next page: Development>>