Should you consider building a non-dev open-source SaaS product?

What we learned from analyzing 40 commercial open-source software products that are not developer tools.

Recently, Y Combinator published its annual startup request, and one particular area has piqued my interest, which I've been contemplating for the past year: commercial open-source products for sales or productivity suite.

Several successful companies in the commercial open-source sector target developers, including Docker, Elastic, Apollo, Confluent, and GitLab. This strategy has become the norm in the developer tools industry as being open source proves to be a potent method to attract developers. Additionally, it is an efficient means for startups to grow and appeal to enterprise clients faster.

In this newsletter series, I researched the 40 non-dev tools (here and beyond, I use the term “operational tools”) of OSS products from the perspective of their monetization strategy and go-to-market motion to understand whether a pitch like "We're similar to Mailchimp but open-sourced" makes any sense.

I reached out to my friend Vlad to collaborate on an article. Currently, he leads the product at Handl.ai, an AI-driven document recognition API. He was a 0->1 PM @ Borzo (same-day delivery for LATAM, India, and SEA) and founded and failed two companies (one venture-backed). He nerds on pricing and business models, which, combined with trying to bootstrap a company, led him to self-hosting COSS tools and, eventually, writing a series of Substacks about COSS pricing. Check it out!

Enjoy!

---

When it makes sense

Open-source companies are typically founded by technical individuals seeking to solve personal problems. These technical founders find it easier to communicate with users who are also engineers like them, which allows for faster iteration since they can receive feedback from the open-source community. 

While this approach may lead to the front page on HackerNews, building a sustainable company can be challenging.

The main idea behind OSS dev tools is to attract a large user base without charging individual developers. This approach encourages users to become paying customers when their needs grow, such as when they want to use the tool within a larger team or organization. It is logical to compensate the creators for support, consulting services, or custom features.

However, hypertechnical open-source CRM or CEP may not fit the same model as such products can be run in production from day one.

Let’s dive in when it makes sense.

The dev bro is a crucial decision-maker

This is relevant for any operational tool deeply integrated into product development. I see three contexts or personas here. 

1. The engineering-driven team is led by a tech-savvy founder who prefers self-hosted technology. It’s just a matter of religion rather than any rational choice, and likely, as the company grows, it will face conflicts with the marketing and sales departments when refusing to utilize Salesforce instead of open-source self-hosted CRM. 

2. The data or the engineering leadership is a key decision-maker when it comes to the problem you’re trying to solve. Those teams likely develop internal tools similar to what you’re building because they couldn't find suitable, flexible, and cost-effective options on the market that fit their strict demands. In this case, they may leverage open-source tools to customize and enhance their functionalities. They want to ensure continuity if the SaaS company disappears or decides to pivot. 

3. Strict security requirements. You know what that means if you’re selling to government agencies or healthcare providers.

The tight budget makes it challenging for OSS dev tools to seal the deal with buyers. And here’s the best point with OSS operational tools –you’re building rapport with the IT team by speaking the same language, and the purchasing authority resides in another department.

Think of building an OSS dev tool, but where sales buying your product

Transparency

While the transparency side of open-source software may not be a precise fit for small and medium-sized businesses, it can be beneficial for accelerating deal closures in enterprise sales.

Analytical tools pioneered the new wave of open-source solutions as handling sensitive client data is challenging, especially in the time of GDPR. That’s how Posthog stands out among analytical tools like Amplitude, and RudderStack stands out among Segment and other CDPs. Tools usually offer two options: self-host or cloud SaaS. Even if you opt for the product's cloud version, you can verify and audit data processing transparently.

Using open-source software may streamline the process by reducing the need for a hundred XLS files from security and compliance teams. Security developers can look at the running code, even if they don't run it themselves.

Moreover, most COSS companies even offer air-gapped self-hosted versions that do not send back data.

Integration-rich products

Open-source systems allow users to contribute features, such as integrations and adaptors, which can expand the software's utility to new use cases. 

The community develops niche features while a central engineering team manages the core product. In contrast, closed-source solutions face challenges as they depend solely on their internal engineering team’s capacity.

