The paradox of OSS
In this post, we discuss the paradox of open-source software and how you can support its sustainability.
Building open-source software (OSS) is a privilege. You need a very precious asset that's scarce in the world: time. Some people have it, for whatever reason—that's outside the scope of this post. Others don't, yet from an unprivileged position, they still manage to squeeze out some time to contribute to OSS. They often do so because they believe in its value and the freedom it brings to the world.
Open-source is better than closed-source software. We've learned that story throughout the history of software. Yet, we get irritated when open-source mentions the word "sustainability". Let's pause for a moment.
If a software is closed-source, which comes with high risks for the person or company using it, they are comfortable not only with the idea of paying for it but also with being a product of the company. But if the software is open-source, which significantly reduces the risks of using it, people are rarely comfortable with the idea of paying for it.
The paradox of OSS
Let's break down this paradox in the context of developer tools.
You are willing to pay for a service to bring CI/CD to your project. You come across a closed-source service that everyone talks about. They don't list the price on their website, and after some back and forth with the sales team, you end up paying an expensive subscription. Your product leans on proprietary design decisions because you are a product of the company.
Your entire company has migrated to this service, and two years down the line—in the spirit of meeting their VCs' expectations and knowing that moving away would be extremely difficult—they multiply the price by 10.
Back then, you had the alternative of paying for the cloud service of an open-source project. They offered a cloud plan to sustain the development of the project. But you could not wrap your head around the idea of paying for something whose source code is available. Not many people were talking about it at the time, so it felt more natural to pay for that flashy closed-source service that could afford to pour millions into marketing and associating their brand with the open-source community.
Now you find yourself having to decide between paying 10 times more for the same service or stopping business development for months to migrate to a service you could have paid for initially.
Supporting OSS Sustainability
If you come across an open-source project figuring out sustainability, offer them a hand. Sustainability can take many shapes:
- It can be an AGPL-3.0 license with a dual-license for enterprise. And despite what you've heard, AGPL-3.0 is not a viral license. Businesses want you to believe that, but a license only enters into effect when you distribute the software, which is not the case when you use it internally. In case of doubt about what "distribution" means in this context, the developers behind the project are usually happy to clarify. 2. Sustainability can also mean building cloud services, like we are doing with Tuist. If we were privileged enough to have the time to build open-source without worrying about money, we'd happily do it, but unfortunately, that's not the case.
We need to draw a line between what's free and what's paid. We do this for three simple reasons:
- We want the project to thrive and continue supporting users. 2. We want to do more open-source work to advance the Swift ecosystem. 3. We want to move the ecosystem away from closed-source tools.
Making informed decisions When choosing a tool, consider the following:
- Open-source, even if not fully, is better than closed-source. You eliminate risks for your business. 2. If you can afford it, pay for the open-source tools you use. It's a way to support the developers, the ecosystem, and even your brand. 3. If you can't afford it, contribute to the project in other ways. Report bugs, write documentation, or spread the word about it.
We are not privileged to have the time to build open-source without worrying about money. But we hope to reach a point where we don't have to think about finances, so we can gift more open-source tools to the Swift ecosystem and foster innovation through the commoditization of the tools we use to build software.