When I explain to people that I run a business writing free, open source software, most people look at me like I'm an alien. Understandably so. It's weird and confusing to those who aren't knee-deep in it. It works, and it's great when it works, but there are some unique challenges that this type of business introduces - namely, how do you prevent your business from competing against your free product? How do you produce an excellent open source product while still offering something of enough value to make it worth it for people to pay you?
If you run a popular open source software project (or are considering starting one), and have ever kicked around the idea of trying to turn it into a business, there are some things you should consider first.
Let's explore some of the more common options...
You have several models to choose from, the most popular being dual licensing, software as a service, consulting, freemium, donation-based funding, and crowdfunding.
Dual-licensing allows you to offer your software under an open source license, but also a separate, proprietary license, for example Oracle's MySQL database which is dual-licensed under a commercial proprietary license as also under the GPLv2. A common tactic here is to draw users in with your free version, and then up-sell them to enterprise features or support.
You can learn more about multi-licensing here.
Selling online subscriptions for hosted versions of your software is a sometimes complex but viable solution. Wordpress, for example, gives away their source code at Wordpress.Org, but users who don't want to host their own blog can sign up for a free or paid account at Wordpress.Com.
If your software is multi-tenant (meaning it shares one instance/database for multiple top-level users), this can be an easier proposition, but multi-tenancy can also bring additional technical overhead and support issues with open source products. It can also raise security concerns with enterprise customers, since shared resources can mean potential data leakage if a bug or exploit occurs in the code that controls what user data belongs to which customer account.
While I don't want to get too in the weeds with respect to software licenses in this article, I do feel there is a key difference between the GPL and the AGPL that's important to note for the SaaS model.
Under the GPL, someone can take your source code, make changes to it and create a SaaS business around it, and they won't be required to disclose their code changes. Under the AGPL, someone can take your source code, make changes to it and create a SaaS business around it but they are REQUIRED to disclose their code changes.
That includes your changes to your own AGPL software. If someone pays us to build a feature for their Snipe-IT install, we have to release those changes or we'd be in violation of our own license. The way we handle this is by explaining to customers that we can build features, but any feature we build must be released to the community project, so we only build features that make sense for the project as a whole and that will benefit all users.
Providing SaaS services without releasing the open-source software itself conforms with most open-source licenses (with exception of the AGPL), but I would argue isn't aligned with the spirit of open source software. From Wikipedia
Because of its lack of software freedoms, Richard Stallman calls SaaS "inherently bad" while acknowledging its legality. The FSF [Free Software Foundation] called the server-side use-case without release of the source-code the "ASP loophole in the GPLv2" and encourage therefore the use of the Affero General Public License which plugged this hole in 2002.
Consulting can mean building additional features, providing training, or support, building plugins or themes, etc.
Other professional services can include paid online support training courses, distribution of physical installation media or binaries, for example as RedHat and IBM do.
Freemium is a harder model to implement in open source, since the source is, well, open, but we do see this in things like Wordpress. While Wordpress itself uses the SaaS model, they also offer plugins like Jetpack, which is free for the basic version but users can upgrade to premium services for a subscription fee.
You can develop proprietary modules, extensions, add-ons, plugins themes, etc for your open source project (assuming it's architected in a way where that makes sense), but it's important to keep in mind the potential software license implications here. From Wikipedia:
Some companies sell proprietary but optional extensions, modules, plugins or add-ons to an open-source software product. This can be a "license conform" approach with many open-source licenses if done technically sufficiently carefully. For instance, mixing proprietary code and open-source licensed code in statically linked libraries[45] or compiling all source code together in a software product might violate open-source licenses, while keeping them separated by interfaces and dynamic-link libraries might often adhere to license conform.
While you can absolutely run a business based off of donations or feature/bugfix bounties, I wouldn't recommend this for smaller projects. The lack of reliability in income makes it difficult to plan a business around. For smaller projects, it might make more sense to find a corporate sponsor to provide more consistent income.
This method can work, but it requires a lot of marketing and word-of-mouth, and the possibility definitely exists that it could flat-out fail if you're unable to drum up enough excitement about your project.
We tend to see pre-order/crowdfunded scenarios as a one-off or two-off project-based campaign and I'm not confident in the long-term viability of this as a business model (although I'm not saying that it couldn't. I just don't know.)
Each of these models have pros and cons, and you'll need to put serious thought into each of them to determine what will work for you based on the nature of your software, the strengths and weaknesses of the team or organization working on the project, and the software license(s) your software is released under.
For example, if you're a programmer without experience in configuring, deploying, maintaining, and managing servers and SLAs, a software-as-a-service (SaaS) model might not be a good fit unless you can partner up with someone with experience there or can secure funding for managed services. It is possible to do, but you're setting yourself up for failure (and a lot of pissed off customers).
When I decided to take the leap and turn Snipe-IT (my open source IT asset management solution) into a business, I had to spend some time thinking about how my business could (and more importantly should) work. The first question in figuring that out is...
You can't really have a discussion about business models in open source without determining who uses your software and what pain points they might have.
In my case, our user base is largely small to medium-sized businesses. My software is web-based, which made it difficult to install for IT managers that had plenty of experience deploying desktop applications but little to no experience running web servers. This meant there was a pain-point we could solve for them as a SaaS product.
The most straightforward model is consulting. You still run your open source project the way you normally would, but you make additional money (either solo or by building a consulting company around it) doing training, building features, etc for companies that want more.
That's a perfectly viable (and successful) model for a lot of companies, but it wasn't what I wanted. I've been a consultant, and while I enjoyed the work at the time, I'm simply not interested in consulting anymore. I don't want to do consulting myself, and I don't want to run a consulting company.
This is your business. It's going to take heroic effort and time to build it, grow it, and maintain it. It's critical that you start with something you want to be doing. Sometimes that means that the most obvious model isn't the right model for you.
Before you jump in with both feet, there are a few more issues you need to think about.
Developing open source software is infinitely more difficult and complex than developing private, proprietary software where you control the environment, the versions that are used in production, and the upgrade process from start to finish.
To make things more complicated, once you decide to open source your product, or to turn your open source product into a business, you have to figure out how to integrate your business into your product without compromising the open source version.
For example, with Snipe-IT, there are things we could add to the source that would make it easier for us to remind users when their credit card is expiring soon, so they don't lose access to their hosted instance - either using a drop-in service like Stunning, or by adding code that calls back to our corporate APIs to check on billing status. That would be better for our business, but would require we add a bunch of proprietary code into our open source product, so we don't do it.
Additionally, there are technical solutions we would use that would make our product better (for example, a simple queuing system for large imports), but would make it more difficult for open source users to install. If an IT manager can't handle setting up a web server, what are the odds they will know how to set up Redis or RabbitMQ? Each dependency adds an additional barrier to open source users. For some projects, that's okay, but for us, knowing what our open source users' pain points are, it's not worth it.
And let's face it, when you add layers of complexity, you end up with more support requests. Which leads us to the next point...
This seems obvious, but I can't stress it enough. When your business is open source software, you still have to maintain support in the open source community. That means that you now have paying customers to support, and a free community to support.
For Snipe-IT, the fact that we release so frequently is a blessing and a curse. It's great because it means new features and bugfixes are always shipping, but it also means that if you run your own version, you're going to be updating a lot. Some people don't want to deal with that hassle. Other people just don't want to bother with running a server just for their asset management system.
We've managed to find the sweet spot of price and value that seems to make sense for our customers so that we're growing every month at a pace that works for us.
We do occasionally lose paying customers to our own free product. Folks who signed up for an account and love the product but decide they want to host it in-house to save money absolutely exist, but interestingly, we have more customers who started with a local install and decided to go with us for a SaaS solution than we have customers defecting to host it themselves. And frankly, those are my favorite customers, since they've already tested the product, they know what it does (and doesn't do), and now just want it implemented in a way that makes their life easier.
We do occasionally get free users who accuse of making the installation hard deliberately to drive people to the hosted version (LOLOMGWUT), which is super frustrating to hear someone say, but we try not to let it bother us too much. We bust our asses building a great open source product. Everything else is just infrastructure automation.
The other thing to consider is that this will be a real business, and not everyone is prepared or willing to handle all that entails. It's a giant pile of paperwork and headaches - totally worth it, IMHO, but not everyone wants to deal with that. Payroll, taxes, marketing, accounting, benefits, employee agreements and employee handbooks all come with running a business.
I ended up going with a hybrid model. The majority of Snipe-IT's revenue comes from our SaaS product, but we do also offer pro support options for folks who want to host the product themselves, usually due to security policies forbidding SaaS products handling certain types of data.
Our pro support plan is actually more expensive than our hosted option, because when we host the product ourselves, we know the environment well and can easily troubleshoot issues. When supporting an install where we sometimes literally can't even access the front-end, support takes a lot more time.
Running your own business, especially one based on open source software, is enormously rewarding, but it's a big step and requires a lot of commitment. Make sure you put the time in ahead of time to determine which model, if any, is right for you.