This is particularly beneficial for products with long-tail dynamics that need multiple connections with libraries, frameworks, or applications. For instance, Airbyte excels in ETL by offering unique connector support that other solutions may not provide. Previously, users had to persuade proprietary ETL providers to build the specific connector they required, which was often challenging.

However, it may sound more complex than it may sound. Source

AgentHub was open source when I first started it. I was really excited about the idea of people building their own integrations and fostering some sort of community around cool automation.

We noticed a few things though. 

1. People who were most excited about no code did not want to contribute code to the project. 2. We were 95% open source because we were dealing with credentials and sensitive info on our hosted servers. This 5% of obfuscation was enough to make contributing annoying since you didn't totally understand how some pieces fit together. 

3. We were adding new features and redesigning aspects of the system so often that it felt simpler to close it and accelerate. Features like node versioning and secure credential storage made it all quite difficult to maintain in an open way.

I do still love the idea though. Having people contribute their own integrations would be an absolute dream.

Community 

Users talk in forums, comment on docs, create GitHub issues, and chat in Slack or Discord, revealing their pains and preferences to the product's core team. As a result, you can reduce time spent on product discovery and focus on delivery, making the team leaner. 

Hiring is also easier. Being open source alone makes a company way more appealing to engineers. On top of that, as the community is actively listening to new company updates, there is a lead base that does not need to be sold on how cool the company is.

Go-to-market motions

Before proceeding, it’s remarkable how effective the famous Joel Spolsky's “Strategy letter V” essay is today. I suggest reading it before you move forward.

At this point, it’s pretty common for people to try to confuse things by saying, “aha! But Linux is FREE!” OK. First of all, when an economist considers price, they consider the total price, including some intangible things like the time it takes to set up, reeducate everyone, and convert existing processes. All the things that we like to call “total cost of ownership.”

Fundamental economic law applies to most open-source software development tools. But, when the price of a product's complementary goods decreases, the demand for that product increases. Therefore, companies aim to lower the price of their complementary goods as much as possible to increase the demand for their products. Intelligent companies go a step further and try to turn their products' complementary goods into commodities.

Let's explore which parts complement each other in the operational tools market.

OSS Operational tooling companies

We studied 40 commercial non-development open-source products through the lenses of GitHub data, funding data, and annual revenue estimation (powered by Apollo)

The detailed view of the spreadsheet. (Respond to this email (d@nonamevc.com) if you facing any troubles accessing the file)

---

Here’s the distribution of the product categories

• Customer communication: 7 tools

• Website Analytics: 6 tools

• Marketing automation: 5 tools

• Internal tools: 5 tools

• CRM (Customer Relationship Management): 3 tools

• In-product communications: 4 tools

• In-product onboarding: 2 tools

• Product Analytics: 2 tools

• Appointment scheduling: 2 tools

• CDP (Customer Data Platform): 2 tools

• Form builder: 1 tool

• Billing: 1 tool

Out of 40 companies, 18 have raised the VC capital.

1. Odoo CRM (CRM, ERP) - $493M, Latest Funding in 2023

2. Rudderstack (CDP) - $82M, Latest Funding in 2022

3. Appsmith (Internal tools) - $52M, Latest Funding in 2022

4. RocketChat (Customer communication) –$37M, Latest Funding in 2023

5. Cal.com (Appointment scheduling) - $32M, Latest Funding in 2022

6. Lago (Billing) - $22M, Latest Funding in 2024

7. Posthog (Product Analytics) - $27M, Latest Funding in 2021

8. Pipedream (Workflow automation) - $22M, Latest Funding in 2022

9. n8n.io (Workflow automation) - $14M, Latest Funding in 2021

10. Tooljet (Internal tools) - $11M, Latest Funding in 2023

11. OpenReplay (Website Analytics) - $6M, Latest Funding in 2022

12. Umami (Website Analytics) - $2M, Latest Funding in 2022

13. Jitsu (CDP) - $2M, Latest Funding in 2020

