Open source is code escrow on the cheap

I read this article a while back about the VC backed open core playbook. Worth a read.

If you haven’t had a chance yet, the playbook is:

• start an open source product
• create a company around it
• use the siren of open source to drive adoption
• take VC money
• continue to developer the open source solution
• build out closed source functionality, typically as a hosted SaaS
• over invest in the closed source edition
• let the open source version wither on the vine
• profit !?!

The crux of the argument is that the open source version of whatever software is being sold is a pure marketing play, and that all the focus will eventually arrive on the closed source extensions or functionality. After all, that is what drives the revenue, and since the company took VC money, they need outsize revenue.

There are a few flaws in the argument, including, but not limited to:

• it is possible, and even likely if a project succeeds, that there is a community of other companies that will drive the open source project forward under another name (see Opensearch or Valkey)
• the marketing value of the open source project doesn’t necessarily recede as the closed source functionality drives more revenue; it may even grow
• not every open source company is VC funded

But I’m going to set all those aside for now, and focus on the value of open source for the end developer. In particular, why is that so attractive to devs? Why is it such a powerful marketing tool to drive adoption?

There are two reasons OSS is important for dev focused tools:

• permissionless access
• derisking the future

Let’s dig into each of these.

Permissionless access

When a product is open source, a developer can access it, typically by downloading and running the code, without talking to anyone. They don’t have to fill out a ‘contact sales’ form or give any information to the vendor. By the way, marketing departments hate that, not because they want to spam developers, but because it’s really hard to do modern marketing when you have no idea who your users are.

Just as importantly, a developer downloading an OSS project does not have to ask for money or permission from their own organization either. They are spending time, which is an opportunity cost, but for typical developers that isn’t an expense that is tracked too closely. Even agency developers billing by the hour have time to explore and can justify investigating a tool if they think it will speed delivery.

Decreasing the friction of trying a tool means, all other things being equal, more people will try it. If the product is good, and by that I mean it solves a need, this is the first step to adoption.

Derisking the future

Whenever a developer picks up a tool, whether it is a SaaS product or a library, they do so with the knowledge that the tool and the uses for it will break something in the future. This is an unfortunate side effect of the fluidity of software and anyone who has spent days or weeks upgrading from one version of a framework or library to another will understand that it is part of the job.

Using an OSS tool derisks this unpleasant task in two ways, and therefore makes the future better for the developer, increasing the attractiveness of using OSS.

The first is bug fixes. It is quite frustrating to be stopped by a bug in a software library you are using. I still remember decompiling java classes two decades ago to characterize a bug in a software package we were using. I found the bug and then had to raise an issue with the vendor; in the meantime I had to code a workaround.

When you have access to the source as a developer, you can do the fix yourself. You typically want to upstream it to the vendor to ease the burden of maintaining a fork, but you are not stopped in your tracks. And finding the fix is easier because the source and build instructions are available.

The second is operations. If pricing gets punitive or the vendor has a hard time operating the software in a way that meets your availability needs, you can run it yourself. Or, if you don’t want to, you can pay someone else to do so. If the software is successful enough, a hyperscaler may offer a managed service (hello Elasticsearch!). Having  competition for running the product makes it less likely you’ll be stranded engaging with a vendor that doesn’t meet your needs. It’s code escrow without paying Iron Mountain truckloads of cash.

Conclusion

I think the risk of relying on OSS companies that take funding is real. VCs aren’t in the business of giving away value, so there will eventually need to be a business model and I think that the author of the original post described what is unfortunately a pattern. But developers justifiably value the benefits of OSS highly too. Permissionless access lets them get on with doing their job while source code availability derisks future problems.

I predict we’ll see more OSS companies started in the devtools space because of these factors. But the long term trend of successful companies moving from OSS licenses to more restrictive ones will also continue.