The Economic Case for Open Source Foundations

Dirk Riehle
Pro­fes­sor for Open Source Soft­ware
Friedrich-Alexander-University of Erlangen-Nürnberg

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


An open source foun­da­tion is a group of peo­ple and com­pa­nies that has come togeth­er to joint­ly devel­op com­mu­ni­ty 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­nom­ic 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­ev­er, 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­tive­ly across tech­nol­o­gy stacks and there­by increase their address­able mar­ket. Not to be neglect­ed, com­mu­ni­ty open source soft­ware is a com­mon good, cre­at­ing increased gen­er­al 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­tion­al Respon­si­bil­i­ties
3. Intel­lec­tu­al Prop­er­ty Mech­a­nisms
4. Shar­ing Devel­op­ment Expens­es
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 Lin­ux 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 start­ed out as vol­un­teer projects with­out any com­mer­cial back­ing. When the indus­tri­al sig­nif­i­cance of the­se projects became appar­ent dur­ing the 1990s, inter­est­ed soft­ware devel­op­ers and firms decid­ed to put the future of the soft­ware on more solid ground by cre­at­ing non­prof­it orga­ni­za­tions.

Such an orga­ni­za­tion, com­mon­ly called a foun­da­tion, serves as the stew­ard of the projects under its respon­si­bil­i­ty. It pro­vides finan­cial back­ing and legal cer­tain­ty, mak­ing the sur­vival of the soft­ware less depen­dent on the indi­vid­u­als who ini­tial­ly start­ed 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­ni­ty of devel­op­ers, which is also why the soft­ware is called com­mu­ni­ty open source [1] [2].

Com­mu­ni­ty open source is dif­fer­ent from single-vendor open source, which is open source soft­ware that is being devel­oped by a sin­gle firm. Firms behind single-vendor 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­cal­ly not the case with com­mu­nal­ly owned open source, as com­pe­ti­tion is like­ly to keep rev­enues down.

How­ev­er, there are sev­er­al eco­nom­ic rea­sons why soft­ware firms join and sup­port foun­da­tions to devel­op com­mu­ni­ty open source: Some mem­bers expect cost sav­ings for prod­ucts built on the com­mu­ni­ty 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­ni­ty;
  • active­ly mar­ket the soft­ware;
  • clar­i­fy and man­age intel­lec­tu­al prop­er­ty 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 process­es.

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

3. Intellectual Property Mechanisms

Some eschew open source out of fear of a loss of intel­lec­tu­al prop­er­ty. Open source foun­da­tions solve this prob­lem by pro­vid­ing clear and well-defined process­es that clar­i­fy any intel­lec­tu­al prop­er­ty rights issues asso­ci­at­ed with the soft­ware. In the end, the open source project becomes just like every oth­er soft­ware and is pro­vid­ed 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­tu­al prop­er­ty rights must be con­sid­ered:

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

The con­trib­u­tors to the project provide the rel­e­vant intel­lec­tu­al prop­er­ty. 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 enti­ty that wish­es 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 relat­ed texts. Thus, the con­trib­u­tor agree­ment is set up so that the con­trib­u­tor, be it a com­pa­ny 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 weak­er form, some­times only a reli­cens­ing right is required.)

Using this mech­a­nism, the foun­da­tion becomes the sole own­er of the copy­right. It is impor­tant that there be only a sin­gle own­er: Deci­sion mak­ing is with the foun­da­tion rather than a dis­trib­ut­ed 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­er­al license to allow for the widest vari­ety of use cir­cum­stances of the soft­ware by its mem­bers. Such a lib­er­al license typ­i­cal­ly allows embed­ding the soft­ware in oth­er soft­ware pack­ages with­out requir­ing the open sourcing of the­se oth­er pack­ages.

An impor­tant prac­tice of a foun­da­tion is to ensure that no source code is con­tribut­ed from anoth­er 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­ral­ly, the foun­da­tion also becomes the own­er 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.

Final­ly, 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­ment­ed by the soft­ware. This can become par­tic­u­lar­ly nasty if roy­al­ty 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­cal­ly requires con­trib­u­tors to provide a gen­er­al (per­pet­u­al, unre­strict­ed, royalty-free) usage grant of the patent to all users of the open source soft­ware. This pro­tects users from unan­tic­i­pat­ed patent roy­al­ty requests.

4. Sharing Development Expenses

There are many eco­nom­ic rea­sons to start, join, or sup­port an open source foun­da­tion. The orig­i­nal and still most wide­ly 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 expens­es.

Con­sid­er the sit­u­a­tion of Unix and Lin­ux desk­tops in the late 1990s: Sev­er­al com­pet­ing win­dow­ing sys­tems exist­ed, each with incom­pat­i­ble desk­top appli­ca­tions, and all of them con­fig­ured and deployed dif­fer­ent­ly, depend­ing on the Unix or Lin­ux 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 Lin­ux 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 decid­ed 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­mal­ly sup­port­ed by the GNOME foun­da­tion and the KDE e.V., respec­tive­ly. The­se two foun­da­tions remain vol­un­teer efforts, how­ev­er, 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­ni­ty 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 devel­op the open source soft­ware fur­ther. Cur­rent­ly, 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­nom­ic) advan­tage.

