What does Community really mean? (Part 1)

How do you define”Community” in Free and Open Source Software projects? What are the roles of a community? How does one become part of a community? I think these are important questions the LibreOffice project and the Free & Open Source Software in general, and I would like to talk about this a little bit, as I felt some of the people who contribute on the LibreOffice project might either have gotten the membership section of our bylaws in a wrong way or simply didn’t understand what was meant by the term “contributor”.

This essay is not really about the interesting but sometimes fuzzy back and forth between Canonical, the Gnome and KDE projects. This belongs to another level of discussion about cooperation and community processes. Let’s start with some basic definition. When we talk about Free and Open Source Software, we essentially describe two elements: 1) the availability of the source code of that software 2) the rights or freedoms that come with the software itself both in its binary and source code form. Both freedom and source code do not imply, let alone advocate the need for a community. You can perfectly use Free Software that is not developed by  a community and it will be Free Software; it will be software that comes with a Free Software licence, conveys the rights described in its software licence and of course provide the source code and binaries. For instance, the Sylpheed mail client is a venerable yet advanced mail client developed pretty much by one developer and it is Free and Open Source Software (the difference between Free Software and Open Source does not matter much at this point). There is a fork of Sylpheed that is perhaps more popular than its parent, and it is developed collaboratively. Of course it is also Free and Open Source. Its name is Claws Mail. I use it  as my default mail client on Linux as I think it brings some features I need compared to both Sylpheed and Thunderbird or Evolution.

So how does the notion of community get into the mix? That is not an easy one to answer. Let’s just say that because Free and Open Source Software conveys certain freedoms and mandates the availability of the code in its source form, anyone can hack it. Wether its author agrees with patches and changes some new developers might propose is exactly where the notion of community takes shape. (Of course explanations on the new sociology induced by the Internet are also valid but are perhaps somewhat too broad for our specific question). As it were Simon Phipps and others, such as Yochai Benkler have defined the availability of the code both in its source and its binary form as digital commons. The term commons itself goes back to medieval economic concepts, as the “commons” were in western Europe the acres of land that was used by the community of peasants by opposition of the rest of the land that was mostly used by the local lord either for his own consumption or as a certain quantity of agricultural goods meant to be sold on regional markets.

Digital commons are thus code that is out there and can be studied, hacked, used and distributed by anyone. Sometimes the “local” rules will make it so that the author will just produce the code in an opaque way, put it in the commons but won’t do anything else and will not engage with the “community” out there. Pretty often the author will be authors who will develop the software collaboratively, attracting more contributors in the mix. That’s how Free and Open Source Software  communities start. We thus have isolated the “big bang” moment of the community in a Free and Open Source Software project. It is made up of three coordinates:

• the good will of the first author of the code
• the actual interest of people in the code and the project
• their will to contribute – and their subsequent contribution

If you tie these three elements you will have the necessary conditions for the birth of a community around Free and Open Source Software projects. And just like the Big Bang is followed by the expansion of the Universe, we now have to see how a community works.

If we study the three conditions quoted above, we will see that as soon as the code is open to participation and contribution, what’s really missing is the people able to contribute, and their contribution. This stage is crucial, as it is the real first challenge for a FOSS community. If the author of a FOSS project only codes in a language he and another person are familiar with, not a lot of volunteers will show up. In short, the author needs to make the project friendly enough so that the barrier to the contribution is acceptable  so that several people may contribute to it. Yet, you will find many people in Free and Open Source Software projects who are not hackers nor even core developers. Some will still work with code, such as QA testers or localizers, while some others will not even work remotely with code: User Interface teams, marketers, documentation writers, etc. If we push our journey to the other end of the community, we will find users. Yes, users are part of Free and Open Source Software communities too, even if they don’t contribute anything. They’re connected to projects by the mere fact that they’re using digital commons. What’s more, Free Software licences are often described as giving more assertive of users rights than of developers, which can indeed be argued in the way copyleft is implemented.

We thus find ourselves in diverse communities. They seem to encompass anyone from the core developers to the blissfully unaware end user. But how are these communities supposed to work? Can one end user show up on a forum and make demands based on his/her own needs and expect to have that demand fulfilled? Obviously no, or rather, not in this way. This is why understanding how a community works, once it is understood how communities are born and what they’re made of matters a lot.

Simon Phipps usually explains there is no such thing as a community. There are, however, different kinds of communities. According to Simon, there may be three types of communities around digital commons:

• the core developers community
• the extenders community (QA, localization, documentation, etc.)
• the users community.

Each of these communities can be seen as having its standing arranged as a concentric circle around the software commons (the code) and its influence on it decreases as it lies farther away from the code. The reason for this is the barriers of access to the code: core developers can obviously change the code directly, not marketers nor end users.

Yet, it is not as simple as that. For all the accuracy and elegance of the model described by Simon, I believe it is amendable in several ways. Also, the model ignores several elements of a sociological and symbolic nature which will be discussed in the part two of this essay. But perhaps more importantly, it takes into account the value of contribution and community process in an incomplete way. Read on!