Every serious software product runs on code that someone else wrote and released for free. A web service leans on a cryptography library, a data pipeline pulls in a parser, and a mobile app ships a handful of small utilities that one person maintains in spare time. All of it carries the same label. A new paper argues that the single label hides differences large enough to change how each piece behaves once it lands in production.
Researchers sorted open source software into fourteen sub-genres, each defined by who starts and sustains a project and to what end. Their review screened close to four thousand unique papers drawn from two scholarly indexes. The result is a typology, along with an argument that the kind of project a study samples sets how far its conclusions travel.
One label covers many kinds of project
A community Linux distribution, a single-vendor database, a university research library, a humanitarian health-records system, and a one-person utility differ in why they exist, who decides their direction, and how the work gets paid for.
The authors give the differences names. Community-driven projects such as Debian and Arch Linux run on volunteers and merit-based authority. Company-backed projects such as Elastic, MongoDB, and GitLab sit under one firm that earns revenue from the software and controls its roadmap. Foundation-governed projects such as Apache HTTP, Kubernetes, and Eclipse live under a vendor-neutral nonprofit that holds the trademark and keeps competing firms on even terms.
Other categories sit further from the usual picture. Multi-company co-opetition covers rivals who build shared infrastructure together, as firms do around OpenStack and the Linux kernel. Research and scientific software gets written inside labs by domain scientists working to grant cycles and academic careers. Protestware covers packages a maintainer alters or sabotages to send a political or economic message, with node-ipc and colors.js as examples.
Why the category predicts behavior
The practical point lands on funding and governance, since those two things predict how a project holds up once many people rely on it. Critical digital infrastructure is the sharp case. Components such as OpenSSL, curl, and log4j sit underneath much of the software ecosystem, and a few volunteers often keep them running. Nadia Eghbal described this sustainability problem in a Ford Foundation report, and later research formalized it as underproduction, a state where the labor a component receives falls short of how widely it is relied upon. Studies of the npm ecosystem show a related risk, where a small number of maintainer accounts reach much of the network.
Hobbyist and solo projects carry the same fragility. Researchers call this a low truck factor, which is a way of asking how many people would have to walk away before the whole thing grinds to a halt. For a one-person project, the answer is one. When that maintainer gets busy, burns out, or moves on, the code stops moving with them. A project backed by a foundation with member dues and paid staff has more people to lean on when the same thing happens.
The community itself differs too
The differences run deeper than money. Take open source for social good, or OSS4SG, the projects built to help people rather than turn a profit, things like the health-records system OpenMRS or the crisis-mapping tool Ushahidi. People who show up to these projects tend to stay. The authors call them “sticky.”
Conventional projects are “magnetic,” pulling in a crowd where plenty pass through and move on. The road from first-time contributor to trusted core member looks different too, and in OSS4SG people reach that core faster and by more than one path. So a playbook for keeping contributors around, built on one kind of project, can fall flat on another.
Where the category leaves off
For anyone who works in IT, this lands close to home. The typology is still a work in progress, a light review the authors treat as a starting hypothesis, so the categories will shift as more research comes in. The practical read holds up anyway. Before your org commits to an open-source tool or pulls in a new dependency, the category tells you something a star count never will.
An open-core product from a single vendor comes with relicensing risk tied to that vendor’s business plans. A solo package comes with bus-factor risk, the odds that one person walking away breaks it. A foundation-backed project comes with the governance that lets competitors share it in the first place. Knowing what kind of project you are dealing with puts the risk in plain sight before the code ever ships.
Must read:
Subscribe to the Help Net Security ad-free monthly newsletter to stay informed on the essential open-source cybersecurity tools. Subscribe here!
