Open Source Leadership: Debian

by Stuart Yeates on 25 April 2006 , last updated

Introduction

Contributors to open source projects often have diverse affiliations and span many countries, languages and timezones. Leading and motivating such diverse groups is a significant challenge. This document considers how Debian, one of the largest open source projects, elects leaders and how these ideas could be applied to smaller projects.

Organisation of the elections

Since 1999 Debian has held annual leadership elections attracting participation from a large number of Debian developers. The elected Debian project leader is able to delegate responsibility to any Debian developer willing and able to accept. Such delegation is made in consultation with the Debian Technical Committee which is responsible for resolving any technical disputes in the Debian project. Where responsibility has not been delegated the leader will make decisions on behalf of the project, similarly, where an urgent action is required the leader is able to indicate the preferred action. Finally, the project leader is able to make decisions about how money owned by Debian is used.

Since the position of project leader is such an important and potential powerful position, the process of election is critical. The process adopted has resulted in orderly, amicable, and constructive leadership hand-overs. There are a number of important factors relating to the elections which are crucial to their success:

Independence
the elections are organised and run by individuals with no explicit or perceived links to, or preference for, the candidates.
Clearly delineated campaign
the voting timetable sets aside clear time for campaigning by candidates and clear structures for candidates to get their messages to developers. This limits the time and resources which candidates might be expected to invest in campaigning, and thus limits the drain of campaigning on the overall time and energy available to the project.
Transparency
it is clear how the process works, from the method by which candidates get nominated to their term of office and power. An open process mitigates problems with the acceptance of the elections.
Discussion and debate
candidates are encouraged to write an official description of their platform, listing how they stand on any issues they feel are relevant to their candidacy. By focusing on specific technical, organisational, and legal issues, the voting process works as an enumeration of the issues facing the project as a whole and provides a forum that allows not only the candidates but also other developers to air their views constructively. It is noted, for example, that a number of issues that were discussed at length in previous campaigns were not raised in the 2006 elections, suggesting that a consensus had been reached on those issues.
Media
all of the election processes take place using the media by which the project conducts day-to-day business. Developers can thus interact with the candidates, vote administrators and voting system using media they are comfortable and familiar with. This helps make the leadership voting part of the regular business of Debian, rather than something set apart, thus encouraging participation.
Willingness to co-operate
in their campaign platforms, candidates tend to deal respectfully and courteously with their opponents, even while asserting their own positions. This emphasises the fact that these candidates are aware that, no matter who wins the elections, they are going to have to maintain a cooperative relationship with the other candidates.
Focus on content not form
developers are, by and large, technically adept rather than highly literate, and so are encouraged to focus on the content of communication, rather than the form and style of communication. This fits well with the large proportion of developers with English as a second language and with the widespread use of version control systems and wikis for documentation, both of which allow content creation and proof reading as separate phases.
Separation of votes for divisive issues
there are several controversial issues within the Debian community, mostly relating to the exact meaning of the word free in the term free software. These issues are voted upon in a process that is completely divorced from the leadership elections thus preventing the entanglement of otherwise unrelated issues.

Lessons for small projects

Debian is one of the largest and most mature open source projects in the world. As such, it enjoys resources that may not be available to small projects, but there are still lessons to be learned.

Clear leadership responsibilities
when a leader (or leaders) is afforded a level of power and influence over other developers it is important that any boundaries are clearly defined. This ensures that the leader is held accountable, and, if necessary, can be brought to order.
Clear governance process
to encourage participation and minimize any potential discontent within the community it is important to have a fully transparent process for the selection of leaders within a project and for the management of the project by those leaders. A transparent process also mitigates accusations of anyone having a ‘hidden agenda’.
Separate development from other activities
development is the most crucial role of most open source projects and it is important to keep the development communication channels focused on development issues. These channels might be mailing lists, IRC channels, face-to-face meetings or wikis. Separation can be achieved by creating separate channels for user questions and administration; providing FAQs and documentation in search-friendly formats; and even direct management of the channels.
Encourage debate based on content rather than form
for internal communication, spelling and grammar should take a back seat to promptness and technical usefulness. For externally-facing material, wikis and version control systems allow content to be added quickly and then quietly corrected as necessary. Projects need to be clear on the level of tolerance for personal attacks, flame wars and other anti-social activities. That is, while the content of an argument is generally more important than the form, certain forms of communication can be damaging to the community regardless of the quality of the content.
Encourage independence
whilst many developers have little or no direct interest in some parts of the project, they inevitably will have at least some indirect interest in other parts that may be vital for the continuation of the project. These people are ideal candidates to be nominated as independent parties for running voting processes, discussion moderators, and similar duties. If the project is affiliated with a larger umbrella project, such as Debian or The Apache Software Foundation, they may also be able to supply an independent person with suitable skills for such duties.
Use consistent communication methods
as much as possible, the communications of the project should be carried out using the same media and standards as the primary activity. This encourages participation of all project members on either a casual or a permanent basis in this work. If the development coordination is done using archived mailing lists, then so should the new-user question answering and administration.

If you are part of a smaller open source software project and you are considering alternative governance structures for your project, you may be interested to read the briefing note on governance models. OSS Watch has also published template models for projects that wish to adopt a benevolent dictator or a meritocratic governance model.

Further reading

Links:

Related information from OSS Watch: