Debian as a society: an outsider’s view

I am not a Debian Developer – just an user of the distro. When it comes to free software, however, the opinion of the users could be worth something.

My 5 cc:

There was a time when the Debian team was just a bunch of packet maintainers, sharing little outside a set of general principles, and the desire to build a distro together. This time is over. Then, there was a time when the team was interacting socially, but almost only on production topics – teaming on important packages, discussing the New DD process, etc. This time is over, too. With every day the percent of the discussion topics that are closer to the internal distro politics, increases. The Debian Project team is not simply a team anymore – it is a society.

Some people would say that this is an undesired development – but it is inevitable. The project has a core of about 1000 to 1500 active people, and several times that smaller contributors. These numbers, plus an election democracy, are bound to produce a true society. The sooner this is recognized, and the sooner the project people are understood and treated like a society, the better the project, and its product.

Democracies work differently than even most benevolent dictatorships: the latter rely for key decisions on top-down mechanisms, while the former fare better on stimulating down-top initiatives. A dictatorship may function as a team even if numbering millions of people; a democracy the size of Debian Project (or bigger) is only effective when the society is carefuly considered, and treated accordingly. Here is what I believe to be good for Debian as a society, on several key topics:

The “paid participation” experiment

To speed up the release of etch, Anthony Towns came with the Dunc-Tank project. Among other things, it offered monthly payment to key release developers to enable them to dedicate all their time to the release. This had some positive effect, as the paid developers indeed contributed much more efforts during the time they were paid for, and eliminated a lot of problems. However, some other DDs rebelled against the idea, and slowed their work as a form of protest; the overall result was that the release of etch was delayed instead of speeded up.

From a production-oriented viewpoint, this protest was childish and harmful. However, considering Debian as a society, it comes to tell that some rules of this society were broken – and if we don’t understand this, more protests and delays await us.

Formally, the protest was based on the understanding that every DD does his work for free, and this is the only proper way to participate, if Debian is to remain what it prides with. However, there are probably some other reasons behind this. I’d try to guess some, and to suggest a cure against them.

There seems to be the fear that eventually Debian will come to “all are equal, but some are more equal than the others”. That some will start being paid all the time, while others will be shunned, and DP will eventually turn into a company, building its fortune on exploiting most of the developers. I’d believe that strictier and even more transparent rules, and a more democratic procedure for chosing who should benefit from the payment opportunity, may help alleviate this fear.

There is also an understanding that people close to Dunc-Tank should not benefit from it, to avoid cronysm. This may also be ensured with better rules and procedures; if needed, a rule that excludes people closely related with the paying side from the potential candidates.

Some DDs mention that the payment was not very modest. Yes, $6000 is a relatively good montly salary even for USA. And, coming to this, many DDs live in countries where this would be an excellent yearly salary, thus potentially providing the project with much more work. This controversy probably will not be easy to solve; maybe each case will merit custom solution. So, the rules and the structure should be able to provide an opportunity for them.

Candidates for DDs have to wait for too long

This is a complex problem. Waiting for too long discourages many potential DDs. However, one of the strongest sides of the Debian Project is the dedication of its developers – decreasing the waiting time may lead to an influx of less motivated people.

This problem is also tied to another one. Currently you can’t be a DD without being a packet maintainer. However, many people contribute a lot in other ways – writing Debian-specific code, creating art, providing legal counsel, etc, etc. They very definitely deserve a formal acceptance and affiliation with Debian.

I believe that both these problems can be solved by treating the DP participans as a society. One idea how to do it (not necessarily the only, or the best one) is:

– Create a status (say, Debian Contributor) that can be given to every contributor to the Debian Project, as an acknowledgement for their contribution. Debian Contributors could be listed, unless they prefer otherwise, on the official Debian sites. They may belong to different categories (Packet Maintainers, Art People, Legals, Programmers etc); one may belong to more than one category. They may lose the status on certain conditions. They may be allowed to vote in Debian on certain topics.

– Create a status (say, Debian Participant) that can be earned by people who would like to affilate closer with Debian. They will have to be Debian Contributors, to abide by the Debian’s Philosophy, to have an Advocate, and possibly to be able to use an OpenPGP key. The procedure for giving the Participant status should be no longer than one month (but may require some experience, or a level of contributions, as a Debian Contributor). Participants may belong to the same categories as the Contributors; different categories may require additional skills to be accepted in, and exams to be administered. If the Participant can handle a key, they may vote on all topics within Debian. They will be required to be able to devote some free time to the Project, and to contribute regularly (but these requirements will be less stringent than for the DDs). They may not, even if they are Packet Maintainers, upload packages to the Debian repositories without the supervision of a DD.

– Affirm the status of the Debian Developers as the backbone of Debian. The New Developer process should not be shorter than an year, maybe even two: responsibility is given for reliability, and reliability is proven with persistence. DDs are the only people who may upload a package to the official Debian repositories, or take other decisions that have effect upon the Debian users. If needed, DDs may also be divided in categories like the Participants, to allow better specialization: in this case, Packet Managers will be responsilble for the packages upload, Art People – for the quality of the art that is acceptable in a package to be uploaded, etc.

This division may initially appear confusing, or even discriminating. However, I believe that, if properly done and maintained, it will help the Debian Society flourish, and will provide it with more stability and efforts invested.

The Periodic Release Schedule

Some of the best organized free software projects already have, or aim for a periodic release schedule. This is very good for the project users, but not so easy to keep (especially where high stability is expected). Democratic projects typically achieve this less easily than the “benevolent dictatures”.

However, the very nature of the democratic projects suggests an easy way to solve this problem: treating the project members as a democratic society. That is, relying on a down-top initiative, and providing a mechanism that allows everybody to start or stop participating in the schedule-oriented group, at their choice. Undoubtedly, it will not be easy to negotiate a common timetable: the different sub-projects will have a different release cycle natural length. However, once one is negotiated, most projects will tend to adjust to it; also, it may be re-negotiated on need.

It will probably be easiest to negotiate a schedule if the individual packages and groups are permitted to choose whether to participate in the incoming release. The key packages and groups may be required to participate, or supplemented with volunteers to enable them to do. The others can be allowed to declare a participation whenever they are ready for it. Once a participation is declared, opting out should be discouraged. For example, there may be a condition for participation – having a completely stable version of the package / group. The inter-package tuning can be solved in different ways; probably a good set of rules would help for almost all cases.

Technically, for example, this could be implemented (this is just one way – not the only one, or the grantedly best one) as a “frozen” branch, that is split from “testing” several months ahead of the release date. Packages / groups are permitted to enter on complete stability of the version. Breakdowns introduced by inter-package incompatibility are either solved in time with common efforts, or the package / group is rejected, and older version, if present, is used.

Again: Just my 5 cc.

Leave a Reply