14. Chatwooot (Help center) – $1.6M, Latest Funding in 2021

Seed-stage YC companies (likely raised the seed amount; no other data is available)

15. Activepieces (YC S22) Workflow automation

16. Refine (YC S23) Internal tools

17. Laudspeaker (YC W21) Customer communication

18. Twenty CRM (YC S23) CRM

Not every tool in the dataset has disclosed funding, which could imply self-funding, minimal external funding, or a strategic decision not to seek significant venture capital. According to the data from Crunchbase, Countly (Product Analytics), Matomo (Website Analytics), and SuiteCRM (CRM) generates around $5m annually and haven’t received any VC funding. 

Cloud and Community version

Every OSS product is PLG product in some way. You can try it without a sales conversation. However, designing the proper ladders and pricing is not as easy as it sounds.

There are various strategies here: removing the need to manage the tool yourself, open-core, selling add-ons, or all together.

The harsh reality is that the company is working on 2 or 3 products simultaneously regarding COSS. Generally, the OSS and the commercial product follow two roadmaps and goals.

1. Community product, which makes the company open source.

2. Cloud version of the product. When it comes to the managed cloud, the COSS companies follow the same pattern as their non-OSS counterparts, with an open-core combination for the managed cloud. For instance, the self-hosted version of Posthog has limited features, and additional features like AB testing are available only in the cloud version at an added cost.

3. Enterprise products. There are two directions: the advanced managed cloud plan with security features and custom integrations and the advanced on-premise option, which is only available to select customers.

Note that you don’t have to implement both the cloud and the enterprise option. There are companies that don’t have enterprise plans or companies that provide only air-gapped solutions along with community versions.

The strategy should be tailored to your market, brand, and your approach to sales.

Before designing the pricing strategy, make sure to answer two simple questions:

1. Who is the target audience for each offering?

2. What drives customers to move from the community version to a cloud or enterprise?

Bottom-up motion and SMB

If the company designs the managed cloud solution for self-serve customers, the user has two options for starting the product.

1. Deploy it on your machine and use the self-hosted version. That’s a great way to make the PoC or simply pay less.

2. Begin with the basic tier of the cloud version. In a small startup with three people, avoid focusing on managing the architecture and building your own CI/CD system to update and merge releases. Instead, prioritize essential tasks. It is possible to use cloud products for free for an extended period.

Most companies I’ve researched follow this path to commercialize the product. It seems the OSS tool likely competes with the non-OSS tool here, which leverages self-service usage and follows the PLG ladder. 

Some harsh truths from HackerNews

I maintain an open source push notification service called ntfy [1]. It's 100% open source, but I have recently started offering ntfy Pro, a paid SaaS offering.

I am telling you it's super hard to get people to pay for it. It may be because the free tier is too generous, or because I don't aggressively push or market it, but most likely it's because people can just selfhost it. I have 25k active daily users for the free tier, and probably hundreds or thousands of selfhosted installations, yet as of today, I have only 20 paying subscribers. It's quite brutal.

The question is whether the community version is a feature or a bug. Keep in mind that some users prefer self-hosted solutions and never become customers of the product.

Feature-wise, most companies use volume-based pricing (12 products), likely following their non-OSS counterparts. Unit-based pricing (7 companies) is famous for website analytics and workflow automation.

On-premise vs Enterprise plan

Large enterprise clients typically do not have an issue paying for SaaS, which is usually considered a minor expense. What is more important to them is that the solution is effective, reliable, and user-friendly.

However, managing an open-source solution can be challenging. This is where white-glove service comes in. Premium Support and Single Sign-On (SSO) are the most commonly offered enterprise features among the researched companies.

To enhance security and data features even further, many companies offer air-gapped instances that prevent tool developers from receiving data on what’s going on in self-hosted instances. This is especially important for tools that handle sensitive data, as it limits compliance issues for GDPR et al.

And back to my point about the importance of product positioning. Some companies, such as Lago and Refine, solely target enterprise clients and do not offer cloud options.

Lago pricing

Refine Pricing.

