Licenses: Trust and Promises

Fundamentally there are two types of perspectives inside Open Source: true believers and opportunists. Also those who still secretly think it’s a disease – but let’s leave those aside for the moment.

I have wandered in the “true believer” FOSS fundamentalist circles for a long time, and it never felt like a practical ideology to me, so I’d consider myself an opportunist, despite having written Open Source software (OSS) for free and for money, having contributed to codebases of others and donated my own money to it and made others direct their cash.

Either way I think that Open Source is a huge chance, irrespective of whether you are building it for yourself, for your company or just harvesting stuff made by others. And it does not have to be extremist either: Even if it’s not really Open Source, meaning under an OSI license, published openly, but even if it’s software that the rest of your organisation can access and send pull requests to, or if it’s code that you send to your customer after the invoice got paid. These small things can have an immense effect on the impact that your developers can have and the trust you build in and outside of your organisation.

Even if your customers might not understand the value that you are sharing the source code with them, it might push you to produce better artifacts.

At its core Open Source might be seen as a legal contract: You are getting a piece of code and technically speaking you can run it as long as you want. Practically speaking you will want to receive updates at some point, either to get new features or fix security problems. The very most sophisticated consumers of software may become contributors themselves: It may be more practical to develop patches in-house than to contract either the original author or switch to a different software.

Since standard licenses are often quite simplistic – grant permissions and exclude warranty – the social contract is crucial. And all the projects that are altering the legal contracts unilaterally are putting a strain on the social aspect.

Future expectations are central to that deal, even if they are not codified: Ten years ago when adoption of Open Source software packages was debated inside of companies, doubts about the longevity were a major contention point. This aspect has become less important, because Open Source as a whole got more accepted and stable. License choice and compatibility are more central aspects of due diligence these days.

With the ongoing license change wave (e.g. Redis, CockroachDB, Terraform) the function and reality of OSS must be questioned: Why are companies deciding to publish their source code? And why do customers want Open Source?

Universal Toolmaking

Tool making is a profitable business, for producers and consumers alike. People are proud of the tools they own: sometimes because a cheap tool is making one unreasonably productive or because they have bought something of extraordinary quality that enriches their enjoyment in the process. ASAKA, a Japanese tool maker, exists since 1661, primarily manufacturing spades and shovels. Their business model works for over 350 years despite not having an end-user agreement that dictates that you may not use their tools in for-profit endeavors.

Derek Collison, founder of NATS, bemoaned in an episode of Changelog¹ that some mega corporations have policies that block them from paying at least for certain kind of Open Source tooling. This framing makes the complaint look extremely reasonable: A huge player having an almost comically bad policy that takes the fruits of a much smaller entity and not paying anything.

From the consuming companies’ perspective they seem to be legally in the clear: The Open Source license allows them to use it as they see fit; they can even make private changes to the code since it’s licensed under Apache 2 license. Why should they pay for something they are already allowed to do? Sure, they didn’t pay for the shovel, because it’s been gifted to them.

Customers of software businesses are often subject to absurd licensing rules: Limitations on concurrent usage, agreement to invasive audits or telemetry, and chiefly “no warranty”, aka the software vendor not guaranteeing that the product performs any function. Open Source corrects this relationship somewhat: The customer can terminate the business relationship if they are unhappy. Even if you have bought a perpetual license, only some form of OSS give you the ability to change the software after the fact.

Upstreaming changes comes with its own troubles: Some vendors are not thrilled about (potential) customers just submitting patches. Many of them would rather make a service contract sale and develop the patch in-house from scratch, instead of inheriting a maintenance burden. But by rejecting these contributions upstreams are risking the customer creating a fork. Some vendors are not integrating the customers’ patches but instead engineering their own solutions that fulfill the requirement. From the outside it looks like the original authors are the only contributors, but in the long run it is a unsustainable business practice if the customers are not paying.

More integrated solutions are creating more value and are often able to achieve higher margins: A shovel manufacturer will have a slimmer margin than a construction company. A scrum ensues when the lower value producer (creator of Open Source Software) cannot even collect their small margin, because the upstack vendor (a public cloud company) is paying zero while selling something more useful.

Cloud providers or even hyperconverged infrastructure vendors have little problems collecting money from the value they provide, mainly because they have gauged correctly how much of the value they are allowed to capture. Although they are at risk of these dynamics shifting, as I alluded to in my Go Big or go On-Prem piece. Some Open Source Software companies are able to earn good money, but measured against the value they are creating, the capture ratio is rather low.

From the perspective of support contracts I find the “Business Software License” (BUSL) by default, Open Source after two years construct not violently unreasonable: Many software and infrastructure contracts are negociated for a multi-year period, and after that expires they have an escape hatch: Whatever they originally bought will become Open Source after the contract ends. If the vendor turns out to be a dick or gets sold to one, you have a kind of insurance and can keep using what you’ve already got.

Execution matters

From a customer’s perspective some OSS vendors are making massive mistakes in their execution and later blaming greedy non-payers for their ills: I still find it baffling how disappointing support and sales sometimes can be.

Open Source allows for a low-friction start: You download a package and start going. When you have to buy software, even if you have access to a trial version (which often isn’t even long enough to cover the sales process), it slows any adopter down by weeks or months.

A customer of mine has been using the Open Source version of a database software. When we hit some issues, we tried to find a solution through support, which wasn’t able to assist us in any meaningful way. Their paid cloud offering was an underdocumented mess and wasn’t even competitive against running the open version on-prem ourselves. The sales process was slow and didn’t resolve any of our questions. In their newest version they finally decided to cripple the Open Source version and shifted focus to their enterprise offering. OSS hasn’t failed here: It’s been their strategy and execution.

When companies close down their source it is easy to be cynical and claim a money grab or see their open efforts as a way to lure customers into their captivity. It definitely tarnishes the reputation of these companies, because it will be much harder to believe them that they will not alter the deal even further. The customers, especially these of VMWare or Oracle, already know this asymmetry of power. And the aftermath of the Terraform agreement change and the emergence of a decentralized OpenTofu shows that this kind of rug-pull may have unintended consequences.

Companies like Tailscale are showing how it’s done: Their product is building upon Wireguard (an Open Source VPN software), and an eager technologist might argue that you could just use that. But their execution makes it so easy to pick them instead: You can create an account using self-service, much of the software they are offering is Open Source, you can even use a different backend. If you want to go further, their support staff can actually help and their sales is proactive. They are pushing themselves to provide more value to their customers, so they don’t have to lock you in.

If you are a “pure play” software company, launching your product as Open Source and hoping to make it a sustainable business through e.g. enterprise support contracts, I do still think that it’s possible, but your fundamentals need to be absolutely solid: Your sales staff needs to be aware what they are up against, your support needs to know how to effectively help. Your strategy must be somewhat transparent or consistent. Your investors need to know that monetisation strategies may not be straight forward. Don’t trade a boost in quarterly numbers for reputation.

If you are on the other side and are enjoying the benefits of Open Source, think about where you already spend your money: Are you maybe paying for a cloud account that doesn’t have good support and doesn’t finance the underlying OSS? Maybe paying for the hosted solution offered by the producer of the software makes more sense? If you are spending big bucks for a support or enterprise contract of an Open Source package, codify that the software will actually stay Open Source.

Whether you are a producer or a consumer of Open Source Software: Be mindful not to overextract value. If you do, the market may overcorrect.