The KL10 PDP-10 at MIT. It ran ITS from 1975-1988. Photograph by Don Hopkins.
Open Collaboration
Wikipedia may be the fullest realization of a truly open community where anyone can contribute. It’s proof positive of radical openness, an idea that dates back to the ITS at MIT in the 1960s.The Incompatible Timesharing System (ITS) was created at the the MIT Artificial Intelligence Laboratory. It first became operational in 1967. As the name implies, the system was an ideological response to the MIT Compatible Time-Sharing System (CTSS). The influential operating system saw the first versions of Emacs, a text editor used by many to this day, popular games like Zork and the multi-player Maze War, and languages such as Maclisp and Scheme. Astonishingly, you can access a real ITS system connected to the internet running on a PDP-10 at the Living Computer Museum. Simply click here and sign up!
In both Wikipedia and ITS, no single person owns any single file; the system’s content can be improved by anonymous people accessing it from the network. Wikipedia essentially brought these ideas out of the lab and into common parlance to astonishing effect.
But a system that is technically open can be still be closed in spirit. This is where Wikimedia initiatives tend to fall short. On Wikidata, for example, painters that identify as women represent only 17% of all painters. This is the same rate of representation found at the Tate in the United Kingdom.These are my personal calculations. Proof of work is available as a runnable notebook on Nextjournal: The Guerrilla Girls: Equality and Activism in the Internet Age.
Technical openness has provided no meaningful improvement over the notoriously closed world of art.
Open technology hasn’t made conventional power structures less prevalent. The closed culture of Wikipedia/Wikimedia is just one prominent example.According to Wikimedia’s own 2018 survey, only 10% of the contributors are women. 
This has contributed to accusations of unfair editing practices and an unfriendly community.
Unfortunately, the burden of good practice falls on each individual volunteer. For people giving up their time, it may seem like asking a lot for them to also reflect on their practices. But the way they represent the community is just as important as any contribution they make.
A recent personal experience may seem benign on its own, but consequential when considering Wikimedia’s poor record. I wanted to edit the number of registered users/contributors on Wikidata because the entry is both incorrect and not cited. After finding nothing in the “help:items” documentation, I asked for help editing “semi-protected entries” such as this one. Hazard-SJ offered an answer that embodies the generally unhelpful ambivalence towards new users:To be fair, not every Wikidata member answers this way. the-erinaceous-one provided a complete and useful response to Nigeria’s Madonna Onwuka when she asked about the difference between Wikipedia and Wikidata just days later.
Hi Schmudde, semi-protection is described in the page protection policy.
That’s it. Not quite a simple RTFM, but pretty close.“Read The Fucking Manual”
Open Open Collaboration
An open open source community must make a coherent effort to include people from a variety of different backgrounds and experience levels. The process can be frustratingly slow because change takes time. It’s important that the community sets realistic short-term goals, look for incentives, and reassess at regular intervals. Lots of strategies will not work, but consistent effort will lead to meaningful moments and eventual change. My personal highlight was as a lead instructor at ClojureBridge NYC 2017.Pierre de Lacaze and several organizers at LispNYC did much of the hard work of organizing this event.
I spent a weekend sharing a technology I care about with a hundred women eager to learn a new language. Win win!
A culture of real openness must start early because a community’s values become more deeply entrenched over time. This also holds true for mentorship. While teaching others may cut into time spent coding or contributing, adding empowered contributors pays long term benefits.
Contributor agreements must be stated early and their clarity should not be presumed - especially over the span of a project’s life. The Clojure community experienced a significant disruption around this issue and several valuable members of the community left.Zach Tellman’s exit from the community was particularly disappointing for me. He wrote one of my favorite books on programming, Elements of Clojure. It should be on every programmer’s reading list.
This problem may not be unique to Clojure, but it is noteworthy because it happened over a decade into the language’s existence. It illustrates how a community’s expectations can change even if the terms of contributing do not.
Discourse Does Not Scale But Culture Does
A project’s adoption is a prerequisite for any of these concerns.The Clojure community is relatively small compared to contemporary languages like Python. There are several reasons for this, but Python’s adoption by the machine learning community has skyrocketed the language’s popularity. A “killer app” like machine learning is the cornerstone of an open initiative’s broad adoption.
Maintaining a constructive discourse can become increasingly difficult as more and more people arrive. The internet, with its myriad of tools and approaches, offers little that makes this problem any easier.New terminology and management efforts appear all the time. Arne Brasseur recently brought the concept of a missing stair to my attention. It is a term that identifies a person that everyone in the community knows is a problem, but tend to work around. The missing stair is especially dangerous to newcomers that do not have the institutional knowledge to step around. The problem has been formalized in various places, including the Orogene Code of Conduct.
Project stewards must find a way to make their contributors feel heard even though they cannot listen to everyone. This is where culture is everything.
Project stewards guiding a large project must think small. A couple of contributors working on a small projects can provide invaluable insight. A few hours mentoring every other week adds up. Virtually drop into a ten person meetup in Kenya and listen to people coming from a different place. When human-sized experiences frame the big conferences and monumental decisions of a large project, a robust culture will emerge.