Some 15 years ago I had a falling out with an acquaintance of mine over a realization I had that Open Source is an absolutely terrible way to build products. When I shared this, I could immediately feel the atmosphere in the room darkening. I did say that I thought Open Source was a great way to build technology, but that didn't do much to temper the situation.

The anger was understandable: we were both at the time very active in Open Source, in fact we met and developed a friendship through our Open Source work, and I was seen in our group as “the” Open Source guy, especially through my extensive work on the Linux Kernel.

That maybe Open Source wasn't a great way to build products was an early realization of mine at the time. But fifteen years and two startups later, I am now even more confident in my conclusion than before: While Open Source is a great way to build technology, it is an absolutely disastrous way to build a product. But I also came to the paradoxical conclusion that… this is exactly why Open Source should be a part of every product pipeline!

#What is a product? What is technology?

The core of the question lies on the distinction between product and technology. Back then, I'd have asked Wikipedia for a definition, just to keep me honest and avoid getting too biased. Now I'll ask ChatGPT — a product based on the GPT-3 (or 4) technology:

This touches on the core of the issue: a product is created using technology, and is a derivative work. Because we install those things– like Linux, or databases like Postgres — they have logos, mascots, conferences, we may think of them as products.

But a product is much more than that. A product solves a particular problem (or set of problems), has a particular form factor, warranties, guarantees, a supply chain, all of that. Lots of Open Source projects, in the quest to make themselves useful for a wide audience, approximate products, but at the end of the day, they are still technology.

#What makes good technology?

Technologies are ultimately building blocks. So what makes a building block superior to others?

#Affordability

If every nail cost $1.00, any product with 10 nails would have to cost at least 10 dollars. One of the dimensions through which products compete in the marketplace is on cost. By being free to reuse, Open Source software has a unit cost of zero, and can be added to any product to the extent that your heart desires it.

#Versatility

There's a reason Lego is the behemoth it is: the ability to combine pieces the way you like it allows you to do more, with the same blocks. Healthy Open Source communities allow their software to be used anywhere, in as many architectures as possible, in as many deployment platforms as possible. At the inflection point where Linux became dominant, it started seeing usage in supercomputers and mobile devices, and anything in between. It had support for a wide variety of processor architectures and a mindblowing amount of hardware devices.

#Adaptability

Nobody sees what goes on the backstage, so when building a finished product you may want to adapt your components. Drive-by Open Source contributors are contributors that have an itch, and find a piece of Open Source software that does almost what they want. The contributor can then adapt it for its own needs, without being concerned if they are the single user of it, or a part of a large group.

What makes a good product?

When building products, you are concerned with retention numbers, slicing a market, and educating your users about what it does. In the time it took you to explain all the five ways one can use your product, your competition has figured out the way 80% of the users want to use it, and built a workflow that does just that.

This is especially important when building a support function. In order to achieve predictability and train a support team, you want users deviating as little as possible from the script, and guide the users through the happy path as much as possible.

One easy example is platform support for games: even if your technology allows you to support multiple Operating Systems and platforms, standardizing on one or two allows you to serve that community a lot better.

Good products are an act of path-carving. It is not an effort on maximizing the amount of features and connections, but deciding with a single vision what not to do. Building products is incredibly hard. But not because the act of building is hard, but because the act of choosing what to build is hard.

Open Source makes for bad products

It is not that it is inherently impossible to build an Open Source product. But building a product using Open Source conveys no inherent advantage: you still need a strong vision and the determination to cut through the forest at a single place, foregoing every other alternative.

But the imposition of the vision may drive contributors away, and tame the powerful force that Open Source is when fully unleashed.

If you try to build an Open Source product, an inevitable tension between product needs and technology needs arises, and at best one of them will suffer. At worst, both will.

A great way to use Open Source

Open Source software is special. Lots of projects approximate products by investing a lot in documentation, making it as easy as possible to get started, and removing friction whenever possible. But even those are still a couple of inches away from becoming true products.

Good Open Source communities do well if they lay the foundations for maximum composability, lower the barrier for new developers to enter and push their own requirements. We're then able to allow people to experiment with many possible paths, before laying the stones.

But by keeping the productization layer separate, we are able to use Open Source to de-risk the hardest part of product development, which is understanding what to build, while keeping the animal spirit of Open Source untouched by product needs.

An example

I am currently serving as the Founder and CEO of Turso, an edge database, meaning a database that is cheap enough to replicate, so that it can be replicated globally and serve reads with low latency from anywhere.

Turso is based on libSQL, an Open Contribution fork of SQLite. We created this fork exactly to allow for more experimentation, given that SQLite operates as a very tight community with only three developers committing regularly.

If we were starting the process of conceiving an edge database from scratch, we'd have many questions on our mind:

• How much of the market is okay with workloads that are mostly reads, with very few writes?
• How much of the market is okay with a very simple type system that doesn't support most of the data types that bigger databases like Postgres and MySQL do?
• Are there unique ways people would use a small database that others bigger databases can't do well?

We of course would have theses about those, but wouldn't know the answer for sure. But SQLite as a technology, over its two decades of existence, answered all of those. There is a huge community out there using SQLite in this exact same manner — heavy reads, low writes, and we know they are okay with a simple type system.

We also know that people rely on the flexibility of SQLite to spawn thousands of small databases, and that it embeds very well in local SDKs. This all surfaced from its OSS usage, embedded in other products.

To our fork, we have added a variety of new, cool features. The biggest of them was the ability to access libSQL over the network. We have added the Postgres and HTTP protocols, and have quickly learned that while accessing SQLite over the Postgres protocol is a nice technical direction, it is a path filled with hurdles that the HTTP implementation simply doesn't have, making it a superior choice.

We built Turso on a very strong Open Source foundation, and keep producing more into that commons as we go. But at the end of the day, of all the things that are possible to do with SQLite, we chose one, and only one. We have done more work to clarify what we don't support and what use cases we don't want to serve than the other way around.

We carved a path, not blindly, but by looking at the markings on the ground.

In Summary

With its collaborative nature, Open Source is a great way to foster innovation and draw developer communities together. Open Source projects thrive when multiple different use cases can coexist under the same tent.

Products, however, benefit from laser-focused vision, and a process of restricting, rather than expanding possible paths.

The dynamic between Open Source technology and finished products works best when there is a clear line of demarcation between them.