🗒️ Lessons from building an OSS business
SourceCode Session_01 // Summary Blog
Dear reader,
Welcome to the first blog of our newsletter. A summarization of the session we conducted with Anoop Dawar & Joydeep Sen Sharma on building an OSS business from India.
As promised, here are the learnings and key takeaways from the session.
But first…
👋 Introducing the panel: Anoop & Joydeep
To kick things off, we had Anoop Dawar share his learnings on building an open-source business on April 2nd, 2022. Anoop most recently led product management at GitLab ($GTLB). Over the last 11 years, Anoop has led product teams at ($GTLB, HIVE (Acq by $EXTR), and MapR (Acq by $HPE)). During this time he has built products that cater to Enterprises, SMB, and Mid-market across Data, AI, Developer, SaaS, Open Source, and Infrastructure. He specializes in product-led, sales-assisted GTM models. He has strong experience in company building with a specific focus on making remote and async companies successful.
In case you want to, you can watch the entire session here. However, we’ve got you covered with the summary right below.
🗒️ Lessons from building an OSS business
A lot of the lessons and frameworks discussed are general lessons that are applicable widely. Every business has its own nuances and we’d need to tweak them to make them relevant to it.
To begin with, it’s extremely important for early-stage founders and practitioners to ask themselves why do they want to be an OSS business. Anoop shared four common reasons from his experience →
There are strong beliefs in the industry that all enterprise software should be open source. It gives a lot of autonomy as startups go through various changes.
OSS helps differentiate from the competition and is also easier to sell as an emerging upstart.
OSS also helps people recruit and retain talented employee
OSS also helps keep the company honest and get very good feedback
Anoop also shared some of his favorite open source companies and the ones that he thought had a lot of potential but failed to realize. The live audience felt a lot of front-end frameworks fall in the later bucket too.
The core lesson, as per Anoop, was that having one center of gravity for all those who contribute to the OSS project is critical to the success of the company. Think of some of the successful commercial OSS companies → Confluent, Databricks, MongoDB etc have all one center of gravity. And the ones who weren’t able to do well like Hadoop vendors, the center of gravity was distributed, making it hard for them to win.
🤔 Where are the OSS effects the strongest?
As you can see in the Venn diagram above, there are product users, product buyers, and product builders. Product users and product buyers can be the same in most cases but that’s often not the case in enterprise software.
The strongest OSS effects are felt at the center where the users and buyers of the product also have the opportunity to influence the product development process.
The buyers and users are different in enterprises but even in enterprises, the first wins are in small teams and groups where the user, builder, and buyer are often the same. So it helps as the land motion and then expands outwards.
The interesting case is where product users are buyers but the persona is a non-technical user. Think Notion → Notion isn’t OSS. Will most Notion users consider an OSS product? Maybe not. But will the developers who use Notion consider an OSS product? Maybe yes. And can they eventually influence others? Maybe yes.
🙁 When not to do OSS?
There are situations when you’re not at the center of the OSS Venn Diagram. Do you still consider OSS? OSS might not seem like the best idea for a number of reasons as stated in the image above but Anoop feels that these are some of the common misgivings. Let’s unpack them one by one →
You feel it’s a tax as you’d need to do a lot of stewardship and governance. Especially, institutions like Apache are very demanding in terms of requirements. Yes, you spend a lot of time doing this but you derive a lot of value and discipline out of it. You leverage the community and see how consensus can be made and you’re also able to work with voices and influencers outside of your company. And this back and forth communication is healthy as the company matures and gets into sales negotiations.
You think it’d help you get customers and then change it to closed source → it’s clearly NOT the way to go as it’s damaging to the reputation. There are ways to deal with it. For instance, after a certain point, most major new improvements could be closed source as add-ons or even could be under a different license.
You don’t feel like engaging the community but that kills the benefits of OSS. One of the major benefits of OSS is having other people’s eyes and opinions on it. When run well, OSS wins many well-wishers and deep advocates outside of the company.
You are afraid the OSS would expose your best engineers to the world and someone might poach them. The reality is actually counterintuitive as OSS contributions give your best engineers a legacy and it helps in acquiring the best talent to come and work for you and not the other way around.
You want to hire a non-tech community person to engage with the community → early on, the people building the product should be the ones to evangelize it in the community.
You are afraid that an OSS product might distract you from building for the user. If you re-look at the Venn diagram, you might understand that this is a valid concern. A lot of time OSS products are not good at UX.
You are concerned about why the customer would pay money since it’s already OSS. This was a valid concern in the previous years but a lot has changed now. OSS products have a lot more than the source code. There is support, there are extensions, there’s domain expertise, there are enhancements, there are managed services, and there’s also an ability to have a conversation with the user to understand how to use the product well.
🤝 OSS stewardship is a commitment
OSS comes with its own set of responsibilities and commitments but it does help win a community that’d evangelize and champion you during the darkest of times. Some common things include →
Not putting any piece of software as a closed source once it is OSS
Once a capability is in the free tier, do not upgrade it to the paid tier
Enterprises always give the scope of experimentation to try and make some revenue
Anoop shared an interesting incident from Gitlab that was before his tenure. Gitlab had an early SaaS offering that went down because somebody deleted the database. And in response, Gitlab did a live YouTube video stream to show everyone how Gitlab was working on fixing it.
💰 Monetization in OSS
Recent history suggests that OSS is best monetized as SaaS. Support is a low-margin business but it doesn’t mean that it’s the best monetization strategy for OSS projects. OSS developers are generally more adept with the all-remote work culture.
The recipe for early success starts breaking once companies stop adding capabilities and features into the free/open tier. The techniques that work for SMB and mid-market may not work for the enterprise. And while the free tier is crucial for OSS's success, getting a strong handle on how much it’s costing the company is a great way to start thinking about monetization.
A large part of the commercialization aspect of a SaaS business model begins with instrumentation and data collection. This helps us understand what customers might be willing to pay for.
Anoop recommends an OSS Monetization Expert mode where successful OSS projects measure the right business KPIs and metrics like CAC, LTV, funnel, monthly actives, what features do paid and free users use, etc from the start. This helps differentiate and measure things like paid CAC and organic CAC and also helps align free hosting costs w/ the sales & marketing strategy. Community building is critical and hence, in the early days, it’s very helpful to have basic boilerplate responses for most things.
⁉️ Anoop fielding some Q&A from the attendees and Joydeep
1. Anoop’s view on OSS monetization models that include support
Support might not be the sustainable model while building a long-term products company but it could be a good idea as you’re bootstrapping as you’d get to know to engage with customers which would allow you to discover the kind of implementation and support challenges they run into. It’ll help you improve the product as well as get some revenue. But the key is to articulate why the offering is more than support.
For instance, this is why the paid tiers of multiple commercial OSS projects have features that the company needs to run and not the individual user. The paid tier also includes support but alongside a licensed or subscription revenue.
2. How to monetize a SaaS version of OSS? In some ways, it does go against the multi-tenant SaaS model
Gitlab has a self-managed model which customers do today but they'd love for Gitlab to come and host this in the customers’ VPC for example. But increasingly, a lot of companies are offering SaaS models and customers are paying a premium for it. The proposition is “Come and run in my multi-tenant SaaS environment that has a lot of data isolation and security built-in. But if you want me to run my search or database cluster in your environment and in your VPC, I’m happy to run all of it in your VPC where you own all the administration as it relates to your use-cases but as a vendor, I own uptime, SLOs, SLAs, updates, patching and the like”
3. What is the right time to build your SaaS offering as an OSS company?
Gitlab was a little early to build out a SaaS offering and no one was willing to use it. Thus, they shut it off and then started something when the timing was right. There’s a lot of serious engineering effort that goes into taking your OSS offering and turning it into a SaaS offering.
But this can distract you from building for your customers especially if your customers want to do self-hosting. So, this is a tricky thing to balance. Common knowledge tells us that we need to get to PMF first and then think of building a SaaS offering and maybe by then the customers also start asking for it.
4. New age licenses in OSS
Gitlab’s community guidelines had properly stated that if a feature or capability is in a certain buyer tier, it’d remain in the buyer tier. So if someone submits a contribution that brings it into the free tier, Gitlab refuses the contribution and points them to the community guidelines. They were able to do that as they had such licensing mechanism in place.
Apache as a license isn’t compatible with this. And hence, prematurely engineering your license might not be a good idea. If cloud vendors are interested in your software, it’s easy for the OSS companies to change away from the license then and run away from the vendors as fast as they can.
5. How to measure the health of the community?
To begin with, think of community as two parts → internal community which is a part of the community that is inside your company and then there’s a community that is outside. Typically, for the rate of contributions we can see the rate of contributions, rate of change, how many lines of code, what features, are there few people contributing or are there many, etc.
Ideally, we want a more spread-out system over time. And often these communications happen across all sorts of platforms like Reddit, Twitter, Slack, etc which makes it very fragmented. The idea is to have a systematic way to bring everything to the same forum. For instance, on Reddit, you can point them to something that you have already well documented in the community guidelines.
6. How can OSS projects grow their community beyond Slack and Twitter?
To kickstart some of the conversations, a very good idea used to be to cast a wide, open net on the problem itself to attract all those who are solving that problem. And then the best ideas tend to bubble up into the program and project. It’s also important to build an OS for the community, that at reasonable cadences, throws fresh information and exciting problems to be shared, then the community can keep on buzzing.
As the project gets traction and we have customers, prospects, champions, and users, it’s very important to give them the platform to have their own voice. It helps build credibility massively.
7. How to help individuals thrive when you’re running a distributed, remote team?
Anoop feels async work is the pre-condition for remote work. If in an organization, most of the conversations and deep communication is happening asynchronously, even if you’re in the same time zone, it’s likely going to help you if you want to continue pursuing remote work.
So discussing something synchronously might mean booking a conference room, setting up the infrastructure, and then visiting it with the required set of individuals to do something. This is a lot of human capital hours utilized possibly not in the best way.
Another way of doing the same thing could be to articulate the problem statement very well and then send it to the other person over a document and the team collaborates on the doc using follow-ups. This documentation also helps everyone else to understand how did the entire conversation flow happen.
The habit of writing things down and documenting them for the rest of the team pays big dividends as the company scales.
7. Top-down vs Bottoms-up in OSS
Gitlab had to eventually go top-down and the journey had some interesting learnings. If in a large enterprise, the product is being used by 50 groups in a large company where each group has transacted individually with you and out of which, 10 of them are paying and 40 of them aren’t paying.
Assuming you have done the right level of instrumentation to get telemetry, you’d be able to reach out to the CIO directly saying that 50 groups from the company use the tool. And 10 groups are using it properly with security and compliance while the others are just using the OSS version. Thus, the pitch becomes “how about bringing all 50 of them under one umbrella and making it part of your central services?”.
This happens slightly later in the lifecycle.
🥁 Join the SourceCode community and attend our next session
To participate live in such sessions and get a chance to ask your questions to some of the best minds building products for technical end-users, we’d need you to do two things →
Subscribe to this newsletter & our YouTube channel here
And sign-up for our next event which would be announced shortly
Hope you liked the content. If you have any feedback/suggestions on how to improve, please do not hesitate to let us know.