Affectio Societatis

I have been meaning to write this post since this Summer, and since we will have a session at the Paris Open Source Summit in November about this topic, I thought now is the right time to discuss it here.
There is a mystery of sorts about the reasons people have (or think they have) to contribute to a Free and Open Source Software project. It seems very few people can explain it and it continues to puzzle everyone in the industry, the press and the governments alike.

The funny aspect of the question, by the way, is that this mystery could very well be ignored by everybody if it wasn’t a key element in understanding how online communities and Free Software projects work: It isn’t unusual, after all, to witness some corporate-owned and aging codebase being dumped into an established FOSS foundation and after a few years or even months, realize nothing’s actually coming out of it…

In order to “solve” the mystery of the Free Software contributor, I think all we need is to approach it in a simple yet subtle way. And that starts by acknowledging that in lieu of a mystery, we may have quite a lot of them. E.S.Raymond, in his seminal work “The Cathedral & the Bazaar”, puts in straightforward terms that people contribute to FOSS projects because they have an itch to scratch. This is quite an important reason, and it certainly defines a clear set of motivations for people to contribute. In this approach, you rely on a given software for a given set of tasks. This software is useful to you for a variety of reasons but a specific need or set of needs, aka a feature or maybe a detail in an existing feature is missing. Therefore you may become a contributor by filling in that space, by coding the missing feature. My perception of this approach is that it’s a working one, but that it is more elegant than straightforward and above all, it isn’t a really compelling one. I am not a developer, yet I started to contribute (in non-code contributions) to the OpenOffice.org project in 2001. Why would I ever do this? I had no itch to scratch and my motivation was perhaps not so rational after all. And what about the developer who, having scratched his itch in a satisfactory way, moves on to work on yet another bugfix or feature within the same project? Is that another itch? If not, then what is it?

My suggestion above is that perhaps the mystery requires simplicity and subtelty. If we try to keep this simple then we could first say that there seems to be a variety of reasons why anyone would contribute to Free Software projects, and that it is true regardless of the ability to be a developer or not. Let’s outline some of them, and just the ones that I can quickly list of common reasons without trying to be exhaustive:
– my employer pays me to contribute to this particular project
– I came with an itch to scratch and stayed for the fun (nice community, the code is interesting)
– it’s a technical challenge or at least, I like the software and the technology for what it does, so I think why not try to participate to its development?
– my university curriculum requires that I pick one FOSS development project and contribute to it in a regular fashion for a fixed period of time
– I just want to be part of a group
– people are friendly, I came in to ask a question as a simple user, and stayed to help others. Soon, I found myself doing quality assurance
– I truly believe this projet may change the world and make it a better place so I’m here to give back to it and help it grow

Among all these stated motivations, I see very little of an itch to scratch, but I see a lot of personal reasons blended with external motivations (career, research, etc.). At least what we can now say is that there seems to be a variety of motivations for people to contribute to FOSS projects. The question at this stage becomes really political: Considering that such a project relies on its community of contributors to function and be succesful, what makes a great FOSS project? How does one attract skilled contributors, make them stay and grow its project? Make no mistake, this is the crux of the problem for many people, from corporate strategists wondering how to make a project successful without investing too much in it to research circles wondering why this or that project failed to take off. To all these people wondering about what makes a FOSS project great, there will come a moment where they will put their finger on the supposed reasons external contributors (anyone, really) may have to spend time, effort and sometimes money on their project. The answer, however, is both simple and complex.

Meaning

