The experience of maintaining an open source project can differ greatly depending on the type of project but one thing that most open source maintainers can agree on, however, is that it’s very difficult to turn open source into a full-time career.
In addition to difficulties related to dealing with entitled and sometimes abusive users, the next biggest problem for OSS maintainers seems to be about monetizing their open source projects. Monetization might seem like the antithesis of open source, but in reality, most OSS developers would love to be able to quit their day job to be able to dedicate all of their time to their open source work. Unfortunately, finding sponsors is often very difficult.
This article is an attempt to make sense of some of the forces at play in various open source communities when it comes to monetization. I hope that it will help developers who are thinking of starting an open source project to figure out what they want out of it and to better understand what the different options might be.
Opinionated vs standardized
If your goal is to create a popular open source project, then one of the best ways to achieve that is to implement an open source product which follows existing industry standards or conventions.There are lots of known problems whose solutions have been standardized (e.g. ISO or RFC standards) but which are yet to be implemented in various languages or which could be adapted to new scenarios.
It’s usually much easier to adhere to existing standards and practices than to try to invent something completely new from scratch. Trying to change an entire industry on a $0 budget is essentially impossible these days; the wise thing to do is to build a product that the industry already understands and where the demand for similar products already exists.
If you don’t follow standards, you are choosing the path of “trial and error”; trying to invent something entirely new from scratch will usually take much longer than you can anticipate and there is a significant risk that people might not see any value in what you’ve built. It’s one thing to make your code run on your own machine to suit your own needs but it’s an entirely different thing to make your product ‘open source worthy’ to the point that large companies would consider using it in production. Getting big companies on board is a crucial step toward monetizing your open source project later.
Following standards is great to get your code out there but it does have one significant downside; the more closely your project adheres to standards, the more difficult it will be to monetize once you do get users. When you implement a standard, you’re not creating any new markets; you’re tapping into an existing user base and competing with other implementers in a race-to-the-bottom in terms of performance, efficiency and usability and it’s hard to capture any value out of that.
Standalone vs integrated
Standalone open source projects also tend to be difficult to monetize. By standalone, I mean software like ‘Gimp’, ‘Libre office’ and any other utilities/tools which are self-contained, complete products.One significant difficulty with them is that the surface complexity of the product is usually small and limited — They’re not designed to be integrated into other more complex software or architectures. The other difficulty with standalone products is that they tend to target non-enterprise users who don’t have much cash to spare.
The best way to monetize stand-alone OSS software is typically through commercial add-ons or by selling a premium version of the software on the side (freemium model)… The challenge with this approach is that most of your users tend to be individuals (not companies); these users don’t have big budgets to spend on add-ons and they’re often not willing to pay for premium versions; this means that you have to get a lot of exposure in order to generate any income. You need to create a product that has enough free features so that it looks attractive when compared to commercial alternatives but not so many features that you have nothing left to sell; it’s a difficult balance to achieve.
Leaf vs branch
You may find that some projects are like ‘leaves’ and others are more like ‘branches’. In this context, a ‘leaf’ is a project that services users directly; a ‘branch’, on the other hand, does not service users directly; typically it is a dependency or component of one or more higher-level ‘leaf’ projects.
An interesting thing to note about a branch project is that a disproportionate portion of the project’s users don’t actually realize that they’re using it. Branch projects are the ones that people tend to take the most for granted because they’re incorporated into other projects and essentially hidden from the user… Until something goes wrong. If the software crashes with an error, and the error appears to be related to a specific dependency, developers can be quick to blame the dependency instead of the higher-level project. This is at odds with reality because branch projects are typically much more heavily battle-tested and stable than leaf projects. If you maintain a popular branch project and you introduce a bug in your project’s code, you will know about it after 5 minutes when the complaints start pouring in on GitHub… So errors are typically discovered and fixed quickly.
One other thing which frustrates maintainers of these branch projects is that different users tend to raise the same issues over and over again, sometimes over the course of several months or even years. The worst part is that it’s often because of unrelated problems in one or more downstream projects.
So before raising a new issue on a GitHub project, please do yourself and the community a favor by searching through past issues before posting; if the project is widely adopted, you will usually find that the solution to your problem already exists.
In spite of being extremely important, open source ‘branch’ projects tend to be difficult to monetize. One of the biggest problems in open source (and perhaps in society as a whole) is that in order to make money, you need to be close to the people who have the money; in this case, users of the product — Ideally, you want those users to be big companies with big budgets.
If you maintain a branch project, most users of your project won’t realize that you exist until something goes wrong in a dependent project. So basically, if things go wrong, users will blame you but if things go well, you’ll get no credit. When things do go well; all the credit and donations will go straight to the dependent ‘leaf’ project maintainer. As you’ve probably figured by now, it sucks to be a branch.
So if you maintain a popular ‘leaf’ open source project and you can identify some dependencies that are critical to your project, maybe try to get in touch with the authors and see if you can give back in any way; even if it’s just to say thanks.
Library vs engine/platform
Developers love building libraries and engines to make other developers’ jobs easier. If you want to create an open source library, that’s great but it’s much harder to monetize than a full-fledged engine or platform. Most of the time, people take open source libraries for granted. Also, simple libraries are typically easy for users to replace with other libraries. On the plus side they don’t require much commitment in terms of maintenance and they’re nice to mention on your resume; especially if they get a lot of downloads.
Engines and platforms are easier to monetize because they tend to be more complex, harder to replace and they are more ‘architectural’ in nature which means that big companies often need help setting them up in accordance to their specific infrastructure and requirements. As a project maintainer, engines require a lot more commitment than libraries though. For example, it takes a team of people many years to build a good quality open-source database engine. Any other kind of engine or platform will typically also take many years to build so you should approach it as a lifelong commitment.
Overhyped vs underhyped
A tiny portion of open source projects get a disproportionate amount of attention very early on in their lifecycle while the vast majority of projects get hardly any attention for years. If your project is in the latter category, rest assured that it’s not all bad. Getting a lot of hype early can be great but it can also introduce a lot of problems that make life difficult and can set the project up for failure later.
One problem with hype is that if your project isn’t ready for it, you run the risk accumulating a bad reputation before you even get the chance to collect meaningful feedback from your users.
Another problem with hype is that it can create unrealistic expectations in the minds of your users. Once the hype reaches fever pitch and people start blindly jumping on the bandwagon, your project will start being used in unintended ways and by people who probably shouldn’t be using it in the first place. Users will start raising issues that are outside the scope of the project; at best this will create a lot of distracting noise and at worst it could affect the evolution of the project in ways that are not desirable in the long run. Eventually, when users realize that your project is not a silver bullet as advertized, the project’s reputation could start to falter when disillusionment sets in.
In terms of monetization, hype is generally a good thing; you could actually get into situations where different companies are competing to be the main sponsor of your project in order to get their logo displayed on your project website. The hard part is probably figuring out the right companies to work alongside with depending on what they can bring to the project.
Summary
Ironically, it seems that the more ‘low-friction’ a product is, the more difficult it is to monetize. Some people in the OSS community will make jokes about how some terrible OSS projects make a lot of money by being intentionally poor quality and thus forcing enterprise customers to keep paying for support. Fortunately, there are less cynical ways to monetize OSS projects; ultimately it comes down to choosing a problem domain which is inherently complex and where the solution usually needs to be customized to some extent — Projects like Hadoop and Kubernetes are good examples of this; they operate in very complex problem domains that may demand a significant amount customization and integration work from end users. Selling technical support and consulting around these products should be relatively easy.
Of course, projects like Kubernetes and Hadoop are extremely demanding technically, as a lone developer, it’s probably wiser to try to find a complex problem domain within a more narrow niche that you have experience with.
If you want more information about specific approaches to monetization, you may want to look at this guide: https://github.com/nayafia/lemonade-stand/blob/master/README.md