Entrepreneurship for Engineers: Making Open Source Pay
With all of the talk about monetizing open source projects, it would be easy to conclude that all projects are appropriate for monetization, or at least that all “open source companies” have a path of similar difficulty to follow as they make a business out of an open source project.
But is that true? And if not, how do we evaluate what projects are ripe for monetization and which ones are important, well-loved but not likely to be commercially successful?
Alessio Fanelli, an engineer-turned-investor at 645 Ventures, has a framework he calls the “monetization helix” that is useful for thinking about this problem. He spoke at the Linux Foundation Member Summit in November about the monetization helix and how it can help maintainers think about the roadmap to commercial success.
“I wanted to make a better structure around how to actually monetize [open source] because there’s been a lot said about open source development, community management and whatnot, but the monetization part is a little obscure,” Fanelli said.
‘Free’ Stands for Freedom
Before we talk about the monetization helix and what it means for people looking at starting an open source company, there’s a conversation around the word “free” that we should address.
The way the word “free” was originally used in an open source context was not about price or money, but rather about freedom, Fanelli pointed out. The original frustration that led to the creation of open source software and the open source community was not about money, but about a proprietary system that did not allow engineers to fix things themselves.
Why even make that point? Because for some, talking about money in an open source context is scandalous. But it needn’t be.
Not all popular open source projects are ripe for monetization
“There are a lot of false positives,” Fanelli said about open source projects. For instance, noted the popularity in the open source community of Gatsby JS, a Jamstack site generator. “But that was not something that could be monetized easily.”
A project that facilitates payments is going to be very easy to monetize, but a project that makes the fonts on a webpage particularly beautiful has an uphill battle.
The point Fanelli makes is that there’s a phase in a software’s adoption when it matters that a project is open source — at the beginning, when developers are discovering the software and using it to build things. The fact that the project is open source makes it easier for engineers to discover it, and can also make it more fun for them to use it to build applications.
Things shift as the application is deployed and scaled. At that point, the fact that something is open source quickly becomes irrelevant. Instead, engineers — and business leaders — care about things like reliability and security. And they are willing to pay for it.
If an open source project is geared primarily towards the “build” phase and is either less visible or less valuable at the deploy and scale phase, it will be hard to monetize, no matter how popular it is.
Similarly, it’s always easier to monetize a project that provides a mission-critical capability, something that would directly impact users’ revenue if it didn’t work. A project that facilitates payments is going to be very easy to monetize, but a project that makes the fonts on a webpage particularly beautiful has an uphill battle.
As an example, Fanelli pointed to Temporal, an open source microservice orchestration platform started by the creator of the Cadence project, which was developed by Uber to ensure that jobs don’t fail and was used for things like ensuring that payments are processed.
“People care somewhat that Cadence is open source, but what they really care about is that Temporal works, because your payments are going through it,” he said.
When Business Interest Matters Most
As companies start deploying and scaling applications, the conversations they need to have are around business metrics and requirements, rather than just engineering metrics.
“You’re never going to tell your head of sales that we’re using Gatsby instead of WordPress because I like the Jamstack,” Fanelli said.
Instead, you need to talk about things like better performance or less surface area for hackers to attack. Those kinds of business factors matter in production much more than whether or not a product is open source.
Monetization at Different Stages
An open source project’s lifecycle in the enterprise goes from discovery to build to deploy to scale, according to Fanelli. Each phase has different monetization opportunities, and those opportunities increase as reliability becomes more important — in other words, as we get closer to “scale.”
At the “discover” phase, open source companies need to focus on creating content and building community, and shouldn’t focus on monetization at all. Once engineers are actively using the project, there’s an opportunity to provide paid training programs that can offer one monetization channel.
As the project moves into the “deploy” phase, there’s an opportunity to monetize with managed services. At scale, companies can start adding the enterprise support/enterprise version as a monetization channel. The more geared towards reliability (and the more mission-critical the project is), the more lucrative the monetization channels become.
If you’re thinking about monetizing an open source project, Fanelli’s framework is useful for considering how the open source project will provide value, when to launch commercial offerings and how to move potential customers along from the discovery phase to the scale phase.
