The Economic Case for Open Source Foundations

Dirk Riehle
Pro­fes­sor for Open Source Soft­ware
Friedrich-Alexan­der-Uni­ver­sity of Erlan­gen-Nürn­berg

Citable ref­er­ence (includ­ing PDF file)

Abstract

An open source foun­da­tion is a group of peo­ple and com­pa­nies that has come together to jointly develop com­mu­nity open source soft­ware. Exam­ples include the Apache Soft­ware Foun­da­tion, the Eclipse Foun­da­tion, and the Gnome Foun­da­tion.

There are many rea­sons why soft­ware devel­op­ment firms join and sup­port a foun­da­tion. One com­mon eco­nomic moti­va­tion is to save costs in the devel­op­ment of the soft­ware by spread­ing them over the par­tic­i­pat­ing par­ties. How­ever, this is just the begin­ning. Beyond shar­ing costs, par­tic­i­pat­ing firms can increase their rev­enue through the pro­vi­sion and increased sale of com­ple­men­tary prod­ucts. Also, by estab­lish­ing a suc­cess­ful open source plat­form, soft­ware firms can com­pete more effec­tively across tech­nol­ogy stacks and thereby increase their address­able mar­ket. Not to be neglected, com­mu­nity open source soft­ware is a com­mon good, cre­at­ing increased gen­eral wel­fare and hence good­will for the involved com­pa­nies.

Table of Contents

1. Open Source Foun­da­tions
2. Orga­ni­za­tional Respon­si­bil­i­ties
3. Intel­lec­tual Prop­erty Mech­a­nisms
4. Shar­ing Devel­op­ment Expenses
5. Prof­its per Sale in a Given Mar­ket
6. Increased Sales in a Given Mar­ket
7. Grow­ing the Address­able Mar­ket
8. Con­clu­sions

1. Open Source Foundations

The Linux oper­at­ing sys­tem and the Apache web­server are pop­u­lar exam­ples of open source projects that are in wide­spread indus­try use. They started out as vol­un­teer projects with­out any com­mer­cial back­ing. When the indus­trial sig­nif­i­cance of these projects became appar­ent dur­ing the 1990s, inter­ested soft­ware devel­op­ers and firms decided to put the future of the soft­ware on more solid ground by cre­at­ing non­profit orga­ni­za­tions.

Such an orga­ni­za­tion, com­monly called a foun­da­tion, serves as the stew­ard of the projects under its respon­si­bil­ity. It pro­vides finan­cial back­ing and legal cer­tainty, mak­ing the sur­vival of the soft­ware less depen­dent on the indi­vid­u­als who ini­tially started it. There are many vari­ants of foun­da­tions like trade asso­ci­a­tions and con­sor­tia. Each of them has its own match­ing legal struc­ture, depend­ing on the speci­fic goals of the founders. This arti­cle uses the term foun­da­tion to denote all of them.

The foun­da­tion rep­re­sents the com­mu­nity of devel­op­ers, which is also why the soft­ware is called com­mu­nity open source [1] [2].

Com­mu­nity open source is dif­fer­ent from sin­gle-ven­dor open source, which is open source soft­ware that is being devel­oped by a sin­gle firm. Firms behind sin­gle-ven­dor com­mer­cial open source expect direct rev­enue from sell­ing the soft­ware and ser­vices for it [3]. This is typ­i­cally not the case with com­mu­nally owned open source, as com­pe­ti­tion is likely to keep rev­enues down.

How­ever, there are sev­eral eco­nomic rea­sons why soft­ware firms join and sup­port foun­da­tions to develop com­mu­nity open source: Some mem­bers expect cost sav­ings for prod­ucts built on the com­mu­nity open source soft­ware, oth­ers expect increased rev­enue and sales from com­ple­men­tary prod­ucts, and yet oth­ers want to grow their address­able mar­ket.

2. Organizational Responsibilities

