You can absolutely profit from an open source project

Hacking for fun and profit

When I started building my first project back in 2010, I was mostly focused on features and getting as many users as possible to visit my website.
Back then, I thought of open source software (OSS) as the ideology of hackers and not a real job. Having read Eric Raymond's The cathedral and the bazaar, I really liked the idea of developing software out in the open and sharing my work with the Internet. At first, I thought I'd be doing this just for fun, rather than for profit. I thought to myself that it'd be cool to be working for a big tech company and building open source projects in my spare time. But I soon realized, what I really wanted was, to be an independent software developer working on open source projects.

For the longest time, I thought I was crazy to believe that such an occupation could ever bring me any money. Then I found that other people were already doing it! I was inspired by developers like Mike Perham (Sidekiq) and Lukas Eder (jOOQ) who were maintaining OSS and selling it at the same time. They gave me the courage to try it myself, so I did.

Transparency equals trust

When you build in public or you use platforms like GitHub or GitLab to build your project, you essentially generate trust by providing transparency. And trust is obviously a foundational requirement for doing good business. These source hosting platforms also keep a public track record of your work, which is good for your reputation too. Forget how many stars your project has, focus on how to build the most useful tool in your niche.

It's also a good idea to use websites like Huntr, where you can get reports for vulnerabilities found in your project. Prove that your project is serious about security. And last but not least, always give your users the option to keep their data safe and private - use a robust database and stay away from exotic or obscure data storage technologies.

Types of OSS projects which work best

If you have an open source project which is used by people and companies, chances are it can be sold for profit. Of course, this model would work better for certain types of projects. For example, if you are developing a tiny JavaScript library, it would be hard to package it as a product for sale. I think that it's better to have some sort of full-featured product, which is useful for teams in smaller companies. It is much easier to ask for money from a business, rather than from an individual customer (see B2B vs B2C). If a company already uses your OSS, that's awesome - go and monetize it!

If you don't already have an open source project, or you want to start a new one, here are a few ideas:

• Tools for increasing productivity in teams
• Tools for tracking and organizing projects
• Tools for gathering and sharing knowledge in an organization
• Open source alternatives to expensive enterprise software

Open source software as a marketing funnel

If you have a successful open source project, you can start thinking about monetizing it. Think of the open source model as a sort of marketing funnel:

1. Your useful free tool attracts lots of customers
2. Customers use it and integrate it into their workflow
3. Customers come back to you with feature requests or they look for support
4. You make a profit by selling your time or you build extra features for them for a premium
5. You can also make money by providing cloud-based hosting if that applies to your product

You always have a better chance of converting a free user to a paid customer by offering a paid version of a product that they already use and like.
There are basically two ways to do that - have a single product with two different licenses (e.g. GPL and a custom EULA), or, sell a premium ("pro") version of your software. The best decision you can make is to just start asking for money as soon as possible. Yes, it may sound rude at first but it's vital to your success and sustainability as an indie hacker.

Dual-licensing means offering your software under both a proprietary license and an open-source license, typically the GPL. Customers choose which one they'll use. In a case where your customer is a company, they would most probably choose the proprietary license and pay you, because they don't want to open source their modifications of the software. And when it comes to the client-side code the GPL is very restrictive. Serving a JavaScript or CSS package on a website constitutes "distribution" of the package to the website visitors as they are transferred to and run on the client's machine. This is a violation of the GPL license which your customers would want to avoid and they would prefer the proprietary license. The downside of this model is that you will need to collect signed Contributor License Agreements (CLAs) from your contributors to ensure you have full ownership of the code. Some people are not OK with that and that might result in fewer contributions to your OSS project.

I'm more in favor of the second approach where you have a free and a paid version of the same product. The free version can have a more permissive and commercial-friendly open source license, like the Apache 2.0, and the paid version can have a proprietary license (EULA) and include extra features and support. This is exactly how I run my business - I have a couple of 100% open source projects, one of which has a "pro" version (Scoold Pro). I charge 499€ for the pro version as a one-time fee. It's up to you to decide whether you want to include the source code in that price. I've decided to charge four times that amount for the source code. I simply have a private Git repository that can be accessed only by customers who paid for the code. They are free to download the code and modify it however they need. In terms of support - you'd want to include at least some basic support in the price. For example, the price of my paid project includes one year's worth of basic support (email, chat) and after that customers can "renew" their license to continue receiving more support and features. Even though I'm not technically selling a subscription for the software, the continued support is a sort of subscription-based service which is sold for the same price, each year.

Of course, you also have the option to provide cloud-based hosting for your product, if applicable. Most of my clients prefer to deploy the software on their premises, but some do prefer to have a managed service where they don't have to worry about maintenance and security. This is why last year I launched a subscription-based SaaS for my paid software which is running on the AWS cloud.

On a final note - open source is serious business, so be bold and charge money for it!