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, as 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.
Open source projects are composed of real-world people, with
the same failings and foibles as anyone else. Consequently good people skills are necessary in order to lead an open source
project.
3. Further reading
Related information from OSS Watch: