神马文学网The Emerging Economic Paradigm of Open Source
来源：百度文库 编辑：神马文学网 时间：2024/04/28 04:36:23
Bruce Perens
Senior Research Scientist, Open Source
Cyber Security Policy Research Institute, George Washington University.
Last edited: Wed Feb 16 06:22:06 PST 2005
Abstract
Open Source developers have, perhaps withoutconscious intent, created a new and surprisingly successfuleconomic paradigm for the production of software. Examining thatparadigm can answer a number of important questions.
It's not immediately obvious how Open Source[1] workseconomically. Probably the worst consequence of this lack ofunderstanding is that many people don't understand how OpenSource could be economically sustainable, and some may even feelthat its potential negative effect upon the proprietary softwareindustry is an overall economic detriment. Fortunately, if youlook more deeply into the economic function of software ingeneral, it's easy to establish that Open Source is bothsustainable and of tremendous benefit to the overall economy.
Open Source can be explained entirely within the context ofconventional open-market economics. Indeed, it turns out that ithas much stronger ties to the phenomenon of capitalism than youmay have appreciated.
A Strong Economic Foundation
In the early days of Open Source, its proponents did not fullyunderstand its economics. Through our lack of understanding, wecreated the perception that Open Source's economic foundationwas intangible. This led many people to feel that Open Sourcewould not be sustainable over the long term and would beincapable of scaling to meet the market's need for newtechnology. It's important to correct that perception now. InThe Cathedral and theBazaar[16], Eric Raymond attempted to explain OpenSource as a gifteconomy, a phenomenon of computer programmers having theleisure to do creative work not connected to their employment,and an artistic motivation to have their work appreciated.Raymond explains excellently how programmers behave withintheir own private subculture. The motivations he exploreddominated during the genesis of Open Source and continue to beeffective within a critically important group of Open Sourcecontributors today.
Raymond did not attempt to explain why big companies like IBMare participating in Open Source, that had not yet started whenhe wrote. Open Source was just starting to attract seriousattention from business, and had not yet become a significanteconomic phenomenon. Thus, TheCathedral and the Bazaar is not informed by the insightinto Open Source's economics that is available today.
Unfortunately, many people have mistaken Raymond's earlyarguments as evidence of a weak economic foundation for OpenSource. In Raymond's model, work is rewarded with an intangiblereturn rather than a monetary one. Fortunately, it's easy toestablish today that there is a strong monetary return for manyOpen Source developers. But that return is still not as direct asin proprietary software development. Thus, I'll ask you to followa few more steps than you would in understanding the economics ofproprietary software.
How Are You Going To Be The Next Microsoft?
Prospectivesoftware entrepreneurs are often asked: how are you going to be the NextMicrosoft? And those who base a business upon Open Sourceare asked: how are you going to be the next Microsoft withFree software? But thisisn't the right question if our goal is to achieve animprovement over theMicrosoft model. It reflects the fact that most people have beenthinking about software from an extremely vendor-centric viewpoint.
Whether or not we will admit it, most of us are very impressedwith Microsoft's wealth and arrogance, and when we think ofproducing software, we automatically think of Microsoft and theway they do it. But itturns out that the Microsoft model accounts for only aminority of the softwarethat is made and used in business today. Around 30% of thesoftware that is written is sold as software[2]. Most software is not sold at all.It is developed directly for its customer, by the customer's ownemployees or by consultants who bill for the service of software creation ratherthan for the end product. It's important to look at why that isthe case, in order to understand the economics of OpenSource.
Indication of an Unfulfilled Need
In February 1998, Eric Raymond and I formed the Open Source Initiative. We werestanding on the shoulders of a giant: Richard Stallman'sFree Software campaignhad existed since 1983[17] and created much of what people callOpen Source today. Thecombination of the Linux operating system kernel and Stallman'sGNU System was becomingviable for business use. But the way that Stallman chose topresent Free Software depends upon the a priori acceptance of the virtue ofcertain freedoms. Stallman is a programmer, and chose aphilosophical presentation that appealed to programmers. Incontrast, business people are pragmatists and are more impressedby economic benefit. Because Stallman's presentation limited hisaudience, his campaign had not been able to achieve the economicserendipity that is visible today[18]. Raymond andI chose to approach business people in a more pragmatic fashion,with the expectation that they would come to appreciateStallman's philosophy once they'd seen its concretebenefits[3].
The first time the public heard of Open Source was in an announcementthat I posted on Slashdot and a few mailing lists. Itcontained an introduction and the Open Source Definition, both amanifesto of Open Source and a definition of acceptable OpenSource software licensing, which I'd created as a policy documentof the Debian Projectsix months earlier. Eric Raymond edited The Cathedral and the Bazaar, then ayear old, to replace the words Free Software with Open Source.
Some time after myannouncement, a reporter asked Steve Ballmer, then president ofMicrosoft, if Microsoft would "Open Source" their Windowsproduct. Ballmer was reported to have explained that Open Sourcewasn't just source code, it was a form of software licensing. Thevice president of Microsoft had read my manifesto, and the presswas asking him about it.
Manifestos from then-unknowns like myself and Raymond don'tget that sort of recognition, unless for some reason the world iswaiting for them. I submit that the reason was widespreaddissatisfaction with the dominant economic paradigm of softwarecreation at the time: Microsoft and its products. Microsoft waswidely perceived as placing their own interests ahead of those ofthe customer. Their software was known to contain a large numberof un-rectified bugs, and their desktop operating system wasextremely crash-prone. They could get away with this because theyessentially had no viable competition on the desktop.
People were searching for an alternative. If we were going tomake software better, we'd have to find some other way to do itthan what Microsoft was doing. Open Source created new economicrelationships. There was a new peer-to-peer relationship betweenenterprise software customers, who were enabled to participatedirectly in the development of the Open Source software and thusbecame software developers for each other. There were newrelationships between software vendors, who collaborated on OpenSource projects while they competed elsewhere. And there werechanges to the customer-vendor relationship: the customer could nowparticipate with the vendor in software development. Because many vendorscould access the same source code, and thus support the product,there was less lock-in and less exclusivity to thecustomer-to-vendor relationship. As a result of these changes, new suppliersarose, and existing suppliers began to substitute Open Source products forproprietary software.
The public sharing of the creation, ownership, and benefits of softwarewas the antithesis of the Microsoft model. OpenSource had already created a technically successful operatingsystem and the first practical web servers and clients, and thusshowed signs of being surprisingly effective. And so, the publicbuy-in to Open Source started out strong. It was followed bytremendous economic growth, with the Linux sub-sector aloneshowing an annual growth rate of 37 to 45 percent and predictedto be a $35 Billion dollarmarket by 2008[4].
The unusual acceptance and startling financial figures arguethat Open Source must be the answer to somepreviously-unfulfilled need. Otherwise we would not have seensuch wild, seemingly absurd phenomena:
The hobby project of a student in his twenties, Linux, takes over enterprise computing.
IBM, the epitome of conservative business, de-emphasizes its billion-dollar "AIX" operating system in favor of a product developed by a loose coalition of programmers with no financial motive in common, upon whom no corporate directive can be binding, whose leader has no power but the respect of others.
Microsoft faces its first serious competitor in a decade: programmers who give away their work.
These events seem absurd: they certainly don't fit thecommon economic paradigm of technology production. A new economicphenomenon is operating, and to explain it we'll have to lookmore deeply into the economics of software production.Looking for Economic Impact
Since Microsoft is thedominant model of a software manufacturer in most people's minds,and we're exploring the economics of software, let's ask:What is the greatest economic impact of Microsoft?
Is Microsoft's greatest economic impact the wealth of BillGates? Of course not! A lot of people envy his wealth, but Bill'spiece isn't the whole pie.
Is it the fact that they have amassed 40 Billion dollars inthe bank, are the worlds largest software company, and employ55,000 people in 85 countries? No, not that either.
Is the greatest economic effect of Microsoft the fact thatthey have enabled a great many businesses - their customers - todo business more efficiently, and to have businesses that theycould not operate at all without the software that enables them?Yes, that is the biggest economic impact of Microsoft.
Microsoft is a tool-maker, and the effect of the tool-maker onthe economy is tiny next to the economic effect of all of thepeople who are enabled by the maker's tools. The secondary economic effect caused byall of the people and businesses who use an enabling technologyis greater than the primary economic effect of the dollars paidfor that technology. And of course the same is true for OpenSource software.
Considering the Economic Function of Software in aBusiness.
It's important to consider that most companies arenot in the business of software manufacturing. They sell ships,shoes, services, everything under the sun. However, all but thesmallest companies are enabled by software to some extent.Without software, their business would be less efficient, orimpossible. Consider financial planning before computerspreadsheets, correspondence before email, andcustomer-to-computer interfaces when the most sophisticated inputdevice in the customer's home was a touch-tone phone. Today, weneed software to dobusiness! Indeed, we need it so badly that even though mostbusinesses don't sell software, any business of 50 people orgreater is likely to employ a programmer, web designer, or ascript-programming systems administrator[5]. For thosebusinesses, software is essential enabling technology, ratherthan their product.Enabling Technology vs. Business Differentiation
Enablingtechnology is essential to your business, but it's not what yousell. If you sell books, books are your profit-center, andsoftware lives in a cost-center as an unavoidable cost ofdoing business. A polemicist has said IT doesn't matter, but what he isreally telling us is that IT isn't your profit-center. You stillneed it to the extent that it enables your business.
There are two main forms of enabling, cost-center technology:differentiating, andnon-differentiating. Differentiating technology is what makes your business moredesirable to your customer than your competitor's business. Forexample, if you visit the Amazon.com web site and look for abook, Amazon will also tell you about other books that were purchased bypeople who bought the book you're interested in. And often thebooks it suggests areinteresting enough that you will buy one of those books aswell.[6] If you goto the Barnes and Noble site, they don't have that feature, andit's no surprise that Amazon sells more books online. So, forAmazon, the "recommendation" software is a businessdifferentiator. Obviously, it would be a mistake to Open Sourceyour business differentiators, because then your competitor'sbusiness might use them to become as desirable to the customer asyour own business.
But in contrast, it wouldn't hurt your business for yourcompetitor to understand how every bit of yournon-differentiating software works. Indeed, that competitor mightbe the best collaborator you could have, if the partnership islimited to working on your non-differentiating software, becausetheir needs are most similar to yours. This fact is demonstratedevery day in the Open Source world, in which HP and IBM arepartners in developing software that helps sell the systems ofboth vendors, and they remain fierce competitors at higher levelsin the software stack where differentiation between them ispossible and effective.
Perhaps 90% of the software in any business isnon-differentiating. Much of it is referred to as infrastructure, the base upon whichdifferentiating technology is built. In the category ofinfrastructure are such things operating systems, web servers,databases, Java application servers and other middle-ware,graphical user interface desktops, and the general tools used onGUI desktops such as web browsers, email clients, spreadsheets,word processing, and presentation applications. Any software thatprovides differentiating value to a non-software company is builton top of one or more of those infrastructure components.
An important indicator of whether software is differentiatingis whether or not your competitor can get the same software.Neither Microsoft software nor Linux and Open Source can help youdifferentiate your business for long, because they are availableto everyone. They differentiate against each other, they justdon't differentiate yourbusiness. One or the other can save you money or make you moreefficient, but in general they don't make your business moreattractive to your customer.
Another important indicator of whether software isdifferentiating or not is whether the customer can see thesoftware's effects. Your customer doesn't care what OS you run,unless your systems are crashed all of the time. She doesn't carewhether you run Microsoft Office or OpenOffice. You might havegood reasons to care, but the customer can't see them.
Thus, to make your business more desirable to customers, youshould spend more on differentiating software that makes yourbusiness more desirable, and less on software that doesn'tdifferentiate your business. Open Source is the key to spendingless on non-differentiators, by distributing cost and risk thatwas formerly your company's alone across multiple collaboratingcompanies.
Of course, you will need to take an honest look at whatsoftware in your business is differentiating and what isn't.And this turns out to be difficult. A lot of companies havenot invented heresyndrome. That's when managers and technical people aren'twilling to consider the work of outsiders, because they don'tbelieve that it could be as good as their own. "NIH" is anexpensive disease: it will cause your employees to duplicateeffort that is available elsewhere, instead of spending theirtime on the differentiating software that is most important toyour business.
Participation in Open Source makes our software cost-centersmore effective, because we can share cost and risk that we wouldotherwise be sustaining alone. What do we do with the money thatwe save? It becomes additional profit, or is spent in other areaswhere we need it more.
Economic Paradigms of Software Development
Since ourbusinesses need software, we'll need to develop it somehow. Themain economic paradigms for software development are: Retail.
In-House and Contract.
Efforts At Collaboration Without Open Source Licensing.
Open Source.
Each is different from the other in: How they distribute the cost of development.
How they distribute the risk of failure.
Their efficiency in funding software development rather than overheads of the process.
The degree to which others can be excluded from using the software.
These factors determine which paradigm is suitable for usein development of a particular piece of software. It's importantto remember that the ultimate source of funds for software is thecustomer, not thevendor. The customer can direct its funds to operations usingany of the economicparadigms to acquire the software it needs.The Retail Paradigm
Retail is the paradigm most familiarto the average person, yet it is responsible for less than 30% ofall software development[2]. In thisparadigm, the cost of software development is usually borne by asingle manufacturer. The manufacturer aims to recover thosecosts, plus profit, from sale of the finished product. Thus, thedevelopment expense is extremely front-loaded, with the entiredevelopment of a product necessary before the manufacturer canbegin to recover expense. The risk of failure to produce aprofitable product is borne entirely by the manufacturer.
Eventually, the cost of development is distributed tocustomers, if the product is successful in the market. Since theretail development paradigm can not directly distribute cost andrisk until the product matures, it is often necessary formanufacturers to turn to investment markets as an externalmechanism to distribute cost and risk. The manufacturer's needfor outside capital is of long duration, since it could takeyears to develop the software and its market, and additional timebefore the cost of development can be amortized and it becomespossible to take a profit. Stock markets increase the liquidityof the investment by allowing investors to monetize theperception of the company's future potential, reflected in itsstock price, rather than the company's actual earnings.Successful companies may re-invest profits in the development ofsubsequent software products rather than return to investmentmarkets.
The overhead of the traditional brick-and-mortar retail salesparadigm is extremely high, with the result that less than 10% ofthe money paid for the software by the end-user actually goesinto product marketing, software development, anddocumentation[7]. Micrsoft spent only 16.8% of its 2004revenues on research and product development. The rest ofMicrosoft's income went into items that don't directly benefitthe customer, such as the very expensive process of findingcustomers for Microsoft's products: overhead such as advertising,the design and manufacture of an attractive package that isdiscarded after the sale, payment to the retailer for shelf spaceupon which the product is displayed, sales staff, and profit. The16.8% figure does not include the mark-ups of the retailer andwholesaler, which would bring the portion of the product pricethat represents software development well below 10%.
There is inefficiency on the purchasing side too, due to amismatch between customer requirements and the softwarepurchased. The customer often purchases software that turns outupon closer evaluation not to be usable for the application inquestion, or is not deployed. Often the customer can not recoverthe cost of this "shelfware". There are also losses becausesoftware companies fail or discontinue and de-support productsthat the purchaser has not yet amortized. Since generally evendiscontinued products do not have source available, they are leftin an unsupportable state and the customer has little choice butto write off their investment.
Combining these risk factors, we can arrive at a conservativeestimate that 50%[8] of purchased retail software is not used,or not fully and effectively deployed - the purchase is afailure.
If we multiply the less-than-10% efficiency of the retailparadigm at directing dollars toward software development by the50% failure rate, we find that the efficiency of funding softwaredevelopment via retail software purchases is lower than 5%.
The most important implication of this extremely lowefficiency is that the retail paradigm can only be used economically to createproducts for a mass market. A mass market will mask theinefficiency of the paradigm, because each customer can pay arelatively small cost compared to the cost of the softwaredevelopment. As an aggregate, they would still pay more thantwenty times the cost of software development.
There are many important software products that simply can'tbe created using the retail paradigm, because they would notprovide a large enough market to amortize both the cost ofdevelopment and the large overheads of the paradigm. In addition,many new products that could eventually build a large market willnot be considered by a manufacturer, because companies andinvestors can not be convinced that such a market would develop,or the risk of failure is too high. This tends to damp innovation withinsoftware manufacturers that make use of the retail softwaredevelopment paradigm.
One telling example of the failure of the retail paradigm toinnovate is the fact that the most important innovation in thelast decade of global computer business, the web server andbrowser, had to be developed as an Open Source product at afederally-funded university research laboratory. None of thecompanies that could have completed the work were convinced thatit would make money. Indeed, the only company that did investsignificant funds to develop the web (Autodesk, by investing inTed Nelson's Xanadu Project), chose not to complete the projectbecause the revenue model that Xanadu foresaw for the web(payment to content producers for each word, with complicatedtracking of derivative works and references) was too difficult todevelop. The eventual leader in the development of a successfulweb, Tim Berners-Lee, did not see a need to develop any canonicalrevenue model, but left it to his users to figure out a means ofmaking money from the web.
And as we've discussed, since a retail business must approachas many customers as possible in order to generate the highestpossible profit, retail software is generally made available toeveryone. Thus, it is difficult or impossible for retail softwareto differentiate the customer's business.
The In-House and Contract Development Paradigm
In-housedevelopment is done by the customer's own programmers, whilecontract development is done by an outside company, generally asa work-for-hire for the customer's exclusive use. In both cases,the programmers are generally paid for the act of writingsoftware, rather than for the software as a product as would bethe case in the retail paradigm.
Another form of contract development is extensivecustomization of an otherwise-available product by the vendor.For example, a medium-to-large company may purchase a standardweb server environment and then pay its vendor for thecustomization of that environment to the customer's particularbusiness needs.
The customer has excellent control of in-house and contractdevelopment, because the programmers won't get paid unless theydo what the customer says. The customer can generally dictatewhether the software will be exclusively for that customer orwill be made accessible to others. Because the customer cancontrol distribution, this isan excellent paradigm for development of differentiatingsoftware. Indeed, it may be the only paradigm that reallyworks for development of software that would differentiate anend-user's non-software business.
In general, a contractor will try to use some of the work he doesfor one customer to leverage his business with other customers byre-selling work that's already been paid for. How successful heis at this depends on the contract terms and the honesty of thecontractor. If your contractor is confident that he can re-sellwork he does for you, he might charge you less and you mightbenefit from some distribution of cost and risk to the contractorand his next customer. However, this is not generally anappropriate scenario for differentiating software: if yourcontractor is selling your business differentiators, yourbusiness could soon be in trouble.
In exchange for the total control available through contractor in-house development, the customer generally sustainsall of the cost and riskof the development. Because of that cost and risk, contract andin-house development may not be the most cost-effective means ofdeveloping non-differentiating software. If a customer is paying100% of the cost to develop new software that duplicates thefunction of existing software that would be available to thatcustomer for less, that's called re-inventing the wheel and it's awaste of money. If the customer can stand having the softwaredistributed to others, and does not need absolute control overthe development, the Open Source or retail paradigms may be morecost-effective for developing that particular piece ofsoftware.
In-house and contract development are reasonably efficient atdirecting most of each dollar spent toward software development.Their efficiency in this regard is 50% to 80%, in contrast to the10% of a brick-and-mortar retail paradigm. The major sources ofinefficiency are the costs of finding new customers for acontractor's business, the cost of retaining expertise that maynot be fully utilized at all times, and the contractor'smark-up.
Many in-house and contract projects fail to produce workingsoftware that is deployed in the customer's business and meetsthe goals set for it. We can attribute to this paradigm a successrate of 50%[9],similar to the overall success rate we assigned to the retailparadigm.
Efforts At Collaboration Without Open SourceLicensing
Consortia used to be the standard means ofcollaborating between companies upon software development. Closedconsortium software development has a record of titanic failures.More recently, Billion-dollar closed consortia have a record ofbeing replaced by more successful Open Source projects. ConsiderTaligent andMonterey, two consortiaintended to create a replacement for Unix. Linux replaced them.Consider the Common DesktopEnvironment project, which has been replaced by the OpenSource GNOME desktop atmost of the companies that supported CDE.
A few years ago, the huge agricultural corporationCargill founded aconsortium with the stated intent of providing its partners withthe benefits of Open Source while also providing secrecy andsharing the benefits of the software only with consortiummembers. This is called a gatedcommunity. Two years later, Cargill walked away from theproject it founded. A closed consortium is simply the wrongstructure for the development of non-differentiating software. Itmakes sense to throw the doors wide open when you don't havedifferentiation to protect. and admit members that can make auseful contribution even when they can't pitch in funding. Aconsortium costs more because there are fewer members to sharecost and risk than with an Open Source project, yet there's muchmore structure and overhead than there would be for an equivalentOpen Source project. Closed consortia generally are directedthrough pay-for-say,while technical merit would be the case for Open Source. Withpay-for-say, a member can work to the detriment of the overallproject when that is to the member's advantage. Consortiumproduct planning often devolves into irresolvable arguments amongthe companies, because each has a different marketing idea andmarketing arguments between companies are subjective anddifficult to resolve.
Given the poor history of consortium development and, incontrast, the high rate of success for large Open Source projectscarried out by the same groups of companies, it seems that thefairness imposed by Open Source licensing is an essentialcomponent of effective collaboration between a large number ofparties with different interests.
The Open Source Paradigm
In the Open Source paradigm,multiple entities (individuals, companies, academic institutions,others) come together to develop a software product. Generallythe initial development is done by a single entity as in thein-house and contract development paradigm, and the software isreleased to the public as soon as it is useful to others,generally before it would be considered a finished product andthus much earlier than a retail product would be released. Oncethe software is useful, other entities make use of it. Only whenthe software becomes useful to others does the Open Sourceparadigm work fully, because only then will other parties have anincentive to use the software. Once they are using the software,these other parties will have an incentive to extend the softwareto implement additional features that are of interest to them.This extension is performed by the customer's own employees orcontractors under the customer's control.
The incremental cost of adding a feature is much smaller thanthe cost of the entire development. Parties that createmodifications have an incentive to write them in such a way thatthey will be accepted by the other developers on the project andwill be merged into the main body of source code that is sharedby all developers. If this merge does not happen, the continuingcost of maintaining the added feature will be higher, since itsdevelopers must track changes to the main source code andmaintain compatibility with that changing base.
Thus, Open Source tends to foster a community of developerswho make contributions to a useful product. The cost and risk ofdeveloping the product is distributed among these developers, andany combination of them can carry on the project if others leave.Distribution of cost and risk begins as soon as the project ismature enough to build a community outside of its initialdeveloper.
Open Source is developed directly by its end-users. Forexample, Apache web server features are added by the companiesthat need those features to operate their own web sites, orsometimes by contractors working for those companies.
The customers for a particular Open Source product generallyidentify themselves: they search for the product in a directoryof Open Source software, and then they download and test thesoftware. If tests are successful, they deploy it. Thus they gaina continuing interest in the product. At that point if theydesire additional features to the product, they have an incentiveto become co-developers of the software they are using.
The companies that join Open Source collaborations are seekingto use the software in a non-differentiating, cost-center role.It's not important to thesecompanies that Open Source does not in itself produce aprofit. Their profit-centers are things other thansoftware, and software is for them an enabling technology. Inorder to continue to operate their profit-centers, they must makesome investment in their cost centers. In the case ofdifferentiating software, they have little choice but to make useof the in-house or contract development paradigm, because theyneed to prevent their differentiators from falling into the handsof their competitors. For their non-differentiators, they havethe choice of the retail or Open Source paradigms. But which ismore efficient?
Because the customers are self-identifying, Open Source doesnot have the inefficiency of the retail paradigm, which must makeuse of advertising or other expensive mechanisms to seekcustomers [10]. Itis at least as efficient in directing dollars to softwaredevelopment rather than overhead as the in-house or contractdevelopment paradigm.
Because of its greater efficiency in allocating resources todevelopment rather than overhead, the Open Source paradigm can beused to develop products that would not support a mass market,and thus could not economically be developed within the retailparadigm.
Engineer Craig Small, a builder of network infrastructure,sums up the advantages for his customers:
Using Open Source cut way down on startup software costs. Thiswas important because it was the way to get in the door withthat particular customer. I was going to build the networkmanagement system from scratch, until I found a project thatwas close enough to what I needed. I could spend a fraction ofthe hours on the problem compared to what I would have neededto implement from zero.
Expanding and customizing Open Source is by far easier todo, because the developers expect from the start that peoplewill extend their work in ways that they haven't thought of,and thus they write in a style that is easier to extend.Proprietary software creators write as if nobody outside oftheir company will ever read their code. We took an Open Sourceproject for entirely different hardware from ours, and easilygot it to monitor our equipment.
I have returned my extensions back to the Open Sourceproject. Thus, I have confidence that if I leave the company,the extensions will still be looked after, at least by othermembers of the project.
There is now a community of people with the same sort oftechnical needs, both developers and non-programmer users, thathas sprung up around the software project that we allcollaborated upon. We discuss how to better satisfy our needs,and pool ideas that we would never have had on our own.
Proprietary software has costs that businesses have onlystarted to consider. Organizations like the Business SoftwareAlliance have raided businesses with federal marshals,demanding sufficient documentation that the company purchased alicense for every computer on site. Much time and effort isspent making sure that companies comply with increasinglyonerous licensing rules. Why can't I take that Windows XP offof my laptop and put it on the desktop legally? Open Sourceavoids that unproductive nonsense.
Not all Open Source projects succeed. Most immature OpenSource projects die on the vine or remain solo projects that uselittle in resources. But the expense of such projects isinsignificant, because they die without first attractingsignificant customers or a developer community. More mature OpenSource projects may die when something better comes along, butoften it is possible to use the actual source code, data, andskills from one project in another, and thus the investment indevelopment of the project is not lost.
The cost-of-participation in mature OpenSource projects is very different from the costs of retail orin-house and contract development. The major expense is thetime-cost of employee participation. This figure is a combinationof the personnel cost of software evaluation, the personnel orcontractor resources spent to adapt existing Open Source tocustomer needs and to support the Open Source for internal users,and the possibility that time will be invested into software thatis eventually replaced due to a failure to track customerneeds[19]. The maximum cost for OpenSource would come when there is no community other than thecustomer: this would be similar to the cost of contract orin-house development, in which one customer supports the entireexpense. The actual cost will be lower depending on the number ofactive participants and the work required. The lost investment isgenerally personnel time. Taking this into account, the OpenSource paradigm yields an economic efficiency at least as greatas the in-house and contract development paradigm, and muchgreater than the retail paradigm.Summary of Software Production Business Methods
The Open Source paradigm has several significant economicadvantages over the retail or in-house and contract softwareproduction paradigms: it combines efficiency in allocatingresources to software development with distribution of cost andrisk better than either of the other dominant paradigms ofsoftware development. It is amenable to the development ofproducts that are untenable under the retail paradigm becausethere is no mass market. Open Source can distribute the cost andrisk of projects, while the in-house and contract developmentparadigm would focus all cost and risk on one party. Open Sourcedistributes cost and risk directly, rather than requiring the useof investment markets. Distribution of cost and risk starts muchearlier than it would in the case of the retail paradigm. OpenSource gives the customer complete control over customization ofthe product. However, it does not give the customer control overwho has access to the product. Thus, Open Source is generallynot a good mechanism fordeveloping differentiating software.
Businesses that require non-differentiating software (really,all businesses) would be well advised to shift some developmentto Open Source and reap greater economic efficiency.Participation in Open Source development communities should be animportant part of any businesses overall strategy to shiftdevelopment dollars from non-differentiating to differentiatingsoftware.
Paradigm Efficiency Failure Rate Distributes Cost Distributes Risk Protects Customer Differentiation Protects Vendor Differentiation Required Market Size
Retail less than 10% 50% Late, sometime after sales start. No. No. Yes. Mass market 100,000 and up, specialized markets less.
In-House and Contract 60% to 80% 50% No. No. Yes. Maybe. 1
Consortium and Non-Open-Source Collaboration 60% to 80% Perhaps 90%, unacceptably high. Yes. Yes. Maybe. Maybe. 5 and up.
Open Source 60% to 100% 50% Early, during development. Yes No. No. 5 and up.
Who Contributes to Open Source, and How Do They FundThat?
There are several main sorts of Open Sourcecontributor: Volunteers.
Linux distribution companies.
Companies with a single Open Source program as their main product.
Companies for whom Open Source software enables sales of hardware or solutions.
Service Businesses.
End-user businesses and their contractors.
Government.
Academics and scientific researchers.
Each of these sorts of entity works differently within theeconomics of Open Source software, drawing from a differentsource to fund their contributions. We'll explore each one.Volunteers
I (Bruce Perens) was an example of this sortof contributor from 1993 through 1998, when I worked extensivelyon Open Source development that had no connection to myemployment.
The 2002 FLOSS study[11] reportedthat the creation of Open Source was, at that time, primarily a hobby activity! Buttheir participation of individuals without an immediate financialmotivation in Open Source software development is serious enoughto transcend the term hobby. Perhaps volunteer is a better description,because of the obvious professionality of their work [12], and thefact that their motivation is not pecuniary in nature.
Eric Raymond proposed that the volunteer's motivation ismainly intangible, and that a particularly important motivator isparticipation in a community of respect in which developers arerecognized by their peers for the quality and innovation in theirwork. The FLOSS study surveyed Open Source developers regardingtheir motivation, found that many of them are motivated bytechnical curiosity and the desire to learn. I feel that theirmotivation is similar to that of an artist: just as a painterwants people to appreciate his paintings, a programmer wants tohave users who appreciate his software.
There is a continuing transition from volunteer toprofessional, as Open Source is used increasingly in companiesthat then become motivated to participate in its continueddevelopment. Former volunteers are gaining employment inorganizations that support their Open Source work on companytime. Open Source supporters within companies come "out of thecloset" to become internal experts as their employers express aninterest in Open Source.
Linux Distribution Companies
Red Hat and Novell are well-known fordistributing Linux-based systems. But, surprisingly, businessesdedicated to selling Open Source software as their main productdo not create themajority of Open Source software. They act mainly as integratorsof the work of others. They do a lot of maintenance work in orderto eliminate bugs for their paying customers, and they dooriginal Open Source software development where they feel this isnecessary to enable their product or a new market. The Linuxdistributions are for the most part medium-sized companies, andtheir employees represent a small but active component of theoverall population of Open Source contributors. Sometimes theyinflate their impact in marketing communications. For example,one Linux distribution promotes that it employs 300 programmers,but a much smaller proportion make regular contributions to OpenSource software. The majority seem to be doing "salesengineering" or working on internal solutions for customers.
Indeed, the economics of Open Source seem to work worst for Linux distributions. Whenyou Open Source your business differentiators, your competitorcan appropriate them and reduce your business differentiation.That is the quandary of the Linux distributions: their product ismostly Open Source, their customers want it to stay that way, andthey struggle to differentiate a product that the customer knowsis available elsewhere without charge.
Linux distributions originally tried to deal with thedifferentiation problem with the first generation of Open Sourcevendor business plans, which Eric Raymond explains inThe Cathedral and theBazaar. These models mostly coupled some other product toOpen Source software as the money-maker: service on the OpenSource software, or a proprietary software addition to the OpenSource component. The Open Source software would be enablingtechnology for a business with some other component driving itsrevenues, but the money-making component would be very closelycoupled with the Open Source software. But unfortunately,services alone were not enough to make the distributionsprofitable during Linux's early-adopter period.
Today we are experiencing the second generation of Open Sourcebusiness plans. Some Linux distributions are attempting toimitate proprietary software. Behind their costly box of softwareor per-seat license is a product that the customer could acquirewithout charge through other channels. Several strategies arecombined to make this work: the development of a brand that isperceived to hold more trust or value than the naked software.The vendor invests resources into certification by proprietaryapplication vendors, who each want to support only a fewdistributions[14]. Customers who need support for aproprietary product on Linux thus have an incentive to pay forthat vendor's version of Linux. Some support services aresequestered, such as security problem reports or bug patches, sothat they will only be available to people who have purchased thecostly box and per-seat licenses. If the customer loads the freesoftware on more systems than he's paid for and the vendor findsout, the customer will be penalized by the revocation of hisservice contract and the withdrawal of security informationcritical to the continued operation of the software. Perhaps thebest name for this business model is proprietary Open Source, in whichservices are offered but the business is operated in theproprietary box-software model. This business model isessentially antagonistic to the volunteers who have created muchof the Open Source software. They weren't out to develop anotherMicrosoft, and they resent the sequestering of serviceinformation on theirsoftware. It is in conflict with the spirit, but not the letter,of Open Source licensing such as the GPL[15]. In general,volunteers help the companies they approve of. As the internalexperts on Open Source for their employers, they recommend thecompanies that they approve of. And thus there will besignificant challenges to the proprietary Open Source model.
It's important to emphasize that not all Linux distributionsengage in proprietary OpenSource, and that proprietary Open Source is not the dominant business model forOpen Source software development. The vast majority ofcontributors to Open Source belong to the other categoriesexamined here.
The money used to purchase Linux distribution "seats" andtheir associated services comes from enterprise IT departmentcost-centers.
Companies With a Single Open Source Program As Their MainProduct
This sort of company can be divided into severalcategories: Mixed Open Source and proprietary licensing model.
A core Open Source program with proprietary software accessories.
Pure Open Source plus services model.
We'll explore each category.Mixed Open Source and Proprietary LicensingModel.
Examples of this sort of company are MySQL AB andSleepycat Software, which produce databases, and Trolltech, whichproduces the Qtgraphical user interface toolkit. This sort of company vends thesame software under two different licenses: an Open Sourcelicense and a commercial license.
The Open Source license chosen, often the GPL, includes a"poison pill" meant to make production of proprietary derivativeworks commercially untenable. Since the GPL requires that allderivative works must be distributed in source-code form underthe GPL or a GPL-compatible license, this would remove thebusiness differentiation from any software to which it isapplied.
To escape the poison pill and preserve businessdifferentiation, the producer of a proprietary derivative workmust purchase a commercial license for the same product. Thisprovides the producer of the Open Source software a directrevenue capture for unit sales of software to creators ofproprietary derivative works.
This model works only for software that will be combined intoderivative works, such as a software library. It generally isn'tusable for applications.
The future viability of this model is in question, because aprogrammer can make a "server" of a software library and exportall of its functionality to another program without creatingsomething that would be considered a derivative work undercopyright law or the definitions in Open Source licenses. In Unixparlance, servers are referred to as "daemons", and thus thepractice of embedding software in a daemon in order to avoidcreating a derivative work is called daemonization. It is possible that afuture Open Source license could restrict this practice.
Today, it is possible to make use of the MySQL database serverin a proprietary application without a commercial license, byusing the MySQL database engine as a server (its usual mode) andmaking use of a special variant of the MySQL client library thatis under appropriate licensing terms for proprietaryapplications. Of course, MySQL AB doesn't support that clientlibrary.
This sort of company generally supplements its commerciallicensing revenue with additional revenue from training andsoftware development services.
The main customer of this sort of company is the enterpriseuser, in the case of MySQL. Trolltech's main customers areembedded device developers and software application developers.The funds used to purchase these products come from cost-centerswithin IT and software development departments.
A Core Open Source Program With Proprietary SoftwareAccessories
Eric Raymond calls this model Widget Frosting and discusses it indetail. Sendmail Inc. isan example of this sort of participant. Sendmail Inc. has createda constellation of proprietary products around the Open Sourcesendmail email server. This funds ongoing maintenance of the coreOpen Source product. Some of the Linux distribution companiesalso intend to operate using this model, and some of IBM'sbusiness is under this model: for example their sales of theproprietary DB2 databaseon Linux. This sort of company essentially operates as if it werea proprietary software business. The funds used to purchase itsproducts come from IT department cost-centers.Specialization In One OpenSource Program Plus Services Model
This model wasproposed to be an important one in Eric Raymond's paper, but hasnot performed as well as was expected so far. Many Open Sourcedevelopers supplement their income by providing services upon thesoftware that they develop, and there are a number of newcompanies pursuing this model - some with sizable venturefunding. Some of these new companies seem to be operating acertification model,servicing a particular version of the software that they certify,perhaps in the manner of the proprietary open source businessmodel at some of the Linux distribution companies.
Some small and medium-sized companies have been able toproduce sustainable revenue while developing Open Source softwareas their major business focus and providing services on that OpenSource as their only profit-center. But many have failed, somespectacularly like VA Linux Systems and Linuxcare. Companies thatwould be support customers seem to prefer to do their Open Sourcesupport inside, or through a vendor with whom they already havean existing relationship or whom can service more than oneprogram. There may also have been an early-adopter problem.Early-adopters in general do not want the hand-holding of aservice company. Time will tell if this model can performeffectively.
The funds for services provided by this sort of company comefrom IT department cost-centers.
Hardware Vendors
Examples of this sort of company are IBMand HP. Hardware is a great product to sell along with OpenSource software. It costs a penny to copy software, but you can'tcopy a loaf of bread without a pound of flour. Until we have theStar Trek"replicator"[13],hardware is a difficult-to-copy product. Allowing the customer toknow something of hardware internals doesn't necessarily removeall of its business differentiation, as might be the case forsoftware. The hardware manufacturers that participate in OpenSource development do so to enable sales of their hardwareproducts. Hardware is useless without software, and specificallycomputers are useless without the operating system thatinterfaces the computer hardware to software applications. OpenSource developers seem to be better at systems programming thanany other form of programming, so far, and the Linux operating system kernel is nowas good as, or better than, many proprietary operating systemsfor similar hardware. Hardware manufacturers formerly spentbillions on proprietary operating systems that, for them, werealways enabling technology rather than a profit-center. Themargins were in the hardware itself. Many of these manufacturershave eagerly embraced Linux because it allows them to distributethe cost and risk of the operating system among multiplecompanies, has a cost-efficiency greater than that of similarproprietary operating systems, and is in general desirable to thecustomer.
Hardware companies are good at producing Open Source becausethere isn't nearly so much conflict between Open Source anddifferentiation for them as there might be in a software company.Making software products Open Source enables sales, doesn'treduce their hardware-based business differentiators, and thusdoes not threaten their profit center.
Generally this sort of company supplements its hardware incomewith services, and sometimes training.
The funds for hardware and services provided by this sort ofcompany come from IT department cost-center hardware budgets.
End-User Businesses and Their Contractors
eBay is anexample of this sort of contributor. Many companies make use ofOpen Source software in their own operations. Web applicationsare particularly important, but there are many others. And thesecompanies make up a significant portion of the Open Sourcecontributors. In general the contributions come from internalsoftware support and development staff, or contractors supportingthe company, who modify the Open Source software to fit thecompany's needs.
What is most interesting about this sort of contributor isthat they are the main customers of essentially all of the othersorts of companies that contribute to Open Source softwaredevelopment. Their cost-center dollars fund the work of the othersorts of companies analyzed here. And they appear to be puttingsome of those dollars directly into Open Source software, eitherthrough use of their own staff or via contractors workingdirectly for them, instead of going through the traditionalintermediates.
But why should this sort of company should do work outside ofits core competency? Core competency is a property of individualsmore than of companies. Thus, you should consider not whether anOpen Source software project is the focus of your business, butwhether you can operate your business most economically by makingthe Open Source participation a focus of some staff members. Themain advantage for your company is the reduction of cost andrisk, and an improvement of the degree of control that you haveover your software. Consider today the degree to which softwarecontrols your business. Do you control the software?
Service Businesses
A number of service businesses createsolutions by integrating multiple Open Source programs with"glue" software specialized for the particular customer. Otherbusinesses provide service for a collection of Open Sourceprograms. This sort of business participates in the developmentand maintenance of many Open Source programs, but perhaps notintensively in any one. In general, the motivation of theend-user businesses that employs this sort of contractordominates that of the contractor itself, and thus thesebusinesses should be considered under End-User Businesses And TheirContractors, above. Some businesses vend a web serviceunder the application service provider (ASP) model, buildingmostly upon Open Source software. There is a loop-hole in manyOpen Source licenses (particularly the GPL as it exists today)that protects differentiation of ASP businesses. The requirementto provide source code doesn't trigger until the software isdistributed, and an ASP need only perform the software for thecustomer, rather than distribute it. Since this is widelyregarded as a flaw in the GPL, it may not persist in the nextversion of that license.Government
Government's use of Open Source is similar tothe way that business approaches Open Source for its costcenters. However, government is expected to function for thebenefit of the citizens and is not generally thought of as havingprofit-centers of its own. Rather, it provides services thatenable economic and social activities.
Government contracting should not provide a commercialadvantage to a particular vendor outside of the direct revenuefrom the products or services purchased. Government shouldespecially not lock itself to a particular vendor after thecontract term because of switching costs. It's poor policy forgovernment to lock its vendors or citizens into use of aparticular vendor's product for communicating with thegovernment, as this would provide an inappropriate advantage tothe vendor. All vendors can make use of Open Source componentswith appropriate licensing, and thus can facilitate e-governmentto make use of Open Source for government-to-citizen,government-to-business and government-to-governmentinterfaces.
All vendors can make use of Open Source components withappropriate licensing. Such use can assure that the softwareinterface to government facilities is an open interface that can be utilizedby all vendors. Thus, it can facilitate e-government to make useof Open Source for government-to-citizen, government-to-businessand government-to-government interfaces.
Government carries out some activities solely for the publicbenefit, and can carry out Open Source development in thiscapacity. This is generally done through research funding.
Academics and Scientific Researchers
Academic researchprojects have historically been large contributors to OpenSource, and mostly graduate rather than undergraduate work. Ingeneral, an undergraduate class does not provide sufficient timefor a student to come up to speed on an Open Source project andmake a contribution. In contrast, graduate research projects areoften years in duration. A large body of Open Source softwarecame out of the BSD (Berkeley System Distribution) project fundedby the U.S. Department of Defense. Additional academic researchprojects produce more software daily.
There are vigorous Open Source communities involved inscientific research. In science, the maxim is publish or perish, and Open Sourcefits that well. To be considered valid, scientific research mustbe capable of being duplicated. If an experiment doesn't turn outthe same way when performed by another scientist, that may meanthat the research is erroneous. These days software makes up alarge part of many experiments, and a human-language descriptionof the experiment may not convey every detail of how it has beenperformed. If the researchers can share code, outsiders canexamine their software for errors and duplicate their experimentsmore easily.
The community of scientists researching a particular field ofstudy is small. Retail software would not be effective indeveloping such specialized software. Open Source is the best wayfor scientists to share the cost of developing software tosupport their research.
Proprietary software supporters have tried to turn back thetide of academic contributions to Open Source by forging newpartnerships between college research projects and proprietarysoftware companies. This trend is especially disturbing whenpublicly-funded research work results in patents that aretransferred to the proprietary software company partners, sinceit is likely that those patents will be prosecuted against thevery taxpayers who funded their creation. In general,publicly-funded work should be maximally utilizable by the publicthat funded it. DARPA (the U.S. Department of Defense researchgrant organization) and the University of California recognizedthis when they applied the BSDLicense to the pioneering extensions of Unix created atthe university. That licensing allowed any Open Source orproprietary use of the software.
Some research work is performed by unsalaried students. Whenthey are salaried, thefunds for their software development generally come from grants.Governments are the largest provider of such grants, a secondarysource is philanthropic, and some funds come from industrypartners.
Summary of Contributors To Open Source Projects
The largest contributor to Open Source development today maystill be the volunteer. There is a conflict between businessdifferentiation and Open Source that makes its economics workworst for the sort of business that would generally fund the samesort of development in the case of proprietary software.Businesses without such a conflict are more effective at fundingOpen Source development. Thus, hardware manufacturers have takena large role, and end-user businesses are taking an increasingrole.
Type Example Conflict between Open Source and Business Differentiation? Differentiation Protection Mechanism Source of Funding. Commercially Effective
Volunteer Bruce Perens from 1993 to 1998. No n/a, doesn't need one. Donates own time. n/a, motivation is non-commercial.
Academic Contributors University research projects. No Government, philanthropic grants. Paid to do research, not the result. Yes.
Linux Distribution Red Hat Yes Branding, certification, sequesters service data. Per-box or seat sales to IT cost-centers. Too early to tell.
Companies with Single Open Source Program as Product. MySQL, Trolltech, Sleepycat Software No Dual-licensing, "poison pill" in the Open Source license protects differentiation in the case of commercial users, provides incentive for commercial license purchases. Per-box or seat sales to IT cost-centers. Yes.
Core Open Source Product with Proprietary Additions Sendmail Inc. No Differentiating products are proprietary. Proprietary software sales to IT cost-centers. Dubious.
Specialization in Open Source Program Plus Services ? No Service, not the program, is what is differentiated. Services sales to IT cost-centers. Dubious.
Service Businesses ? No Service, not the program, is what is differentiated. Service sales to IT cost-centers. Yes.
Hardware Manufacturer IBM, HP No Hardware can't be copied for pennies as software can be. IT cost-center hardware budgets. Yes.
End-User Business eBay No Software lives in a cost-center, enables sales of profit-center products. Their own IT cost-centers. Yes, from savings alone.
How Open Source Does Product Marketing
A common objectionto Open Source is the perception that Open Source developmentwill not be well focused or targeted. People are used todevelopment that is directed by one company in an extremelyfocused manner, driven by a product marketing process. Somemature Open Source projects do perform their product marketingthe way a company would. But while a company generally woulddevelop an overall strategy that drives all of its softwaredevelopment, there is no global planning authority for OpenSource, and no overarching strategy followed by all Open Sourcedevelopers. However, it's an error to ask for such a thing: youcan't compare Open Source to a company, it's an entire industry.A central planning authority for an entire industry wouldindicate something other than an open market. The productmarketing for the global Open Source community operates in theway that a capitalist nation operates its economy, rather thanthe way a company plans its products.
The paradigm by which Open Source does product marketing canbe described as amassively-parallel drunkard's walk filtered by a Darwinisticprocess. First, very many people all over the worlddevelop whatever they want, going in any direction they wishwithout any central coordination. Out of this process come manypotential products that would not interest more than a few otherpeople, some products that are interesting to at least fiftypeople, and a few products that are interesting to millions ofpeople.
Fifty people who want the same thing, but are geographicallydistributed all around the world, can form a viable softwaredevelopment team via the Internet. The spare time of fifty peoplewho are otherwise employed turns out to be sufficient resource toenable the development of large and complex software products,and of course the size of the development team increases as theproduct matures and becomes of interest to more people. Thus, byleveraging upon the excellent collaboration that is possible whenusing Open Source licensing, it is possible to initiate andsuccessfully carry out projects that would otherwise be beyondthe capability of any of the participating entities.
But how do 50 people who haven't met work together to form aviable software product? Part of the reason this works so well isthat software is extremely modular by nature, and thus manypeople can work on different segments of the software, almostautonomously, if they can come to agreement about how the piecesfit together. A good example of this is the Debian GNU/Linux Distribution. Thissystem includes more than 16,000 software packages maintained byover 1000 volunteer developers in many nations around the world.When these packages are combined, the result is a reliable andwell-integrated system. That system has supervised experimentswhile in orbit on the Space Shuttle, and has a user communitysecond in size only to Red Hat (yes, it's bigger thanNovell).
But how can we develop products when everyone has the freedomto go their own way and there isn't a real boss? This seems oddto business people, until they realize that this is exactly howcapitalism works in democratic countries. In the broader economyof a capitalistic nation, many companies set out to developproducts without any central guidance from the government. Theyall compete with each other, and some products succeed and builda market while other products fail. Loose collaborations arisebetween companies for the purpose of building markets for newproducts. The role of the government, the only entity thatconceivably could guide the economy, is in general limited to theinjection or removal of capital from the economy, tax incentivesand funding programs, and the enforcement of laws designed tocreate fair markets.
Most sensible people have accepted that a "sure thing" is rarein gambling or stock-picking, and yet they expect marketingdepartments to make reliable forecasts in guiding new productdevelopment. Marketing departments have no crystal ball. If asufficient number of self-guided developers are available, adrunkard's walk strategy will outperform conventional productmarketing. The massively-parallel drunkard's walk tries manydifferent paths, and thus has a higher probability of accessing asuccessful path. The Darwinistic filtering is what recognizesthat a particular path is successful.
Most business people are adamant that they want to live in afree market economy, and that the government should not take astrong guiding role in determining what products will be producedand how they are made. They say this because they understand thatthe free market is more likely to produce good products and ahealthy economy than any central planning process. It should beno surprise to them, then, that the open-market-like paradigm ofOpen Source can sometimes do a better job than the centralcontrol of marketing departments and management at creatingdesirable products.
Is Open Source Self-Sustaining?
Many people have troubleunderstanding how Open Source could be self-sustaining if it doesnot operate according to the retail development paradigm. Whatpays for such software? It is funded directly or indirectly as acost-center item by the companies that need it. Those companiesneed a great deal of cost-center, non-differentiating software.They are willing to invest in its creation through the OpenSource paradigm because it allows them to spend less on theircost centers by distributing the cost and risk among manycollaborators, and makes more efficient use of their softwaredollar than the retail paradigm. This is essentially the samesource of funding that pays for proprietary software. It'simportant to remember that the software manufacturer isn't theultimate source of funds: the customer is.What is the Economic Impact of Open Source?
We definedthe major economic impact of Microsoft as:The fact that they have enabled a great many businesses - theircustomers - to do business more efficiently, and to havebusinesses that they could not operate at all without thesoftware that enables them.The same definition applies to Open Source.
It is a fact that Open Source enables a majority of webservers today, a majority of email deliveries, and many otherbusinesses, organizations, and personal pursuits. Thus, itseconomic impact must already be numbered in many tens of Billionsof dollars.
Any improvement in technology that permits business tofunction more efficiently means the economy runs moreefficiently. In this case, Open Source enables business to spendless on software and to have better quality and more control overits software. The money that is saved on software doesn'tdisappear, the people who save it spend it on things that aremore important to them.
What Does All Of This Mean To Software Producers?
Thisdiscussion has been mostly from the perspective of thesoftware-using business, who ultimately pays for softwaredevelopment, rather than the software-producing one. But whatdoes this mean to software producers?
Does your business really sell finished software? Somebusinesses sell the act of software creation rather than thesoftware itself. This is the case, in general, for consulting and"solutions" companies. Your customers will be willing to pay forthe creation of Open Source software.
In the case of a business that wishes to produce software forsale, rather than sell the service of programming or training,Open Source will be a difficult product to monetize.
It may be that Open Source eventually causes a reduction indemand the for proprietary software. This would not, however,reduce the demand for programmers, because the demand forsoftware in general would not decrease. The displaced proprietaryprogrammers would move to an organization that can produce OpenSource software in an economically successful manner.
It is possible that programmers who move to a lessentrepreneurial setting could earn less. However, surplus profitsin proprietary software companies have historically beendistributed to management in much larger portions than to staff.It is the rare programmer that has been able to profit from astock incentive windfall from a company whose products arepredominantly software offered for sale.
What Effect Does The Free-Rider Problem Have Upon OpenSource?
The Free-RiderProblem is familiar in economics. What do you do aboutpeople who take advantage of a product or service withoutproviding any return to the provider of that product or service?Do you have a mechanism to prevent free-riders?
All Open Source users start out as free-riders. They downloadand try the software, and perhaps deploy it, and do not generallyconsider contributing to that software's development until theyare already using it and desire an additional feature.
If they desire an additional feature, they may implement thatfeature themselves rather than pay one of the initial developers.At this point, are they still free riders? No. Businesses thatjoin an Open Source project as developers contribute somesoftware to the product, and all of those businesses derive aneconomic benefit from making use of the software in a cost-centerof their business. The interests of the various developers aregenerally similar because they have self-selected a particularsoftware product as one useful to them. The contributions of anyone developer are generally of use to other developers.
There are developers that are not motivated by the desire toprovide software for a business cost-center. These areindividuals whose motivations are primarily artistic, andscientific researchers.
Volunteers derive emotional fulfillment from having users fortheir software, just as artists derive fulfillment from havingothers appreciate their paintings. For volunteers, users providean intangible benefit which the volunteer desires. Thus, thoseusers should not beconsidered free-riders.
Companies that place importance in a particular Open Sourceproduct tend to hire developers who have already gained statureas a developer of that product. Thus, individuals who havestarted with no pecuniary interest in the Open Source projecttend to find employment with an organization that does have suchan interest. And thus individuals who participate in Open Sourcedevelopment often reap an economic gain from that participation.This is another reason that users should not be consideredfree-riders by these individuals.
Scientific researchers have their own paradigm of constantexchange of knowledge similar to that in the Open Sourcecommunity, because science advances most rapidly when discoveriesare made known to other scientists who can add their intuitionsto them. Scientists gain fulfillment from the publication oftheir work, because this increases their stature among otherscientists and in general determines the success of theircareers. Scientists routinely use Open Source as a means ofpublishing the software component of their work. In addition,scientists are motivated by the desire to be of benefit tosociety, and wish to see other people benefit from the use ofsoftware developed through scientific research. Thus, toscientific participants, users are of benefit and shouldnot be consideredfree-riders.
And finally, users are the people whom we recruit to becomemore active participants in an Open Source project, just asretailers try to recruit the general public to buy theirproducts. Invariably we are successful with some of them.
There is some question regarding whether the free-riderproblem is as significant in the case of software as it is forother sorts of products, and whether it applies to Open Source atall. A free-rider on a bus uses the scarce resource of a seat, sothat a potential paying rider could be denied a chance to ridethe bus. A free-rider who has bootlegged a copy of MicrosoftWindows may or may not diminish the market for paid copies ofWindows, but does not use any scarce resource that would excludeother Windows users. A free-rider using Open Source does notdiminish a market or use any scarce resource.
All of this leads me to believe that the free-rider problem isnot a significant detriment to Open Source development.
If Open Source Works, Why Don't We All Build Our OwnCars?
The Open Source paradigm works well for many productswhere the major value of the product is its design. It's most successfullybeen used to date to produce software, an encyclopedia, andintegrated circuit designs.
The integrated circuit designs are programmed into afield-programmable gate-array, a special device that can beprogrammed with a design and will then immediately behave as acircuit with that design. This is an example of a field in whichhardware is very much like software.
However, most things are not software. It only takes a cent'sworth of resources to make a copy of a piece of software, but ittakes a pound of flour to make a loaf of bread. Someone has tofarm the wheat and grind it into flour, and those efforts have tobe paid for.
Automobiles, of course, are much more complex than bread, andit takes a great many physical processes with expensive toolingto manufacture them. Consider that to make an electric motor, onemust mine and refine metal, then draw wire, roll sheet metal,cast and machine bearings, and then assemble all of these piecesinto very precise forms. It should be no wonder that it takes anentire economy to manufacture an automobile, while a singleindividual may produce an important software product.
When the day comes that we can makecomplex physical products by producing their designs anddirecting a machine to manufacture them from easily-availablematerials and electricity[], theeconomy will change radically. Today, we are limited to producingindividual parts with computer-controlled milling machines, aslow and dirty process that still requires manual intervention. Ahealthy Open Source community has evolved around such machines,and we are starting to see them share part designs. But thescience of computer-controlled manufacturing will have to improvetremendously before we can have "Open Source cars".
Summary
Open Source is self-sustaining, with an economicfoundation that operates in a capitalistic manner. It does notrequire any sort of voodoo economics to explain. It is anextremely beneficial component of a free-market economy, becauseof the very many people and businesses that it enables to maketheir own economic contribution. It is more efficient than othereconomic paradigms of software development for producing softwarethat does not differentiate its user's business.Non-differentiating software makes up the lion's share of allsoftware in a business, and businesses would be well advised topursue Open Source collaborations for producing such software.Topics for Further Development
Economists would be interested in a discussion of Open Source as a public good.
About the Speaker
Bruce Perens is one of the founders ofthe Open Source movement in software, and the creator of theOpen Source Definition,the manifesto of Open Source. He is founder or co-founder of theLinux Standard Base, thestandardization project of Linux, the UserLinux project, and No-Code International.
Perens currently sits on the board of directors ofOpen Source RiskManagement, an insurance company covering the risks ofOpen Source software and Software in the Public Interest, thenon-profit that supports the Debian Project. He is a significantstockholder in Progeny LinuxSystems, which was funded through his VC firm Linux Capital Group.
Perens is Senior Research Scientist for Open Source with theCyber Security Policy Research Institute of George WashingtonUniversity. He is series editor of the Bruce Perens' Open Source Serieswith Prentice Hall PTR publishers, which has published 13 bookswith all of their text under Open Source licenses.
Perens operates a strategy consulting firm, Perens LLC, which specializes inissues related to Linux and Open Source software.
Perens formerly served as Senior Global Strategist for Linuxand Open Source with the Hewlett Packard Company, and as invitedexpert on the World Wide Web Consortium's Patent Policy Board. Hewas Project Leader for the Debian GNU/Linux Distribution, andwrote the Debian SocialContract, a portion of which later became The Open Source Definition.
Acknowledgements
The generous support of NTT Docomo LabsUSA is making this and other articles possible. Thanks to TheCyber Security Policy Research Institute of George WashingtonUniversity, and Tony Stanco there, for granting me an affiliationwith their prestigious institution. Thanks to Prentice Hall PTRand executive editor Mark Taub for publishing Bruce Perens' Open Source Series,currently numbered at 13 books, in which this article willeventually find a home. Martin Fink, now Vice President for Linuxat HP, was the person to name proprietary open source, even ifhe's being forced to accept it now. Martin also provided myintroduction to management of large corporations as my manager atHP, and has taken lots of guff for and from yours truly. TheDebian developers never cease to amaze me with their erudition.They were the first reviewers of this document, and contributedtremendously to its quality. Participants were: Bill Allombert,Ben Armstrong, Jeff Breidenbach, Andrew M.A. Cater, Tim Cutts,Ryan Golbeck, Joshua Kwan, Alexander List, Andrew McMillan, RaulMiller, Nick Phillips, M.J. Ray, Craig Small, Andrew Stribbehill,David N. Welton, Florian M. Weps, Matt Whipp, Matthew Wilcox.Other reviewers were Kael Goodman, Mark Shuttleworth.Footnotes
For the purposes of this paper, Open Source and Free Software mean the same thing. There are philosophical differences between the two groups, but the great majority of software to which the definition of Open Source applies would also fit the Free Software Foundation's definition of Free Software.
It is important to note that when I created the document that later became the Open Source Definition, as a policy document for the Debian Project, the FSF had not created its own definition of Free Software. At that time, Richard Stallman commented in personal email that my document was a good definition of Free Software.
Stallman would not agree with my suggestion that a business might be better off not assigning a Free Software license to software if that license would reduce the differentiating value of the software to that business. Thus I am using the nomenclature Open Source in order to avoid diverting Stallman's agenda for Free Software.
A report on the size of the U.S. software market is at http://web.ita.doc.gov/ITI%5CitiHome.nsf/AutonomyView/87200518f179196c85256cc40077ede1 . In that report, "Packaged Software" represents 24.6% of the industry. All other industry sectors that represent computer programming, including all of Computer Programming Services, Computer Integrated Systems Design, Computer Processing and Data Preparation and Processing, Information Retrieval Services, Computer Facilities Management Services, and some sub-categories of Software Publishing represent the remainder.
However, that report does not account for the software produced solely for company-internal use by programmers employed by companies that have a non-software product. I conservatively estimate the population of internal programmers to be equal to that of contract ones, who are listed under Computer Programming Services (19% of market).
To some extent, Raymond deprecated Stallman when speaking for Open Source, when he might simply have promoted to the different audience of Open Source without any conflict with Stallman and his Free Software campaign. In my opinion, this unfortunate outcome is attributable more to a difference in personalities than philosophy.
IDC Software Consulting: The Linux Marketplace - Moving from Niche to Mainstream. Prepared for OSDL.http://www.osdl.org/docs/linux_market_overview.pdf
Bureau of labor statistics reports for 2002 show 2,153,000 people hold programming-related jobs in the United States: 499,000 are Computer Programmers, 675,000 are Computer Software Engineers, 979,000 are Computer Systems Analysts, Database Administrators, and Computer Scientists. This does not count 758,000 jobs held by Computer Support Specialists and Systems Administrators, who generally perform at least some script programming, and Computer Operators, who held 182,000 jobs.http://www.bls.gov/oco/ocos110.htm,http://www.bls.gov/oco/ocos267.htm,http://www.bls.gov/oco/ocos042.htm,http://stats.bls.gov/oco/ocos268.htm,http://stats.bls.gov/oco/ocos128.htm
Ironically, the Amazon "recommendation" feature is the topic of a patent-infringement suit brought by Cendant against Amazon.
Microsoft's 10-Q report to the SEC for September 30, 2004 shows that only 16.8% of their revenue goes to research and product development. "Research and development expenses include payroll, employee benefits, stock-based compensation and other head-count-related costs associated with product development. Research and development expenses also include third-party development and programming costs, localization costs incurred to translate software for international markets, and the amortization of purchased software code and services content". Of course, this report does not show the markups of wholesalers and retailers, which would bring the software-development-per-dollar figure below 10%. The report is at http://microsoft.shareholder.com/redesign/EdgarDetail.asp?CIK=789019&FID=1193125-04-189841&SID=04-00
A terrible thing to waste, article on "Shelfware", CFOEurope.com:http://www.cfoeurope.com/displayStory.cfm/1739037, CRM Software or CRM Shelfware?, CNET News.com,http://news.com.com/2100-1012-990880.html
Collaborating on Project Success, Standish Group, http://www.softwaremag.com/archive/2001feb/CollaborativeMgt.html, Immature Software Acquisition Processes Increase FAA System Acquisition Riskshttp://ntl.bts.gov/lib/000/200/234/ai97047.pdf
We do, however, see advertising by various entities connected to Open Source. This generally concerns hardware or services, rather than the software. In some cases the Open Source teams make use of low or no-cost advertising venues such as web banner advertising to draw new users to their products and thus expand their development communities. A recent ad in The New York Times for Mozilla Firefox is notable as it is motivated by the political goal of maintaining the open-ness of the web and reducing dominance by Microsoft over the browser. The advertising was funded by charitable contributions from parties that in general have no pecuniary interest in Firefox.
http://www.infonomics.nl/FLOSS/report/
Studies by Stanford and CMU researchers show that the Linux 2.6 kernel has 0.17 bugs per 1000 lines of code while non-Open-Source commercial software generally scores 20-30 bugs per 1000 lines. The studies are reported in Wired magazine athttp://www.wired.com/news/linux/0,1411,66022,00.html, I do not presently have a reference to the actual studies.
The replicator is a fictional device that manufactures many different physical objects on demand, presumably from designs stored on a computer. In the Star Trek: The Next Generation television series, a character walked up to the device and gave it a voice command: tea, earl gray, hot. A cup and the tea were manufactured instantly.
The Linux Standard Base was meant to make it possible for proprietary application vendors to support all standard-compliant Linux distributions. It has not been commercially effective at this so far.
Analysis of pro-bono counsel, Free Software Foundation, in private communication.
http://www.catb.org/~esr/writings/cathedral-bazaar/ Raymond followed The Cathedral and the Bazaar with two additional papers, Homesteading the Noosphere (1998) and The Magic Cauldron (1999), which continue his discussion of the economics of Open Source. They can be found at the same link. His last revision to The Magic Cauldron appeared in 2002.
The GNU project was announced in September 1983, seehttp://www.gnu.org/gnu/initial-announcement.html, although the project didn't actually start until January 1984, and it was not until sometime later that the Free Software Foundation was formed around it. Seehttp://www.gnu.org/gnu/gnu-history.html for an overview of the GNU project.
There was also the fact that the GNU project had developed and integrated a lot of software, but had not been able to produce its own operating system kernel. This left the door open for Linus Torvalds to do the last part of the project. Generally an operating system is referred to by the name of its kernel, dispite the fact that it contains many components other than the kernel. This caused an injustice to Stallman that persists today. Although Stallman did a great deal of the work that made Linux possible, Torvalds' team of kernel contributors was not closely allied with Stallman, and announcements of Linux were not attributed to FSF.
Linux is in truth only the kernel. The rest of what comes in a Linux distribution is what Stallman intended to be the GNU System, and Stallman should be credited with its concept, with directly developing the C compiler (surely as important as the kernel) and the Emacs editor, and with inspiring the development of much of the rest of the system.
There is a cost-of-participation for retail software as well. Part of that is discussed here as the shelfware problem. The after-purchase cost is not discussed, but includes such things as the cost of documenting problems to the vendor (often an all-day task for a programmer) and going through service escalation procedures with the vendor's service staff until those problems get attention.
Senior Research Scientist, Open Source
Cyber Security Policy Research Institute, George Washington University.
Last edited: Wed Feb 16 06:22:06 PST 2005
Abstract
Open Source developers have, perhaps withoutconscious intent, created a new and surprisingly successfuleconomic paradigm for the production of software. Examining thatparadigm can answer a number of important questions.
It's not immediately obvious how Open Source[1] workseconomically. Probably the worst consequence of this lack ofunderstanding is that many people don't understand how OpenSource could be economically sustainable, and some may even feelthat its potential negative effect upon the proprietary softwareindustry is an overall economic detriment. Fortunately, if youlook more deeply into the economic function of software ingeneral, it's easy to establish that Open Source is bothsustainable and of tremendous benefit to the overall economy.
Open Source can be explained entirely within the context ofconventional open-market economics. Indeed, it turns out that ithas much stronger ties to the phenomenon of capitalism than youmay have appreciated.
A Strong Economic Foundation
In the early days of Open Source, its proponents did not fullyunderstand its economics. Through our lack of understanding, wecreated the perception that Open Source's economic foundationwas intangible. This led many people to feel that Open Sourcewould not be sustainable over the long term and would beincapable of scaling to meet the market's need for newtechnology. It's important to correct that perception now. InThe Cathedral and theBazaar[16], Eric Raymond attempted to explain OpenSource as a gifteconomy, a phenomenon of computer programmers having theleisure to do creative work not connected to their employment,and an artistic motivation to have their work appreciated.Raymond explains excellently how programmers behave withintheir own private subculture. The motivations he exploreddominated during the genesis of Open Source and continue to beeffective within a critically important group of Open Sourcecontributors today.
Raymond did not attempt to explain why big companies like IBMare participating in Open Source, that had not yet started whenhe wrote. Open Source was just starting to attract seriousattention from business, and had not yet become a significanteconomic phenomenon. Thus, TheCathedral and the Bazaar is not informed by the insightinto Open Source's economics that is available today.
Unfortunately, many people have mistaken Raymond's earlyarguments as evidence of a weak economic foundation for OpenSource. In Raymond's model, work is rewarded with an intangiblereturn rather than a monetary one. Fortunately, it's easy toestablish today that there is a strong monetary return for manyOpen Source developers. But that return is still not as direct asin proprietary software development. Thus, I'll ask you to followa few more steps than you would in understanding the economics ofproprietary software.
How Are You Going To Be The Next Microsoft?
Prospectivesoftware entrepreneurs are often asked: how are you going to be the NextMicrosoft? And those who base a business upon Open Sourceare asked: how are you going to be the next Microsoft withFree software? But thisisn't the right question if our goal is to achieve animprovement over theMicrosoft model. It reflects the fact that most people have beenthinking about software from an extremely vendor-centric viewpoint.
Whether or not we will admit it, most of us are very impressedwith Microsoft's wealth and arrogance, and when we think ofproducing software, we automatically think of Microsoft and theway they do it. But itturns out that the Microsoft model accounts for only aminority of the softwarethat is made and used in business today. Around 30% of thesoftware that is written is sold as software[2]. Most software is not sold at all.It is developed directly for its customer, by the customer's ownemployees or by consultants who bill for the service of software creation ratherthan for the end product. It's important to look at why that isthe case, in order to understand the economics of OpenSource.
Indication of an Unfulfilled Need
In February 1998, Eric Raymond and I formed the Open Source Initiative. We werestanding on the shoulders of a giant: Richard Stallman'sFree Software campaignhad existed since 1983[17] and created much of what people callOpen Source today. Thecombination of the Linux operating system kernel and Stallman'sGNU System was becomingviable for business use. But the way that Stallman chose topresent Free Software depends upon the a priori acceptance of the virtue ofcertain freedoms. Stallman is a programmer, and chose aphilosophical presentation that appealed to programmers. Incontrast, business people are pragmatists and are more impressedby economic benefit. Because Stallman's presentation limited hisaudience, his campaign had not been able to achieve the economicserendipity that is visible today[18]. Raymond andI chose to approach business people in a more pragmatic fashion,with the expectation that they would come to appreciateStallman's philosophy once they'd seen its concretebenefits[3].
The first time the public heard of Open Source was in an announcementthat I posted on Slashdot and a few mailing lists. Itcontained an introduction and the Open Source Definition, both amanifesto of Open Source and a definition of acceptable OpenSource software licensing, which I'd created as a policy documentof the Debian Projectsix months earlier. Eric Raymond edited The Cathedral and the Bazaar, then ayear old, to replace the words Free Software with Open Source.
Some time after myannouncement, a reporter asked Steve Ballmer, then president ofMicrosoft, if Microsoft would "Open Source" their Windowsproduct. Ballmer was reported to have explained that Open Sourcewasn't just source code, it was a form of software licensing. Thevice president of Microsoft had read my manifesto, and the presswas asking him about it.
Manifestos from then-unknowns like myself and Raymond don'tget that sort of recognition, unless for some reason the world iswaiting for them. I submit that the reason was widespreaddissatisfaction with the dominant economic paradigm of softwarecreation at the time: Microsoft and its products. Microsoft waswidely perceived as placing their own interests ahead of those ofthe customer. Their software was known to contain a large numberof un-rectified bugs, and their desktop operating system wasextremely crash-prone. They could get away with this because theyessentially had no viable competition on the desktop.
People were searching for an alternative. If we were going tomake software better, we'd have to find some other way to do itthan what Microsoft was doing. Open Source created new economicrelationships. There was a new peer-to-peer relationship betweenenterprise software customers, who were enabled to participatedirectly in the development of the Open Source software and thusbecame software developers for each other. There were newrelationships between software vendors, who collaborated on OpenSource projects while they competed elsewhere. And there werechanges to the customer-vendor relationship: the customer could nowparticipate with the vendor in software development. Because many vendorscould access the same source code, and thus support the product,there was less lock-in and less exclusivity to thecustomer-to-vendor relationship. As a result of these changes, new suppliersarose, and existing suppliers began to substitute Open Source products forproprietary software.
The public sharing of the creation, ownership, and benefits of softwarewas the antithesis of the Microsoft model. OpenSource had already created a technically successful operatingsystem and the first practical web servers and clients, and thusshowed signs of being surprisingly effective. And so, the publicbuy-in to Open Source started out strong. It was followed bytremendous economic growth, with the Linux sub-sector aloneshowing an annual growth rate of 37 to 45 percent and predictedto be a $35 Billion dollarmarket by 2008[4].
The unusual acceptance and startling financial figures arguethat Open Source must be the answer to somepreviously-unfulfilled need. Otherwise we would not have seensuch wild, seemingly absurd phenomena:
The hobby project of a student in his twenties, Linux, takes over enterprise computing.
IBM, the epitome of conservative business, de-emphasizes its billion-dollar "AIX" operating system in favor of a product developed by a loose coalition of programmers with no financial motive in common, upon whom no corporate directive can be binding, whose leader has no power but the respect of others.
Microsoft faces its first serious competitor in a decade: programmers who give away their work.
These events seem absurd: they certainly don't fit thecommon economic paradigm of technology production. A new economicphenomenon is operating, and to explain it we'll have to lookmore deeply into the economics of software production.Looking for Economic Impact
Since Microsoft is thedominant model of a software manufacturer in most people's minds,and we're exploring the economics of software, let's ask:What is the greatest economic impact of Microsoft?
Is Microsoft's greatest economic impact the wealth of BillGates? Of course not! A lot of people envy his wealth, but Bill'spiece isn't the whole pie.
Is it the fact that they have amassed 40 Billion dollars inthe bank, are the worlds largest software company, and employ55,000 people in 85 countries? No, not that either.
Is the greatest economic effect of Microsoft the fact thatthey have enabled a great many businesses - their customers - todo business more efficiently, and to have businesses that theycould not operate at all without the software that enables them?Yes, that is the biggest economic impact of Microsoft.
Microsoft is a tool-maker, and the effect of the tool-maker onthe economy is tiny next to the economic effect of all of thepeople who are enabled by the maker's tools. The secondary economic effect caused byall of the people and businesses who use an enabling technologyis greater than the primary economic effect of the dollars paidfor that technology. And of course the same is true for OpenSource software.
Considering the Economic Function of Software in aBusiness.
It's important to consider that most companies arenot in the business of software manufacturing. They sell ships,shoes, services, everything under the sun. However, all but thesmallest companies are enabled by software to some extent.Without software, their business would be less efficient, orimpossible. Consider financial planning before computerspreadsheets, correspondence before email, andcustomer-to-computer interfaces when the most sophisticated inputdevice in the customer's home was a touch-tone phone. Today, weneed software to dobusiness! Indeed, we need it so badly that even though mostbusinesses don't sell software, any business of 50 people orgreater is likely to employ a programmer, web designer, or ascript-programming systems administrator[5]. For thosebusinesses, software is essential enabling technology, ratherthan their product.Enabling Technology vs. Business Differentiation
Enablingtechnology is essential to your business, but it's not what yousell. If you sell books, books are your profit-center, andsoftware lives in a cost-center as an unavoidable cost ofdoing business. A polemicist has said IT doesn't matter, but what he isreally telling us is that IT isn't your profit-center. You stillneed it to the extent that it enables your business.
There are two main forms of enabling, cost-center technology:differentiating, andnon-differentiating. Differentiating technology is what makes your business moredesirable to your customer than your competitor's business. Forexample, if you visit the Amazon.com web site and look for abook, Amazon will also tell you about other books that were purchased bypeople who bought the book you're interested in. And often thebooks it suggests areinteresting enough that you will buy one of those books aswell.[6] If you goto the Barnes and Noble site, they don't have that feature, andit's no surprise that Amazon sells more books online. So, forAmazon, the "recommendation" software is a businessdifferentiator. Obviously, it would be a mistake to Open Sourceyour business differentiators, because then your competitor'sbusiness might use them to become as desirable to the customer asyour own business.
But in contrast, it wouldn't hurt your business for yourcompetitor to understand how every bit of yournon-differentiating software works. Indeed, that competitor mightbe the best collaborator you could have, if the partnership islimited to working on your non-differentiating software, becausetheir needs are most similar to yours. This fact is demonstratedevery day in the Open Source world, in which HP and IBM arepartners in developing software that helps sell the systems ofboth vendors, and they remain fierce competitors at higher levelsin the software stack where differentiation between them ispossible and effective.
Perhaps 90% of the software in any business isnon-differentiating. Much of it is referred to as infrastructure, the base upon whichdifferentiating technology is built. In the category ofinfrastructure are such things operating systems, web servers,databases, Java application servers and other middle-ware,graphical user interface desktops, and the general tools used onGUI desktops such as web browsers, email clients, spreadsheets,word processing, and presentation applications. Any software thatprovides differentiating value to a non-software company is builton top of one or more of those infrastructure components.
An important indicator of whether software is differentiatingis whether or not your competitor can get the same software.Neither Microsoft software nor Linux and Open Source can help youdifferentiate your business for long, because they are availableto everyone. They differentiate against each other, they justdon't differentiate yourbusiness. One or the other can save you money or make you moreefficient, but in general they don't make your business moreattractive to your customer.
Another important indicator of whether software isdifferentiating or not is whether the customer can see thesoftware's effects. Your customer doesn't care what OS you run,unless your systems are crashed all of the time. She doesn't carewhether you run Microsoft Office or OpenOffice. You might havegood reasons to care, but the customer can't see them.
Thus, to make your business more desirable to customers, youshould spend more on differentiating software that makes yourbusiness more desirable, and less on software that doesn'tdifferentiate your business. Open Source is the key to spendingless on non-differentiators, by distributing cost and risk thatwas formerly your company's alone across multiple collaboratingcompanies.
Of course, you will need to take an honest look at whatsoftware in your business is differentiating and what isn't.And this turns out to be difficult. A lot of companies havenot invented heresyndrome. That's when managers and technical people aren'twilling to consider the work of outsiders, because they don'tbelieve that it could be as good as their own. "NIH" is anexpensive disease: it will cause your employees to duplicateeffort that is available elsewhere, instead of spending theirtime on the differentiating software that is most important toyour business.
Participation in Open Source makes our software cost-centersmore effective, because we can share cost and risk that we wouldotherwise be sustaining alone. What do we do with the money thatwe save? It becomes additional profit, or is spent in other areaswhere we need it more.
Economic Paradigms of Software Development
Since ourbusinesses need software, we'll need to develop it somehow. Themain economic paradigms for software development are: Retail.
In-House and Contract.
Efforts At Collaboration Without Open Source Licensing.
Open Source.
Each is different from the other in: How they distribute the cost of development.
How they distribute the risk of failure.
Their efficiency in funding software development rather than overheads of the process.
The degree to which others can be excluded from using the software.
These factors determine which paradigm is suitable for usein development of a particular piece of software. It's importantto remember that the ultimate source of funds for software is thecustomer, not thevendor. The customer can direct its funds to operations usingany of the economicparadigms to acquire the software it needs.The Retail Paradigm
Retail is the paradigm most familiarto the average person, yet it is responsible for less than 30% ofall software development[2]. In thisparadigm, the cost of software development is usually borne by asingle manufacturer. The manufacturer aims to recover thosecosts, plus profit, from sale of the finished product. Thus, thedevelopment expense is extremely front-loaded, with the entiredevelopment of a product necessary before the manufacturer canbegin to recover expense. The risk of failure to produce aprofitable product is borne entirely by the manufacturer.
Eventually, the cost of development is distributed tocustomers, if the product is successful in the market. Since theretail development paradigm can not directly distribute cost andrisk until the product matures, it is often necessary formanufacturers to turn to investment markets as an externalmechanism to distribute cost and risk. The manufacturer's needfor outside capital is of long duration, since it could takeyears to develop the software and its market, and additional timebefore the cost of development can be amortized and it becomespossible to take a profit. Stock markets increase the liquidityof the investment by allowing investors to monetize theperception of the company's future potential, reflected in itsstock price, rather than the company's actual earnings.Successful companies may re-invest profits in the development ofsubsequent software products rather than return to investmentmarkets.
The overhead of the traditional brick-and-mortar retail salesparadigm is extremely high, with the result that less than 10% ofthe money paid for the software by the end-user actually goesinto product marketing, software development, anddocumentation[7]. Micrsoft spent only 16.8% of its 2004revenues on research and product development. The rest ofMicrosoft's income went into items that don't directly benefitthe customer, such as the very expensive process of findingcustomers for Microsoft's products: overhead such as advertising,the design and manufacture of an attractive package that isdiscarded after the sale, payment to the retailer for shelf spaceupon which the product is displayed, sales staff, and profit. The16.8% figure does not include the mark-ups of the retailer andwholesaler, which would bring the portion of the product pricethat represents software development well below 10%.
There is inefficiency on the purchasing side too, due to amismatch between customer requirements and the softwarepurchased. The customer often purchases software that turns outupon closer evaluation not to be usable for the application inquestion, or is not deployed. Often the customer can not recoverthe cost of this "shelfware". There are also losses becausesoftware companies fail or discontinue and de-support productsthat the purchaser has not yet amortized. Since generally evendiscontinued products do not have source available, they are leftin an unsupportable state and the customer has little choice butto write off their investment.
Combining these risk factors, we can arrive at a conservativeestimate that 50%[8] of purchased retail software is not used,or not fully and effectively deployed - the purchase is afailure.
If we multiply the less-than-10% efficiency of the retailparadigm at directing dollars toward software development by the50% failure rate, we find that the efficiency of funding softwaredevelopment via retail software purchases is lower than 5%.
The most important implication of this extremely lowefficiency is that the retail paradigm can only be used economically to createproducts for a mass market. A mass market will mask theinefficiency of the paradigm, because each customer can pay arelatively small cost compared to the cost of the softwaredevelopment. As an aggregate, they would still pay more thantwenty times the cost of software development.
There are many important software products that simply can'tbe created using the retail paradigm, because they would notprovide a large enough market to amortize both the cost ofdevelopment and the large overheads of the paradigm. In addition,many new products that could eventually build a large market willnot be considered by a manufacturer, because companies andinvestors can not be convinced that such a market would develop,or the risk of failure is too high. This tends to damp innovation withinsoftware manufacturers that make use of the retail softwaredevelopment paradigm.
One telling example of the failure of the retail paradigm toinnovate is the fact that the most important innovation in thelast decade of global computer business, the web server andbrowser, had to be developed as an Open Source product at afederally-funded university research laboratory. None of thecompanies that could have completed the work were convinced thatit would make money. Indeed, the only company that did investsignificant funds to develop the web (Autodesk, by investing inTed Nelson's Xanadu Project), chose not to complete the projectbecause the revenue model that Xanadu foresaw for the web(payment to content producers for each word, with complicatedtracking of derivative works and references) was too difficult todevelop. The eventual leader in the development of a successfulweb, Tim Berners-Lee, did not see a need to develop any canonicalrevenue model, but left it to his users to figure out a means ofmaking money from the web.
And as we've discussed, since a retail business must approachas many customers as possible in order to generate the highestpossible profit, retail software is generally made available toeveryone. Thus, it is difficult or impossible for retail softwareto differentiate the customer's business.
The In-House and Contract Development Paradigm
In-housedevelopment is done by the customer's own programmers, whilecontract development is done by an outside company, generally asa work-for-hire for the customer's exclusive use. In both cases,the programmers are generally paid for the act of writingsoftware, rather than for the software as a product as would bethe case in the retail paradigm.
Another form of contract development is extensivecustomization of an otherwise-available product by the vendor.For example, a medium-to-large company may purchase a standardweb server environment and then pay its vendor for thecustomization of that environment to the customer's particularbusiness needs.
The customer has excellent control of in-house and contractdevelopment, because the programmers won't get paid unless theydo what the customer says. The customer can generally dictatewhether the software will be exclusively for that customer orwill be made accessible to others. Because the customer cancontrol distribution, this isan excellent paradigm for development of differentiatingsoftware. Indeed, it may be the only paradigm that reallyworks for development of software that would differentiate anend-user's non-software business.
In general, a contractor will try to use some of the work he doesfor one customer to leverage his business with other customers byre-selling work that's already been paid for. How successful heis at this depends on the contract terms and the honesty of thecontractor. If your contractor is confident that he can re-sellwork he does for you, he might charge you less and you mightbenefit from some distribution of cost and risk to the contractorand his next customer. However, this is not generally anappropriate scenario for differentiating software: if yourcontractor is selling your business differentiators, yourbusiness could soon be in trouble.
In exchange for the total control available through contractor in-house development, the customer generally sustainsall of the cost and riskof the development. Because of that cost and risk, contract andin-house development may not be the most cost-effective means ofdeveloping non-differentiating software. If a customer is paying100% of the cost to develop new software that duplicates thefunction of existing software that would be available to thatcustomer for less, that's called re-inventing the wheel and it's awaste of money. If the customer can stand having the softwaredistributed to others, and does not need absolute control overthe development, the Open Source or retail paradigms may be morecost-effective for developing that particular piece ofsoftware.
In-house and contract development are reasonably efficient atdirecting most of each dollar spent toward software development.Their efficiency in this regard is 50% to 80%, in contrast to the10% of a brick-and-mortar retail paradigm. The major sources ofinefficiency are the costs of finding new customers for acontractor's business, the cost of retaining expertise that maynot be fully utilized at all times, and the contractor'smark-up.
Many in-house and contract projects fail to produce workingsoftware that is deployed in the customer's business and meetsthe goals set for it. We can attribute to this paradigm a successrate of 50%[9],similar to the overall success rate we assigned to the retailparadigm.
Efforts At Collaboration Without Open SourceLicensing
Consortia used to be the standard means ofcollaborating between companies upon software development. Closedconsortium software development has a record of titanic failures.More recently, Billion-dollar closed consortia have a record ofbeing replaced by more successful Open Source projects. ConsiderTaligent andMonterey, two consortiaintended to create a replacement for Unix. Linux replaced them.Consider the Common DesktopEnvironment project, which has been replaced by the OpenSource GNOME desktop atmost of the companies that supported CDE.
A few years ago, the huge agricultural corporationCargill founded aconsortium with the stated intent of providing its partners withthe benefits of Open Source while also providing secrecy andsharing the benefits of the software only with consortiummembers. This is called a gatedcommunity. Two years later, Cargill walked away from theproject it founded. A closed consortium is simply the wrongstructure for the development of non-differentiating software. Itmakes sense to throw the doors wide open when you don't havedifferentiation to protect. and admit members that can make auseful contribution even when they can't pitch in funding. Aconsortium costs more because there are fewer members to sharecost and risk than with an Open Source project, yet there's muchmore structure and overhead than there would be for an equivalentOpen Source project. Closed consortia generally are directedthrough pay-for-say,while technical merit would be the case for Open Source. Withpay-for-say, a member can work to the detriment of the overallproject when that is to the member's advantage. Consortiumproduct planning often devolves into irresolvable arguments amongthe companies, because each has a different marketing idea andmarketing arguments between companies are subjective anddifficult to resolve.
Given the poor history of consortium development and, incontrast, the high rate of success for large Open Source projectscarried out by the same groups of companies, it seems that thefairness imposed by Open Source licensing is an essentialcomponent of effective collaboration between a large number ofparties with different interests.
The Open Source Paradigm
In the Open Source paradigm,multiple entities (individuals, companies, academic institutions,others) come together to develop a software product. Generallythe initial development is done by a single entity as in thein-house and contract development paradigm, and the software isreleased to the public as soon as it is useful to others,generally before it would be considered a finished product andthus much earlier than a retail product would be released. Oncethe software is useful, other entities make use of it. Only whenthe software becomes useful to others does the Open Sourceparadigm work fully, because only then will other parties have anincentive to use the software. Once they are using the software,these other parties will have an incentive to extend the softwareto implement additional features that are of interest to them.This extension is performed by the customer's own employees orcontractors under the customer's control.
The incremental cost of adding a feature is much smaller thanthe cost of the entire development. Parties that createmodifications have an incentive to write them in such a way thatthey will be accepted by the other developers on the project andwill be merged into the main body of source code that is sharedby all developers. If this merge does not happen, the continuingcost of maintaining the added feature will be higher, since itsdevelopers must track changes to the main source code andmaintain compatibility with that changing base.
Thus, Open Source tends to foster a community of developerswho make contributions to a useful product. The cost and risk ofdeveloping the product is distributed among these developers, andany combination of them can carry on the project if others leave.Distribution of cost and risk begins as soon as the project ismature enough to build a community outside of its initialdeveloper.
Open Source is developed directly by its end-users. Forexample, Apache web server features are added by the companiesthat need those features to operate their own web sites, orsometimes by contractors working for those companies.
The customers for a particular Open Source product generallyidentify themselves: they search for the product in a directoryof Open Source software, and then they download and test thesoftware. If tests are successful, they deploy it. Thus they gaina continuing interest in the product. At that point if theydesire additional features to the product, they have an incentiveto become co-developers of the software they are using.
The companies that join Open Source collaborations are seekingto use the software in a non-differentiating, cost-center role.It's not important to thesecompanies that Open Source does not in itself produce aprofit. Their profit-centers are things other thansoftware, and software is for them an enabling technology. Inorder to continue to operate their profit-centers, they must makesome investment in their cost centers. In the case ofdifferentiating software, they have little choice but to make useof the in-house or contract development paradigm, because theyneed to prevent their differentiators from falling into the handsof their competitors. For their non-differentiators, they havethe choice of the retail or Open Source paradigms. But which ismore efficient?
Because the customers are self-identifying, Open Source doesnot have the inefficiency of the retail paradigm, which must makeuse of advertising or other expensive mechanisms to seekcustomers [10]. Itis at least as efficient in directing dollars to softwaredevelopment rather than overhead as the in-house or contractdevelopment paradigm.
Because of its greater efficiency in allocating resources todevelopment rather than overhead, the Open Source paradigm can beused to develop products that would not support a mass market,and thus could not economically be developed within the retailparadigm.
Engineer Craig Small, a builder of network infrastructure,sums up the advantages for his customers:
Using Open Source cut way down on startup software costs. Thiswas important because it was the way to get in the door withthat particular customer. I was going to build the networkmanagement system from scratch, until I found a project thatwas close enough to what I needed. I could spend a fraction ofthe hours on the problem compared to what I would have neededto implement from zero.
Expanding and customizing Open Source is by far easier todo, because the developers expect from the start that peoplewill extend their work in ways that they haven't thought of,and thus they write in a style that is easier to extend.Proprietary software creators write as if nobody outside oftheir company will ever read their code. We took an Open Sourceproject for entirely different hardware from ours, and easilygot it to monitor our equipment.
I have returned my extensions back to the Open Sourceproject. Thus, I have confidence that if I leave the company,the extensions will still be looked after, at least by othermembers of the project.
There is now a community of people with the same sort oftechnical needs, both developers and non-programmer users, thathas sprung up around the software project that we allcollaborated upon. We discuss how to better satisfy our needs,and pool ideas that we would never have had on our own.
Proprietary software has costs that businesses have onlystarted to consider. Organizations like the Business SoftwareAlliance have raided businesses with federal marshals,demanding sufficient documentation that the company purchased alicense for every computer on site. Much time and effort isspent making sure that companies comply with increasinglyonerous licensing rules. Why can't I take that Windows XP offof my laptop and put it on the desktop legally? Open Sourceavoids that unproductive nonsense.
Not all Open Source projects succeed. Most immature OpenSource projects die on the vine or remain solo projects that uselittle in resources. But the expense of such projects isinsignificant, because they die without first attractingsignificant customers or a developer community. More mature OpenSource projects may die when something better comes along, butoften it is possible to use the actual source code, data, andskills from one project in another, and thus the investment indevelopment of the project is not lost.
The cost-of-participation in mature OpenSource projects is very different from the costs of retail orin-house and contract development. The major expense is thetime-cost of employee participation. This figure is a combinationof the personnel cost of software evaluation, the personnel orcontractor resources spent to adapt existing Open Source tocustomer needs and to support the Open Source for internal users,and the possibility that time will be invested into software thatis eventually replaced due to a failure to track customerneeds[19]. The maximum cost for OpenSource would come when there is no community other than thecustomer: this would be similar to the cost of contract orin-house development, in which one customer supports the entireexpense. The actual cost will be lower depending on the number ofactive participants and the work required. The lost investment isgenerally personnel time. Taking this into account, the OpenSource paradigm yields an economic efficiency at least as greatas the in-house and contract development paradigm, and muchgreater than the retail paradigm.Summary of Software Production Business Methods
The Open Source paradigm has several significant economicadvantages over the retail or in-house and contract softwareproduction paradigms: it combines efficiency in allocatingresources to software development with distribution of cost andrisk better than either of the other dominant paradigms ofsoftware development. It is amenable to the development ofproducts that are untenable under the retail paradigm becausethere is no mass market. Open Source can distribute the cost andrisk of projects, while the in-house and contract developmentparadigm would focus all cost and risk on one party. Open Sourcedistributes cost and risk directly, rather than requiring the useof investment markets. Distribution of cost and risk starts muchearlier than it would in the case of the retail paradigm. OpenSource gives the customer complete control over customization ofthe product. However, it does not give the customer control overwho has access to the product. Thus, Open Source is generallynot a good mechanism fordeveloping differentiating software.
Businesses that require non-differentiating software (really,all businesses) would be well advised to shift some developmentto Open Source and reap greater economic efficiency.Participation in Open Source development communities should be animportant part of any businesses overall strategy to shiftdevelopment dollars from non-differentiating to differentiatingsoftware.
Paradigm Efficiency Failure Rate Distributes Cost Distributes Risk Protects Customer Differentiation Protects Vendor Differentiation Required Market Size
Retail less than 10% 50% Late, sometime after sales start. No. No. Yes. Mass market 100,000 and up, specialized markets less.
In-House and Contract 60% to 80% 50% No. No. Yes. Maybe. 1
Consortium and Non-Open-Source Collaboration 60% to 80% Perhaps 90%, unacceptably high. Yes. Yes. Maybe. Maybe. 5 and up.
Open Source 60% to 100% 50% Early, during development. Yes No. No. 5 and up.
Who Contributes to Open Source, and How Do They FundThat?
There are several main sorts of Open Sourcecontributor: Volunteers.
Linux distribution companies.
Companies with a single Open Source program as their main product.
Companies for whom Open Source software enables sales of hardware or solutions.
Service Businesses.
End-user businesses and their contractors.
Government.
Academics and scientific researchers.
Each of these sorts of entity works differently within theeconomics of Open Source software, drawing from a differentsource to fund their contributions. We'll explore each one.Volunteers
I (Bruce Perens) was an example of this sortof contributor from 1993 through 1998, when I worked extensivelyon Open Source development that had no connection to myemployment.
The 2002 FLOSS study[11] reportedthat the creation of Open Source was, at that time, primarily a hobby activity! Buttheir participation of individuals without an immediate financialmotivation in Open Source software development is serious enoughto transcend the term hobby. Perhaps volunteer is a better description,because of the obvious professionality of their work [12], and thefact that their motivation is not pecuniary in nature.
Eric Raymond proposed that the volunteer's motivation ismainly intangible, and that a particularly important motivator isparticipation in a community of respect in which developers arerecognized by their peers for the quality and innovation in theirwork. The FLOSS study surveyed Open Source developers regardingtheir motivation, found that many of them are motivated bytechnical curiosity and the desire to learn. I feel that theirmotivation is similar to that of an artist: just as a painterwants people to appreciate his paintings, a programmer wants tohave users who appreciate his software.
There is a continuing transition from volunteer toprofessional, as Open Source is used increasingly in companiesthat then become motivated to participate in its continueddevelopment. Former volunteers are gaining employment inorganizations that support their Open Source work on companytime. Open Source supporters within companies come "out of thecloset" to become internal experts as their employers express aninterest in Open Source.
Linux Distribution Companies
Red Hat and Novell are well-known fordistributing Linux-based systems. But, surprisingly, businessesdedicated to selling Open Source software as their main productdo not create themajority of Open Source software. They act mainly as integratorsof the work of others. They do a lot of maintenance work in orderto eliminate bugs for their paying customers, and they dooriginal Open Source software development where they feel this isnecessary to enable their product or a new market. The Linuxdistributions are for the most part medium-sized companies, andtheir employees represent a small but active component of theoverall population of Open Source contributors. Sometimes theyinflate their impact in marketing communications. For example,one Linux distribution promotes that it employs 300 programmers,but a much smaller proportion make regular contributions to OpenSource software. The majority seem to be doing "salesengineering" or working on internal solutions for customers.
Indeed, the economics of Open Source seem to work worst for Linux distributions. Whenyou Open Source your business differentiators, your competitorcan appropriate them and reduce your business differentiation.That is the quandary of the Linux distributions: their product ismostly Open Source, their customers want it to stay that way, andthey struggle to differentiate a product that the customer knowsis available elsewhere without charge.
Linux distributions originally tried to deal with thedifferentiation problem with the first generation of Open Sourcevendor business plans, which Eric Raymond explains inThe Cathedral and theBazaar. These models mostly coupled some other product toOpen Source software as the money-maker: service on the OpenSource software, or a proprietary software addition to the OpenSource component. The Open Source software would be enablingtechnology for a business with some other component driving itsrevenues, but the money-making component would be very closelycoupled with the Open Source software. But unfortunately,services alone were not enough to make the distributionsprofitable during Linux's early-adopter period.
Today we are experiencing the second generation of Open Sourcebusiness plans. Some Linux distributions are attempting toimitate proprietary software. Behind their costly box of softwareor per-seat license is a product that the customer could acquirewithout charge through other channels. Several strategies arecombined to make this work: the development of a brand that isperceived to hold more trust or value than the naked software.The vendor invests resources into certification by proprietaryapplication vendors, who each want to support only a fewdistributions[14]. Customers who need support for aproprietary product on Linux thus have an incentive to pay forthat vendor's version of Linux. Some support services aresequestered, such as security problem reports or bug patches, sothat they will only be available to people who have purchased thecostly box and per-seat licenses. If the customer loads the freesoftware on more systems than he's paid for and the vendor findsout, the customer will be penalized by the revocation of hisservice contract and the withdrawal of security informationcritical to the continued operation of the software. Perhaps thebest name for this business model is proprietary Open Source, in whichservices are offered but the business is operated in theproprietary box-software model. This business model isessentially antagonistic to the volunteers who have created muchof the Open Source software. They weren't out to develop anotherMicrosoft, and they resent the sequestering of serviceinformation on theirsoftware. It is in conflict with the spirit, but not the letter,of Open Source licensing such as the GPL[15]. In general,volunteers help the companies they approve of. As the internalexperts on Open Source for their employers, they recommend thecompanies that they approve of. And thus there will besignificant challenges to the proprietary Open Source model.
It's important to emphasize that not all Linux distributionsengage in proprietary OpenSource, and that proprietary Open Source is not the dominant business model forOpen Source software development. The vast majority ofcontributors to Open Source belong to the other categoriesexamined here.
The money used to purchase Linux distribution "seats" andtheir associated services comes from enterprise IT departmentcost-centers.
Companies With a Single Open Source Program As Their MainProduct
This sort of company can be divided into severalcategories: Mixed Open Source and proprietary licensing model.
A core Open Source program with proprietary software accessories.
Pure Open Source plus services model.
We'll explore each category.Mixed Open Source and Proprietary LicensingModel.
Examples of this sort of company are MySQL AB andSleepycat Software, which produce databases, and Trolltech, whichproduces the Qtgraphical user interface toolkit. This sort of company vends thesame software under two different licenses: an Open Sourcelicense and a commercial license.
The Open Source license chosen, often the GPL, includes a"poison pill" meant to make production of proprietary derivativeworks commercially untenable. Since the GPL requires that allderivative works must be distributed in source-code form underthe GPL or a GPL-compatible license, this would remove thebusiness differentiation from any software to which it isapplied.
To escape the poison pill and preserve businessdifferentiation, the producer of a proprietary derivative workmust purchase a commercial license for the same product. Thisprovides the producer of the Open Source software a directrevenue capture for unit sales of software to creators ofproprietary derivative works.
This model works only for software that will be combined intoderivative works, such as a software library. It generally isn'tusable for applications.
The future viability of this model is in question, because aprogrammer can make a "server" of a software library and exportall of its functionality to another program without creatingsomething that would be considered a derivative work undercopyright law or the definitions in Open Source licenses. In Unixparlance, servers are referred to as "daemons", and thus thepractice of embedding software in a daemon in order to avoidcreating a derivative work is called daemonization. It is possible that afuture Open Source license could restrict this practice.
Today, it is possible to make use of the MySQL database serverin a proprietary application without a commercial license, byusing the MySQL database engine as a server (its usual mode) andmaking use of a special variant of the MySQL client library thatis under appropriate licensing terms for proprietaryapplications. Of course, MySQL AB doesn't support that clientlibrary.
This sort of company generally supplements its commerciallicensing revenue with additional revenue from training andsoftware development services.
The main customer of this sort of company is the enterpriseuser, in the case of MySQL. Trolltech's main customers areembedded device developers and software application developers.The funds used to purchase these products come from cost-centerswithin IT and software development departments.
A Core Open Source Program With Proprietary SoftwareAccessories
Eric Raymond calls this model Widget Frosting and discusses it indetail. Sendmail Inc. isan example of this sort of participant. Sendmail Inc. has createda constellation of proprietary products around the Open Sourcesendmail email server. This funds ongoing maintenance of the coreOpen Source product. Some of the Linux distribution companiesalso intend to operate using this model, and some of IBM'sbusiness is under this model: for example their sales of theproprietary DB2 databaseon Linux. This sort of company essentially operates as if it werea proprietary software business. The funds used to purchase itsproducts come from IT department cost-centers.Specialization In One OpenSource Program Plus Services Model
This model wasproposed to be an important one in Eric Raymond's paper, but hasnot performed as well as was expected so far. Many Open Sourcedevelopers supplement their income by providing services upon thesoftware that they develop, and there are a number of newcompanies pursuing this model - some with sizable venturefunding. Some of these new companies seem to be operating acertification model,servicing a particular version of the software that they certify,perhaps in the manner of the proprietary open source businessmodel at some of the Linux distribution companies.
Some small and medium-sized companies have been able toproduce sustainable revenue while developing Open Source softwareas their major business focus and providing services on that OpenSource as their only profit-center. But many have failed, somespectacularly like VA Linux Systems and Linuxcare. Companies thatwould be support customers seem to prefer to do their Open Sourcesupport inside, or through a vendor with whom they already havean existing relationship or whom can service more than oneprogram. There may also have been an early-adopter problem.Early-adopters in general do not want the hand-holding of aservice company. Time will tell if this model can performeffectively.
The funds for services provided by this sort of company comefrom IT department cost-centers.
Hardware Vendors
Examples of this sort of company are IBMand HP. Hardware is a great product to sell along with OpenSource software. It costs a penny to copy software, but you can'tcopy a loaf of bread without a pound of flour. Until we have theStar Trek"replicator"[13],hardware is a difficult-to-copy product. Allowing the customer toknow something of hardware internals doesn't necessarily removeall of its business differentiation, as might be the case forsoftware. The hardware manufacturers that participate in OpenSource development do so to enable sales of their hardwareproducts. Hardware is useless without software, and specificallycomputers are useless without the operating system thatinterfaces the computer hardware to software applications. OpenSource developers seem to be better at systems programming thanany other form of programming, so far, and the Linux operating system kernel is nowas good as, or better than, many proprietary operating systemsfor similar hardware. Hardware manufacturers formerly spentbillions on proprietary operating systems that, for them, werealways enabling technology rather than a profit-center. Themargins were in the hardware itself. Many of these manufacturershave eagerly embraced Linux because it allows them to distributethe cost and risk of the operating system among multiplecompanies, has a cost-efficiency greater than that of similarproprietary operating systems, and is in general desirable to thecustomer.
Hardware companies are good at producing Open Source becausethere isn't nearly so much conflict between Open Source anddifferentiation for them as there might be in a software company.Making software products Open Source enables sales, doesn'treduce their hardware-based business differentiators, and thusdoes not threaten their profit center.
Generally this sort of company supplements its hardware incomewith services, and sometimes training.
The funds for hardware and services provided by this sort ofcompany come from IT department cost-center hardware budgets.
End-User Businesses and Their Contractors
eBay is anexample of this sort of contributor. Many companies make use ofOpen Source software in their own operations. Web applicationsare particularly important, but there are many others. And thesecompanies make up a significant portion of the Open Sourcecontributors. In general the contributions come from internalsoftware support and development staff, or contractors supportingthe company, who modify the Open Source software to fit thecompany's needs.
What is most interesting about this sort of contributor isthat they are the main customers of essentially all of the othersorts of companies that contribute to Open Source softwaredevelopment. Their cost-center dollars fund the work of the othersorts of companies analyzed here. And they appear to be puttingsome of those dollars directly into Open Source software, eitherthrough use of their own staff or via contractors workingdirectly for them, instead of going through the traditionalintermediates.
But why should this sort of company should do work outside ofits core competency? Core competency is a property of individualsmore than of companies. Thus, you should consider not whether anOpen Source software project is the focus of your business, butwhether you can operate your business most economically by makingthe Open Source participation a focus of some staff members. Themain advantage for your company is the reduction of cost andrisk, and an improvement of the degree of control that you haveover your software. Consider today the degree to which softwarecontrols your business. Do you control the software?
Service Businesses
A number of service businesses createsolutions by integrating multiple Open Source programs with"glue" software specialized for the particular customer. Otherbusinesses provide service for a collection of Open Sourceprograms. This sort of business participates in the developmentand maintenance of many Open Source programs, but perhaps notintensively in any one. In general, the motivation of theend-user businesses that employs this sort of contractordominates that of the contractor itself, and thus thesebusinesses should be considered under End-User Businesses And TheirContractors, above. Some businesses vend a web serviceunder the application service provider (ASP) model, buildingmostly upon Open Source software. There is a loop-hole in manyOpen Source licenses (particularly the GPL as it exists today)that protects differentiation of ASP businesses. The requirementto provide source code doesn't trigger until the software isdistributed, and an ASP need only perform the software for thecustomer, rather than distribute it. Since this is widelyregarded as a flaw in the GPL, it may not persist in the nextversion of that license.Government
Government's use of Open Source is similar tothe way that business approaches Open Source for its costcenters. However, government is expected to function for thebenefit of the citizens and is not generally thought of as havingprofit-centers of its own. Rather, it provides services thatenable economic and social activities.
Government contracting should not provide a commercialadvantage to a particular vendor outside of the direct revenuefrom the products or services purchased. Government shouldespecially not lock itself to a particular vendor after thecontract term because of switching costs. It's poor policy forgovernment to lock its vendors or citizens into use of aparticular vendor's product for communicating with thegovernment, as this would provide an inappropriate advantage tothe vendor. All vendors can make use of Open Source componentswith appropriate licensing, and thus can facilitate e-governmentto make use of Open Source for government-to-citizen,government-to-business and government-to-governmentinterfaces.
All vendors can make use of Open Source components withappropriate licensing. Such use can assure that the softwareinterface to government facilities is an open interface that can be utilizedby all vendors. Thus, it can facilitate e-government to make useof Open Source for government-to-citizen, government-to-businessand government-to-government interfaces.
Government carries out some activities solely for the publicbenefit, and can carry out Open Source development in thiscapacity. This is generally done through research funding.
Academics and Scientific Researchers
Academic researchprojects have historically been large contributors to OpenSource, and mostly graduate rather than undergraduate work. Ingeneral, an undergraduate class does not provide sufficient timefor a student to come up to speed on an Open Source project andmake a contribution. In contrast, graduate research projects areoften years in duration. A large body of Open Source softwarecame out of the BSD (Berkeley System Distribution) project fundedby the U.S. Department of Defense. Additional academic researchprojects produce more software daily.
There are vigorous Open Source communities involved inscientific research. In science, the maxim is publish or perish, and Open Sourcefits that well. To be considered valid, scientific research mustbe capable of being duplicated. If an experiment doesn't turn outthe same way when performed by another scientist, that may meanthat the research is erroneous. These days software makes up alarge part of many experiments, and a human-language descriptionof the experiment may not convey every detail of how it has beenperformed. If the researchers can share code, outsiders canexamine their software for errors and duplicate their experimentsmore easily.
The community of scientists researching a particular field ofstudy is small. Retail software would not be effective indeveloping such specialized software. Open Source is the best wayfor scientists to share the cost of developing software tosupport their research.
Proprietary software supporters have tried to turn back thetide of academic contributions to Open Source by forging newpartnerships between college research projects and proprietarysoftware companies. This trend is especially disturbing whenpublicly-funded research work results in patents that aretransferred to the proprietary software company partners, sinceit is likely that those patents will be prosecuted against thevery taxpayers who funded their creation. In general,publicly-funded work should be maximally utilizable by the publicthat funded it. DARPA (the U.S. Department of Defense researchgrant organization) and the University of California recognizedthis when they applied the BSDLicense to the pioneering extensions of Unix created atthe university. That licensing allowed any Open Source orproprietary use of the software.
Some research work is performed by unsalaried students. Whenthey are salaried, thefunds for their software development generally come from grants.Governments are the largest provider of such grants, a secondarysource is philanthropic, and some funds come from industrypartners.
Summary of Contributors To Open Source Projects
The largest contributor to Open Source development today maystill be the volunteer. There is a conflict between businessdifferentiation and Open Source that makes its economics workworst for the sort of business that would generally fund the samesort of development in the case of proprietary software.Businesses without such a conflict are more effective at fundingOpen Source development. Thus, hardware manufacturers have takena large role, and end-user businesses are taking an increasingrole.
Type Example Conflict between Open Source and Business Differentiation? Differentiation Protection Mechanism Source of Funding. Commercially Effective
Volunteer Bruce Perens from 1993 to 1998. No n/a, doesn't need one. Donates own time. n/a, motivation is non-commercial.
Academic Contributors University research projects. No Government, philanthropic grants. Paid to do research, not the result. Yes.
Linux Distribution Red Hat Yes Branding, certification, sequesters service data. Per-box or seat sales to IT cost-centers. Too early to tell.
Companies with Single Open Source Program as Product. MySQL, Trolltech, Sleepycat Software No Dual-licensing, "poison pill" in the Open Source license protects differentiation in the case of commercial users, provides incentive for commercial license purchases. Per-box or seat sales to IT cost-centers. Yes.
Core Open Source Product with Proprietary Additions Sendmail Inc. No Differentiating products are proprietary. Proprietary software sales to IT cost-centers. Dubious.
Specialization in Open Source Program Plus Services ? No Service, not the program, is what is differentiated. Services sales to IT cost-centers. Dubious.
Service Businesses ? No Service, not the program, is what is differentiated. Service sales to IT cost-centers. Yes.
Hardware Manufacturer IBM, HP No Hardware can't be copied for pennies as software can be. IT cost-center hardware budgets. Yes.
End-User Business eBay No Software lives in a cost-center, enables sales of profit-center products. Their own IT cost-centers. Yes, from savings alone.
How Open Source Does Product Marketing
A common objectionto Open Source is the perception that Open Source developmentwill not be well focused or targeted. People are used todevelopment that is directed by one company in an extremelyfocused manner, driven by a product marketing process. Somemature Open Source projects do perform their product marketingthe way a company would. But while a company generally woulddevelop an overall strategy that drives all of its softwaredevelopment, there is no global planning authority for OpenSource, and no overarching strategy followed by all Open Sourcedevelopers. However, it's an error to ask for such a thing: youcan't compare Open Source to a company, it's an entire industry.A central planning authority for an entire industry wouldindicate something other than an open market. The productmarketing for the global Open Source community operates in theway that a capitalist nation operates its economy, rather thanthe way a company plans its products.
The paradigm by which Open Source does product marketing canbe described as amassively-parallel drunkard's walk filtered by a Darwinisticprocess. First, very many people all over the worlddevelop whatever they want, going in any direction they wishwithout any central coordination. Out of this process come manypotential products that would not interest more than a few otherpeople, some products that are interesting to at least fiftypeople, and a few products that are interesting to millions ofpeople.
Fifty people who want the same thing, but are geographicallydistributed all around the world, can form a viable softwaredevelopment team via the Internet. The spare time of fifty peoplewho are otherwise employed turns out to be sufficient resource toenable the development of large and complex software products,and of course the size of the development team increases as theproduct matures and becomes of interest to more people. Thus, byleveraging upon the excellent collaboration that is possible whenusing Open Source licensing, it is possible to initiate andsuccessfully carry out projects that would otherwise be beyondthe capability of any of the participating entities.
But how do 50 people who haven't met work together to form aviable software product? Part of the reason this works so well isthat software is extremely modular by nature, and thus manypeople can work on different segments of the software, almostautonomously, if they can come to agreement about how the piecesfit together. A good example of this is the Debian GNU/Linux Distribution. Thissystem includes more than 16,000 software packages maintained byover 1000 volunteer developers in many nations around the world.When these packages are combined, the result is a reliable andwell-integrated system. That system has supervised experimentswhile in orbit on the Space Shuttle, and has a user communitysecond in size only to Red Hat (yes, it's bigger thanNovell).
But how can we develop products when everyone has the freedomto go their own way and there isn't a real boss? This seems oddto business people, until they realize that this is exactly howcapitalism works in democratic countries. In the broader economyof a capitalistic nation, many companies set out to developproducts without any central guidance from the government. Theyall compete with each other, and some products succeed and builda market while other products fail. Loose collaborations arisebetween companies for the purpose of building markets for newproducts. The role of the government, the only entity thatconceivably could guide the economy, is in general limited to theinjection or removal of capital from the economy, tax incentivesand funding programs, and the enforcement of laws designed tocreate fair markets.
Most sensible people have accepted that a "sure thing" is rarein gambling or stock-picking, and yet they expect marketingdepartments to make reliable forecasts in guiding new productdevelopment. Marketing departments have no crystal ball. If asufficient number of self-guided developers are available, adrunkard's walk strategy will outperform conventional productmarketing. The massively-parallel drunkard's walk tries manydifferent paths, and thus has a higher probability of accessing asuccessful path. The Darwinistic filtering is what recognizesthat a particular path is successful.
Most business people are adamant that they want to live in afree market economy, and that the government should not take astrong guiding role in determining what products will be producedand how they are made. They say this because they understand thatthe free market is more likely to produce good products and ahealthy economy than any central planning process. It should beno surprise to them, then, that the open-market-like paradigm ofOpen Source can sometimes do a better job than the centralcontrol of marketing departments and management at creatingdesirable products.
Is Open Source Self-Sustaining?
Many people have troubleunderstanding how Open Source could be self-sustaining if it doesnot operate according to the retail development paradigm. Whatpays for such software? It is funded directly or indirectly as acost-center item by the companies that need it. Those companiesneed a great deal of cost-center, non-differentiating software.They are willing to invest in its creation through the OpenSource paradigm because it allows them to spend less on theircost centers by distributing the cost and risk among manycollaborators, and makes more efficient use of their softwaredollar than the retail paradigm. This is essentially the samesource of funding that pays for proprietary software. It'simportant to remember that the software manufacturer isn't theultimate source of funds: the customer is.What is the Economic Impact of Open Source?
We definedthe major economic impact of Microsoft as:The fact that they have enabled a great many businesses - theircustomers - to do business more efficiently, and to havebusinesses that they could not operate at all without thesoftware that enables them.The same definition applies to Open Source.
It is a fact that Open Source enables a majority of webservers today, a majority of email deliveries, and many otherbusinesses, organizations, and personal pursuits. Thus, itseconomic impact must already be numbered in many tens of Billionsof dollars.
Any improvement in technology that permits business tofunction more efficiently means the economy runs moreefficiently. In this case, Open Source enables business to spendless on software and to have better quality and more control overits software. The money that is saved on software doesn'tdisappear, the people who save it spend it on things that aremore important to them.
What Does All Of This Mean To Software Producers?
Thisdiscussion has been mostly from the perspective of thesoftware-using business, who ultimately pays for softwaredevelopment, rather than the software-producing one. But whatdoes this mean to software producers?
Does your business really sell finished software? Somebusinesses sell the act of software creation rather than thesoftware itself. This is the case, in general, for consulting and"solutions" companies. Your customers will be willing to pay forthe creation of Open Source software.
In the case of a business that wishes to produce software forsale, rather than sell the service of programming or training,Open Source will be a difficult product to monetize.
It may be that Open Source eventually causes a reduction indemand the for proprietary software. This would not, however,reduce the demand for programmers, because the demand forsoftware in general would not decrease. The displaced proprietaryprogrammers would move to an organization that can produce OpenSource software in an economically successful manner.
It is possible that programmers who move to a lessentrepreneurial setting could earn less. However, surplus profitsin proprietary software companies have historically beendistributed to management in much larger portions than to staff.It is the rare programmer that has been able to profit from astock incentive windfall from a company whose products arepredominantly software offered for sale.
What Effect Does The Free-Rider Problem Have Upon OpenSource?
The Free-RiderProblem is familiar in economics. What do you do aboutpeople who take advantage of a product or service withoutproviding any return to the provider of that product or service?Do you have a mechanism to prevent free-riders?
All Open Source users start out as free-riders. They downloadand try the software, and perhaps deploy it, and do not generallyconsider contributing to that software's development until theyare already using it and desire an additional feature.
If they desire an additional feature, they may implement thatfeature themselves rather than pay one of the initial developers.At this point, are they still free riders? No. Businesses thatjoin an Open Source project as developers contribute somesoftware to the product, and all of those businesses derive aneconomic benefit from making use of the software in a cost-centerof their business. The interests of the various developers aregenerally similar because they have self-selected a particularsoftware product as one useful to them. The contributions of anyone developer are generally of use to other developers.
There are developers that are not motivated by the desire toprovide software for a business cost-center. These areindividuals whose motivations are primarily artistic, andscientific researchers.
Volunteers derive emotional fulfillment from having users fortheir software, just as artists derive fulfillment from havingothers appreciate their paintings. For volunteers, users providean intangible benefit which the volunteer desires. Thus, thoseusers should not beconsidered free-riders.
Companies that place importance in a particular Open Sourceproduct tend to hire developers who have already gained statureas a developer of that product. Thus, individuals who havestarted with no pecuniary interest in the Open Source projecttend to find employment with an organization that does have suchan interest. And thus individuals who participate in Open Sourcedevelopment often reap an economic gain from that participation.This is another reason that users should not be consideredfree-riders by these individuals.
Scientific researchers have their own paradigm of constantexchange of knowledge similar to that in the Open Sourcecommunity, because science advances most rapidly when discoveriesare made known to other scientists who can add their intuitionsto them. Scientists gain fulfillment from the publication oftheir work, because this increases their stature among otherscientists and in general determines the success of theircareers. Scientists routinely use Open Source as a means ofpublishing the software component of their work. In addition,scientists are motivated by the desire to be of benefit tosociety, and wish to see other people benefit from the use ofsoftware developed through scientific research. Thus, toscientific participants, users are of benefit and shouldnot be consideredfree-riders.
And finally, users are the people whom we recruit to becomemore active participants in an Open Source project, just asretailers try to recruit the general public to buy theirproducts. Invariably we are successful with some of them.
There is some question regarding whether the free-riderproblem is as significant in the case of software as it is forother sorts of products, and whether it applies to Open Source atall. A free-rider on a bus uses the scarce resource of a seat, sothat a potential paying rider could be denied a chance to ridethe bus. A free-rider who has bootlegged a copy of MicrosoftWindows may or may not diminish the market for paid copies ofWindows, but does not use any scarce resource that would excludeother Windows users. A free-rider using Open Source does notdiminish a market or use any scarce resource.
All of this leads me to believe that the free-rider problem isnot a significant detriment to Open Source development.
If Open Source Works, Why Don't We All Build Our OwnCars?
The Open Source paradigm works well for many productswhere the major value of the product is its design. It's most successfullybeen used to date to produce software, an encyclopedia, andintegrated circuit designs.
The integrated circuit designs are programmed into afield-programmable gate-array, a special device that can beprogrammed with a design and will then immediately behave as acircuit with that design. This is an example of a field in whichhardware is very much like software.
However, most things are not software. It only takes a cent'sworth of resources to make a copy of a piece of software, but ittakes a pound of flour to make a loaf of bread. Someone has tofarm the wheat and grind it into flour, and those efforts have tobe paid for.
Automobiles, of course, are much more complex than bread, andit takes a great many physical processes with expensive toolingto manufacture them. Consider that to make an electric motor, onemust mine and refine metal, then draw wire, roll sheet metal,cast and machine bearings, and then assemble all of these piecesinto very precise forms. It should be no wonder that it takes anentire economy to manufacture an automobile, while a singleindividual may produce an important software product.
When the day comes that we can makecomplex physical products by producing their designs anddirecting a machine to manufacture them from easily-availablematerials and electricity[], theeconomy will change radically. Today, we are limited to producingindividual parts with computer-controlled milling machines, aslow and dirty process that still requires manual intervention. Ahealthy Open Source community has evolved around such machines,and we are starting to see them share part designs. But thescience of computer-controlled manufacturing will have to improvetremendously before we can have "Open Source cars".
Summary
Open Source is self-sustaining, with an economicfoundation that operates in a capitalistic manner. It does notrequire any sort of voodoo economics to explain. It is anextremely beneficial component of a free-market economy, becauseof the very many people and businesses that it enables to maketheir own economic contribution. It is more efficient than othereconomic paradigms of software development for producing softwarethat does not differentiate its user's business.Non-differentiating software makes up the lion's share of allsoftware in a business, and businesses would be well advised topursue Open Source collaborations for producing such software.Topics for Further Development
Economists would be interested in a discussion of Open Source as a public good.
About the Speaker
Bruce Perens is one of the founders ofthe Open Source movement in software, and the creator of theOpen Source Definition,the manifesto of Open Source. He is founder or co-founder of theLinux Standard Base, thestandardization project of Linux, the UserLinux project, and No-Code International.
Perens currently sits on the board of directors ofOpen Source RiskManagement, an insurance company covering the risks ofOpen Source software and Software in the Public Interest, thenon-profit that supports the Debian Project. He is a significantstockholder in Progeny LinuxSystems, which was funded through his VC firm Linux Capital Group.
Perens is Senior Research Scientist for Open Source with theCyber Security Policy Research Institute of George WashingtonUniversity. He is series editor of the Bruce Perens' Open Source Serieswith Prentice Hall PTR publishers, which has published 13 bookswith all of their text under Open Source licenses.
Perens operates a strategy consulting firm, Perens LLC, which specializes inissues related to Linux and Open Source software.
Perens formerly served as Senior Global Strategist for Linuxand Open Source with the Hewlett Packard Company, and as invitedexpert on the World Wide Web Consortium's Patent Policy Board. Hewas Project Leader for the Debian GNU/Linux Distribution, andwrote the Debian SocialContract, a portion of which later became The Open Source Definition.
Acknowledgements
The generous support of NTT Docomo LabsUSA is making this and other articles possible. Thanks to TheCyber Security Policy Research Institute of George WashingtonUniversity, and Tony Stanco there, for granting me an affiliationwith their prestigious institution. Thanks to Prentice Hall PTRand executive editor Mark Taub for publishing Bruce Perens' Open Source Series,currently numbered at 13 books, in which this article willeventually find a home. Martin Fink, now Vice President for Linuxat HP, was the person to name proprietary open source, even ifhe's being forced to accept it now. Martin also provided myintroduction to management of large corporations as my manager atHP, and has taken lots of guff for and from yours truly. TheDebian developers never cease to amaze me with their erudition.They were the first reviewers of this document, and contributedtremendously to its quality. Participants were: Bill Allombert,Ben Armstrong, Jeff Breidenbach, Andrew M.A. Cater, Tim Cutts,Ryan Golbeck, Joshua Kwan, Alexander List, Andrew McMillan, RaulMiller, Nick Phillips, M.J. Ray, Craig Small, Andrew Stribbehill,David N. Welton, Florian M. Weps, Matt Whipp, Matthew Wilcox.Other reviewers were Kael Goodman, Mark Shuttleworth.Footnotes
For the purposes of this paper, Open Source and Free Software mean the same thing. There are philosophical differences between the two groups, but the great majority of software to which the definition of Open Source applies would also fit the Free Software Foundation's definition of Free Software.
It is important to note that when I created the document that later became the Open Source Definition, as a policy document for the Debian Project, the FSF had not created its own definition of Free Software. At that time, Richard Stallman commented in personal email that my document was a good definition of Free Software.
Stallman would not agree with my suggestion that a business might be better off not assigning a Free Software license to software if that license would reduce the differentiating value of the software to that business. Thus I am using the nomenclature Open Source in order to avoid diverting Stallman's agenda for Free Software.
A report on the size of the U.S. software market is at http://web.ita.doc.gov/ITI%5CitiHome.nsf/AutonomyView/87200518f179196c85256cc40077ede1 . In that report, "Packaged Software" represents 24.6% of the industry. All other industry sectors that represent computer programming, including all of Computer Programming Services, Computer Integrated Systems Design, Computer Processing and Data Preparation and Processing, Information Retrieval Services, Computer Facilities Management Services, and some sub-categories of Software Publishing represent the remainder.
However, that report does not account for the software produced solely for company-internal use by programmers employed by companies that have a non-software product. I conservatively estimate the population of internal programmers to be equal to that of contract ones, who are listed under Computer Programming Services (19% of market).
To some extent, Raymond deprecated Stallman when speaking for Open Source, when he might simply have promoted to the different audience of Open Source without any conflict with Stallman and his Free Software campaign. In my opinion, this unfortunate outcome is attributable more to a difference in personalities than philosophy.
IDC Software Consulting: The Linux Marketplace - Moving from Niche to Mainstream. Prepared for OSDL.http://www.osdl.org/docs/linux_market_overview.pdf
Bureau of labor statistics reports for 2002 show 2,153,000 people hold programming-related jobs in the United States: 499,000 are Computer Programmers, 675,000 are Computer Software Engineers, 979,000 are Computer Systems Analysts, Database Administrators, and Computer Scientists. This does not count 758,000 jobs held by Computer Support Specialists and Systems Administrators, who generally perform at least some script programming, and Computer Operators, who held 182,000 jobs.http://www.bls.gov/oco/ocos110.htm,http://www.bls.gov/oco/ocos267.htm,http://www.bls.gov/oco/ocos042.htm,http://stats.bls.gov/oco/ocos268.htm,http://stats.bls.gov/oco/ocos128.htm
Ironically, the Amazon "recommendation" feature is the topic of a patent-infringement suit brought by Cendant against Amazon.
Microsoft's 10-Q report to the SEC for September 30, 2004 shows that only 16.8% of their revenue goes to research and product development. "Research and development expenses include payroll, employee benefits, stock-based compensation and other head-count-related costs associated with product development. Research and development expenses also include third-party development and programming costs, localization costs incurred to translate software for international markets, and the amortization of purchased software code and services content". Of course, this report does not show the markups of wholesalers and retailers, which would bring the software-development-per-dollar figure below 10%. The report is at http://microsoft.shareholder.com/redesign/EdgarDetail.asp?CIK=789019&FID=1193125-04-189841&SID=04-00
A terrible thing to waste, article on "Shelfware", CFOEurope.com:http://www.cfoeurope.com/displayStory.cfm/1739037, CRM Software or CRM Shelfware?, CNET News.com,http://news.com.com/2100-1012-990880.html
Collaborating on Project Success, Standish Group, http://www.softwaremag.com/archive/2001feb/CollaborativeMgt.html, Immature Software Acquisition Processes Increase FAA System Acquisition Riskshttp://ntl.bts.gov/lib/000/200/234/ai97047.pdf
We do, however, see advertising by various entities connected to Open Source. This generally concerns hardware or services, rather than the software. In some cases the Open Source teams make use of low or no-cost advertising venues such as web banner advertising to draw new users to their products and thus expand their development communities. A recent ad in The New York Times for Mozilla Firefox is notable as it is motivated by the political goal of maintaining the open-ness of the web and reducing dominance by Microsoft over the browser. The advertising was funded by charitable contributions from parties that in general have no pecuniary interest in Firefox.
http://www.infonomics.nl/FLOSS/report/
Studies by Stanford and CMU researchers show that the Linux 2.6 kernel has 0.17 bugs per 1000 lines of code while non-Open-Source commercial software generally scores 20-30 bugs per 1000 lines. The studies are reported in Wired magazine athttp://www.wired.com/news/linux/0,1411,66022,00.html, I do not presently have a reference to the actual studies.
The replicator is a fictional device that manufactures many different physical objects on demand, presumably from designs stored on a computer. In the Star Trek: The Next Generation television series, a character walked up to the device and gave it a voice command: tea, earl gray, hot. A cup and the tea were manufactured instantly.
The Linux Standard Base was meant to make it possible for proprietary application vendors to support all standard-compliant Linux distributions. It has not been commercially effective at this so far.
Analysis of pro-bono counsel, Free Software Foundation, in private communication.
http://www.catb.org/~esr/writings/cathedral-bazaar/ Raymond followed The Cathedral and the Bazaar with two additional papers, Homesteading the Noosphere (1998) and The Magic Cauldron (1999), which continue his discussion of the economics of Open Source. They can be found at the same link. His last revision to The Magic Cauldron appeared in 2002.
The GNU project was announced in September 1983, seehttp://www.gnu.org/gnu/initial-announcement.html, although the project didn't actually start until January 1984, and it was not until sometime later that the Free Software Foundation was formed around it. Seehttp://www.gnu.org/gnu/gnu-history.html for an overview of the GNU project.
There was also the fact that the GNU project had developed and integrated a lot of software, but had not been able to produce its own operating system kernel. This left the door open for Linus Torvalds to do the last part of the project. Generally an operating system is referred to by the name of its kernel, dispite the fact that it contains many components other than the kernel. This caused an injustice to Stallman that persists today. Although Stallman did a great deal of the work that made Linux possible, Torvalds' team of kernel contributors was not closely allied with Stallman, and announcements of Linux were not attributed to FSF.
Linux is in truth only the kernel. The rest of what comes in a Linux distribution is what Stallman intended to be the GNU System, and Stallman should be credited with its concept, with directly developing the C compiler (surely as important as the kernel) and the Emacs editor, and with inspiring the development of much of the rest of the system.
There is a cost-of-participation for retail software as well. Part of that is discussed here as the shelfware problem. The after-purchase cost is not discussed, but includes such things as the cost of documenting problems to the vendor (often an all-day task for a programmer) and going through service escalation procedures with the vendor's service staff until those problems get attention.
The Emerging Economic Paradigm of Open Source
The Emerging Economic Paradigm of Open Source
Strategy Letter V - The Economics of Open Source
Open Source is Coming of Age
Open Source is Coming of Age
The OSSwin project: Open Source for Windows!
Open Source Projects - The Neuros Technology ...
OpenTravelSystem, the open source system for ...
Innovate Out of the Economic Downturn - Busin...
The Knowledge Building Paradigm: A Model of Learning for Net Generation Students
The Knowledge Building Paradigm: A Model of Learning for Net Generation Students
ReportLab - Open Source Software
Open Source Email Marketing
Statistical Communique on the 2002 National Economic and Social Development of the City of Beijing
Statistical Communique on the 2002 National Economic and Social Development of the City of Beijingpp
The Savvy Technologist Blog Archiv Open source tools you can use
The Open University of Hong Kong: 教育科技與資訊科技
Jorge Majfud, “Eduardo Galeano: The Open Eyes of Latin America
Eduardo Galeano: The Open Eyes of Latin America
The axis of oil: China and Venezuela | open D...
Get source ?(Android Open Source Project?)
The Search for the Source of Data - How SimpleDB Differs from a RDBMS | High Scalability
Open source functional testing tools
OSCON: Open Source Awards 2007