The ini­tial thrust behind com­pa­ny con­tri­bu­tions to Lin­ux 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­pa­ny is sell­ing a busi­ness appli­ca­tion that also needs an oper­at­ing sys­tem to run, more mon­ey will be avail­able for the busi­ness appli­ca­tion ven­dor if no mon­ey 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 mon­ey, while for the busi­ness appli­ca­tion ven­dor more mon­ey becomes avail­able, at the expense of the closed source oper­at­ing sys­tem ven­dor, who miss­es a sale. Fig­ure 1 illus­trates this eco­nom­ic sit­u­a­tion.

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

An ear­ly exam­ple of this mech­a­nism is IBM’s sup­port of Lin­ux. Real­iz­ing that OS/2, IBM’s then-competitor to Microsoft’s Win­dows, was los­ing in the mar­ket­place, IBM threw its weight behind Lin­ux and relat­ed 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­er­al terms, replac­ing a high-cost closed source com­po­nent of the tech­nol­o­gy stack with a lower-priced open source com­po­nent increas­es pric­ing flex­i­bil­i­ty for the ven­dors of the oth­er com­po­nents in the stack. It also reduces costs for cus­tomers and makes more mon­ey avail­able for oth­er pur­chas­es.

6. Increased Sales in a Given Market

A sec­ond con­se­quence of the increased pric­ing flex­i­bil­i­ty is that a soft­ware devel­op­er can sell to more cus­tomers than before. Some cus­tomers are more price-sensitive 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-transparent mar­ket), the devel­op­er 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.

High­er 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­cal­ly, 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­cat­ed, an open source plat­form is eco­nom­i­cal­ly 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 oth­er ven­dors to do the same. More and bet­ter appli­ca­tions will grow the val­ue 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 mon­ey 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­chas­es anew in accor­dance with what’s avail­able and how big their IT bud­get is. This dynam­ic is par­tic­u­lar­ly attrac­tive to the providers of mission-critical appli­ca­tions, which typ­i­cal­ly get high­er pur­chas­ing pri­or­i­ty than less impor­tant, more incre­men­tal appli­ca­tions.

Fig­ure 3. Grow­ing an open source plat­form increas­es 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­i­ty of the firm to poten­tial cus­tomers and promis­es high tech­ni­cal qual­i­ty of its soft­ware prod­ucts. Gain­ing a strong posi­tion in the foun­da­tion and devel­op­ment process­es of the soft­ware cre­ates a sig­nif­i­cant posi­tion­al advan­tage over lat­er com­peti­tors.

There are more plat­forms or lay­ers in the tech­nol­o­gy 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 bus­es or elec­tron­ic patient records, we can expect a wealth of new domain-specific open source plat­forms to appear in the com­ing years.

A firm should con­sid­er cre­at­ing com­mu­ni­ty open source and sup­port­ing an open source foun­da­tion if it is not only com­pet­ing with­in the same stack, but across stacks. Lin­ux, the Apache projects, and the Eclipse plat­form can all be viewed as soft­ware plat­forms on which revenue-generating appli­ca­tions are built. The­se plat­forms com­pete with closed source alter­na­tives, for exam­ple, the Microsoft set of plat­forms, name­ly Win­dows, ASP.NET, and Visu­al Stu­dio.

A reli­able plat­form attracts oth­er soft­ware ven­dors that might base their own prod­ucts, whether pro­vid­ed as open source or not, on this plat­form. The increas­ing rich­ness of func­tion­al­i­ty 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-supported plat­form to a firm’s own plat­form increas­es the size of the address­able mar­ket, which is like­ly 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 high­er num­ber of sales, and a larg­er 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­nom­ic mod­els and deci­sion process­es to answer the­se ques­tions.

The open source research group at the Friedrich-Alexander-University of Erlangen-Nürnberg and its col­lab­o­ra­tors are work­ing on this ques­tion. In addi­tion, we are look­ing at the process­es and tools used by open source foun­da­tions and in open source soft­ware devel­op­ment in gen­er­al.

In col­lab­o­ra­tion with the Open Source Busi­ness Foun­da­tion, an inter­na­tion­al non­prof­it orga­ni­za­tion locat­ed in Nurem­berg, Ger­many, we are mak­ing our research find­ings avail­able to indus­try. Final­ly, we are inter­est­ed in sup­port­ing pub­lic pol­i­cy deci­sions with eco­nom­ic and tech­ni­cal insight to help increase gen­er­al wel­fare through high-quality com­mu­ni­ty open source.


[1] D. Riehle, “The Eco­nom­ic Moti­va­tion of Open Source: Stake­hold­er Per­spec­tives,” Com­put­er, Apr. 2007, pp. 25–32.

[2] E. Capra and A. Wasser­man, “A Frame­work for Eval­u­at­ing Man­age­ri­al 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 Mod­el,” Proc. 15th Amer­i­c­as Conf. Infor­ma­tion Sys­tems (AMCIS 2009), AIS Elec­tron­ic 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 devel­op for an Open Source project for a web-based Church Man­age­ment Sys­tem called 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.

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

Leave a Reply