There is no doubting the merits of the open source philosophy for writing code and producing software. Many of the software packages at the core of modern computing, from the Linux operating system to MySQL, were created using a model of open sharing and collaborative development. Four decades of great code, nurtured by the philosophy of openness, have settled any questions about whether the open source idea works.
But for all its greatness, open source is not without faults. Now that open source has entered the mainstream, let us consider some of its downsides—not so much the philosophy but the day-to-day reality. Here are seven reasons developers might think twice about contributing to an open source project.
Open source doesn’t work with the cloud
Many of the current open source licenses were crafted before the cloud, when users accessed software by downloading and running it on their desktops. Cloud companies have since figured out ways to freeload on the open source ethos while keeping their code changes proprietary. One open source manager at a major cloud company told me, rather coyly, that they distribute the software, so they don’t need to share the source code.
There are dozens of examples of cloud vendors creating special versions of open source projects to resell in the cloud. One of the most visible rifts was between Amazon Web Services and the creators of Elasticsearch. When the two sides couldn’t come to an agreement, they split, and now there are two effective versions of the Elasticsearch codebase.
Some open source advocates are pushing back on cloud co-option by crafting stricter licenses or amendments such as the Commons Clause. We may see improvements going forward, but they won't help with the legacy systems being shipped under the original open source licenses.
Open source has a diversity issue
The word community gets thrown around a lot in open source circles, but that doesn’t mean open source culture is some sort of Shangri-La. Open source developers can be an edgy group: brusque, distracted, opinionated, and even downright mean. It is also well known that open source has a diversity problem, and certain prominent figures have been accused of racism and sexism. Structural inequality may be less visible when individuals contribute to open source projects with relative anonymity, communicating only through emails or bulletin boards. But sometimes that anonymity begets feelings of disconnection, which can make the collaborative process less enjoyable, and less inclusive, than it's cracked up to be.
Community takes time to build and maintain
Many enterprise companies release open source versions of their product as a “community edition.” It's a great marketing tool and also a good way to collect ideas and sometimes code for improving the product. Building a real community around that project, though, takes time and resources. If a user and potential contributor posts a question to an online community bulletin board, they expect an answer. Yes, many contributions are made freely, in the spirit of open source, but nurturing community still takes time. When it works well, the result can be a burgeoning group that is building great code but there’s often plenty of work along the way. One consequence of this tradeoff is that larger, enterprise projects tend to dominate the field. They can afford to finance the community model through paid roles that smaller companies can't manage.
Open source mentorship is surprisingly rare
Along similar lines, many developers are happy to share their code with anyone, but that doesn’t mean they want to help others actually learn. Giving someone access to a Git repository takes a few minutes, but supporting their growth as a developer and fellow contributor is a significant commitment. Some projects even include a clause in their contributor agreements that contributors should not expect to be onboarded or supported, or even to have their questions answered. In essence, contributing to an open source project can feel like a slam dunk into the deep end of the pool: Here’s a bazillion lines of code and an issue for you to solve. You will find very few comments to explain what’s going on. Thanks and good luck!
Even die-hards need paychecks
The majority of open source developers are idealists who aren’t motivated by fame and fortune, but they still need to eat and sleep under a roof. The real world has many physical limitations that aren’t compatible with the free sharing ethos of open source. Scarcity may be a foreign concept to the digital world, but it's a very real issue for biological life forms.
Open source works well for small stacks and passion projects, where no one expects to get paid, but it can be an uneasy fit for larger codebases that are supported by full-time coders. If too many users opt for the free version, the entire project can crater.
Nothing is really free
Hang out in open source long enough and you will likely run across the acronym TANSTAAFL, which stands for “There Ain't No Such Thing As a Free Lunch.” Richard Stallman liked to say that he wanted to create software that was “free as in speech, but not free as in beer.”
After users download open source software and use it, they will begin to discover its limitations. Sometimes, the code just needs some minor refinement. Sometimes, it doesn’t have the right features at all. No one wants to complain about the glass that’s only half full, especially when the price is zero. But filling the rest of the glass can be a substantial burden for the developer on a deadline. Even when the free code gets you 99% of the way to your goal, that last 1% can be a real slog.
Some projects shouldn't be open source
One developer of a database told me that he never really considered open-sourcing his project. His customers were a few big companies with massive data sets. They had the budget and they were willing to pay him to do the work. If a customer wanted to read the source code, he was more than willing to let them have it. But he didn’t want to go through the trouble of splitting off a formal, open version of the project.
Open source versions are good for code that’s used by a wide class of developers who can help develop the code together. In some cases, though, the exchange of money is a simpler and ultimately more sustainable way of organizing the work of making software.