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.
1. 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.
2. 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.
3. Further reading
Related information from OSS Watch: