Open Source Is Not One Thing: A Typology of Open-Source Software Sub-Genres
This paper argues that open-source software is not a homogeneous entity but rather comprises fourteen distinct sub-genres with varying drivers, governance, and funding, and proposes a typology and research agenda to address the limited generalizability of empirical findings across these diverse categories.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine you walk into a giant library and someone tells you, "All the books in here are just 'books.' They all work the same way." You might nod, but if you actually look, you'd see a huge difference between a comic book, a medical textbook, a diary, and a legal contract. They have different authors, different reasons for existing, and different rules for how you can use them.
This paper argues that Open Source Software (OSS) is exactly like that library. Researchers often treat all open-source code as one big, uniform group, but the authors say, "No, it's not one thing." It's actually a collection of 14 different "sub-genres," each with its own personality, rules, and way of surviving.
Here is a simple breakdown of their findings using everyday analogies:
1. The Big Problem: The "One-Size-Fits-All" Mistake
Imagine a doctor who studies how people recover from a broken arm. They study a professional athlete, a toddler, and an elderly person. If they average the results and say, "This is how everyone heals," they are wrong. The athlete needs a different plan than the toddler.
The paper says researchers make this same mistake with software. They study a popular project (like a Linux operating system) and assume their findings apply to all software. But a project run by a single company for profit is totally different from a project run by volunteers to help a village in a developing country. If you try to use the "company" rules on the "volunteer" project, it might fail.
2. The Solution: A "Menu" of 14 Software Types
The authors created a "menu" (a typology) to sort software into 14 distinct categories based on who drives it, who runs the show, and who pays the bills.
Think of these categories like different types of restaurants:
- The Chain Restaurant (Company-Backed): Run by one big corporation (like Red Hat or GitLab). They want to make money, so they control the menu and the direction.
- The Food Truck Collective (Foundation-Governed): A group of competing companies (like Google and IBM) join a neutral non-profit (like the Linux Foundation) to build a shared kitchen. They agree on rules so they don't fight over the stove.
- The Community Garden (Community-Driven): No boss. Volunteers grow vegetables because they love gardening. The best gardener gets to decide what to plant next, not the person who owns the land.
- The Charity Kitchen (OSS for Social Good): Built specifically to feed the hungry or help during disasters. The goal isn't profit; it's saving lives. The people working here stay longer because they are passionate about the mission.
- The School Cafeteria (Educational): Students cook meals to learn how to run a kitchen. They are there for a grade, not a career.
- The Solo Hobbyist (Hobbyist/Solo): One person building a cool gadget in their garage for fun. If that person gets sick, the project stops (this is called a "low truck factor").
- The Protest Sign (Protestware): A developer secretly changes their code to send a political message or sabotage a system. The goal isn't to fix a bug; it's to make a statement.
- The Invisible Plumbing (Critical Digital Infrastructure): These are the tiny, boring pieces of code (like
curlorOpenSSL) that the whole internet relies on. They are often maintained by just one or two tired volunteers who aren't paid enough. If they break, the whole internet leaks.
3. Why This Matters (The "Research Agenda")
The authors aren't just listing these types; they are telling researchers to stop mixing them up.
- The "Transfer" Problem: If you figure out how to keep volunteers happy at a "Community Garden" project, that advice might not work for a "Chain Restaurant" project. The paper asks: Does a rule that works for one type of software work for the others? The answer is likely "no."
- The Blind Spots: Some types of software are well-studied (like the big community projects), but others are being ignored. The paper points out that we know very little about "Protestware" (software used for political sabotage) or "Open Source Appropriate Technology" (tools for basic needs in poor areas). These are the "dark corners" of the library that need more light.
4. The Takeaway
The paper concludes that Open Source is plural, not singular. It's not just "code"; it's a mix of businesses, charities, schools, hobbyists, and political activists.
By recognizing these 14 different "sub-genres," we can:
- Understand better: Stop making bad generalizations about how software works.
- Help better: If you want to support a project, you need to know what kind of project it is to give it the right kind of help.
- Study better: Researchers need to label which "type" of software they are studying so their results make sense.
In short: Not all open source is created equal, and treating it that way hides the real story.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.