Gemeinschaft in the net: a study of open source software and online communities
“Gemeinschaft” is a term used in sociology to describe social relationships that are based on shared values, beliefs, and traditions rather than on individual interests or needs. It is a form of social life that people have lost with urbanization and the breakup of traditional families. The new sociality is based not on an immutable shared identity but on fluid interests. Trust is created by impersonal rules and institutions, not by interpersonal relationships and the belief that you are dealing with good people. To save you hours of reading the classics of sociology, it is believed that having no Gemeinschaft makes it harder to coordinate joint action. But more importantly, people are sad when they are lonely.
It is very difficult for a modern urbanite to find Gemeinschaft. Belonging to a group requires the development of a collective identity. Still, neither religion, ethnicity, nor family is accessible anymore as a basis for it: the church carries opposing values, we are not racist anymore, we do not trust the government, and our familial ties are limited. The best-case scenario for acquiring a collective identity is to join a club. However, clubs are based on changing interests and are composed of strangers who come and go. Just remember Fight Club and how easy it is for a woman to walk into a testicular cancer support group. Compare that to the year it took us to start attending services at the synagogue because of how protective that community is of itself.
When deciding how much to invest in a community, people consider the severity of the consequences if they were to lose it. For example, if we were to commit an unforgivable act that causes the Jewish community in our city to ostracize us, we risk losing everything from our gastronomic preferences to my dating life and your spiritual practices. In contrast, being mean to people in a book club has little impact on a person’s life; find another one. There is no reason to invest as much time and resources in understanding and following the rules of a community that is easy to change for another one.
Gemeinschaft might not be gone, though. There was a brief period in the development of the internet when it seemed like primordial social structures were established again. People found themselves belonging to a particular internet “village” that did not overflow with other “villages”, had a defined list of members, and relied on the community as a whole to solve conflicts. They were not based on immutable traits, but they had other characteristics of a Gemeinschaft.
One example of human activity that early internet communities have chosen as the centre of gravity was creativity. In the awesome book I read, Working in Public: The Making & Maintenance of Open Source Software, the author examines open-source software as an example of human creativity and the lessons it can teach us about shaping our communities.
What does a developer do all day
Before analyzing the sociological aspects of this book and pondering the nature of humanity, there are some things that need to be explained about the world of coding. I have to say this book was incredibly comforting in its explanation of what programmers do all day because, as a beginner, I have always thought that it is me who’s doing it wrong. So here is the process of working on a coding project.
Given that there is a clear vision of what needs to be done, my first step would be to search for existing code on GitHub and then watch a wise Indian man explain it to me. It will cover some of the things I need but not all, and it is going to require adjustments for the particular purpose. The code I find on my first search will become the first building block for the finished product. This first block is going to run just fine, but pasting the second block into the file might cause a miniature explosion.
(…) when a developer copy-pastes that code into their own software, it suddenly comes to life. It might break instantly. It might break their other code, and now they have to rewrite everything around it. When software transitions from static to active state, it starts to incur a set of hidden costs.
At this point, I would turn to Stack Overflow, a forum for coding issues. In many cases, it turns out that the first block has received an update, and its prior successful execution was due to a pure lucky aberration of the Universe. After spending several hours reading forums and documentation, I would locate up-to-date versions of both blocks and repeat the process for every additional element in the code. In a month or two, the process repeats again, as at least some of the blocks have received an update that wiped out the functionality I used or changed how certain commands should be applied.
The “block” here refers to a library of commands: instead of describing the whole process of making a kugel to a computer, my code would feature a command “cook(kugel)” that would prompt it to look for what to do in the external library, that I do not control and am only connected to. This allows me to use the functionality without knowing how it actually works. This saves time and enables less experienced programmers to work on more complex topics.
Both the content on GitHub and Stack Overflow is maintained by people who simply enjoy writing code and solving problems and do not care about getting paid for it. Of course, there are reputational gains from being a popular open-source developer, but come on, there is no difference in financial compensation between a good developer and a good developer who is also popular. Additionally, the general psychological profile of a person entering the field does not suggest a thirst for fame.
A detour
A note that I would like to share with you, which is not relevant to the overall story, is the way the book conceptualizes the work of a software developer. While software can be created as a single piece of art, it cannot be used as such. The world around the software changes, including other software. Our devices get faster, our needs change, and some annoying bugs are fixed.
Software developers are not paid for the text files they produce; they are paid to keep the software running while every building block inside it is constantly evolving and breaking everything around it.
Of course, it is possible to wish really hard to stop time and refuse to update the software. There are examples of software being conserved, such as the software used by banks whose executives do not understand what better programming languages can do that their own cannot. These banks still require programmers writing in COBOL despite it being over 60 years old.
COBOL, another programming language, was first released in 1959 (…) a notoriously bad programming language. (…) Byrne Hobart (…) declares that “we either need to pay people to learn [COBOL] or put them in jail if they try.”
Making Open-Source Software
Open-source software is widespread. Basically, every single corporate-issued software includes several dependencies on code that the company does not control. Besides the security risks this creates, it raises the issue of maintaining open-source software, facilitating its continued support, and creating incentives to encourage its growth.
(…) Bootstrap, a popular design framework used by an estimated 20% of all websites,4 where three developers have authored over 73% of commits. Another example is Godot, a software framework for making games, where two developers respond to more than 120 issues opened on their project per week.
In many cases, big and critically important projects are maintained by no more than two or three people. It is a common story that when the original author of the project loses interest, the entire project goes with them. “The Bus Factor” is a term used to describe the project’s resilience. It signifies the number of people who would need to be hit by a bus for the necessary knowledge for the project to be lost.
The tendency of open-source software to randomly flatline is costly. When a major project dies, it creates a void that the largest software consumers attempt to fill with alternatives. This process is chaotic and expensive.
Feeling overwhelmed with attention
The first solution that comes to mind is to increase the number of people involved in the projects. Nadia Eghbal, however, argues that attracting more people is precisely what causes projects to die and developers to burn out.
An open-source project typically starts with a small group of friends who are passionate about an idea. They write their code and consider the idea realized. However, as more people discover their code and find it useful, they will start reporting bugs, requesting updates from the developers, or suggesting their own modifications. Other people may need educational support to learn how to use the code. This is where the omniscient Indian men come in.
The book argues that the more contributors work on a project, the more resources are spent on communication between them. At some point, developers may spend more time talking to people than working on developing their ideas. They realize that this is not what they want to be doing with their time and career, which leads them to kill the project many people and companies rely on.
The newcomer effect is also known as the “Eternal September” problem, a term coined by members of the early online community Usenet, which experienced an influx of newcomers every September due to new students getting access for the first time. But once America Online (a sort of early highway system itself) began offering access to Usenet, the service provider exposed the community to a constant stream of new users, creating an “eternal September.”
New users or contributors aren’t familiar with the established practices of the original team and rarely fully integrate. They may not take the time to read the requirements for formatting their suggestions, making it harder for the developer to navigate the growing flow of messages. While there are usually rules and traditions associated with each language and each particular branch of applying this programming language, people who are just passing by and trying to help have no way of knowing these rules.
The developer’s message box will get overwhelmed with requests for functionalities that are already being developed, features that have already been considered and rejected, and questions that have been addressed. As the number of messages increases, people become less willing to read through them to find out if somebody has posted the message they want to send already, which creates a vicious circle driving the developers mad.
Casual contributors are often aware that they have little context for what is going on behind the scenes of the project. But more importantly, they do not want to spend time familiarizing themselves with a project’s goals, roadmap, and contribution process. These developers primarily see themselves as users of the project; they do not think of themselves as part of a “contributor community.”
Feeling invaded
With more attention turned to the project and more people contributing, the conflicts between developers become subject to public discussion. There is often a negative relationship between how much a person is involved in the project and how entitled they are to express their opinion in a Twitter discussion.
In 2015, a controversy dubbed “Opalgate” arose on the Opal project when a maintainer’s comment about transgender people on Twitter led to a developer opening an issue calling for the maintainer’s removal and questioning the project’s inclusivity for transgender developers.
Although Opalgate was ostensibly about whether a maintainer’s personal political views should affect their ability to participate in the project, another reason the issue blew up the way it did is because it was opened by, and attracted pile-on from, developers outside of Opal’s contributor community.
In a field that exists solely due to the unexplainable creative desire of a few individuals, even seemingly trivial psychological pressures can have a significant impact. Since developers are primarily motivated by enjoyment, the burden of dealing with others’ opinions can quickly turn a project that was once a fun hobby bringing respect from peers, into a burdening obligation.
We need a village to manage a public good
It was only in 2006, when Facebook introduced the News Feed, that we got our highway system. Roads and bridges, like hyperlinks and news feeds, brought together previously disconnected rural towns, forging paths between those that once sat blindly within arm’s reach.
The difficulty with developers being overwhelmed with attention and people’s opinions on how they should spend their time only became pressing with the rise of GitHub. While the platform allowed for incredibly easy access to code and larger exposure, it is also the equivalent of Facebook in what it did to our social structures. Social media platforms have destroyed internet villages. They mixed communities together, blended their borders, and made the tight-knit social life impossible.
The book argues that a developer's attention should be treated as a public good facing the tragedy of the commons. Looking at Ostrom’s criteria for successful management of public goods, they curiously overlap with a Gemeinschaft:
- Membership boundaries are clearly defined, and people don’t easily enter and exit;
- The rules that govern the Commons should match the actual conditions, and those who are affected by these rules can participate in modifying them;
- Those who monitor the rules are either community members or are accountable to the community rather than outsiders; conflicts should be resolved within the community using low-cost methods.
Hence, the question that people who enjoy open-source software and want there to be more of it should be asking is, “How do we close off the communities and deter people from engaging with the projects?”
The book then goes into discussing the ways this can be achieved, but I find it trivial. It also discusses the ways developers can be compensated for their work, which is also unlikely to spark your interest.
Thoughts
Overall, this book is a wonderfully crafted example of a very simple idea that, in my opinion, should be more prominent in modern discourse: people require well-defined, traditional communities to function and achieve their idealistic goals. This does not mean that we all have to run naked into the forest in search of primal sociality. Instead, it means that a set of design principles can help us effectively manage and channel the beautiful force of human creativity and willingness to help and contribute.
The all-encompassing openness and transparency that we often strive for can leave us with nothing that is truly ours. Strangers telling us how to solve our conflicts and good Samaritans offering their suggestions on improving our work are the biggest obstacles to creating more things that will hopefully make people like us happier.
Support Kugel Books and Buy on Amazon 🐌
