The Rise Of Open Source
We are coming to an end of our Go-To-Market series. We covered go to market strategies for different motions, i.e 1) Founder led sales, 2) Product led sales (PLG), and 3) Developer Tools. Before moving ahead to other criticalities of building a SaaS business, we wanted to cover the rise of Open source tools and understand what does it take to build a successful Global OSS business (from India).
To understand about the space, we tapped into our go-to-network. We spoke to Rushabh Mehta (Founder of Frappe/ ERP Next — Open source ERP), Navaneeth Pk (Founder of Tooljet — Open-source low-code platform to build custom internal tools), Brian Leonard (Founder Grouparoo — building an open source reverse ETL solution), Jonah Kowall (CTO at Logz.io — an Open source Observability platform).
Before we move ahead, as usual, let’s take the ‘The Nuts and Bolt’ approach to understanding the How’s and the Why’s about Open source. We have seen a few stellar OSS proejcts coming out of India and rooting for more to come in the next few years. Let us try to understand in detail about the evolution of the space, where it is today and list down some tactical steps to make sure you do not fail to tick the sanity boxes if you are building in OSS. We bring the consolidated learning to you below.
What is OSS and what principles does it stand on?
The fundamentals of open source software development is based on the ideology of code re-use and sharing. It is a way to work collaboratively and in an async fashion with no boundries as such to build something larger than a small set of developers can deliver. For some it is legal innovation of licenses. Licenses dedicate how an open source project can be used (or rather monetized). The reason OSS is preferred is that most developers feel that it is a better quality software, without vendor lockin and also available at a lower cost.
If individuals find a bug or see an opportunity for improvements in a particular code. They can suggest changes of improvements to the code and thereby become a contributor to the project. Around 2000 era, Software was mostly proprietary and the ideal convention was to hoard the proprietariness of a code and use it for commercialization. But in this process a lot of tail end use cases do not get the attention and the developers have to redo a lot of things to customize for their niche use case. Contributing to open source also usually comes from a developer’s urge to build something and share it with like minded people.
Rushabh Mehta from Frappe:
Most open source projects start by some engineer “scratching their own itch” (Linux was started by Linus when he was a college student trying to build Unix for x86 architecture as a fun project). Another common source is that engineering teams within large organisations solve a problem that isn’t their core business, and decide to open source the solution (Kailash Nadh started Listmonk because he solved the problem of sending transaction email at Zerodha). Open source projects in that sense are unlike startups, where founders solve someone else’s problem.
At some point if you think your solution is good enough for others to use, you open source it. It’s also a way to earn some credibility and respect in the community of engineers and just get some kicks from doing something cool. You have to try and make your solution as generic as possible.
📈The journey so far…
Traditionally most of the open source projects have been infrastructure related. It is in recent times that “OSS for X” has become a theme. How does an OSS alternative to X perform compared the incumbent is yet to be seen (but it definitely helps with faster adoption early days). These are exciting times when are seeing OSS projects gather traction in a lot of verticals — From Preset and Metabase in BI, Posthogg in Analytics, CoderHQ in IDE, to RobocopInc in RPA and many more.
During the very early days the value of closed source companies superseded the open source projects. Thinking of OSS as the next big monetization engine was never even a second thought. This was a gradual shift from You can’t make money from Open source or Why Open source business model is a failure to having Cloudera, Github, Mulesoft, MongoDB and Elastic that were the part of multi-billion dollar IPOs or M&A deals. We cannot forget Redhat, from going public in 1999 at $3.6Bn to be sold to IBM for $34Bn. We believe this is just the beginning. In the 2000 era, cloud computing opened the doors for software-as-a-service (SaaS). As more and more projects got hosted on the cloud, the users started less caring about if the project is proprietary or open source.
Can’t agree with what Rushabh thinks on the journey of OSS so far -> Commercial Open Source has really come of age in the last few years. While there was an odd RedHat and MySQL, few projects were able to make it big. A whole bunch of companies that bet on Open Source like Novell and Sun Microsystems (Java) went into flames because they couldn’t find the right monetization model.
Now with the coming of the cloud, the open source companies do have a chance. The success of MongoDB and Elastic have attracted tons of venture money into this model. But neither Mongo nor Elastic are profitable yet. Clearly there is a model here, but I still think we are in early days to figure out where this market is going. Right now we are witnessing a Cambrian explosion of funded open source projects mainly driven by too much capital looking for the next hit. This will either end in a bloodbath with 100s of dead projects or the entire history of software engineering will be re-written. The next several years will give the answer to this.
Benefits of Open source?
There are many benefits to open source software, but one of the most important is that it provides an environment for rapid feedback on products and innovation. It speeds up product reviews and innovation as well as improving reliability while scaling up support or driving adoption rates among users who also have access to pooling their knowledge about certain fields. This type of development first started with free software but now has expanded into other forms like “open-core” models where products come with some features freely available while others need payment in order to be unlocked.
But on the flipside, for years companies have tried to be the “Red Hat of category X” and every one of them has failed with zero exceptions. Instead, these same companies started being mostly open source also known as “open core”. The idea was that you’d license 90% or more of your code under an open source license while holding back just enough (in areas outputting in security, management etc.) to nudge a small percentage of your project users into product buyers.
There are a few obvious benefits of OSS which are listed below:
- High Inflow of users: A lot of projects struggle to get the mind-share of their potential users. OSS is a great way to be out there, build in public model where you can solve for the top-of-funnel for your user case. You can then reach them directly and have an established credibility before you connect with them to convert a customer when you are competing with the cloud vendors. OSS can help you gain traction, build trust and help users save development costs.
- Reduce friction: OSS is more of a developer PLG. It reduces the friction for the devlopers to try out the project offerings which in turn results in increasing awareness in the community and increased adoption of the project. The traditional sales model is taking a hit which used to be majorly top-down. Here projects can reach their target audiences directly reducing the friction to adoption.
- Consolidation: In a traditional SaaS model, if you are using N different vendors, your data is on N different databases. OSS solve for the classic build in the build vs buy scenario. A lot of teams are today favouring more control over the data they have. Secondly OSS also helps in a way that it also takes care of the tail-end use cases of a particular product which a startup may not have bandwidtch to work upon. This indirectly helps with more control over data i.e low privacy and security concerns.
⚙️How to approach problem solving?
There are many open source companies today, but not all of them follow the same business model. The right approach for a company depends on various factors. There is no one true way to build a business around an open-source project. But there are set steps that you can follow to ensure you are not missing out on anything.
1) Chase a problem that is hard to solve
Best way to get this validated is to speak to early users. Most developers are focused a lot on creation but what’s equally important is to be out there talking to as many users as you can. Make sure to vet it with Enterprise customers and see if the problem that you are trying to solve is a vaccine or a pain killer. Get thought leaders to be a part of your journey. This would help your project with some validation.
2) Articulate your value
One of the critical parameters going about building an open source tools is to convey the problem you are solving to potential contributors. Drive interest and awareness through documentation and there are multiple tools coming up in the domain that help you do this. Onboard some advisors on board who could speak for you in conferences and explain the impact of your project. Hackernews, Reddit, Quora — are some of the places where you can talk about your product.
3) Make projects easy to use/ download
Make sure that whatever you are solving for has been a pain point for your users and they have spent some time trying to rectify the pain point — this is a sure. shot way to understand that your customers will love what you are building. If it is in OSS for X category → See if you are making it atleast 2x better for developers to use than using the existing SaaS tool. Have a framework on on the product thinking aspects — communicate on what will be paid and what will be free.
4) Focus on community development
Everyone has been speaking about community led growth. But this concept has existed since a while now as far as developers are concerned. Bounties, hackathons are great but are unlikely to bring in long term contributors and they might also cost some good amount of time and money. Focus on creating a high gravity community — one that excels in attracting and retaining members by providing an outstanding member experience.
Managing the community and evaluating the intent of the users to understand their intent of use might help you understand your funnel better.
Peter Levine — “your code is not a competitive advantage, your community is!”
A strong community creates a loyal user base of significant customer leads for the proprietary paid commercial version.
5) Measure success early in the days: It depends upon the persona. For the founders of the projects, it matters who are contributing to the project. For the users of the projects, they look at Github stars and number of contributors. This is just a side product of the fact that your project is working well and not something that you should be chasing. The success of the community can be measured by GitHub stars, commits, pull requests or contributor growth. A truer metric is how many people are showing up on your channel or raising issues or even sending fixes.
💰Commercialization for Open source
Open source adoption has historically been difficult to monetize — less than a decade ago, it was nearly impossible. Sadly, that’s still the reality for many open source maintainers and companies alike today. Lots of successful open source projects can’t get enough financial support to maintain their code-of course there are some exceptions too! For example in 2020 GitHub reported having more than 190 million repositories; if only 10% of those want to build a business on top of their code what are the odds they’ll see any financial reward?
They’re probably lower than startup success rates. And even if something is successfully maintained by outside parties, that doesn’t mean it will be self-sustaining long-term because an external party might not always have all the needed skillsets or resources. Despite its large user base at MongoDB ($100M spent on development), did not become financially sustainable until over ten years after launch.
It has not been an easy journey and you can read up on struggles Gitlab had to go through, or blogs around how CockroachDB, MongoDB or Elastic had to go through repositionings in their open source categories.
On the other hand, building an open source business is a time consuming activity. BVP has done an excellent analysis of understanding the timelines for some very successful projects:
Monetization of open source is a deep topic in itself and shall be covered later on. Licensing is the best way to approach this.
To lay it out briefly there are three types of licenses:
- Copyleft License (copyright focused),
- The Server Side Public License (developed by MongoDb),
- Permissive License (minimal restrictions.
Permissive OSS licenses are the preferred option for most OSS projects these days — ~75% chosing to do so. Make sure that you think about monetization since the start — “Docker had massive adoption but was not able to monetize”. But when the open source business model works, it brings lasting monetization. Once these companies turn on the monetization engine they are catapulted by the strong underlying community, and the journey from $1 million to $100 million ARR can be faster than some of the fastest-growing traditional SaaS businesses.
The approach that we are seeing here that is gaining traction is building a proprietary code over an open source software. You can provide value added services and charges for certain features. There is thin line between providing value and driving your users away. At a slight disappointment, you are at the threat of ‘reverse uno’ with someone forking your project and deciding to build on the features if the value/payment expectations are not met.
Now, there is a definite threat when open source businesses reach maturity. This would be when the topic of licensing comes up, which may cause companies to shift from open source to public cloud environments for their own purposes. Licensing has been an ongoing discussion in many forums and discussions at different times, so it’s important but with startups we see too much time being spent debating licenses early on rather than focusing on what needs to happen next in order for them grow or progress.
Rushabh articulates beatifully on the commercialization bit →
For most people starting new, you must remember that you won’t make money from your code, you have to build allied services. The best analogy I have heard is that your open source software is like a public highway system, the people who make money are the auto companies. Be prepared with the fact that if your open source project creates a lot of value, everyone from AWS to Azure are going to make money off it. For us at Frappe, we spent the longest time making software that did not suck (it still does to a point), but since we are in the complex domain of enterprise software / ERP, we were able to sustain via services.
If your project becomes wildly successful, you will easily make money. If you have an investment runway, you should invest time in talking to your users from early on and build a solid roadmap. There are many blogs on how to make money from open source, but the typical models are:
- Services
- Hosting / Cloud
- Open Core — licensing extensions and advanced features (there are many flavours of this)
Of these, services are hard to scale. You need tremendous scale to make money from hosting or licensing. Personally I am not a fan of Open Core as it appears like a deception or a “freemium” rather than true open source.
Resources
We have pulled in some resources that we think might be helpful for someone thinking to start an open source project might find helpful.
- Balancing Makers and Takers to scale and sustain Open Source
- Amazing perspectives on Open source
- The Money In Open-Source Software by Max Schireson at TechCrunch
- Charging for Open Source by Mike Perham (author of Sidekiq)
- Free and Open source software foundation
- The Money In Open-Source Software by Max Schireson at TechCrunch
- Tools for managing Open source programs
- Equity for effort
📑OSS Landscape
We tried to map categories against their OSS offerings and highlighted a few projects built from India. Please note that this landscape is not comprehensive and we may have missed out some names. Do drop a comment to notify what we’ve missed adding to the list.
