Free Software Business Models
From a text at http://dasht-brk.livejournal.com/28013.html?nc=1
This text explains why the traditional corporate model is difficult to implement in case of free software, with some exceptions. Read the whole article for insight into this rule and its exceptions.
See also our entry on Open Source Business Models
Definitions
From: http://dasht-brk.livejournal.com/28013.html?nc=1
"* What is A Software Business?
We adopt a simple model of a "software business" as one which
provides three services:
1) Basic Support
Customers can report bugs or other problems with the software products. The software business responds with fixes or work-arounds.
2) Critical Maintenance
Customers have already installed and are using the software product. The software business proactively supplies the customer with essential patches. Patches for bugs with security implications are an important example of what is supplied by critical maintenance.
3) Inventing the Future
Computing systems evolve rapidly -- faster than the rate at which they can be deployed and replaced.
A customer often can not buy a software product today unless the customer is reasonably assured that in future years, progressive upgrades to the product will be available. Upgrades must keep up with changes in hardware. Often upgrades must add new features that help a customer to compete.
If a business model can *break even* by performing these three tasks in combination, we define that to be a "software business".
If a software business can return a *profit* by performing the three tasks in combination, we define that model to be suitable for a corporate software business: one which can return a profit to shareholders.
* What is a Free Software Business?
We define a "free software business" to be a software business
in which all software is exchanged under a free software license
such as the GPL.
In contrast, a "proprietary software business" is one which supplies software to customers only under terms which do not permit the customer (or supplier) to freely examine and modify the source, make copies, use the software without restriction, and redistribute the software (modified or not)."
Case Study: Red Hat
"* The Case of Red Hat
Red Hat's pricing scheme for typical deliveries of their
Enterprise-targeted versions of GNU/Linux behave much like licensing fees for proprietary software. Customers are charged per "Installed System" to run this software and the Critical Maintenance patches delivered against it. {note: RH Subscription} {note: RH pricing}
Paradoxically, the software itself is essentially free software (much of it licensed by the GPL, some licensed by various "open source" licenses). {note: FSF Licensing Commentary}
How is this possible? Well, actually, it appears to be temporary market irrationality and we predict its eventual correction.
One problem concerns the subscription agreement which appears to promise to deliver free software to customers but with restrictions on how that customer may copy and use the software. If that is a correct interpretation of the contract (we are not a lawyer!) then the contract clearly implies that Red Hat's distribution of software covered by the GPL is in violation of the GPL. The legal consequence would be that Red Hat therefore has, in fact, no legal right to copy, use, modify, or distribute that GPLed software.
Another problem concerns the possibility of free riders. Red Hat is obligated to make source code for the software they deliver available to customers. (In fact, they make the source publicly available.) Customers have every incentive to expect source code for distributions and maintenance patches to be available very quickly. While it requires a delicate dance around contractual issues, ultimately Red Hat's core "Inventing the Future" and "Critical Maintenance" work products are subject to rapid redistribution which Red Hat can not legally prevent and for which Red Hat receives no fee. Indeed, the CentOS project appears to be headed in that direction. {CentOS}
A third problem concerns the Red Hat brain drain. Red Hat is able to be a leader in "Inventing the Future" and "Critical Maintenance" because it hires so many of the best programmers. As the supply of programmers increases, wage pressures will encourage the creation of not-for-profit organizations which duplicate or surpass Red Hat's work. "Brain workers" will be able to command higher wages if no part of the revenue they help generate is returned to shareholders.
In short, a market optimizes allocation of resources *including* those resources used to modify the market to improve the current optimization. While Red Hat's levels of profit are relatively low, optimizing that unjustified profit away is unimportant and unlikely to happen. Should Red Hat grow too far, attacks already underway against Red Hat's business model are likely to significantly advance.
This puts Red Hat management in a curious position with respect to "Inventing the Future" -- free software R&D. They have incentive to keep Red Hat at a comfortable level of profit: one large enough to survive as a public company but small enough to postpone the inevitable attack as long as possible. What this specifically implies is that, unlike proprietary software companies, Red Hat has only *negative* incentive to invest in the kind of R&D that can generate significantly disruptive breakthroughs. If there were a sudden discontinuous spike in the marginal utility of GNU/Linux and other free software, Red Hat would not expect a corresponding spike in its profits: it would expect to be driven out of business.
So the proprietary software business model gives a firm incentive to create true revolutions in software. Red Hat's model does just the opposite. This factor, too, creates an opportunity for others to construct competing models, either corporate or otherwise, which will eventually displace Red Hat's model." (http://dasht-brk.livejournal.com/28013.html?nc=1_
More Information
Listen to Mark Shuttleworth on the Business Ecology of Ubuntu