The main pur­pose of a foun­da­tion is to act as the stew­ard of the soft­ware being devel­oped and to ensure its long-term sur­vival. A foun­da­tion has var­i­ous respon­si­bil­i­ties, includ­ing the fol­low­ing:

  • orga­nize the project com­mu­nity;
  • actively mar­ket the soft­ware;
  • clar­ify and man­age intel­lec­tual prop­erty rights;
  • set strate­gic direc­tions for the soft­ware;
  • respond and remain account­able to its mem­bers; and
  • run all rel­e­vant back-office processes.

Open source foun­da­tions are usu­ally open to every­one to join; how­ever, a mem­ber­ship fee may apply. Many of their processes are sim­i­lar to those of tra­di­tional soft­ware asso­ci­a­tions and will not come as a sur­prise. What is dif­fer­ent, how­ever, is the pro­vi­sion of the main pro­duct as open source and the result­ing intel­lec­tual prop­erty impli­ca­tions.

3. Intellectual Property Mechanisms

Some eschew open source out of fear of a loss of intel­lec­tual prop­erty. Open source foun­da­tions solve this prob­lem by pro­vid­ing clear and well-defined processes that clar­ify any intel­lec­tual prop­erty rights issues asso­ci­ated with the soft­ware. In the end, the open source project becomes just like every other soft­ware and is pro­vided under an open source license that spells out its usage con­di­tions.

In soft­ware devel­op­ment, three main cat­e­gories of intel­lec­tual prop­erty rights must be con­sid­ered:

  • copy­right (to the source code and related texts);
  • trade­marks; and
  • patents.

The con­trib­u­tors to the project provide the rel­e­vant intel­lec­tual prop­erty. Most foun­da­tions define the rela­tion­ship between a con­trib­u­tor and the project using a so-called con­trib­u­tor agree­ment. Any legal entity that wishes to con­tribute to the project, whether a mem­ber of the foun­da­tion or not, must sign this agree­ment.

A com­mon prac­tice of open source foun­da­tions is to own the copy­right to all source code and related texts. Thus, the con­trib­u­tor agree­ment is set up so that the con­trib­u­tor, be it a com­pany like IBM or a vol­un­teer pro­gram­mer, signs over the copy­right of any cur­rent or future con­tri­bu­tions to the foun­da­tion. (In a weaker form, some­times only a reli­cens­ing right is required.)

Using this mech­a­nism, the foun­da­tion becomes the sole owner of the copy­right. It is impor­tant that there be only a sin­gle owner: Deci­sion mak­ing is with the foun­da­tion rather than a dis­trib­uted group of diverse copy­right hold­ers. The foun­da­tion can now define and enforce the license terms under which the project is made avail­able to the pub­lic and can defend the soft­ware in court.

The choice of the license depends on the foundation’s goals. Most foun­da­tions choose a lib­eral license to allow for the widest vari­ety of use cir­cum­stances of the soft­ware by its mem­bers. Such a lib­eral license typ­i­cally allows embed­ding the soft­ware in other soft­ware pack­ages with­out requir­ing the open sourcing of these other pack­ages.

An impor­tant prac­tice of a foun­da­tion is to ensure that no source code is con­tributed from another open source project with an incom­pat­i­ble license. The speci­fic fear is that the con­tri­bu­tion of incom­pat­i­ble code would require an unde­sired change of license, as might hap­pen, for exam­ple, with the con­tri­bu­tion of GPL-licensed code to Apache-licensed code. The GPL license is the orig­i­nal rec­i­p­ro­cal (“viral”) open source license that requires all derived code to have the same license as well. “Keep­ing the code clean” is a prime direc­tive at many foun­da­tions.

Nat­u­rally, the foun­da­tion also becomes the owner of the soft­ware trade­marks and acts to enforce them. Thus, the foun­da­tion becomes the trustee of both the source code and its trade­marks.

Finally, the con­trib­u­tor agree­ment clar­i­fies the use of soft­ware patents. Source code imple­ments soft­ware patents. Even if the foun­da­tion owns the copy­right to the source code, with­out fur­ther mea­sures, users of the soft­ware may still have to pay roy­alties to the hold­ers of the patents imple­mented by the soft­ware. This can become par­tic­u­larly nasty if roy­alty requests sur­face only after the soft­ware has been put to use in a user orga­ni­za­tion. For this rea­son, the con­trib­u­tor agree­ment typ­i­cally requires con­trib­u­tors to provide a gen­eral (per­pet­ual, unre­stricted, roy­alty-free) usage grant of the patent to all users of the open source soft­ware. This pro­tects users from unan­tic­i­pated patent roy­alty requests.

