There are hundreds and thousands of open-source products/projects, and we witness the release of many more daily. This surplus poses an existential question of whether one should bother to create another open-source product instead of a closed-source product. That's a multi-faceted question we struggled to decode for a long time before finally making Devtron open source in November 2020.
As avid open-source users, we have tremendous awe and gratitude for people working on open-source projects. We love open source and want to democratize the DevOps space truly. In our utopia, we imagined that every company should be able to have a high level of DevOps maturity without having to spend substantial amounts of funding and mental space on DevOps.
In front of us, we had examples of companies like Nginx, Elasticsearch, MongoDB, and many others, but did they forward our idea of utopia? We also had a fiduciary duty to our investors, some of whom were very close friends, and as co-founders, the decision was not easy.
In this article, I will walk you through the process we underwent to discover our way of creating a commercial company on the ethos of open source. I hope this will help you find credible reasons to make your product open source.
Why should one build an open-source product?
People build products because they are passionate about technology and want to solve a particular problem for the community. Some build open-source products as a GTM strategy. Let us understand some top reasons to go the open-source way.
To answer this question, one must know why one want to make an open-source product. If the idea is to getting a shortcut to mass adoption is the prime motive, then the chances of failures rise exponentially. They are better off making a closed-source product. There are so many make-and-break decisions one has to make, and if the north star is not at the right place, one can end up being worse than a for-profit closed-source project.
An open-source project can only succeed if it has a symbiotic relationship with the community. A thriving community will also ensure commercial success, but it cannot be the primary reason. With this understanding, let's look at the opportunities that open-source products can create.
Lower barrier to adoption.
As open source is free to use, it is much easier for the community and users to adopt the product without purchasing a purchase order. They can download the product and start using it, and unlike the free-to-use/freemium product, they don't have to worry that they might have to start paying for it once they find it useful.
The flexibility to try the product instantly is critical as this helps with the grass root adoption. Any user looking for a solution to their business use case can start using it immediately.
Collaboration and Crowdsourcing
Collaboration and crowdsourcing form two important parts of the open-source journey. The synergy between them is essential for the success of the project. Crowdsourcing receives feeds from collaboration and, at the same time, sends feedback to collaboration.
As the adoption barrier is low, more users start adopting an open-source project and sharing their use cases openly. The low barrier allows the community to shape up and grow. The use cases, once matured, fuel the adoption of that project.
Product market fit
The symbiotic relationships between collaboration and crowdsourcing allow products to evolve faster in the open and solve genuine use cases for the masses.
An open-source product can provide early warning signs to funders and creators if their project will perform in the future. The creators can gauge if what they have built is solving the pain point of the users or not. If the project is not helping them in their work, they will not adopt it.
How to Navigate an Open-Source Project into an Open-source Product?
Companies like MongoDb, and HashiCorp are great examples of commercial companies built around open-source software. But one has to understand that Open sourcing software is not a business model.
Open-sourcing software can help you reach users and build a product that solves their pain points. It is a great way to make people aware of a solution, and as it is open source, people are more inclined to use it in their environment. When people foresee value, they will share feedback to improve it further. Such crucial feedback needs to be prioritized to improve the project's success.
Many founders try to open-source a project to get adoption from the community, but the community is the sole judge to measure if something is not working and should be closed down. These signals will save the founders severe losses they may have incurred while trying to commercialize it.
The stages of the Open Source community adoption journey
There are three stages in achieving a commercially viable open-source product.
Project community fit:
The first stage is to attain a community fit for your project. The fit is achieved by writing extensive documentation and fixing issues on the project. If the community perceives value, the project will grow, and more people will get involved. A community contribution is essential to achieve the project community fit.
Product market fit:
When a project has attained a community fit, it is time to analyze if people have started using the software in production environments. Finding features to improve and trim will be essential to catapult the product into a commercially viable product. This assessment will provide critical indicators for the founder to decide the project's future.
Most complex products stop at product market fit. Let us understand what the next phase has in store for the founders.
Value market fit:
A Value market fit is when people are ready to pay for your product. The community will provide continuous feedback, and as founders of the project, they must segregate features that large organizations need. This segregation will be crucial to attaining a value market fit.
What stops value market fit?
Simple products and easy to operate.
People will be ready to pay for managing services within an SLA if the product domain is complex. But when products are simple to operate at scale, organizations will not look for help.
No Value on the base version.
Usually, for more straightforward products, founders start building features not available in the base version. But the founder has to ensure that the base version should still add value to organizations. A paywall makes sense only around niche or enterprise use cases. Otherwise, everything will fire back, and the adoption will drop drastically.
Artificial Complexity at scale.
In instances where the domain is complex, the product tends to be challenging while managing at scale. In such a case, users are ok with paying to manage the product. But introducing artificial complexity to the product is not the right way. Founders must simplify it to the maximum extent possible. Even after efforts of simplification, if the domain remains complex, enough people would want to pay to manage services with an SLA.
Business models
Open-source products have three business models to choose from. These models are straightforward, but as a founder of an Open-Source product, one has to select the correct business model to monetize the product.
Let us understand these models and how to decide it.
Services & Consulting:
The main product is free, whereas services and maintenance are charged. Organizations operating with this model have fairly complex products due to the nature of the domain. Most organizations in this model provide end-to-end solutions. A client in this model is less likely to switch to competition as existing integrations and dependencies become deeply intertwined, which may require extensive efforts for migration.
Founders make the mistake of retiring the services as their clients mature. This decision is misguided. Businesses focus on their core competency as they grow and scale, and this is the inflection point where they will look for vendors to outsource noncore operations. Engagements designed to reduce their domain complexity will become a priority, as managing these needs in-house will push them a few years back.
Some examples of platform providers operating the service and consulting model are Redhat, MySql, etc.
Subscription:
In a subscription model, the open-source software version is free but will only work when self-hosted. The software operating in this domain tends to be complex. Users looking for additional features and benefits like backups, upgrades, and worry-free maintenance are willing to pay a subscription fee to use it. The ability to stop using software on short notice makes the model less sticky, with a higher rate of customers leaving to competition, providing better features.
Here founders need to continuously improve their product and bring innovation so customers don't need to migrate to competition. Some examples operating in this model are WordPress, MongoDB, etc.
Open-core model:
The product's core is open and free to use. This base version of the software targets small teams and individual users who can rely on a piece of software without paying heavily from their pocket. But as the team plans to scale to an enterprise level, they have to pay for additional features and capabilities that can work in a large-scale environment.
Conclusion
Every business has challenges, and so does one built around open-source products. I hope you are convinced that the open-source journey is a challenge worth taking. It can help you scale faster and build a product that genuinely solves users' pain points.
It's important to remember that this journey is not some gimmick. One has to be genuinely devoted to the ethos of open source. It is also essential that everyone who is a part of the company is also immersed in the same ethos. If, as a founder, you can achieve that, this journey will be delightful and satisfying.