For a project to exist, you actually don’t need it to mean anything. A project may actually be absurd; or more likely it may be a project that is public -i.e. it has a website and a mailing list for announcements- but makes little sense beyong the individual situation of its author(s). For a project to aggregate a community of contributors and grow in code, quality, userbase and outreach, this is very different. The meaning of the project could not be entirely explicit, but it needs to make sense. If you think this is obvious, then you may be mistaken by the simple term “meaning”. As an example -and it is not an opinion, but an actual example- I have never quite gotten around the true meaning of the Apache OpenOffice project. Before you think I’m back trolling on the matter, hold on and think about this: why does Apache OpenOffice even exist? We all have more or less informed background on how it came to existence, but not about the meaning of its existence. To be more clear: if LibreOffice exists, why does Apache OpenOffice exist? At that point, and keeping in mind that both projects do exactly the same thing, which is to develop a FOSS office suite starting from the same codebase, there needs to be a difference in the technological approach or in the choice of features. If not, or if these differences are not really clear to enough people, then the only difference left is one to be found vis-à-vis the other project. But then things get unhealthy, because it means that -and this is the case with Apache OpenOffice- the only meaning is to deny any value or at the very least position itself against the other project, in this case LibreOffice. When you analyze the meaning of Apache OpenOffice, you only find the claim that despite the documented history having taken place since 2010, Apache OpenOffice is the legitimate successor of OpenOffice.org, and that is great and cool, you see, because this project is the successor of OpenOffice.org. No wait: it IS OpenOffice.org, reborn under the Apache Software Foundation, and that’s even better. Except that at this point, you’ve lost 99% of your audience. What about the meaning of LibreOffice you may ask? LibreOffice is born from a community and came with a manifesto clearing stating what the project was aiming for, and quickly did things very differently from OpenOffice.org and Apache OpenOffice. Also, it never published anything about Apache OpenOffice but only spoke of its activities, its new features and the people contributing to the project. Meaning was created out of that, meaning was nurtured, grown, and in the end, people started making the difference, users and contributors alike.

Community

Once you have meaning, you need to have code. And not just code in fact: you need to rely on some infrastructure and collaborative tools to enable contributors to work on the project. It’s all right if not everything is there in the first place: but if you don’t have anything to show after a while and there’s only an announcement mailing list, do not expect that people will keep on knocking at your door for ever.
A community of contributors is a strange thing. On one hand we speak of communities as actual entities, but when you look closer you tend to see that these are quite fragmented circles. Core contributors may never speak to documentation writers; people providing online users support for free may rant against developers and have the perception that changes “made from high up” only break more things but seldom improve them. And then you have designers, people working on quality assurance, even in some cases people promoting or working on the outreach of the project, who have their own tasks, their own perception of the project. And yet everyone tends to feel part of one wholesome project, one community. My point is that in order for this to happen, you need to enable a community with tools, infrastructure and code. Anything else would be a forum for hobbyists.

Ownership

Now we’re reaching something that is a bit hard to explain. There are roots in psychology and behavioural sciences for this, but let’s keep this as clear as possible. In a nutshell, people won’t stay as contributors (unless influenced by external factors, such as their job) if they do not feel like they own at least a piece of the project. Of course, this ownership needs not be an actual property: everything may be under the licence most approved by the FSF. People still need to feel they own something of the project. Most of this is unconscious or at least not explicit even to the contributors themselves. This ownership may not be expressed as a feeling of owning something; it could be an attachment to the project like someone is attached to or cares about another human being. In any case, there’s a deeper relation that each contributor needs to grow overtime with respect to the project. What can be done to enhance or enable this sense of ownership? Since this is so personal the answer may not be easy to find, but things such as ensuring the project is understood as a common good, as a place anyone with the right attitude and the right amount of work can influence are generally factors increasing this sense of belonging to the project? Anything displaying a differentiation of one contributor -whoever this may be- based not on its contributon and accepted social role in the community, but rather on external priviledges (“I own the server, damn you!”) tends to be unhelpful in that regard.

Technology

This last point tends to build upon all the others, but is distinct from them. Let me ask the following: what attracts someone towards contributing to Nginx rather than the Apache server stack? What about the opposite case? Both projects have pretty much I’ve described above; they all have rather large pools of contributors; their internal structure and governance is different, and they are direct competitors in the market. The choice someone can do between the two relies upon a personal situation, but most of the time it will be about technology. The technical approach of one may prompt someone towards one of the two. Languages, platforms and technologies matter a lot: if you want to code for LibreOffice, it is easy once you know C++ or Python. If you are used to tinker with Clojure or Rust, the project may simply not appeal to you.

There is an old term in Latin: “Affectio Societatis”. It is still used today in legal systems, mostly in continental Europe. Its rough meaning is: “the will to be part of a group ( company / community  /band/ whatever…)”. The notion describes the personal will, expressed in various legal forms, to be part of a group that anyone may have at some point in his or her life. This is something that is deeply human, and yet not so familiar to anyone. In the 21st century it has become an important question for the IT industry: it is fascinating, misunderstood and lies at the cornerstone of failure or success for online development projects. May we never neglect this grain of sand that is so human and yet so alien to so many out there.