The business world has thoroughly embraced, by some definition of “embraced”, Free and Open Source software. No longer is it the sole province of the barefooted ideologues, MIT AI lab vagabonds, or bearded Berkeley beatniks. The biggest businesses in the world now have an Open Source deployment plan. Even Microsoft, the historical protagonist in the FOSS (Free and Open Source Software) story, has begun making vaguely conciliatory gestures towards the community alongside its traditional FUD (Fear, Uncertainty, and Doubt) and Embrace and Extend tactics, because their biggest customers have started demanding better interoperability, better standards compliance, and more transparency: features that are core beliefs of the FOSS world. So, big money has come to FOSS, but so far, the majority of big winners have been traditionally proprietary vendors adding FOSS solutions to their portfolio.
There are a few success stories from pure play OSS companies. Red Hat Software is one, Mozilla is another. But, I see a lot of great Open Source projects floundering with poor business plans and even poorer execution on those plans, wasting time that could have been spent developing and spending it instead on plugging the holes in the business. Most Open Source entrepreneurs start out with the goal of being able to work full-time on their project, but end up having even less time for the project and being broke, to boot. So, I’d like to offer some advice to budding FOSS entrepreneurs.
I’ve now built two businesses based on Open Source software, and I’ve learned a few things about what works and what doesn’t. Many of the “standard answer” solutions to the problem of making money on something that is available for free have died out over the years, as it’s become apparent, at least to the folks who’ve tried them, that they simply don’t work. I’d like to talk about some of those failed models, as well as some of the models that do seem to be working across a wide range of Open Source based businesses.
Service and Support (or, “what’s wrong with being a consultant?”)
This is the old standby for lots of Free Software and OSS purists. The argument goes, “don’t charge for the software, charge for the service and support that you offer”. Most of the people putting forth this as a viable business model haven’t actually built an Open Source based business based on this model. It is possible, but the scale on which you’ll be operating will never be very large.
- Support is fundamentally a consulting business. To increase sales revenue you have to increase head count. Increasing head count is expensive, and your best employees will eventually start their own consulting business and likely compete with you. If you’re lucky, they’ll pick a niche that doesn’t overlap much with your core business.
- Expertise is hard to find. You may be the absolute master of the popular Open Source Frobnosticator project, and people come from all over the world to pay you for that expertise. But when it’s time to scale, see item 1 and contemplate finding or training someone to have your level of expertise with the Frobnosticator.
- The only advertising that works is word of mouth. You can’t easily have someone else sell your services for you. Most of the businesses (IBM, for instance) that might be well-placed to do so have their own services arm that they’d sell before they’d sell your service. Sure, IBM professional services doesn’t have any Frobnosticator experts on staff, but they’ll wing it and bill $200/hour while they figure it out. Thus, you have to pound the pavement to drum up your sales. Do not underestimate the cost of getting and keeping customers.
That said, if I can’t talk you out of building a service and support business around an Open Source project, there are a few things you can do to improve your chances and reduce the pain of the above problems.
Making the best of an Open Source service business
Pick a popular project. I mean a really popular project. Apache, MySQL, PostgreSQL, Linux for an interesting and growing niche (like mobile and embedded devices), one of the more popular web application frameworks, etc. By picking a popular project, you insure there are a lot of users. You also guarantee that you can find other experts to hire when it’s time to scale your business from a one-man consulting shop to a real business with employees.
Become an established expert on that project. Your name needs to be on the core developer list. If it isn’t, you’ll always be picking up scraps. If you can’t see a way to get yourself into this position, you don’t have a business.
Write a book about that project, or at least start a blog. The money for technical documentation isn’t very good, and you’ll spend a lot of time on it, but nothing says “expert” like “You can pick up a copy of my Frobnosticator book at Amazon, for more details on this subject”. If you’ve got a blog, people searching for help on a particular topic related to your area of expertise will find you. There is no better marketing than helping someone solve their problems.
Swell Technology: Joe’s case study OSS service business
Back in 1999, I started an Open Source service business called Swell Technology. I actually intended to build a product company, but the only aspect of the business that ever made money was service. So, it remained a service business until it closed up shop in December of 2005.
I accidentally picked a reasonably popular project, Squid, because I had used it and thought it was really cool. I accidentally became a core developer, because I submitted a few patches, helped out a lot on the mailing lists, did lots of hardcore testing, and made myself extremely useful to the other developers on the project. When one of them needed hardware, I sent it to them. When they needed to make some money, I hired them to build things for my company.
But, it failed to scale. Swell Technology was throughout its life a small business. It bought me a 350Z, and kept me in food and houses all those years. But, I took only two vacations during that time. I also managed to avoid doing a lot of things that I enjoyed, because I was always too busy with the company and its customers.
Hardware Bundling (or, “It’s an appliance!”)
This one is frightfully common. The basic premise is, “Open Source software is hard to install, hard to optimize, and hard to use, so I’ll put it on a box, and sell the box!” This is a horrible idea, and here’s why:
- You can’t afford to be in the hardware business.
- If you’re not already in the hardware business on a large scale, you really can’t afford to be in the hardware business. Dell does not leave room for companies selling a billion or more dollars worth of hardware each year (see Compaq)…how do you think you’re going to hold up doing $1mil, or even $10mil, a year in sales?
- Hardware is really a service business. When you sell an all-in-one solution and charge a premium for it, customers want 24 hour, top of the line, support. If you’re a one or two man shop, that means you’re answering the phone at 3 AM on a regular basis.
- You can’t charge enough. Your customers will talk specs, and the moment they do, they’re going to realize you’re selling equipment they can buy from Dell for a third the price. You’ll actually find that customers want to buy Dell hardware and pay you an hourly rate to install your products on it. The moment you accept such a deal, you have a pure service business, limited to the number of hours you can summon each day.
- Being in the hardware business means that you have one more thing to distract you from your core competency. You develop software, right? What are you doing futzing around with hard disks and RAM and processors all day? Every 12 months your hardware platform changes, by necessity. Do not underestimate the time expense of managing a hardware-based business.
Hardware bundling is the worst possible solution to the problem of “how do I make money with Open Source software”, but it crosses every OSS entrepreneurs mind at least once. I can’t think of a single pure-play OSS “appliance” company that has been an enduring success. Not one. The success stories I can think of have ended up selling proprietary products along-side their Open Source core (Barracuda), or pretending there is no Open Source core (InfoBlox). The really lucky ones sold out to a bigger vendor before things had a chance to go south (Cobalt). The ones that lasted a few years had time to burn through their capital and find themselves on the wrong side of the profit line. (Swell Technology, my first business, was one of those that lasted long enough to lose money on hardware sales…the hardware business was subsidized by service pretty much the whole time it was in operation.)
Plugins (or, “the coffee table is free, but the doilies are going to cost you”)
This one actually crosses the line from pure play OSS business model to a hybrid model, since the plugins aren’t Open Source. Not coincidentally, this is the point at which the business model begins to make sense as a scalable business where your core competency is what you do all day: write software. There are actually a few examples of this that work. MySQL AB doesn’t charge for the core database, but they charge for various extensions and management tools that work with the database. Because databases are a huge market and MySQL is the most popular relational database in the world, in number of installations, they can build a nice company, with employees and everything.
Of course, this is also the point at which Free Software zealots begin to squirm. It’s generally legal, as long as you comply with the relevant licenses, or hold the copyright on the software, so you aren’t restricted by the license. The majority of folks aren’t going to begrudge you making a living. But, there will be some pushback if you’re taking a historically Open Source project, and building proprietary products on top of, or alongside, it. Depending on the community, this pushback could be dramatic and ugly or peaceful and friendly.
Mambo is a fine example of handling this approach poorly. Very, very, poorly. I don’t know the whole story, but the end result was a loud and angry fork and exodus of developers to another project. So, here’s a few tips for how to avoid the OSS death penalty (a fork which takes away all of your best developers):
- If you aren’t a core developer of the project in question, stop here. You need to become more important to the project. You don’t have the clout to pull off a commercial venture based on this project. There is at least one shortcut to this clout: Hire one or more of the core developers, after making sure they’re on board with where you’re going. With Virtualmin, Inc. we have the original author of Webmin, Usermin and Virtualmin, as well as the second best known Webmin guy whose previous company actually funded the original Virtualmin development (that’d be me and Swell Technology). Even so, we got a bit of pushback on building proprietary products.
- Don’t screw with the license. If you don’t hold the entire copyright, you must abide by the license, religiously. Respect the license, and respect the developers, and the users will generally keep quiet. With Virtualmin, we actually hold all of the copyrights, but we are, nonetheless, respectful of the license of Webmin. Everything good we do in Webmin for Virtualmin, Inc. purposes, gets rolled out to the Open Source Webmin immediately.
- Make the core project better through your involvement. Be the best friend the users of the OSS project have. Be involved on the mailing lists or forums, make large contributions in the form of code or money, and make great things happen with the core project. Don’t be pushy about it, and make sure the big ideas you have aren’t at cross-purposes with the other developers on the project. Since we’ve started Virtualmin, Inc. we’ve rolled out a huge swath of usability and UI enhancements to Webmin, as well as several new plugins for Virtualmin GPL. Even though the Open Source users don’t get everything we build, they get more than they would have gotten had Virtualmin, Inc. not existed.
Freemium (or, “the grass is greener on the other side, but your wallet is a bit slimmer”)
This one is sort of an extension of the shareware model of yore, and it’s roughly the model we’ve chosen for Virtualmin, Inc. In this model, you’re distributing the majority of your software under an Open Source license, but for a few premium features, you charge money and protect them with a different license. So, you continue to enjoy the popularity that free software brings, while still knowing that there is a pretty good chance lots of people will pay for the extra features. Our Open Source core has millions of users, so we have a reasonably large pool of potential customers, though the percentage of converts is still quite low (Webmin is downloaded 2 million times per year, and we have 700 paying customers for Virtualmin), but increasing at a steady rate.
This is, perhaps, the riskiest of all Open Source business models, from the perspective of keeping your Open Source users happy. We have effectively forked our own software into two versions, and because the Open Source version of Virtualmin is under the GPL, it attracts the most vocal of OSS fanatics to its defense. We hold all of the copyrights to Virtualmin, and there have been no other significant contributors to the codebase besides me and Jamie, and so the gnashing of teeth didn’t last too long. But, we still rigorously follow the advice given in the section above for keeping our OSS users happy. We give away more than we hold for paying customers. This is probably a mistake in the short term, but we suspect it will pay off in the end, when the de facto solution to a wide array of systems management problems is based on our software.
Dual Licensing (or, “you don’t have to admit you’re using Free Software”)
This is, perhaps, the oldest Free Software business model, and thus one that has stood the test of time. The basic premise with this model is that there are lots of businesses out there that would like to make use of your code in their software, but they don’t want to release their own source code under a Free Software license. So, they buy a non-viral alternative license. SleepyCat, makers of the BerkeleyDB, ran on this model for many years. Likewise for the makers of the Ghostscript Postscript library.
We even tinkered with this model for a while with Virtualmin. Very early versions of Virtualmin exist in two other commercial products, licensed under traditional copyright terms, for which we made a few thousand dollars each. But, this model works best for libraries, because the software really needs to be invisible to the end users (otherwise, users figure out that it’s just some Free Software re-branded and complain about it). This is another case where your market must be huge for it to make sense. Databases and typography are both pretty big and are used behind the scenes in thousands of products.
Note that this model only applies to software that has a viral license, like the GPL. BSD-style licenses are already liberal enough to permit re-branding and distribution without source or without any particular restrictions. So, while our underlying software, Webmin, is used in hundreds of products, we don’t see any licensing revenue from this usage, because it is under a BSD license.
Hosted Applications (or, “Web 2.0!”)
This one is a beauty. You don’t have to worry about licenses, much. Your end users never need to know you’re using FOSS, though you can still get lots of goodwill by tossing out crumbs now and then. The vast majority of Web 2.0 companies (Facebook, MySpace, Digg, 37signals, etc.) fall into this category to one degree or another, as do the big search (Google) and internet media companies (Yahoo). In these cases FOSS is your lever, and some big problem is the world you want to move. It’s kind of like TV, in that you can offer premium services like HBO, or advertiser supported services like the big three networks.
I won’t go into too much detail about business models for web applications, as it is pretty well-covered ground, and I’ve never actually built a pure play web application business, so my knowledge is all anecdotal. But, there’s a lot to be said for hosted applications.
- You don’t have to worry about platform compatibility. At least 25% of my development time goes into making Virtualmin Professional run easily on several Operating Systems, versions and architectures. It’s a serious drain on productivity, and yet it’s a necessary expense.
- Bugfixes can roll out immediately. At Virtualmin, we manage update repositories for our software, so it’s easy to update to the latest versions…but we still find customers running versions over a year old. Having many versions in the field is another big drain on productivity, because you’re answering questions about bugs that have long since been fixed (sometimes I don’t even remember that it’s a bug that’s been fixed, so I end up helping a user troubleshoot the problem from scratch again, only to find at the end of it all that all they had to do was update to the latest version).
- Licensing is a hard problem. Selling software and protecting it from illicit use requires walking on eggshells. Your honest users (luckily most of them, in our field) will be offended if the license management gets in their way. Users who don’t want to pay will do nasty things to avoid it. One of our serious headaches is chargebacks due to fraudulent credit card purchases. Of course, if your hosted app business model involves credit card billing, you have this problem, too…but since the software isn’t installed elsewhere you can lock the account after the chargeback comes through and the user loses their data and the service. Our stick is much smaller: We shut down updates, and make the red license violation box show up on the front page of the software whenever they use it. We could be more harsh, but then we’d risk treating honest customers poorly in the event of problems contacting the licensing server, which we won’t do.
So, those are the obvious business models for Free and Open Source software. A couple of them are known to fail. A couple are known to be difficult and require a lot of luck and a lot of popularity. And a couple are proving themselves effective in a large number of cases. Which one is right for you and your favorite Open Source project, if any, is up to you to figure out.
Getting Real A book by the founders of 37signals about starting a web application business on the cheap.
Paul Graham’s essays. Virtualmin, Inc. accepted funding from Paul’s company Y Combinator in 2007, and many of his essays inspired the business we’ve built over the past couple of years. We’re big fans.