Is Open Source democratic?

In his recent post, Glyn Moody asks an important question - “Can Open Source be democratic?” He describes how Free Software emerged as a distributed, bottom-up system of writing code. The central defining aspects of that culture are a uniquely open process not just of programming but also of its organization, and a close relationship between programmers and users. Effectively, users and programmers together were both contributors, they collaborated on the project. Glyn goes on to explain how this community effort changed over time to become more institutionalized, more corporate and more dull - “becoming a ‘Firefox Affiliate’, hardly something that sets the pulse racing.” Ordinary users no longer play an important part in Open Source projects.

Underlying is the assumption that Open Source is democratic, and this assumption needs to be questioned. Open Source communities have been coined to be self-directed, meritocratic,  …, but it is rarely emphasized that they are democratic. Since individuals are investing effort in their favorite projects to contribute to something greater, and democracy is commonly considered to be a greater good as well, it is intriguing to make the jump to thinking of Open Source communities as being democratic. But are they? What is the meaning of democracy in the context of Open Source? What does a democratic community look like?

Some may say that such political concepts cannot easily be transferred to how Open Source communities should function. While it may not be easy, it is still worthwhile - democracies have dealt with similar problems of inclusion and the distribution of power and responsibility. Just like democratic states, communities are volunteer organizations that congregate to build the public goods they desire in the commons. Just like citizens, members of communities have a choice of voice or exit that they make based on the expected influence they have as citizens. There are enough similarities to justify learning by example.

On being a contributor

Democracy means “rule of the people”, and postulates, amongst other things, for each individual to be equal before the law and to have a vote in the political process and election of the government. This immediately boils down to the central Yin-Yang question of who is a citizen and who is not. Are users considered integral parts (citizens) of the Open Source communities, or outsiders who provide feedback? And should they be the equals of developers?  While today we seem to think that equality comes standard, it is in fact a dynamic concept, its meaning changes with culture. Think about the Voting Rights Act of 1965 that finally abolished voter’s discrimination by race in the US, or the fact that women will gain the right to vote in Saudi Arabia in the year 2015. This is what Glyn observes - users changed from being integral elements of the community to playing an only marginal role, akin to not having a vote.

Eligibility and acceptance are what discerns citizens from barbarians and slaves. Eligibility answers the question of which individuals can potentially become citizens. Acceptance is the requirements an eligible individual has to fulfill to gain citizenship. For example, a foreigner living in a country may be eligible for citizenship, but to be accepted needs to pay taxes for a number of years. When the same questions are applied to Open Source communities, they translate to “Who is a contributor and could thus become a citizen of our community? How does somebody join the project?” and second, “What does a newcomer have to do to be considered a contributor, a part of the community?” (does that sound like “How do I become a committer”? - exactly). In Open Source communities usually all individuals are eligible to join, but to be accepted and integrated, they need to contribute to the code.

So for users to become integral parts of Open Source communities again, users that engage with an Open Source project need to be equal contributors amongst peers, to be eligible. This is far from standard, and not the mind-set of most contributors I know. Most communities I work with value direct contributions to the project source code higher than feedback from users. They (unconsciously?) consider users outsiders and refer them to talk to the issue tracker, a proven way to make sure they never come back again with more feedback. So firstly, users need to be considered eligible to become community members, and second their efforts (feedback, for example) need to qualify them for acceptance as ordinary contributors.

On Open Governance

But not all communities are created equal. When evaluating how democratic a community is, we need to look at their reason to exist. Not all Open Source projects are created by developers and users together, and the distribution of power and responsibility usually follows this outset goal or doctrine. If a project that is founded by developers and users  grows organically into an openly governed community (like KDE), it is likened to a democracy. A project that is founded by a company (think Mozilla or Qt) and maybe allows external contributors in along as they accept the decrees^wCLA of the king^wowner company aches more towards an aristocracy. Not all contributors are equals, and the ruling government cannot be replaced.

There has been a long debate over what the most central trait of a democracy is. Opinions differ, but there is one question - can the citizens, on a regular basis, re-elect or replace the ruling government in a structured process, without the need for a revolution? With this argument in mind, it becomes apparent that not all Open Source communities are democratic. KDE is to an extend, with a weak government and regular elections where every active member has exactly one vote. Think about electing a new government for Android, and the difference becomes apparent. Of the Open Source projects Glyn mentioned in his post, few can be considered democratic by this standard.

Back to the question on how to reduce the distance between users and developers and how to build communities that thrive on collaboration. Users, like any contributor, will consider the effect their investment of time into the project will have. If the utility they gain from contributing outweighs the cost of the effort to contribute, they will join the community and help with the project. The utility is directly related to the openness of the community governance; it will be less if the contributor’s influence is only on mundane details, and greater if she has the chance to become the next president of KDE e.V. This emphasizes the importance of Open Governance for the longevity and community spirit of Open Source projects. Only with both the Open Source way and Open Governance, the user experiences the freedom to create that convinces her to join the project. Democracy in communities is Open Source combined with Open Governance.

Conclusions

From the status of being a contributor - a citizen - follows the right and duty to take part in the community’s affairs. Open Source can be democratic if it treats all the community members equally. Three requirements for considering an Open Source community democratic have been developed in the discussion above:

• To be democratic requires not to discriminate amongst contributors (users and developers). Users are contributors. They need to be encouraged to join the community, to give feedback and to otherwise help improve the project.
• Demmocracy in communities means Open Source combined with Open Governance. The availability of the source code under a Free Software license is not sufficient for an Open Source community to be democratic. Without equality, without the contributors controlling the project as equals, it may be Open Source, but it is not democratic.
• Governance is open if the contributors are equals and the community elects its own representation. Defining Open Governance as the situation where the contributors are in control of their project on all levels, democracy in an Open Source project can only be achieved when all contributors have equal say on all matters of the project.

Whether or not contributors fully are equals amongst peers can only be decided by actions, not by words. The ethical question whether or not democracy is desirable for an Open Source project has been avoided in this article. In my personal opinion, Glyn is absolutely right: For Open Source to continue being successful, direct and indirect contributors need to get back to working together. With the widening appeal of Open Source software, naturally developers will become more experienced and professional, and the average user will turn to be less technical and computer savvy. This trend will likely continue with the growing user base of Open Source. And because it is inevitable, Open Source projects should instead prepare to liaise more with users and generally get good at integrating users and coders in the community.

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.