In the first part of this essay I attempted to describe how communities around Free & Open Source Software (FOSS) projects are born and what is their underlying model. After having described the conditions necessary to have communities emerge around Free and Open Source Software I used Simon Phipps’ s typology of communities in order to highlight the various roles that are found in these groups, and how several sub-groups may be distinguished inside a FOSS community. I ended up the first part by hinting at the limits of that typology. Here’s why.
The very first comment that somewhat counters’ Phipps’ s model is that it ignores the fundamentally dynamical nature of FOSS communities and the inherent sociological rejection of any real “stable” state of the social structure inside these communities. It means two things: That anyone from the end-user community may turn into a core developer provided he/she has the skills and provides relevant contributions in the relevant way (in my example, the end-user would have to contribute code patches in a regular fashion to become a core developer); second, that the members of these communities have no status that is carved in stone. You are not born a core developer, you become one, but you won’t remain one until you keep contributing. This in turn highlights two notions that are essential inside FOSS communities and that may be seen, as I wrote earlier, as an additional, yet necessary description of the way FOSS communities work through and beyond the typology enunciated by Simon.
But first let’s go back to my example of the core developer who has to keep on contributing unless his role and standing diminishes. What this example shows is that FOSS communities are at their very core “do-ocracies” ruled by the social contract created by the sheer existence of digital commons. Measuring how efficient the social contract may be means to evaluate how open and welcoming the authors/developers/core team are to new contributions. If that’s not the case then of course, FOSS allows code forking, and then the new social contract might be reinstated in a better way. What becomes apparent in these examples, however, is that the notion of contribution is perennial in assessing how a community works and what the standard for this assessment should be. Contribution is pretty much the only thing that gives both meaning and purpose to a FOSS community and is in fact the only activity that matters. The reasons for contributing code, materials, designs, documentation, QA, efforts of various kinds such as users’ support may be very different from one individual to another; the same stays true for a business contributing to such a project, yet it is out of the scope of this essay. Nonetheless, contribution is more than adding one little piece more to the overal project. It is the very fabric of the project and its community. Contributions may differ in quantity, quality and nature; the only people who are not contributing -in theory the end users- are the only ones who cannot properly have their say inside the project by themselves. This sentence needs to be clarified: Unless someone engages with the project by contributing something it will benefit from the protection and the rights of the FOSS licence itself and the availability of the said software as a common digital good. Beyond this, his/her standing inside the project is theoretical. This is why the end-user community lies the farthest from the core of the project. Of course, and this is especially true in projects developing software meant to be used by everyone (i.e Mozilla Firefox, LibreOffice…) end users may be regularly heard because dedicated activities and teams will collect their feedback and engage volunteers in user experience testing, designs, etc. But the very same people engaging in these activities cease being passive at the very moment they start contributing time, effort and sometimes expertise to these activities and enter the “extenders’ community” if we stick to Simon Phipps’ s model. It is therefore crucial not so much to implement users feedback strategies – that truly depends on the project and its scope- but to make sure the barriers to contribution, not just of code but of anything else is low enough to encourage end-users’ interest and involvement.
Contribution also breed what I often call the sense of appropriation, which is, for any given contributor, the feeling of co-ownership of the project and the digital commons developed by the project. This sense of co-ownership implies the adherence to the project’s goal while steering the will to do more and be more inside that community, depending of the person. This sense of appropriation may wane to the point where the contributor will stop contributing, and if several contributors lose appetite and fun contributing it is often a clear sign that something wrong is going on inside the community.Therefore the concept of meritocracy ,when properly applied in a community, is usually one of the best tools to grow that community as it remains as one of the main, if not the sole sane principles of community building. Meritocracy is the direct consequence of the value of contribution in a FOSS project. Anything else in FOSS, such as democracy, ultimately lowers contributions to the benefit of uninvolved people and to the law of numbers, masses and manipulation. That’s why FOSS has never been about democracy but about meritocracy, even if it practices limited democracy among its contributors. But that notion belongs to community processes. Read on.
I have written above that contributions may differ in quantity, quality and nature. It is pretty often difficult to judge contributions objectively when they are made in code patches or bug reports. There are however many other ways to contribute aside code in a FOSS project. The question is not whether there is a standard to assess contribution; there is none, really and each community will evaluate them in a different way depending on its purpose, its history and its sociology. The question revolves around the decision-making process either in between various teams of the community. A good example is a situation where core developers want to go ahead with a release of a version they deem to be stable while the QA team is in disagreement with the core developers because of one specific outstanding bug that’s considered to be annoying enough to block the release. Staying within that case, let’s picture the UX team (user experience team) with one latest push on icons or one specific graphical detail, requesting the inclusion of its latest effort to the core developers. Can anyone tell who will have its own way?
If we refer to the threefold typology of the community described by Simon Phipps, the model is very static but one would say that the core developers would be able to dictate their own decision to the others as they are the ones who directly write the code and therefore have the broadest influence over it. While this is true, the ultimate consequence of this would lead to the complete disintegration of the community, as the powers would be vested once and for all to the core developers with everyone else bowing at them. While developers do make the code, the digital commons, by themselves (although it could be pointed out it’s not always the case) we could demonstrate that the domination of one category of contributors by the others is tyrannical and goes against meritocracy. If marketeers were to have their say in a constant way over developers, this would not be a Free and Open Source Software project anymore, it would mean working at Apple Inc. This highlights the need for community processes. Community processes are not just the processes leading to code creation and release. It is pretty much anything from governance to team setup, conflict resolution and release process.
Community processes thus have a rather broad scope. But they are -or should be- designed to strengthen and uphold meritocracy and transparency, by making sure specific rules of community work are clear and known. They are also supposed to provide the necessary environment for balancing power, which means that they define governance and governance processes. Community processes and governance do fulfill a need that the sheer meritocratic structure does not or rather cannot meet: it manages issues and decides of the political structure (political here is understood in its first sense, that is, the concern of the polis, the city, the tribe) of several people working together on specific but different tasks as a community.
We can now manage to enunciate the following propositions:
- contributions are the fuel for a project (not even money, and even less talk)
- community processes enable issues and conflict resolutions through governance and lower-level processes
- these processes cover contributors inclusion and allow them to contribute.
The term “community” thus needs to be defined with a certain accuracy as it covers several realities and as it is not necessarily a well-understood term. I can roughly and simply answer the initial question with the following (long) sentence:
A Free and Open Source Software community is a loosely knit group of teams and individuals contributing in various ways to a specific project with the help of specific tools, processes and governance yet without any overarching authority imposed from an external source, but from a structure that stems directly from themselves and ensures that the merit of each is rightly valued and taken into consideration from the ground up and in a transparent way.
Comments welcome!