Platform

This relates to the integration-rich part I shared earlier, but I want to extend the initial idea here.  The open-source product has the potential to expand into a platform strategy.

Cal.com is experimenting with building a platform for developers using open-source tools. They provide scheduling capabilities to other applications. Their ICP is another platform or marketplace that facilitates relationships between parties and enables scheduling between them.

The same is true for RocketChat, which enables developers to embed chat experiences into the existing web or mobile app.

Although Cal.com and RocketChat are still in their early days with their Platform strategy, the outlines of their powerful flywheels are already becoming clear.

1. They start by launching a core toolset that offers an excellent developer experience. 

2. This helps them gain traction on the developer side. 

3. As developers build new functionality around the core toolset, the platform's scale and scope increase, leading to more consumer engagement. 

4. As the platform gains wider adoption among platform consumers, the flywheel effect sets in, and developer traction increases even further.

Platforms led by developers have a significant competitive advantage because of their commitment.

License stuff

Each of these licenses has different requirements regarding distribution, modification, and how derivatives must be handled, influencing the adoption and contribution patterns of the software.

Note: the article was published in April 2024, and the license might change. Always double-check the official GitHub repo. 

MIT License (10 companies)

The MIT license is one of the most permissive and allows developers to use, copy, modify, merge, publish, distribute, sublicense, and sell copies of the software and its substantial portions.

Companies: Dittofeed, Umami, Papercups, Shepherd.js, Refine, Fathom Analytics, Jitsu, Postal, Sendportal

AGPL-3.0 License (9 companies)

The Affero General Public License is a free, copyleft license that requires any server that runs a modified program to be accessible to the program's users. It aims to close a loophole in the GPL that allows modifications to be used in networked services without releasing the source code.

Companies: Listmonk, Countly, Plausible, Twenty CRM, SuiteCRM, Automatisch, Typebot, Tooljet, Lago

GPL-3.0 License (4 companies)

The GNU General Public License is a free, copyleft license that allows the software to be freely used, modified, and distributed. Modifications and derivatives must also be open-sourced.

Companies: Mailtrain, Matomo, Easy!Appointments, Budibase

Apache-2.0 License (4 companies)

The Apache License 2.0 is a permissive license similar to the MIT License but also provides an express grant of patent rights from contributors to users.

Companies: Node-RED, Appsmith, Lowdefy, Laudspeaker

GPL-2.0 License (1 company)

Similar to GPL-3.0 but an earlier version. It allows the software to be freely used, modified, and distributed, with all derivatives needing to be open-sourced under the same license.

Company: Open Web Analytics

Elastic License 2.0 (ELv2) (1 company)

This is a source-available license that allows for many uses but restricts the software from being offered as a managed service, aiming to protect the company behind the project's commercial model.

Company: Rudderstack

Custom License (11 companies)

Companies: OpenReplay, Odoo CRM, Chatwoot, Chaskiq, Activepieces, n8n.io, Cal.com, Intro.js, Pipedream, Posthog, RocketChat

9 of the 16 companies that VC has funded have created their licenses. The second popular choice is the MIT license and AGPL3-0.

What to build

As a final note, the idea for the post was initially influenced by personal research on the OSS venture. Still bullish on the approach, and the original post helped to structure the framework. An intelligent open-source approach and outstanding design combination can reshape many established markets.

Love the axis framing of the Posthog team's graph design. Despite being designed for Posthog's specific needs, I think the chart is applicable to the majority of operational tools.

https://posthog.com/handbook/which-products

For instance, as you see, there aren’t many COSS tools for GTM teams besides CRMs. We’re yet to see open-source alternatives for human email (Apollo), lead scoring (Madkudu), product-led sales (Pocus, Endgame), or enrichment tools (Apollo, ZoomInfo, Clearbit) since more tech-savvy personas are getting into the RevOps space. 

If you’re interested in this domain, subscribe to the newsletter or reach out to me in LinkedIn. I will continue to write about it in upcoming issues.

---

Pro tip: Name your company "Open___" then don't open source it.