So you want to make a small fortune in open source software? It's simple, the joke goes: Just start with a large fortune. The open source revolution began at least two decades ago, but businesses and programmers are still struggling to understand the best way to share wonderful code and pay the mortgage.
There have been some notable successes: Sun paid $1 billion for MySQL, an eye-popping amount given that MySQL was celebrating raking in $50 million in revenue not too long before. Red Hat has a market cap of more than $6 billion.
Yet for all of this wealth, there's a feeling that these businesses succeeded by being hybrids. They use the open source vision to attract users, but their business success comes by pushing proprietary options. Thus, the dark secret is that their open source version are merely a form of marketing.
Calling this a bait-and-switch may be too cynical, but all users can feel the commercial tilt. Many companies, for example, find it is cheaper to buy a full commercial licence for MySQL than to hire a lawyer to see if they are in compliance with the open source licence. Red Hat makes a big distinction between the free version, distributed under the name Fedora, and its enterprise products sold under the name Red Hat. Lest there be any expectation that their software is truly free, both MySQL and Red Hat offer 30-day trials, a phrase that's not usually associated with the ideals of open source. Remember Oracle CEO Larry Ellison's famous interview with the Financial Times where he said, "If an open source product gets good enough, we'll simply take it."
Other companies that try to be pure and share their code widely discover that users are happy to share the software but not so ready to pay enough to support the programmers.
Zack Urlocker, a board member and executive for several open source companies, points out the trade-off between the degree of sharing and revenue: "Apache has a great licence model that enables the wide adoption of open source software, but there have been few significant businesses, none approaching even $100 million in revenue, based on a permissive licence model" such as Apache's.
The open source community's business debate
The debate over permissiveness is woven throughout the discussions of open source business models. Some companies stay small on purpose, while others argue that there's nothing wrong with proprietary options if they encourage all users to share the costs of development. There is no free lunch, they say.
Zak Greant, a former community organiser for MySQL and open source consultant, says that the open source model works only when there's a fair exchange of work and software: "Free software and open source exist in a market (or ecosystem) where each of the participants needs to give and receive value. To understand what business models work around open source, we need to understand what each participant in the market stands to gain, what exchange they are making and what the effect is on the market."
While this approach sounds like it was drafted by an accountant, Greant points out that the gains and the exchanges may not be obvious. A freeloader who complains vociferously may be annoying, but such demands are also a stream of free bug reports. The challenge for businesses is to find viable mechanisms for aligning the interests of the users and the programmers, a complex task of social engineering.
What follows are eight open source business models that are successful, in roughly decreasing order of purity. Most won't ever be worth more than $1 billion, but they stand a good chance of delivering useful software that solves real problems. And isn't that what open source is really about?
Open source business model 1: Work with friends
Many open source projects are pure hobbies that join together groups of friends. Everyone is a programmer or at least proficient with software. Most people are solving problems they have, scratching a proverbial itch, so they're well engaged and rewarded for their time.
The results are rarely polished enough for nonprogrammers, and documentation is often either missing or not current with the latest version. But this economic model still serves the programmers well: They can take the code and incorporate it into their own work, producing new software for their clients or bosses. Eben Moglen, a lawyer who helped Richard Stallman draft the General Public Licence (GPL), says that open source software packages "provide cheap raw materials."
Everyone is a first-class citizen with all of the privileges of ownership. The participants can profit whenever they find the ability to sell the service, not the code. There's no overhead, no accounting rules, and no battles over intellectual property because everyone shares the title.
Open source business model 2: Work with colleagues
Some of the most sophisticated tools link professional colleagues at different companies with the same job. This model operates much like the one linking friends, but it connects colleagues instead.
The Apache web server, for instance, was nurtured by a group of programmer who sold websites and decided to build something that was easy to configure and extremely thrifty with clock cycles. The Apache project now includes millions of lines of code built and used by programmers.
Likewise, Lucene is often found in the back end of web servers everywhere. The Commons tools are part of many Java stacks. All knit together the contributions of programmers so that other programmers can benefit.
Open source business model 3: Sell documentation
While many managers and professors would personally kick the programmer who turns in code without comments, some open source companies manage to bring in revenue by selling books and manuals that explain how the code works.
This model may become very limited as paper documentation is replaced by digital instructions. For example, the iText package, a collection of Java routines for manipulating PDF files, used to be distributed under the Lesser GPL (LPGPL) and every message on the mailing list came with a reminder, "Buy the iText book." The books are still available, but version 5.0 of the software was released under the Affero General Public Licence (AGPL): People who wanted to upgrade needed to either release the source code to their entire application or buy a commercial licence.
Open source business model 4: Sell support
Opinions vary on whether anyone can make much money selling hand-holding and deeper insights into the code, but it's the approach that most "commercial open source" vendors took in the early 2000s.
Bob Bickel, an advisor to and board member of several software companies, says there are no good examples of support companies that offer both profitability and growth. The names that first come to mind, such as Red Hat and Swing, rely heavily on proprietary enhancements such as the Red Hat Network and tcServer to entice customers to pay for the enhanced version, he says, "it's not the support."
Support is a difficult sell because the costs seem outrageously high: $200 for a phone call sounds steep until you realise that a basic engineer needs to field two to three per day to cover the costs of salary and overhead.
Then there's the problem of competition. Red Hat's stock plunged in 2008 after Oracle started offering support at half the price. Companies may hate this competition, but customers love it. And at the end of the day, it's better to be in a competitive field where there are customers than to have a lock on an expensive product without any customers.
Knowing the poor economic history of support-funded open source, Monty Widenius' new company MariaDB won't handle support at all, instead concentrating on what he calls "custom engineering." This is a form of support with lots of extra code writing mixed in, in other words, big-ticket contracts to enterprises that want specially tuned versions.
But others point out that support is a perfectly viable small, sustainable business. It may never offer explosive growth, but it can still pay the rent. "Support and professional services can be great businesses," says Luke Kanies, CEO of Puppet Labs. "They're just difficult businesses to get funding for, which means they're slower to build and harder to exit."
The problem, he notes, is that they can't grow without hiring more people, and these people cost money. They may be sustainable, but they won't return much, if anything, to the investors. "In an ideal world, we'd have thousands of small and medium open source businesses doing a healthy $10 million to $50 million in revenue and we'd consider that a huge success," Kanies says. "It's the venture capital world that doesn't consider support to be a good enough model, but that's a question of scale and exit potential, not viability."
Open source business model 5: Sell hardware
The biggest devotees of the more prominent open source software movement have always been the hardware companies. Whether they're looking to bargain with Microsoft by releasing Linux netbooks or building the guts for products like the TiVo, hardware companies love open source software because it lowers the cost of getting their products out the door.
Linus Torvalds worked for a chip company while Linux blossomed, and many of his compatriots did the same. BSD Unix? Many contributors worked for either Sun or Apple. And Hewlett-Packard and IBM weren't shy about hiring them, either.
The open source licence is perfect for hardware companies: They can take what they want from the common distribution and maintain full control. There's no fear of lockdown or the problem that the central OS company, such as Microsoft or Apple, might demand higher fees, more control, more commoditisation, or all three.
Because they demand little beyond the copyright notice, some licences, such as BSD, are easier to swallow. Others, such as GPL, can require that all new code be contributed back into the common pile, but there are usually ways around it. TiVo, for instance, releases some of its changes to the Linux distribution, but the main application is just that: an application. It doesn't link together tightly with the Linux code, so it escapes the GPL.
Hardware companies don't need to worry about coming up with a compelling sales pitch to get people to contribute when they download an app for free. There's no need for a tip jar or yearly support contract because people have no choice but to shell out for hard items that make a sound when you drop them.
Open source business model 6: Don't sell software
The best open source solution may be to not be the software business at all. One executive at Google told me flat out, "We don't distribute, so the GPL doesn't apply to us." He was speaking about other open source packages, not the ones Google hosts at Google Code.
Google may roll its changes into the general distribution of the projects it uses, or it may not. It's not selling software, after all. It has an entirely different business model: Google and many other websites don't sell software per se; they just sell the results of using the open source software, so all of the confusing issues about sharing your source code and even duplication go away. Google doesn't need to worry about someone taking its work and setting up another search engine. However, this doesn't mean that Google doesn't contribute in other ways. It often sponsors students to work on open source software under the auspices of projects like the Summer of Code.
Cloud computing and software as a service are trendy technology approaches that work easily with all but the stickiest open source licences. This flexibility angers some devotees who believe that companies that offer Websites should be forced to distribute their source code if they use open source, an attitude that led the Gnu Software Foundation to create the Affero General Public License (AGPL). However, though there are several projects like the Ryzom gaming platform released under the AGPL, it will be several years before anyone can make any decisions about its success or failure.
Open source business model 7: Sell FUD
The major open source software licences don't make a distinction between commercial and noncommercial usage, but that hasn't stopped some open source companies from implying that commercial companies should buy some kind of license.
Indeed, many open source sales teams have learned the beauty of playing "good cop, bad cop" with the users. The licensing fee may or may not be necessary, they suggest, sowing the seeds of confusion. After a bit of debate over whether the GPL applies, they suggest politely that just buying a commercial licence will free the user from any legal worries and at the same time support the product.
Open source business model 8: Cripple your product
The word "cripple" sounds negative, so no one uses that word. It's better to "enhance" the enterprise version and give away the community version, crippling without the nasty name.
Of course, this model gets pretty close to the "open source as marketing ploy" approach that is so bothersome to open source believers. James Phillips, one of the co-founders of NorthScale, says, "There are companies that require a supplier relationship and will pay for open source software. Holding back feature sets, in my opinion, just confuses the customer."
Puppet Labs' Kanies rebuts these purists: "You absolutely have to have something to sell, no one will pay you just because they use their awesome software." He adds, "If you happen to make usable, simple software that just gets out of their way, you won't even know the users exist." So, he suggests, rather than remove features from the free version, you might get the same push to paid by making the free version onerous to use.
Wealth is in the eye of the beholder
At their core, all eight of these open source business models try to balance the amount of openness against the need for revenue. On one end are the businesses that stay small and very open, and at the other end are those that use the open source core to sell a proprietary product.
Users may enjoy the freedom of open source, but they almost always pay for it with the responsibility to shoulder more of the development load. In some cases, the proprietary packages are better deals when they efficiently spread the cost of development among all users; this approach is often best when the user community doesn't include many programmers who can’t contribute much to the mix. But the proprietary code can be a real headache for those with the ability or the need to change or improve the software.
At the end of the day, will anyone become wealthy in the open source business? It all depends whether the wealth is measured in dollars or lines of code.