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!

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!

Yesterday the Document Foundation has released LibreOffice 3.3 . I guess you may already have seen the news if you read this blog. I wanted to express my joy and my pride of our community who made this release possible. Not only did we make our first release, but we also showed everyone we could improve the software in a significant way. This is just a beginning as you can imagine. In addition, we have now published our short term roadmap (stay tuned for our other releases of February, March and May) and announced our will to work along time-based releases.

All this would not have been impossible without the incredible community of LibreOffice and I would like to thank every contributor for such a great work. It is impressive to see both the spectacular growth of our project when healthy principles and fundamentals have been used since the beginning and the unavoidable, yet relative chaos and conflicts of a community in formation. In a sense it’s a bit like the beginning of an universe: it starts with a big bang. Only here, we are merging evolution with intelligent design.

I am also impressed by the international press coverage we’re getting. It takes about 24 hours to perceive the full span of the articles, and I don’t recall OpenOffice.org ever had a similar coverage, and the tweets with the hashtag #LibreOffice are flowing by the hundreds every hour now. So again, Iwould like to express my heartfelt congratulations to everyone who made this possible: you can be proud of you!

Today is a special day. I feel both sad and relieved, happy and somewhat disgusted. I have officially resigned from all my duties, roles and positions inside the OpenOffice.org project. My resignation is effective immediately and I am leaving the project. I will now be contributing to the Document Foundation, while of course continuing to work at Ars Aperta and at the OASIS as a member of its Board of Director, eGov Steering Committee and ODF Committees.

These past days have been tense. In a sense it was to be expected, but on the other hand I feel that it was in fact quite surprising and unprofessional. The Oracle employees who are members of the OpenOffice.org project and who expressed themselves these past days have displayed a disturbing lack of understanding of Free and Open Source Software; LibreOffice is, after all, and until proven otherwise, a downstream version of OpenOffice.org, and as such deserves inclusion into the OpenOffice.org community.  I can only imagine what it would be like if Debian was rejecting the Ubuntu employees among its teams, calling it a fork.  As for the fork itself, and because we’re still a downstream version of OpenOffice.org, forks become forks only when one of the boys refuse to play ball with the others; and the Oracle team of OpenOffice.org just did that. As such, and you might call this disingenuous, they created the fork and bear the final responsibility for it; of course the community at large created the Document Foundation and LibreOffice, but the astounding lack of dialogue, the immediate labeling as competitors from the very second the Foundation was announced created the fundamental rift that turned a potential, vague state of things into a hard reality.

Now, this is not going to be an Oracle bashing blog: I would like to thank the engineers of Hamburg, the former Sunnies and StarDivision employees for the opportunity and honour they gave hundreds of people like me to work on their side and contribute to a quite unique project. They’re good people. But History plays against them. In any case, they are for ever welcome inside the Document Foundation. Fair winds, Genossen.

This post would not be complete without my final message to the Native-Language Confederation of OpenOffice.org, the bulk of the worldwide communities forming the heart of the OpenOffice.org communities: this is my message of resignation that I’m reposting here:

"It is with great emotion that I am resigning from my role as lead of
the Native-Language Confederation of OpenOffice.org. This resignation
is immediate. It has been a pleasure, a lifetime experience, a honour,
to work with all of you for 10 years. When we started, we were around 3
to 4 projects. We are now over a hundred communities, reaching
worldwide a hundred million of users. This has been the achievement of
the OpenOffice.org community, it has been our achievement, and let no
one take this away from you. I look forward working with all or most of
you again in The Document Foundation, and am considering the future
with optimism. Last but not least, I would like to thank all of you
here, in the OpenOffice.org community, who made all this possible, and
even gave me a chance to become someone better. You can be proud of you.

Cheers up!

Charles-H. Schulz. "