When it makes sense to build an open-source SaaS non-dev-tool

[slippinginfaith]

You probably know that recently, Y Combinator published its annual startup request, and one particular area has picked my interest –commercial open-source products..

YC has a history of investing in over 100 OSS startups, as listed [0]. Most of them are developers' tools, but some non-developer products are also emerging. Posthog, Twenty CRM, Tooljet, Activepieces, Refine, Laudspeaker, Jitsu, Lago can fresh out of YC over the past 3 years.

I've been developing an email marketing platform and thought about making it open-source. Initially, I was thrilled by the idea of presenting it as "Mailchimp, but open-sourced." However, I also had reservations about its business potential. So, I began exploring whether this concept could be commercially viable and what niches might be most appropriate.

The primary philosophy behind open-source development tools is to build a substantial user base by offering free access to individual developers. This model encourages these users to become paying customers as their requirements expand, such as when integrating the tool into larger teams or enterprises. Typically, it's reasonable to expect compensation for providing support, consulting, or tailored features. Yet, a highly technical open-source CRM might align differently with this model since such products are often ready for production use right from the start.

To better understand the monetization strategies and market entry tactics, I examined 40 commercial open-source companies across various domains, including CRMs, CDPs, analytical tools, CEPs, help desks, and more. Out of these, 18 have secured venture capital funding, while the rest are either self-funded or languishing.

Here's some takeaways:

When it makes sense.​

1. The dev bro is a crucial decision-maker. The engineering-driven team is led by a tech-savvy founder who prefers self-hosted technology. The second option is when the data or the engineering leadership is a key decision-maker when it comes to the problem you’re trying to solve.
2. Strict security requirements. 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.
3. Integration-rich products. 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.

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.

Go-to-market strategy​

The harsh reality is that the company is simultaneously working on 2 or 3 products 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 with some additional features, aka open-core.
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. Some companies don’t have enterprise plans or companies that provide only air-gapped solutions along with community versions. (Lago or Refine, for example)

When it comes to enterprise suite, Premium Support and Single Sign-On (SSO) are the most commonly offered enterprise features among the researched companies.. 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.

Also interesting is that 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. The same applies to RocketChat, which enables developers to embed chat experiences into the existing web or mobile app.

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.

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

An intelligent open-source approach and outstanding design combination can reshape many established markets. I decided not to open-source my tool eventually, but the research has opened some avenues for other niches. 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 building something in a similar space, I would be happy to hear your perspective.

You can check out the entire post here [1]

[0] https://www.ycombinator.com/companies/industry/open-source

[1] https://nonamevc.substack.com/p/should-you-consider-building-a-non

 

[elle_vee]

@slippinginfaith Another great COSS platform is Budibase.

https://github.com/budibase/budibase

P.s I don't think Tool jet was yc

 

[slippinginfaith]

@elle_vee You’re right! Actually they were rejected by YC.

https://blog.tooljet.com/raising-vc-funding-for-open-source-project/

 

[walkman1943]

@elle_vee Founder here, ToolJet was rejected by YC.

 

[lapidoth]

@slippinginfaith Of course there’s high demand for open source commercial products. Corporations can all chip in a few pennies for maintenance instead of each one spending $1M/yr on a dev team to maintain their own shitty version.

But look what happened to redis. They were being taken advantage of, went private, and corporations forked the repo to have other people maintain it. FOSS is cutthroat. You’re not gonna be a millionaire off it. That’s for sure.

 

[mynu]

@slippinginfaith I always found that if a product can be offered for free I’m never gonna pay for the paid version and change the code myself to suit my needs. Open sourcing your product is the best way to cannibalize your company.

Instead have a strong monetization strategy and start getting customers instead of stars on GitHub for traction.

 

[ginny16]

@mynu Maybe you were never going to pay, but companies will, and it's perfectly possible to run a business like that. Take a look at some of the examples in the OP, e.g. https://github.com/PostHog/posthog and yet they're still doing well

 

[slippinginfaith]

@mynu Well, it’s true, oss for b2c usage it far from the best distribution. In b2b case it’s paid off by enterprise accounts that value the transparency and security

 

[yoly]

@mynu I think it depends on if the product targets enterprise or consumers. There are subscription models that work.

 

[sylviagab]

@mynu In my experience it often goes in the opposite direction. We need a tool at our company, I really want it to just work rather than invest a lot into it, but we've had a long history of software service bills getting out of control and then having to replace the tool by building it anyway but now with a gun to our head and a bunch of things coupled to the tool we can't use anymore.

So the ideal thing we look for is an easy solution to the problem that doesn't leave us excessively vulnerable to the pricing whims of the service provider. We start out on the paid hosted plan and only move to managing it ourself if the costs are unreasonable.

We've been doing that with qdrant, for example. I don't want to deal with hosting that, especially because I expect rapid progress on the tool and thus to have a lot of work keeping things both stable and up to date. But I could if I needed to, and I very intentionally did not use pinecone because it would leave us too vulnerable. I'll just keep paying unless it gets out of hand, because I don't really want to have to have anyone pay attention to the devops there. If it gets out of hand though, at least now we don't have to start from scratch and rewrite everything that touches it, I just need to figure out the helm chart and migrate some config stuff.

I mostly control technical stuff but we apply this philosophy to other tools integrated into business processes too.

Is it a better business position to have your customer over a barrel and thus have nearly unlimited pricing power? Sure. But people can also see that dynamic before they choose which tool to use, and thus there is some competitive advantage to offering a tool without that power dynamic.