This article is cross-posted from The Lead Dev and juliaferraioli.com.
Open source software (OSS) in spirit has existed since the 1950s, when researchers and academics shared source code with each other, treating code as a common good. After a court decision rendered code copyrightable in 1984, the Free/Libre/Open Source Software (FLOSS) movement started in earnest. Just a few years later, the first license that embodied the spirit of open source was created, though it is debated whether this was the GPL or MIT.
Open source is software where the code is available for anyone to use, integrate, examine, modify, and distribute. Christine Peterson coined the term in 1998, and the Open Source Initiative crafted the commonly accepted open source definition (OSD) shortly thereafter. The OSD adds requirements that prohibit discrimination against people, groups, fields, or technology. Because of the complex legal, technical, and social criteria around open source, most of these are covered by a license attached to the software.
That said, there’s so much more to open source than what fits into a license. It does not cover development philosophies, social structures, governance, or anything else that makes open source the rich ecosystem that it is today.
Technical model versus social model of open source
Defining open source by what you can and cannot do with it is the technical model of open source. It describes the minimum set of criteria for what software needs to do for others to be able to safely use it. This technical model works for establishing this baseline, giving everyone assurances that they can use software without getting into legal hot water.
Some take the position that software is not open source unless it accepts contributions, or has a governance structure, or has maintainers actively engaged with their users. People bring their own opinion to what open source is, and that can lead to mismatched expectations.
Instead of overloading the technical model of open source, we can overlay a social model that adds nuance and further describes aspects of a project.
The social model of open source describes the sociotechnical expectations of how open source interacts (or doesn’t) with the larger ecosystem and the people within it.
I’ll be writing a series of articles defining the characteristics of a social model of open source. In this first article, we will start developing this model by considering the purpose of different open source projects.
Breaking down open source projects by purpose
The first step to creating a social model of open source is to think about how projects differ from each other.
In her book Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure (pp. 20-21), Nadia Eghbal takes an analytical approach, describing different categories of software based on their function: frameworks, languages, libraries, and servers. These categories frame how software is used by developers or end-users, and help people find and identify open source projects of interest.
With a social model in mind, let’s take a different approach to categorizing projects, and instead consider the high-level purpose of _why _something is open source.
Below are a few example categories that can apply to open source projects. Focusing on the purpose (or purposes) of open source projects allows everyone to better understand the motivations of projects and have realistic expectations for how the project will operate.
Collaboration
Most well-known, larger projects fall into this bucket. Collaborative projects are what many people think of when they hear the words open source. They aim to bring the expertise of a wide range of people to build technology, together. Examples of collaborative projects include
Python and Kubernetes.
Demonstration
Demos are often snapshots in time, created to showcase an aspect of technology. They are typically small, self-contained, and single-purpose. Demonstrative projects can range from the practical stress-testing of a particular feature to creative, wacky ways to use them. Examples include WebRTC samples and the Dependabot Demo.
Education
With all the different frameworks, languages, tools, and more available to developers, educational projects are invaluable. Educational projects demonstrate best practices, patterns, and concepts. These projects are open source so everyone can learn from them. Examples of educational projects include Intro to Vue.js and Whispering Gophers.
Validation
We have seen how important validation and verification is for reproducing results in research, which is why more and more journals and conferences are requesting that article or paper submissions are paired with reference implementations. These projects rarely see updates or bug fixes, but it is important for them to be open source in order for others to study the code, learn from them, and incorporate the methodologies into their own applications. Examples include ACORN and LMSOC.
Facilitation
Projects whose purpose is facilitative generally help people use other technologies, most often proprietary technologies. These may be tools, SDKs, or other utilities. It is useful for them to be open source so that developers can extend or customize them to suit their own purposes. Examples of facilitative projects are ld-find-code-refs and the Netlify CLI.
Experimentation
The vast majority of open source projects in the wild fall under this characterization! These are the seeds of new projects, projects that are for tinkering around, and aren’t necessarily ready or even intended for others to use. Examples of experimental projects include Tex Customizations and install-next.
Developing the social model, together
The purpose of open source software is just one characteristic of a social model. There are others that we can and will explore together in future articles. By developing a shared understanding and vocabulary of open source beyond the license, we help maintainers, contributors, and users communicate and collaborate in a way that enriches the spirit of open source.
Top comments (0)