For all intents and purposes, the Litestream project is (and always has been) 100% open source. It satisfies all 10 requirements of the Open Source Initiative’s (OSI) open source definition, uses an OSI-approved license, and you’re more than welcome to fork it and modify it however you wish. There’s just one catch: For some time, the project didn’t accept code contributions of any kind.
But why, you might ask? One of the top reasons for making something open source, after all, is to receive contributions. Why even go the open source route if you’re not going to accept code?
Litestream maintainer Ben Johnson closed the project to contributions in January 2021, explaining in a section of the README titled “Open-Source, not Open-Contribution” that dealing with even small code contributions was too time-consuming.
“As the author of BoltDB, I found that accepting and maintaining third-party patches contributed to my burn out and eventual archival of the project,” he wrote. “Even small contributions typically required hours of my time to properly test and validate them. I am grateful for community involvement and when folks report bugs or suggest features. I do not wish to come off as anything but welcoming, however, I’ve made the decision to keep this project closed to contribution for my own mental health and long-term viability of the project.”
While Johnson’s approach is a bit out of the ordinary and may call into question some assumptions about what is or isn’t open source, it also illustrates that open source isn’t one size fits all. Some projects accept contributions with relative abandon, while others employ lengthy lists of requirements and detailed processes, and others still opt to take code from just a select few. As an open source maintainer, the ongoing burden of bug fixes and feature requests require consideration. Simply turning off all contributions might feel like an easy escape, but it can be limiting in other ways.
We’ll come back to Johnson and his unorthodox method a little later. First, let’s take a look at how we got here.
Open source eats the world (and needs some Tums)
Early software was written by researchers and academics, and open by default—it couldn’t even be copyrighted until 1974. We didn’t even have the now-common phrase “open source” until Christine Peterson coined it in 1998. That same year, the OSI formed and established the aforementioned open source definition, which remains the yardstick by which openness is judged today.
For many of those early years, tedious and time-consuming methods such as email lists were the de facto standard for open source collaboration. Git, the open source distributed version control system created by Linus Torvalds, didn’t arrive until 2005, and even then it only offered a tool based in the command line. Three years later, GitHub offered a user-friendly interface for Git and introduced the pull request, a feature that changed the way maintainers manage patches in open source, which some might argue lies at the core of open source’s recent success.
“One of the amazing things that GitHub did was make contributing easy and accessible. That has brought so many more people into open source, and it’s wonderful,” says Julia Ferraioli, an open source advocate and software engineer. “On the flipside, it’s also made it very easy to make demands without context.”
With that ease of access, open source projects can experience their own form of the Slashdot effect, where sudden popularity can be overwhelming for the lone maintainer.
“As soon as you get noticed, you essentially have an unlimited number of stakeholders,” says Ferraioli. “You’re suddenly plunged into project management, diplomacy, marketing, and branding.”
Ferraioli argues that the knee-jerk reaction you might’ve had to Ben Johnson closing off his project to code contributions is less about the actual definition of open source, but rather the social model that has evolved over time. While the OSI definition offers 10 concise characteristics, those practicing and participating in open source often assume that open source software should be open to contributions from the community, welcoming to discussions around a project’s direction, and willing to accept new developers and maintainers.
“There are plenty of open source projects that people generally don’t consider open source because they’re not building a community or making a lot of updates, but open source isn’t just about contributions. It’s about learning, understanding, and teaching, too” says Ferraoili. Research projects, she notes, are open source partly to allow third parties to independently verify their findings. By their nature, they can’t accept contributions of any kind.
“They’re still open source,” contends Ferraioli. “They have immense value. People can learn from them, modify them, fork them. There are so many reasons they’re still wonderful examples of open source software, and I think we’re quick to dismiss that.”
Beyond open source research, however, some open source projects choose to limit contributions for other reasons.
Open source, but closed to contributions
The Lua programming language has been open source since shortly after its debut in 1993, but has remained closed to outside code contribution the entire time. Lua prioritizes speed, portability, simplicity, and small binary size, and it has found considerable popularity in the realms of embedded systems a
