The non-technological open source problem

2024.05.16

I noticed lately the emergence of tools that aim to tackle the problem of open source sustainability by treating it as a technological platform, such as Polar and the Tea Protocol. While it is exciting to see more companies trying to solve such a critical problem in our industry, the root of the problem lies in some social expectations and assumptions that I highly doubt can be changed with more tools. Don’t get me wrong, we need tools that pave the way for people and organizations that want to contribute to open source, but that’s not enough.

If you asked many citizens to contribute financially to the construction of a park where they’ll be able to relax and bring their kids to play, most will refuse, saying that they expect those things to be free. Now imagine the same thing but with digital infrastructure that many can’t see and on which many for-profit organizations build. Why would they pay if, by doing so, they’d increase their costs? They’d rather not. Not only that, but they take part in echoing misleading ideas such as GPL licenses, like considering them infectious. Why not say my software is incompatible with this license instead? Infectiousness places the blame on the open source software. Would you consider someone infectious because their need to receive a salary for the service they provide as an employee is incompatible with the company’s cost structure? Most likely not. So why do we do that to people who have contributed hours to develop something and therefore have the right to publish it under a license of their choice?

As I mentioned in past blog posts, the backlash from developers often arises when you have to make some changes in a model to protect the project’s sustainability, like we had to do with Tuist. But it was so hard for us to imagine how much work Tuist would require 7 years later, that we couldn’t have agreed on an ideal model when we started. This is not unique to open source, but companies have to go through decision-making that won’t please every user, and that’s alright.

So, going forward, the model that I’m embracing is similar to 37Signals’. I’ll layer the paid software that I build, and publish as MIT-licensed those layers that I believe would benefit from commodification and that the community might be interested in building upon and contributing to. For example, we are going to extract all the generation logic from Tuist, so anyone could build their own project generation tool upon a battle-tested logic to understand graphs and translate them to Xcode primitives.

Open source sustainability is hard, and while it’s necessary to have the tools to reward and pay contributors for their work, the problem requires more of us, developers, speaking out loud about the importance of contributing to the software that we depend on, like we do directly through our taxes to have spaces where we can live and enjoy. Software is no different there, just something more abstract.