While not typically used by large for-profit companies, some individual developers make pretty good money by taking donations for their open source work. Patreon, GitHub, and Buy Me A Coffee are all popular platforms that allow individuals and businesses to help support open source projects that they use or want to see maintained.
The downside to this model is that it’s really hard to build predictable, sustainable income from it. Some people will heavily use and benefit from updates while never paying the creators, and this frustrates those who do support the project. If you’ve ever asked your boss if you can start paying for some of the free, open source software you use at work, you know how tough this can be to sell.
2. Hosted Version of the Product
Some open source projects allow you to run their software on your own servers for free, but they’ll charge you for a hosted version. For example, you can deploy n8n.io to an AWS or DigitalOcean machine and keep it running on your own, or you can sign up for their hosted version and avoid the hassle of maintaining servers.
While this tactic won’t work for every open source project, it’s a very popular option. It offers a clear delineation between the paid and free versions of the product, and can be bundled with other features like support and training. The downside is that your margins are never going to be very high. If you charge too much, users will be able to justify the cost of maintaining their own servers.
3. Paid Support or Courses
Red Hat’s model of open source software financed by paid support contracts and on-premise configuration takes more human hours, but it allows them to improve the user experience dramatically. When companies look at the cost to troubleshoot open source software, it’s usually a better deal to sign up with the people who made the software rather than learn it themselves.
If you want to make your software more accessible, you can sell training at a lower cost than hands-on management and support. For example, The Linux Foundation helps maintain hundreds of open source projects and makes money through its training courses.
4. Open Core
While Wathan’s story is exceptional, it highlights how a free, open source project can make real money by charging for extras (in Adam’s case it’s premade UI components). I would call Tailwind an open core product because while the framework and features are all free, you can support the project and save yourself time by buying extras.
Some open core projects do this by charging for features that larger customers are more likely to need like advanced user management, specialized integrations, or SAML access (there was a good thread on Indie Hackers about this model recently). This is a solid strategy if you know enterprise users will need certain things that individuals and small companies won’t.
5. Dual Licensing
Similar to the open core model, some open source projects offer a dual license. This might allow a small, independent developer to use the software free, but companies using it for a profit must pay a license fee. For example, Qt offers a dual license:
“Qt for Application Development is dual-licensed under commercial and open source licenses. The commercial Qt license gives you the full rights to create and distribute software on your own terms without any open source license obligations…Qt for Application Development is also available under GPL and LGPLv3 open source licenses.”
Companies can decide which license is appropriate and pay Qt as needed. While some companies might abuse this license structure, lawyers will look at things like this in detail if the company ever decides to sell or go public.
6. Selling Other Products
As in Automattic’s case, they offer a free, open source product (WordPress.org) and a suite of related and unrelated proprietary products to generate revenue from. This model is easiest to manage if your other products support the open source one, but some companies raise money from venture capitalists to fund the open source tool’s growth while they figure out other products to build.
The downside to this model is that building and maintaining multiple products is a lot of work. Small teams will find this distracting and it might mean the open source product suffers.