4. Sharing Development Expenses

There are many eco­nomic rea­sons to start, join, or sup­port an open source foun­da­tion. The orig­i­nal and still most widely known rea­son is cost sav­ings real­ized by stan­dard­iz­ing on one plat­form and shar­ing its devel­op­ment expenses.

Con­sider the sit­u­a­tion of Unix and Linux desk­tops in the late 1990s: Sev­eral com­pet­ing win­dow­ing sys­tems existed, each with incom­pat­i­ble desk­top appli­ca­tions, and all of them con­fig­ured and deployed dif­fer­ently, depend­ing on the Unix or Linux dis­tri­b­u­tion they came with. By then, Unix had lost the com­pe­ti­tion for the users’ desk­top to Microsoft Win­dows. Graph­i­cal user inter­faces for Linux were a pure cost posi­tion for the dis­trib­u­tors.

In this sit­u­a­tion, any good-enough desk­top soft­ware would do for the involved soft­ware firms. Dis­trib­u­tors like Red Hat and SUSE (Nov­ell) as well as IBM and HP decided not to com­pete on the mer­its of their desk­top con­fig­u­ra­tion but rather to sup­port a com­mon desk­top envi­ron­ment. This led to the con­tin­ued devel­op­ment and con­sol­i­da­tion of the GNOME and KDE desk­top envi­ron­ments, for­mally sup­ported by the GNOME foun­da­tion and the KDE e.V., respec­tively. These two foun­da­tions remain vol­un­teer efforts, how­ever, with strong cor­po­rate sup­port.

It is not always the soft­ware firms that start or grow a soft­ware foun­da­tion. Cost sav­ings through com­mu­nity open source can have mul­ti­ple roots. Some­times, cus­tomers join forces to cre­ate a foun­da­tion and require that any soft­ware devel­op­ment work by a con­trac­tor uti­lize and develop the open source soft­ware fur­ther. Cur­rently, the US health­care indus­try is under­tak­ing steps in this direc­tion.

5. Profits per Sale in a Given Market

Beyond cost sav­ings in research and devel­op­ment and in user orga­ni­za­tions, orig­i­nal soft­ware devel­op­ment firms can use open source foun­da­tions to their com­pet­i­tive (eco­nomic) advan­tage.

The ini­tial thrust behind com­pany con­tri­bu­tions to Linux and the Apache Soft­ware Foun­da­tion projects focused on sup­port­ing an alter­na­tive to more expen­sive closed source solu­tions. If, for exam­ple, a com­pany is sell­ing a busi­ness appli­ca­tion that also needs an oper­at­ing sys­tem to run, more money will be avail­able for the busi­ness appli­ca­tion ven­dor if no money is spent on the oper­at­ing sys­tem license and less on its main­te­nance fees. Hence, for the cus­tomer, an open source alter­na­tive saves money, while for the busi­ness appli­ca­tion ven­dor more money becomes avail­able, at the expense of the closed source oper­at­ing sys­tem ven­dor, who misses a sale. Fig­ure 1 illus­trates this eco­nomic sit­u­a­tion.

Fig­ure 1. The sup­port of open source soft­ware lets ven­dors sell at a higher price.

An early exam­ple of this mech­a­nism is IBM’s sup­port of Linux. Real­iz­ing that OS/2, IBM’s then-com­peti­tor to Microsoft’s Win­dows, was los­ing in the mar­ket­place, IBM threw its weight behind Linux and related open source projects. Hav­ing an alter­na­tive to Win­dows meant that IBM could keep Microsoft’s license fees in check when sell­ing to cus­tomers.

In gen­eral terms, replac­ing a high-cost closed source com­po­nent of the tech­nol­ogy stack with a lower-priced open source com­po­nent increases pric­ing flex­i­bil­ity for the ven­dors of the other com­po­nents in the stack. It also reduces costs for cus­tomers and makes more money avail­able for other pur­chases.

