Extremely open and incredibly close: should you go open source?

And as with any hard question in life, there is no single answer to this one, either. Further still, the “right” answer may change as the world continues to spiral along the invisible string of time. But where do we stand today? As we, a group of 9 founders, discussed this question over coffee and waffles in the park, we came up with a pretty good overview of the sitaution, which I will break down into factors and models.

First of all, let’s outline some of the key factors in favor of open sourcing a dev-facing product, of which there are quite a few worth mentioning.

Let’s begin by analyzing the attraction of open sourcing from the developer perspective:

• Developers love open source for the transparency: issues can be quickly resolved, dependencies are clear, and, most importantly, the ability to contribute by proposing or implementing a feature or fixing an issue.
• They respect open source; there’s gratitude that someone’s work is being given away for free.

Next, enterprises:

• Enterprises treat open source as insurance against vendor locking, and thus, against unfair price changes. In the worst case scenario, the enterprise could switch to open source and support it independently.
• They can also consider open source software more secure; vulnerabilities are discovered much faster. (Although, this is industry and company specific).
• Enterprises value the ability to contribute or extend software for their own purposes.

Finally, let’s touch upon some other benefits:

• Open source helps marketing for dev-facing products.
• It also helps with hiring, as it fosters engineer recognition and future career opportunities.
• From the industry-wide perspective, open source enables faster innovation by means of knowledge sharing, collaboration, and by diminishing barriers.

But with these benefits, also come some huge risks:

• Open source cannibalizes adoption of a paid product: if your product is free, why would anyone pay for the commercial version?
• Open source means solving other people’s problems for free, since maintaining a popular open source project also means resolving issues and reviewing Pull Requests.

This is why every DevTools company needs to be careful and strategic when choosing a business model that will allow their particular product to reap the benefits of open source (while simultaneously mitigating the risks).

Now, let’s consider some key models for building a commercial open source company.

Open source and SaaS

First up, the open source product and commercial cloud offering (SaaS) model. This is the most wide-spread approach, with examples like Elastic, Redis, Supabase, and so on.

This approach works best with content-driven marketing, self-service adoption, and bottom-up sales. Usage-based pricing comes naturally in this case.

Note that recent innovations in new cloud platforms like Vercel, Fly, and others, are actively erasing much of the overhead needed to run applications. An open source product can be deployed easily, with just a few clicks. This increases the risk of cannibalization of the paid SaaS product by the open source version, which can make the classic SaaS model unsustainable for certain types of products (especially those that can be easily run on modern serverless infrastructure).

Open source tech and dedicated cloud

Next, open source technology and a dedicated commercial cloud. Here’s a rule worth remembering: a programming language runtime, framework, or a technology that’s foundational in some way cannot become popular unless it’s open source. And, indeed, after the stories of giants like Microsoft (.NET) and Adobe (Flash) have been played out, this rule does hold really well.

Most frameworks are funded by non-profit foundations or giant organizations using them in-house. Nonetheless, there is still room for commercialization, with Next.js/Vercel as a popular example. Others worth mention are Ray/AnyScale, and Apache Spark/Databricks.

The model implies doing two things in parallel:

1. Promoting and popularizing the language/framework by growing a community of people using it;
2. And, at the same time, building out a platform dedicated to improve productivity and experience of people from this community, using this open source.

The product-market fit for this model means that the platform contributes to the popularity of the open source, giving it a unique advantage. Additionally, the open source drives paying customers directly to the platform, driving its growth. In essence, the organization has to build two completely different products, while catering to one audience.

Open source and open core

Open source product and extended commercial product (Open Core). This is a classic approach for enterprise software: the basic version is open source, while the extended enterprise-grade version of the product is commercial under a proprietary license. This fits well with a top-down sales process targeting medium and large organizations. Pricing can be per seat or usage-based (linked to traffic and the number of concurrent nodes in a cluster). Examples using this approach include GitLab, Apollo, Sourcegraph, as well as imgproxy, built by Evil Martians.

Enterprise features mostly fall into one of these categories:

• Developer experience: integrations (IDE, frameworks, platforms, issue trackers and project planning software, communication and ChatOps)
• Performance, scalability, stability: added resource efficiency, cluster mode features, multi-region databases and data consistency, zero-downtime deployments, support for private networks and VPNs
• Access control: IAM, SSO, SAML, approval flows, audit trails, security reports
• Compliance (SOC, DPA, HIPAA), single-tenant and VPC
• Geography: multi-region, multi-cloud, edge computing
• SLA, priority support, white-glove onboarding

Open source and consulting

Open source product and consulting revenue is a model that is admittedly out of fashion. This is due to its lower margins and scalability issues. Still, it previously helped RedHat earn billions of dollars. This model has two benefits: it brings liquidity and self-sufficiency from the early days of the company’s existence, and it helps you gain first-hand experience using your own product in a variety of use cases.

At Evil Martians, this is largely our model with AnyCable at the moment, which generates leads that bring over a million dollars in consulting revenue per year. But building your own support and consulting team is not the only option: Evil Martians or another trusted consulting company can become your partner, providing paid support, building customizations and solutions on top of your product. And this partnership can take the form of a revenue sharing agreement.

Teams: open source and free single-user, commercial multiplayer

Finally, single-user product is open source and free, while multiplayer is commercial. This is the model that was popularized by companies like Figma, drawing the line between a free (and possibly open source) single-user mode, and a paid multi-user mode.

This ensures that any person can start and try out the tool, without having their free trial expire, and with no limitations on functionality. From there, a user can invite a colleague or a collaborator to join them, and it’s within this “team” mode that the product switches to a paid model.

Here, an entire additional layer of functionality comes into play:

• Roles: admins, collaborators, reviewers, commenters, billing users, and so on
• Shared resources: projects, boards, documents, and other resources that are stored in a cloud and synced within teams
• A real-time collaboration UX: live presence, live reactions, live edits, data consistency. There are many ways to approach this, from simple to complex solution like CRDT for text editing (a Google docs-like user experience)

This model meets several goals:

• Users inviting collaborators is a viral organic source of growth
• Collaboration becomes a major competitive advantage (Figma, Google Docs)
• Collaboration improves retention as it is harder to move to another platform (it’s no longer just one person’s decision)
• It helps sell to organizations: when the tool is already tried and tested by someone who needs it, and several employees want to use it for collaboration, it’s an easy sell within an organization

And this concludes today’s survey! It’s worth noting that, most large organizations mix and match models, providing both SaaS and on-premise options, as well as support. But at the early and growth stage, each organization has to bet on one simple model. This is so that it can focus its limited resources on winning within one lane. Hopefully, considering the options we discussed today will help the founders reading this develop a strategy that will give you focus and growth from the earliest stages.

Let’s talk about the strategy and the business model for your dev-facing product. We’re excited to help! Get in touch here!