Open source as a Product
Open source as a Product
Tips, tricks, thoughts on running open source projects
I have visited an event on open source. Sharing my notes from what I have learned.
Here are some notes on:
How to grow open source
Types of contributors and their motivations.
Bad contributors
Metrics to track growth
Ideas for monetisation
How to benefit from open source
What to consider
"Open source" refers to software whose source code is made freely available and can be modified, redistributed, and shared by anyone.
Open source projects allow community members from around the world to contribute to the improvement of the software.
Open source software often operates under licenses that grant users the freedom to use, modify, and distribute the code, with varying degrees of restrictions depending on the specific license.
How to grow big as open source
Not much I can say here. Build something valuable so others would want to use you.
Think of Mongo DB. It was so good, that every cloud provider wanted to use them. Scikit learn was so good for data science, everyone uses them.
Pick a niche. Find a problem. Figure out how to solve it.
So far classic Product development.
BUT. Normally you would build a prototype and go test it with users hoping that you will find a PSF/PMF at some point.
Here it is mostly about building something you think will solve your problem. And you hope other contributors will join in and help you build it.
And developers/companies will use it because it solves their problem and it is free.
So once you get traction and many companies/developers use your project - it seems a good time monetise it.
Contributors
Theoretically your open source project depends on developers of different stages: students, juniors, mature developers, developers who are in your industry, and developers who just pass by and want to add something. Collaboration of you, your core team and these people will improve the value of you open source.
Sounds good, but this is probably the long tail of contributors, which barely adds substantial breakthrough to the project. The real value comes from two audiences:
Big developers/big companies - they use your open source for 1-5 years. They build their internal systems, features around your project. Then they feel like “giving back to community” and contribute 100-1000 lines of quality code. 5years for 1000 lines of code - this is a long investment.
Students and indie devs - open source is a great way to build up a portfolio for beginners or solo developers. They can contribute frequently and actively participate in discussions. However, due to lack of experience, probability that they would add something extremely valuable is low.
So, most likely your project would rely on you and your core team on development of the core value of your project, with occasional commits from big companies or middle/senior developer. And frequent commits of minor fixes from junior/student devs.
Spam…
Talking about Contributors, it is worth mentioning the spam, or potential Flood of small PR changes. These changes can be simple changes in ReadMe, like adding “,”, corrected spelling, or other minor stuff.
Why is it a problem? Imagine if 80% your PRs are the same small fixes, changes. You still need to process them. Categorise. Review. Close. Merge. Whatever. Imagine that you have to do it to 10s-100s. Wasted time accumulates, desire to keep on working on this project fades away.
Time of core team should be spent on work on actual core features, fixes, improvements, and not “Added a comma to ReadMe”, “Added 10 test cases for code no one uses".
How to solve it? In such cases, be sure to follow your code of conduct and close spam/duplicating issues. If this issue is somewhat relevant, but it was raised before - make sure to keep 1 main issue and direct people there.
One more note. It was advised not to spam to open source projects, because if Hiring Manager sees that your Github is full of such PRs, it would look bad. So do not flood.
To expand on this topic you can watch this.
This comment summarises what was discussed on the event on this topic:
Metrics
You probably should measure the growth of your open source. Besides measuring your website (if you have it) number of visits, socials (if you have it) following, there are some specific metrics you can look at.
Number of Stars. This seems to be the most conventional metric follow, also nice to show on your website to brag.
Number of Forks. It can signal that people are interested in your project so much that they even fork it. But in reality sometimes people fork just to fork. People end up not contributing back or not using it at all. Good chance that they fork for fun to explore.
Number of Pull Requests. This can show how actively people actually engage with your project. Refer to the previous chapter where we discussed the quality/value of contributors.
So, these metrics are not the only ones, but they can be your high level number to look at. You can think of it as:
Stars bring awareness → awareness brings engagement → engagement brings pull requests.
These metrics show you how active your community. But also it is important for an outside viewer how strong the community around the project. They work like social proof of the project value.
Benefits
If you open source as a company:
It helps as it is the way to find new employees, as you can hire people who contribute to the project.
Good marketing. You develop open source, which is considered to be “good” not only by developers, but by industry professionals, and people in general. Works well for employer branding, company branding, and branding in general.
Giving back to community. You make the world a better place as breakthroughs should not be behind a paywall, but available to people.
One more benefit is for developers/contributors. They get a chance to work with experts in the field, get mentorship while fixing issues, gain experience, build portfolio.
However, consider that most of the benefits above seem to apply to big companies.
The sense of giving to community is great, however, it can burn out at some point if you do not get some feedback. There are many open source projects which discontinue support due to underfunding, core team gets disengaged from running the project further, lack of traction and more.
If you are a small bootstrapped company with small or not active dev community, there is low chance that you would have enough devs to pick/hire from.
And you would not be able to rip off great benefits in marketing at the same scale as larger company. Because open source brings many costs.
How to monetise
Monetisation is difficult. Open source implies that anyone can take and use it free of charge. Maybe they will mention your project, but even then not everyone would do so.
So monetisation in open source is not about “How to become rich?”, but rather “Can we make enough to run this project?”.
Does it mean that your project can’t grow without making money? No, not really. There are examples of projects like Scikit learn and Pytorch, which are HUGE, but do not bring money. Not directly at least.
Monetising without having a big cash machine near you making money is difficult. Or a big service which uses your open source and donates to directly.
What are some ways to make good money with open source:
Education/Consulting. You can educate big companies about your project. For example think of large companies trying to implement Scikit, they can buy a course from scikit developers. A project, Spacy - they do consulting on top of open source. Another one, miUI - they use open source as an ad, it brings awareness and then they sell their human hours (or expertise) as consulting or education. There are more examples like that.
Service. Build add-ons, new features, customise open-source for request of a big client.
Build a product on top of it. You can build a suite of products around your open source which are tailor made to work with your project. For example, an open source software OpenCyphal is developed by contributors and core team at Zubax Robotics. But main business of Zubax is actually selling hardware components which work well with the software. Or a process mining company, Apromore. First it had only open source project. Later on they have built a larger platform for process mining for large enterprise.
Introduce a license. Mongo DB was open source. They got adoption. Everyone started using them. AWS introduced Mongo DB. Since everyone uses them for free and big companies make money on them, Mongo DB introduced a license for cloud solution. Now that Mongo DB is a de facto standard, they can close off, and monetise their success.
Donation or Sponsorship. Yes, in contrast with the previous list, but donations can work well. But there is a catch. You need to be UNIQUE. For example, SQLlite. Large companies pay SQLlite to develop it. But probability that your project becomes of the SQLlite scale is… up to you :) Donations work when you are phenomenal, one in a million player. However, when you reach this scale, it is not much of a donation, rather sponsorship from big corps.
Education and Service are quite similar in a sense that they both follow “Service” business model. It means that they are low-margin, not scalable, not exponential growth type of businesses. But you can charge large check on them indeed.
Building Product around your software is a great idea to build a scalable business model. That’s why it is easier to open source from a big company, as they have the capacity to sustain such project with their cash. But going first with open source and then building a product is a good way as well, esp. if you project sky rockets in popularity.
Introducing a license seems to be a viable way to monetise open source, but requires wide adoption. Maybe that is why at first you would need to be as open source as possible to acquire adoption to later lock user in the licensing.
Donations. Well, if you can pull it off, then you are truly unique. It seems to depend on engaged contributors, followers, value of your project to big sponsors and community.
How expensive
Open source is expensive. How expensive? Very. Mainly we talk about time. Think of the following:
If you are not ready to engage with community - open source is not the best way. You sift through PRs, follow up on issues, project manage contributors, figuring out who works on an issue, who gave up and will never contribute again. It takes time.
If you are a big companies, you have to clean up your code base to remove some of the dependencies, to make your component public. You do not want to make it public with your company secrets :D
One easy thing for big companies is the support. If they open source, then they already tend to support 100+ internal users/developers who ask them questions. When open sourcing a project, it means that they need to support another 100+ users from open source community. Yes, it adds more work, but they already have processes and people in place to handle requests.
A little side note that large projects like React will probably not work with community directly, and come up with other mechanisms to interact with community.
It seems evident that for a big company it is easier to run open source as you have resources (time, money, hardware, etc.) to support, maintain and develop this project.
Well, it is so not only for open source, but for building products as well. For example, Google is in much better position than many founders to kick off a social networking platform. But do we see a successful Google social network? Not really, considering there were many attempts. There are many other examples of startups that work much better, even though big companies seemed to be in a better position to run this business.
You might actually have a competitive advantage, as you are able to provide direct support to every community member (probably, you have ±10 active contributors anyway). So this offers great competitive advantage to grow.
Final thoughts
A dump of thoughts:
Open source is a chance to gain wide adoption if you solve some problem and your solution is great
In projects that are relatively small, they would have time and effort to spare on working directly with community and foster engagement.
It offers a great opportunity for students to learn and work directly with extremely strong experts in the field.
There are some ways to monetise open source. Building product and licensing seem to be the most lucrative. Providing service/consulting/education is the second most lucrative option, but not so scalable. Living on donations is possible if you are really goooood.
As a contributor - do not spam with stupid PRs. Understand the project, use yourself, try to fix issues, contribute. It can help improve your portfolio and Github.
Open source is expensive. Think of community support, interaction, maintenance. Think of preparing your software for public if you are a large company opening your internal component.
It is easier to run open source as a big company because of abundance of resources. But it does not mean that your small open source can’t become a success.
Open source is rewarding as you give back to community.
It sounds fun to do open source. It has a great community around it. And it is fun to see open source from a perspective of Product management.