6. Increased Sales in a Given Market

A sec­ond con­se­quence of the increased pric­ing flex­i­bil­ity is that a soft­ware devel­oper can sell to more cus­tomers than before. Some cus­tomers are more price-sen­si­tive than oth­ers. Fig­ure 2 illus­trates this as the cus­tomer demand curve. Going down the demand curve from left to right, the price for the busi­ness appli­ca­tion plus oper­at­ing sys­tem bundle goes down, and more cus­tomers are will­ing to buy. In sim­pli­fied terms (a non-trans­par­ent mar­ket), the devel­oper stops sell­ing only if the price has come down to its own total cost. Thus, replac­ing the more expen­sive closed source oper­at­ing sys­tem with a lower-cost open source alter­na­tive reduces the low­est pos­si­ble price point for the bundle. This lets a ven­dor sell to more cus­tomers, which leads to more prof­its.

Fig­ure 2. The sup­port of open source soft­ware lets soft­ware firms sell to more cus­tomers.

Higher prof­its on a given sale and more prof­its by sell­ing to more cus­tomers are two impor­tant rea­sons why a soft­ware firm may sup­port open source soft­ware that is com­ple­men­tary to its own pro­duct line. From the firm’s per­spec­tive, sup­port­ing the open source soft­ware is a sub­sidy, paid out of increased prof­its from its own pro­duct. Basi­cally, the open source alter­na­tive lets the firm shift rev­enues from a com­ple­men­tary pro­duct, owned by some­one else, to its own pro­duct.

7. Growing the Addressable Market

The size of the mar­ket a soft­ware firm can sell into depends on the plat­forms on which it is based. If a ven­dor builds on a plat­form that cus­tomers aren’t will­ing to oper­ate, the firm’s prod­ucts will not be con­sid­ered. Thus, the choice of the plat­forms a firm’s pro­duct runs on is cru­cial. As indi­cated, an open source plat­form is eco­nom­i­cally more ben­e­fi­cial than a closed source plat­form. Thus, the soft­ware devel­op­ment firm should sup­port an appro­pri­ate plat­form and encour­age other ven­dors to do the same. More and bet­ter appli­ca­tions will grow the value of the plat­form to cus­tomers. With grow­ing accep­tance of the plat­form, more cus­tomers will be oper­at­ing it, first increas­ing the total size of the mar­ket and then the size of the mar­ket that the soft­ware firm’s prod­ucts can address.

Fig­ure 3 illus­trates the dynam­ics of shrink­ing a closed source plat­form to the advan­tage of an open source plat­form. The money leav­ing the mar­ket around the closed source plat­form enters the mar­ket for prod­ucts built on top of the open source plat­form. As cus­tomers review the choice of prod­ucts avail­able, they pri­or­i­tize pur­chases anew in accor­dance with what’s avail­able and how big their IT bud­get is. This dynamic is par­tic­u­larly attrac­tive to the providers of mis­sion-crit­i­cal appli­ca­tions, which typ­i­cally get higher pur­chas­ing pri­or­ity than less impor­tant, more incre­men­tal appli­ca­tions.

Fig­ure 3. Grow­ing an open source plat­form increases the total mar­ket size.

Par­tic­i­pat­ing in the devel­op­ment of the open source plat­form is of strate­gic inter­est to a soft­ware firm. It ensures vis­i­bil­ity of the firm to poten­tial cus­tomers and promises high tech­ni­cal qual­ity of its soft­ware prod­ucts. Gain­ing a strong posi­tion in the foun­da­tion and devel­op­ment processes of the soft­ware cre­ates a sig­nif­i­cant posi­tional advan­tage over later com­peti­tors.

There are more plat­forms or lay­ers in the tech­nol­ogy stack than some might think. The obvi­ous plat­forms are oper­at­ing sys­tems and mid­dle­ware solu­tions. Beyond this, many more poten­tial plat­forms exist, address­ing indus­try ver­ti­cals as much as hor­i­zon­tal slices of the stack. Whether it is plat­forms for busi­ness account­ing or med­ical imag­ing, auto­mo­tive soft­ware buses or elec­tronic patient records, we can expect a wealth of new domain-speci­fic open source plat­forms to appear in the com­ing years.

