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 them.
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 resources.
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 the New Maintainer process is the path that you follow to become a Debian Developer. Don’t be fooled by the names when reading Debian’s documentation!
The Ubuntu Case
Ubuntu 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 the @ubuntu.com email alias.
For developers, 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 on 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, Mythubuntu, 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 page).
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, while not intended, is not surprising given the high expectations set on potential members of the technical board. Mark, as the founder, is 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).
| Rights | Debian | Ubuntu | ||||
|---|---|---|---|---|---|---|
| DM | DD | UM | PPU/UD | MOTU | UCD | |
| Package maintenance via sponsorship | Y | N/A | Y | Y | Y | N/A |
| Official email alias | – | Y | Y | Y | Y | Y |
| Participate in votes for members | – | Y | Y | Y | Y | Y |
| Participate in votes for developers | – | Y | – | Y | Y | Y |
| Upload rights restricted to pre-approved packages | Y | – | – | Y | – | – |
| Upload rights restricted to a section of the archive | – | – | – | – | Y | – |
| 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 not.
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 if more and more of the contributions flow in both directions.
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 forward.
Possible Evolution?
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 on 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 anything yet.
First of all: a new status for contributors that are not packagers. The tricky part will be defining the process to follow and the rights granted.
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 in the Uploaders field of a 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 almost unavoidable.
Other more invasive changes have been proposed like replacing the NM process by a simple designation by 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. Hopefully, the next episode of this saga will have a better outcome.
This article was first published in Linux Weekly News. In a comment, Mark Shuttleworth tried to explain how the Ubuntu community is being setup.
I still have a problem with Debian’s approach in that it mostly exists to weed out the undesirables, rather than encourage and support the learning process towards becoming a capable developer, plus it gives an insane amount of personal power to DAM to impose their personal issues as a “justification” for weeding someone out.
I also think that the fact that Debian has a debian-private list removes the incentive for existing developers to mature as individuals and learn to calmly and responsibly discuss issues they might have with applicants in the open.
By contrast, Ubuntu supports the learning process towards gradually becoming a core-developer, empowering the applicants in a granular and progressive way and pointing them towards specific areas of improvements and encouraging them to re-apply for the next empowerment level, if the consensus is that they are not yet ready, rather than weed them out.
I think your point of view is too much colored by your own (bad) experience.
First of all, the debian-private list has almost never been used to discuss problems with applicants. Then, even in Debian, we have evolved and people who are not yet ready are told so and they are not told that they will never be able to try again, quite on the contrary in fact. It’s possible to have “hard rejection” but we can count them with our fingers, there are not many of those.
I agree that Ubuntu still does better but Debian is no longer as bad as you suggest it. DAM is even a team nowadays so personal issues with one of them are less problematic (but OTOH if someone is the kind of person that gets into personal issues with other developers, we tend to get very cautious).
My personal experience indeed has something to do with it, but my observation of how things have evolved over the years since the late-90’s also confirm that the fundamental problem still hasn’t been addressed by the Debian roject. One other point you haven’t addressed in your response is how Debian deals with existing developers who act aggressively towards newcomers. This is one area that, if it ever had been addressed properly, would have significantly increased my trust in Debian and helped me agree that things have indeed evolved in a positive direction. Unfortunately, I cannot say that they have, as none of the last 3 DPL ever addressed my concerns even when directly prompted about the issue, in a very neutral way, asking for their advice on how to proceed.
There is no standardized process to deals with existing developers that behave badly, that’s true. But things are evolving: 1/ we’re not making it worse because we try to not accept people who have shown such behavior from the start. 2/ The bad behavior no longer stay unchallenged on mailing list, even the DPL respond sometimes to point out that some behavior are undesirable.
We can always do better but there’s no miracle solution when it comes to issues with people… the situation is never entirely black or entirely white.
I welcome proposals on how to deal with cases similar to mine, where my DM application was rejected solely on the basis of several people objecting with a short message along the line of “I don’t like him and I object to his application. If anyone wants to know why, ask me on debian-private or directly in private” and where only one member of the DAM team voiced his opinion and no final, properly justified decision, was ever reached.
+ 1 Martin-Éric, except for the thing about debian-private (not that I have a different opinion, I just don’t know about that).
I also had a bad experience, and nobody was felt responsible to explain exactly why I was rejected and silently removed from DB (even if it was a simple omission of the system). But that’s not what bugs me the most. What bugs me the most is that Debian is losing a lot of contributors because they just don’t want to bother with the bureaucracy, and specially the feeling that they have to prove themselves against being weeded out. I think that you’re spot on with that definition.
Debian devels are in their marble castle, even those who are completely inoperative and irresponsible to even RFH/orphan their packages (and there are lots of that people, I reported several cases recently to MIA and they confirmed it). Meanwhile, it’s not rare to see that when people apply to *DM* (not even DD), they have been maintaining more packages for years and been more active while doing so than the average Debian Developer. Yet they don’t have any power to upload packages that developers neglect, to vote (a right that many Debian Devels don’t bother with), and they have to depend continuously on the good will of DDs to change things for them. DMs even have to prove themselves with annual pings, whereas there isn’t any kind of similar requirement for DDs.
A few years down the line, by the time that a contributor might get DD status, she might be bored/wore out/busy with life that they only produce a fraction of what they had been produced in their “applicant” years.
So I think that weeding people out from an exclusive club describes quite well the process. And I’m convinced that the decay of Debian in general, specially the high rate of bit-rotting in the archives (shipping packages ~5 years old when there have been upstream releases every year; packages with half a dozen or more NMUs over years not acknowledged; etc) has a lot to do with focusing too much of pushing enthusiastic contributors back, not fully taking profit from the years where contributors are more active, and not imposing stringent rules where matters — in obligations of developers and automatic weeding of them, not in lintian.
Cheers.
I have already discussed the issue at length with Manuel and I just don’t agree with him. He became DM in a bit more than one month after his request, and that only after a few months of contribution. His complaints are mostly unfounded.
Most of the DD went into the same process, and while many vanished without properly orphaning packages, it’s not a reason to grant DD rights to any contributor right from the start. Many DD are active (more than 650 DD uploaded packages in 2010) and they are there to sponsor uploads by new contributors. And many DM went to the next step and became DD.
Yes we have cruft in the archive and neglected packages, but we are not actively forbidding anyone from contributing.
And AFAIK Martin Eric Racine was not accepted as DD/DM for multiple reasons none of them having to do with the fact that some people don’t like him. People can look up the history of the debian-newmaint list if they really care. Communication skills and technical skills were the crux of the issues, that’s all I will say.
But this blog is not the place for discussing those 2 exceptional cases, and this was my last message on this topic.
> “it’s not a reason to grant DD rights to any contributor right from the start”:
And I agree, but it is a question that you (and Martin) address in the article and comments, respectively. The number of roles in Ubuntu is bigger and the process more gradual, and from the outside (I have had very scarce interaction with Ubuntu and never tried to become a member) it seems to me that it applies what Martin says: “I still have a problem with Debian’s approach in that it mostly exists to weed out the undesirables, rather than encourage and support the learning process towards becoming a capable developer”.
> “Most of the DD went into the same process”
(Disclaimer: Indeed you are right, I applied to DM (DD initially) after 7 months of starting to contribute actively; I’m ahead of the average as far as I could observe.)
I don’t think that most of the developers around year 2000 and before typically spent 1-2 years as DMs and then again 1-2 years more to get DD status. 1-2 years is the time that most people applying for DM and DD in the last few weeks spent doing useful things before applying.
If Debian had done this since the beginning, it couldn’t have taken off, and I’d bet that in the years when Debian was more strong the time from outsider to DD was much shorter than the typical time for people who reached the status during last years.
> “Many DD are active (more than 650 DD uploaded packages in 2010)”
I’ve seen many cases recently where the developer updates one or two of her ~10 packages in 2010, while not touching packages in 3-5 years, having several upstream releases in 2008-2010. Updating two, neglecting ten. I can send you links in private if you don’t believe me, I’ve been reporting some of these cases recently trying to get Debian archive up to date.
> “Yes we have cruft in the archive and neglected packages, but we are not actively forbidding anyone from contributing.”
The question being pointed out is not “forbidding”, but the perception that some people (outsiders or not) of pushing back instead of encouraging 😉
I’m collaborating in many other free sw projects (and not only software projects), and I’ve yet to find any other which is so much unwelcoming to people who are wishing to make Debian better. Other projects even offer resources and encouragement before people starts making something useful; while in Debian if you plan to tackle some task when the current maintainer is not bent to help you, or a package that it’s not trivial and there’s nobody who want to sponsor the upload, or the maintainer doesn’t acknowledge and upload your translations, you’re bound to much friction to get things done. (And note that 2 of the 3 examples are real and don’t apply to me).
Finally,
> “But this blog is not the place for discussing those 2 exceptional cases, and this was my last message on this topic.”
I didn’t bring my issues at all (except one phrase at the beginning, kind of disclaimer), I tried to stay on topic and discuss the article.
In fact, it’s you who are continuously bringing up this issue, as if having had a bad affair with Debian would invalidate the rest of my/our opinions for the rest of the life, even when scarcely mentioning it (as my case with these comments).
Cheers.
Actually, as I’ve already stated 1) there was no final decision, only one rather inflammatory statement by one of the DAM saying that he at least wouldn’t give his OK and 2) most of the messages voicing their opposition did involve personal issues and, interestingly enough, since you mention communication skills, some old contributors’ complete lack of communication or social skills. That some people would rather look the other way whenever someone flames me or trolls an NM discussion with really old bug reports as “evidence” of insufficient technical skills (and in which those same people, among other things, throw personal insults at me and threaten to hijack the packages I maintain) is the real reason why NM is broken even for something as simple as finally being allowed to upload the packages I have been maintaining for several years without requiring any sponsor.
Terrific article. Thank you very much Raphaël.
As Jeremiah, I found this article to be very interesting. Considering Debian and Ubuntu share lots of technical things, comparing their [social | structure | …] side is also worth a read.
Let’s hope we can learn from each other (“we” in the sense that I am just a maintainer, but I consider myself part of the project… somehow 🙂 ).
I was about to write “Debian maintainer” wanting to reflect the fact that I maintain packages for Debian. But then I stumble with the fact that DM is another thing.
Maybe I should fire up reportbug and send this bug. Or add this “use case” to an existing bug 🙂