A firm should con­sider cre­at­ing com­mu­nity open source and sup­port­ing an open source foun­da­tion if it is not only com­pet­ing within the same stack, but across stacks. Linux, the Apache projects, and the Eclipse plat­form can all be viewed as soft­ware plat­forms on which rev­enue-gen­er­at­ing appli­ca­tions are built. These plat­forms com­pete with closed source alter­na­tives, for exam­ple, the Microsoft set of plat­forms, namely Win­dows, ASP.NET, and Visual Stu­dio.

A reli­able plat­form attracts other soft­ware ven­dors that might base their own prod­ucts, whether pro­vided as open source or not, on this plat­form. The increas­ing rich­ness of func­tion­al­ity around a given plat­form ben­e­fits every­one: Cus­tomers can­not go wrong in decid­ing for this plat­form. Mov­ing cus­tomers from a not-sup­ported plat­form to a firm’s own plat­form increases the size of the address­able mar­ket, which is likely to lead to more sales.

8. Conclusions

Every soft­ware devel­op­ment firm today should ask which open source foun­da­tion to sup­port or, if nec­es­sary, to found. The ben­e­fits are clear: Done right, the firm can expect cost sav­ings, increased prof­its per sale, a higher num­ber of sales, and a larger address­able mar­ket. The ques­tion then becomes one of invest­ment: How much to invest and what return to expect. At present, we lack eco­nomic mod­els and deci­sion processes to answer these ques­tions.

The open source research group at the Friedrich-Alexan­der-Uni­ver­sity of Erlan­gen-Nürn­berg and its col­lab­o­ra­tors are work­ing on this ques­tion. In addi­tion, we are look­ing at the processes and tools used by open source foun­da­tions and in open source soft­ware devel­op­ment in gen­eral.

In col­lab­o­ra­tion with the Open Source Busi­ness Foun­da­tion, an inter­na­tional non­profit orga­ni­za­tion located in Nurem­berg, Ger­many, we are mak­ing our research find­ings avail­able to indus­try. Finally, we are inter­ested in sup­port­ing pub­lic pol­icy deci­sions with eco­nomic and tech­ni­cal insight to help increase gen­eral wel­fare through high-qual­ity com­mu­nity open source.

References

[1] D. Riehle, “The Eco­nomic Moti­va­tion of Open Source: Stake­holder Per­spec­tives,” Com­puter, Apr. 2007, pp. 25–32.

[2] E. Capra and A. Wasser­man, “A Frame­work for Eval­u­at­ing Man­age­rial Styles in Open Source Projects,” Proc. 4th Int’l Conf. Open Source Sys­tems (OSS 2008), Springer, 2008, pp. 1–14.

[3] D. Riehle, “The Com­mer­cial Open Source Busi­ness Model,” Proc. 15th Amer­i­cas Conf. Infor­ma­tion Sys­tems (AMCIS 2009), AIS Elec­tronic Library, 2009.

10 thoughts on “The Economic Case for Open Source Foundations

  1. Pingback: uberVU - social comments

  2. Pingback: 451 CAOS Theory » Don’t fear the reaper. Why FOSS should not fear M&A by proprietary vendors

  3. Pingback: Links 10/1/2010: Wipro Embraces Mobile Linux | Boycott Novell

  4. Pingback: Open Source Research Opinion: Industry Decision Models

  5. Pingback: Twisting the bytes » A business model for Creative Commons

  6. Pingback: Open Source Business Research at OWF 2010

  7. Pingback: Why I Left Rackspace and What About Openstack « Deprecation

  8. David Carroll

    I develop for an Open Source project for a web-based Church Man­age­ment Sys­tem called BVCMS.com. This arti­cle is very help­ful for us as we think about how to pro­mote and sup­port the project long term. Thank you for this excel­lent research.

    Reply
  9. Pingback: Best of OSR Group 2011 and Before « Open Source Research Group

Leave a Reply