Control Points and Steering Mechanisms in Open Source Software Projects

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

Most com­mer­cial soft­ware today depends on open source soft­ware. The com­mer­cial soft­ware might be using an under­ly­ing open source plat­form, or it might be incor­po­rat­ing open source com­po­nents, or it might be pro­vided as a com­mer­cial open source pro­duct itself. Whichever the case, the soft­ware firm behind the com­mer­cial soft­ware needs to ensure that its inter­ests are met by the open source soft­ware projects it depends on. This arti­cle shows how com­mer­cial soft­ware firms man­age or steer open source soft­ware projects to meet their busi­ness needs.

1. Introduction

Open source soft­ware has become an impor­tant part of the soft­ware busi­ness. In a large 2009 sur­vey, For­rester Research found that 46% of all respond­ing enter­prises were using or imple­ment­ing open source soft­ware [3]. More­over, in 2009 Gart­ner Group esti­mated that by 2012, at least 80% of all soft­ware pro­duct firms will use open source soft­ware in their prod­ucts [2].

With open source soft­ware being an impor­tant part of closed source soft­ware prod­ucts in addi­tion to being its own pro­duct cat­e­gory, it is impor­tant to under­stand how soft­ware pro­duct firms depend on open source and how they man­age that depen­dency to meet their busi­ness goals.

In this arti­cle, we clas­sify soft­ware pro­duct firms into three main cat­e­gories: Tra­di­tional closed source firms, single-vendor open source firms, and open source dis­trib­u­tors.

  • Closed source firms are soft­ware firms that own all com­pet­i­tively dif­fer­en­ti­at­ing soft­ware com­po­nents their pro­duct is based on; these com­po­nents are all closed source. Pro­duct exam­ples are Microsoft’s Win­dows, Oracle’s same-name data­base, and SAP’s Busi­ness Suite.
  • Single-vendor open source firms also own all com­pet­i­tively dif­fer­en­ti­at­ing com­po­nents, but they make some or all of these avail­able as open source [6]. Pro­duct exam­ples are Alfresco’s same-name pro­duct, Jaspersoft’s BI tool suite, and (for­merly) MySQL’s same-name data­base.
  • Open source dis­trib­u­tors are firms that inte­grate a large set of open source com­po­nents and dis­trib­ute the assem­bly for a fee. Dis­trib­u­tors typ­i­cally don’t own their com­po­nents. Pro­duct exam­ples are Suse’s Linux, Red Hat’s Linux, and Acquia’s Dru­pal.

What is com­mon to these three types of firms is that in some form they exclu­sively own some intel­lec­tual prop­erty they cap­i­tal­ize on. In the case of closed source and single-vendor open source firms, it is the soft­ware itself, in the case of dis­trib­u­tors it is the branded con­fig­u­ra­tion. Thus, in this arti­cle we are not talk­ing about pure ser­vices firms sell­ing con­sult­ing or main­te­nance ser­vices. Also, our analy­sis is inde­pen­dent of the soft­ware deliv­ery model, be it on-premise or hosted (soft­ware as a ser­vice).

It is impor­tant to under­stand that while open source may be freely avail­able under an open source license, open source soft­ware nev­er­the­less has an owner. There are two main forms of own­er­ship:

  • Single-vendor open source soft­ware. This type of soft­ware has a sin­gle legal copy­right owner, typ­i­cally a soft­ware firm, that aggres­sively main­tains its own­er­ship rights [6].
  • Com­mu­nity open source soft­ware. This type of soft­ware either has a dif­fuse set of own­ers (the code con­trib­u­tors) or is owned by a foun­da­tion, act­ing on behalf of its mem­bers [1] [8].

More­over, it is impor­tant to under­stand the two main cat­e­gories of open source soft­ware licenses. For the pur­poses of this paper, we sim­plify these cat­e­gories to rec­i­p­ro­cal (“viral”) and per­mis­sive licenses:

  • The use of an open source soft­ware com­po­nent under an rec­i­p­ro­cal license may require a firm to open source its pro­duct source code. Exam­ples licenses are the GPL and AGPL licenses.
  • The use of an open source soft­ware com­po­nent under a per­mis­sive license does not require such open sourcing. Exam­ple licenses are the Apache and BSD licenses.

How then does any of the three types of soft­ware firms depend on any of the two types of open source projects and what are their busi­ness goals for employ­ing open source?

2. Software Products and Open Source

Any real-world soft­ware pro­duct is made from mul­ti­ple soft­ware com­po­nents, all of which may have dif­fer­ent licenses and hence come with dif­fer­ent usage con­di­tions. Fig­ure 1 iden­ti­fies the dif­fer­ent types of com­po­nents one might find in a soft­ware pro­duct.

Fig­ure 1: All com­po­nent types one might find in a soft­ware pro­duct

The pro­duct illus­trated in Fig­ure 1 has a closed source and an open source part. In the closed source part, we find owned and licensed closed source:

  • Owned closed source are soft­ware com­po­nents that the firm owns and uses it in its prod­ucts. Ide­ally, they help to dif­fer­en­ti­ate the pro­duct from its com­peti­tors.
  • Licensed closed source are soft­ware com­po­nents that the firm licenses from other soft­ware firms in order to com­plete their pro­duct.

A closed source soft­ware firm, by def­i­n­i­tion, builds its prod­ucts this way. A single-vendor open source firm may have closed source com­po­nents in its prod­ucts if it dis­tin­guishes a com­mer­cial ver­sion of its prod­ucts from an open source com­mu­nity ver­sion through fea­ture dif­fer­en­ti­a­tion (so-called open core model). Open source dis­trib­u­tors typ­i­cally don’t have closed source com­po­nents in their offer­ing.

In the open source part of the com­po­nent stack in Fig­ure 1 we dis­tin­guish single-vendor open source from com­mu­nity open source:

  • Single-vendor open source are soft­ware com­po­nents that a firm owns but makes avail­able to the world under an open source license for strate­gic rea­sons [6].
  • Com­mu­nity open source are soft­ware com­po­nents owned by a com­mu­nity of stake­hold­ers, that is, they are not under the con­trol of a sin­gle legal entity [7].

Closed source soft­ware firms don’t offer open source com­po­nents; single-vendor open source firms do so by def­i­n­i­tion. All three types of soft­ware pro­duct firms use com­mu­nity open source. Closed source firms and single-vendor open source firms prefer com­mu­nity open source that comes with a per­mis­sive license in order to not risk hav­ing to open source their closed source com­po­nents. Open source dis­trib­u­tors use all types of open source irre­spec­tive of their license because their com­pet­i­tive dif­fer­en­tia­tor is not the soft­ware itself but their capa­bil­ity of keep­ing the com­po­nents con­fig­ured and inte­grated.

Jasper­soft is a single-vendor open source firm that pro­vides busi­ness intel­li­gence soft­ware prod­ucts, most notably JasperServer, a report gen­er­a­tor. In its enter­prise edi­tion, JasperServer con­tains closed source code owned by Jasper­soft, it builds on the open source com­mu­nity edi­tion of JasperServer which it wholly owns, and it uses com­mu­nity open source pack­ages like Hiber­nate, an object to rela­tional data­base map­per. JasperServer runs on both Win­dows and Linux.

Our analy­sis of var­i­ous pro­duct com­po­nent stacks and the cor­re­spond­ing firms’ behav­ior iden­ti­fied the fol­low­ing three strate­gic busi­ness goals:

  • Reduce devel­op­ment costs. Closed source and single-vendor open source firms use com­mu­nity open source or license closed source to reduce devel­op­ment costs.
  • Max­i­mize cus­tomer expo­sure. Single-vendor open source firms actively pro­mote their open source project with the strate­gic goal of sell­ing a supe­rior pro­duct faster at lower costs.
  • Min­i­mize com­pe­ti­tion. Open source invites com­pe­ti­tion, and both single-vendor open source and open source dis­trib­u­tors employ var­i­ous strate­gies to keep com­pe­ti­tion at bay.

Max­i­miz­ing cus­tomer expo­sure is a catch-all for the ben­e­fits expected from open sourcing one’s intel­lec­tual prop­erty. The ben­e­fits derive from a self-sustaining com­mu­nity around the project, as we dis­cuss else­where [6]. Max­i­miz­ing cus­tomer expo­sure and min­i­miz­ing com­pe­ti­tion are strate­gic goals joined at the hip. Firms have to open source to get the ben­e­fits of an open source go-to-market strat­egy, but that same move invites com­pe­ti­tion they now have to deal with.

Reach­ing these busi­ness goals requires that the soft­ware firm actively man­ages or at least influ­ences the open source projects it depends on.

3. Control Points and Steering Mechanisms

Soft­ware prod­ucts firms use a tool­box of mech­a­nisms to man­age open source projects to vary­ing degree to sup­port their busi­ness goals. In the fol­low­ing, we dis­cuss how these mech­a­nisms help meet busi­ness goals, depend­ing on the type of open source com­po­nent at hand. In the dis­cus­sion, we dis­tin­guish con­trol points (enforce­able through the legal sys­tem) from steer­ing mech­a­nisms (not enforce­able through the legal sys­tem but based on social con­tracts and cor­re­spond­ing behav­ior).

Fig­ure 2. Con­trol points and steer­ing mech­a­nisms and how they help meet busi­ness goals

We iden­ti­fied the fol­low­ing con­trol points that give a firm sig­nif­i­cant con­trol over an open source project:

  • Copy­right. While a soft­ware firm may grant third par­ties usage rights through an open source license, it may retain own­er­ship of the copy­right. As the owner, it can stop third par­ties from using the soft­ware under a dif­fer­ent license than the open source license.
  • Trade­marks. Almost all soft­ware embeds trade­marks in the form of logos or slo­gans or names. Trade­mark own­ers can stop third par­ties from using trade­marked open source soft­ware as is, requir­ing the poten­tially expen­sive removal of the trade­marks.
  • Domain own­er­ship. Own­ing domains that users and cus­tomers look up for infor­ma­tion about a pro­duct are an impor­tant means of influ­enc­ing cus­tomer per­cep­tion. Trade­marks allow stop­ping com­peti­tors from using domains with sim­i­lar names.

One might have expected patents to be in this list. How­ever, patent-based law­suits are mostly used by soft­ware firms to stop other firms from using a par­tic­u­lar soft­ware, the one vio­lat­ing the patent owner’s rights. Patents are typ­i­cally not used to exert con­trol over an open source project that a firm’s own prod­ucts build on and hence are not rel­e­vant to this analy­sis. In addi­tion, with increas­ing depen­dence on com­mu­nity open source, retal­i­a­tion clauses in the com­mu­nity open source licenses push back patent law­suits. The retal­i­a­tion clause retracts usage rights from the suing party, mak­ing the law­suit poten­tially hurt­ful to the plain­tiff.

Next to these con­trol points, we iden­ti­fied the fol­low­ing three steer­ing mech­a­nisms that allow a soft­ware firm to influ­ence a project’s direc­tion.

  • Social lead­er­ship. Lead­ers of open source projects have sub­stan­tial lever­age to direct that project. This includes the early license choice, the project cul­ture and cor­re­spond­ing prac­tices, and how the release plan and fea­ture road-map develop.
  • Devel­op­ment process. To the extent that a firm employs the devel­op­ers on a project, it can influ­ence the devel­op­ment process. Actual devel­op­ment may not be pub­lic, code con­tri­bu­tions may be time-delayed, only snap­shots may be pro­vided, etc.
  • Strate­gic posi­tion­ing. Some mar­ket­ing and out­reach chan­nels are bet­ter than oth­ers. Most notably, open source foun­da­tions provide impor­tant mar­ket­ing oppor­tu­ni­ties. By lock­ing up a project, firms can improve their cus­tomer expo­sure while keep­ing com­pe­ti­tion at bay.

In the fol­low­ing, we dis­cuss these mech­a­nisms and how they help reach busi­ness goal. All mech­a­nisms are multi-purpose with pos­si­bly broad effects.

4. Use of Control Points

We have iden­ti­fied the fol­low­ing prac­tices around con­trol points and how soft­ware firms use them to achieve some or all of the busi­ness goals of reduc­ing costs, max­i­miz­ing cus­tomer expo­sure, and min­i­miz­ing com­pe­ti­tion from the open source project.

4.1 Copyright practices

Copy­right prac­tices are most impor­tant for single-vendor open source firms. They are used to min­i­mize com­pe­ti­tion. Single-vendor open source firms open source some or all of their pro­duct com­po­nents, giv­ing the world cor­re­spond­ing usage rights to their soft­ware. How­ever, for com­po­nents con­sid­ered com­pet­i­tive dif­fer­en­tia­tors, single-vendor open source firms will want to avoid that com­peti­tors uti­lize their work to com­pete with them. In addi­tion, single-vendor open source firms typ­i­cally want to be able to sell a com­mer­cial license for the same soft­ware they make avail­able as open source, because some cus­tomers sim­ply insist on a com­mer­cial license.

There are two best prac­tices that single-vendor open source firms use to con­trol projects they open source:

  • They main­tain effec­tive own­er­ship by requir­ing a copy­right trans­fer for any out­side code con­tri­bu­tion. The copy­right trans­fer is real­ized by hav­ing con­trib­u­tors sign a copy­right trans­fer agree­ment (some­times reli­cens­ing rights grant). The agree­ment serves to trans­fer not only copy­right but also to set­tle other issues like patents employed in the con­tri­bu­tion.
  • They use an aggres­sive rec­i­p­ro­cal license for the open source soft­ware that will require that any competitor’s soft­ware built on the open source soft­ware will have to be open source as well. No tra­di­tional com­peti­tor will touch this soft­ware then, because it pre­vents the cre­ation of com­pet­i­tively dif­fer­en­ti­at­ing closed source soft­ware.

With copy­right own­er­ship main­tained, the single-vendor open source soft­ware firm can sell a tra­di­tional closed source license while still reap­ing the ben­e­fits of an open source strat­egy its prod­ucts.

The details of con­trib­u­tor agree­ments and open source license choice depend on the par­tic­u­lar busi­ness model of the single-vendor open source firm. Typ­i­cally, the GPL license is used, and we expect an increased use of the AGPL license as the world moves into the cloud.

Closed source soft­ware firms don’t open source com­pet­i­tively dif­fer­en­ti­at­ing com­po­nents and hence don’t have to worry about this issue. Open source dis­trib­u­tors don’t rely on indi­vid­ual com­po­nent con­trol and hence con­tribute to open source with­out wor­ry­ing much about copy­right.

4.2 Trademark practices

Trade­mark prac­tices are most impor­tant for open source dis­trib­u­tors, but they are also used by single-vendor open source firms. Closed source soft­ware ven­dors use trade­marks as well, but not in open source projects. Trade­mark prac­tices are used to min­i­mize com­pe­ti­tion.

Open source dis­trib­u­tors heav­ily invest into their brand and cor­re­spond­ing trade­marks, because it is the one thing that will set them apart from any com­peti­tor uti­liz­ing their work. Since dis­tri­b­u­tions are typ­i­cally built from com­mu­nity open source, any­one can take an open source dis­tri­b­u­tion and provide com­mer­cial ser­vices around it.

Trade­marks, like copy­right and patents, are exclu­sive rights. Thus, com­peti­tors can’t use a firm’s dis­tri­b­u­tion as is, but will have to remove the distributor’s trade­marks first. The orig­i­nal dis­trib­u­tor may want to make it as hard as pos­si­ble to remove its trade­marks to induce as long as pos­si­ble a time delay between its own release and a competitor’s re-release of the same soft­ware.

In addi­tion, remov­ing well-known brand­ing reduces the value of the soft­ware in the eyes of cus­tomers as the orig­i­nal firm and its capa­bil­i­ties obvi­ously do not stand behind it any longer. More­over, smart cer­ti­fi­ca­tion pro­grams tied to the branded dis­tri­b­u­tion increase its value fur­ther while decreas­ing the value of non-branded or re-branded dis­tri­b­u­tions.

In a sim­i­lar fash­ion, single-vendor open source firms brand their open source projects, threat­en­ing to sue any poten­tial com­peti­tor who uses the soft­ware with­out hav­ing removed the trade­marks first.

4.3 Domain ownership practices

A third con­trol point is Inter­net domain own­er­ship, where the domain names are typ­i­cally reflec­tive of the firm’s prod­ucts. Domain own­er­ship is used to max­i­mize cus­tomer expo­sure. Like trade­marks, this applies to all three types of firms, but only single-vendor open source and open source dis­trib­u­tors uti­lize it to pro­tect their open source intel­lec­tual prop­erty.

Both single-vendor open source firms and open source dis­trib­u­tors main­tain domains that rep­re­sent their prod­ucts to inter­ested par­ties. By man­ag­ing the cor­re­spond­ing web­sites they deter­mine what third par­ties learn about the soft­ware, which in turn sup­ports their respec­tive busi­ness goals.

These firms then use trade­marks to exclude com­peti­tors from buy­ing and using domains that might infringe on their trade­marks, thus max­i­miz­ing cus­tomer expo­sure while min­i­miz­ing com­pe­ti­tion.

5. Use of Steering Mechanisms

The con­trol points are exclu­sive rights that are enforce­able by law. In addi­tion, we have iden­ti­fied the fol­low­ing steer­ing mech­a­nisms that–while not enforce­able by law–can be equally pow­er­ful.

5.1 Social leadership practices

Social lead­er­ship plays out dif­fer­ently, depend­ing on the type of firm and type of open source com­po­nent. Mostly it is used to reduce devel­op­ment costs, but it can also be used to max­i­mize cus­tomer expo­sure.

In single-vendor open source, the firm employs most or all of the key devel­op­ers. At least some of them can ful­fill pub­lic lead­er­ship roles. In this capac­ity, devel­op­ers can nudge the com­mu­nity to focus their atten­tion and pos­si­ble con­tri­bu­tions onto dif­fer­ent aspects of the soft­ware, depend­ing on the firm’s needs. As Marten Mickos observed, only a small frac­tion of soft­ware devel­op­ment cost is actual pro­gram­ming costs–quality assur­ance and test­ing eas­ily con­sume as much if not more time and money [5]. Thus, any con­tri­bu­tion that the firm can gather from the open source com­mu­nity is likely to help reduce soft­ware devel­op­ment costs.

Both closed source and single-vendor open source soft­ware firms use com­mu­nity open source in their prod­ucts to reduce devel­op­ment costs by reusing well-working soft­ware com­po­nents for free. Thus, they will want to ensure the open source soft­ware keeps meet­ing their needs.

In com­mu­nity open source, a firm can also gain influ­ence by hir­ing devel­op­ers and putting them to work on the open source project. To the extent that these devel­op­ers focus on mak­ing the soft­ware work for their employer, the result­ing com­mu­nity open source soft­ware will help the firm save devel­op­ment costs. Thus, the work of a few devel­op­ers may allow for the use of a much larger soft­ware com­po­nent and cor­re­spond­ing cost sav­ings. The more influ­en­tial the employed devel­op­ers, the more they will be able to lead the com­mu­nity to activ­i­ties that will ben­e­fit their employer and increase devel­op­ment cost sav­ings.

The actual influ­ence of a devel­oper in a com­mu­nity open source project evolves over time. An extreme but impor­tant case is being a founder of the project. Most notably, twenty years after the Linux project was started, its founder Linus Tor­valds remains the final arbiter of tech­ni­cal deci­sions over the Linux ker­nel thanks to the unique hier­ar­chi­cal devel­op­ment struc­ture that he cre­ated. Other projects, for exam­ple Post­greSQL or the Apache projects, take a more egal­i­tar­ian approach.

Social lead­ers of a project then use their posi­tion to craft a par­tic­u­lar cul­ture that attracts or repels peo­ple, and they can use it to per­form or direct work to the ben­e­fit of their employ­ers. One might think that this cre­ates push-back from the broader com­mu­nity for sus­pi­cion of con­flict of inter­est, but in gen­eral it is well under­stood that if some­one per­forms work to the ben­e­fit of the whole project that per­son gets to choose what to work on.

Social lead­er­ship in com­mu­nity open source projects can also help single-vendor open source firms and open source dis­trib­u­tors max­i­mize cus­tomer expo­sure. Highly vis­i­ble devel­op­ers can use their posi­tion to reach out to the users of the com­mu­nity open source project and piggy-back a mes­sage onto their out­reach. That mes­sage typ­i­cally con­veys how well the com­mer­cial pro­duct, be it single-vendor open source or an open source dis­tri­b­u­tion, works with the com­mu­nity open source project they are rep­re­sent­ing. The form of out­reach ranges from mail­ing list activ­i­ties to con­fer­ence speaker engage­ments and indus­try pub­li­ca­tions.

5.2 Development process practices

Both single-vendor open source firms and open source dis­trib­u­tors use devel­op­ment process prac­tices to min­i­mize com­pe­ti­tion. Com­mon prac­tices include:

  • Closed rather than open devel­op­ment. This way, com­peti­tors don’t know what’s com­ing nor can they adjust their own soft­ware to trail the chang­ing code base.
  • Snap­shots of the code base rather than a full devel­op­ment his­tory. By not pro­vid­ing the full his­tory, main­tain­ing and work­ing with branches becomes impos­si­ble.
  • Delayed or hid­den pub­lish­ing of source code after release of bina­ries. The firm may choose to delay or hide the release of the source code over the release of the binary.

The main pur­pose of such prac­tices is to gain a time advan­tage over any pos­si­ble com­peti­tor. With a sig­nif­i­cant time delay before they can catch-up, com­peti­tors find them­selves at a dis­ad­van­tage for uti­liz­ing the code. Some­times, the firm doesn’t actu­ally have to do any of these things–the threat may be enough to keep com­peti­tors away.

Another impor­tant rea­son is that firms some­times don’t want their com­peti­tors to know early what they are devel­op­ing. For exam­ple, hard­ware firms fre­quently per­form closed devel­op­ment of the nec­es­sary Linux dri­vers of their new devices, even though the Linux ker­nel com­mu­nity demand they don’t [4]. Open devel­op­ment would let com­peti­tors learn early, from the code, about the specifics of the new devices and hence give the developer’s com­pet­i­tive strat­egy away.

Some­times, firms can lock-up a com­mu­nity open source project by employ­ing all core devel­op­ers (“com­mit­ters”) who then won’t accept any­one into the inner devel­oper cir­cle who doesn’t fit the firm’s strat­egy. How­ever, in com­mu­nity open source, such behav­ior is likely to be detri­men­tal to project suc­cess unless com­bined well with strate­gic posi­tion­ing prac­tices, see below.

Employ­ing key devel­op­ers is cru­cial to being able to estab­lish and fol­low an appro­pri­ate devel­op­ment process that fits the employ­ing firm’s busi­ness strat­egy.

5.3 Strategic positioning practices

Through smart strate­gic posi­tion­ing, closed source and single-vendor open source firms can uti­lize com­mu­nity open source to max­i­mize cus­tomer expo­sure while min­i­miz­ing com­pe­ti­tion. Since they can’t do it by sell­ing the com­mu­nity open source, their rev­enue must come from an extended or com­ple­men­tary offer­ing. An exam­ple is Actu­ate, which is the main devel­oper of the BIRT report designer, an Eclipse Foun­da­tion project. Actuate’s main actual rev­enue is from a com­ple­men­tary report gen­er­a­tor.

Strate­gic posi­tion­ing is best done by cre­at­ing a com­mu­nity open source project under the hood of an estab­lished open source foun­da­tion. The foun­da­tion lends cred­i­bil­ity and vis­i­bil­ity to the project. By mak­ing one of the two or more com­ple­ments avail­able as com­mu­nity open source, closed source and single-vendor open source firms can uti­lize the sup­port­ing foun­da­tion as a mar­ket­ing chan­nel to max­i­mize cus­tomer expo­sure.

To the extent that the foun­da­tion lets the firm lock up the project, the firm can also min­i­mize the com­pe­ti­tion aris­ing from the com­mu­nity open source project. For this to work, the firm has to dom­i­nate the project. This can be achieved by employ­ing all or a major­ity of core devel­op­ers to the project, who may then exclude any­one else from join­ing. This ensures the projects moves accord­ing to the firms goals.

Nat­u­rally, foun­da­tions don’t like such lock-up and work against it. The Apache Soft­ware Foun­da­tion, for exam­ple, allows for com­pet­ing com­mu­nity open source projects and requires for any project to be accepted to show a diver­sity among the core devel­op­ers.

Join­ing a foun­da­tion also serves to pro­tect a soft­ware firm from law­suits. To the extent that the com­mu­nity open source projects is part of the foun­da­tion, that foun­da­tion may pro­tect it and the firms behind it. The pub­lic back­lash over law­suits against a com­mu­nity open source project may well make a poten­tial plain­tiff shy away from suing the orig­i­nal soft­ware ven­dor.

6. Conclusions

Soft­ware pro­duct busi­nesses seek­ing to ben­e­fit from open source projects have three main goals: To reduce devel­op­ment costs, to max­i­mize cus­tomer expo­sure, and to min­i­mize com­pe­ti­tion from open source. To achieve these goals, soft­ware busi­nesses rely on a tool­box of prac­tices using con­trol points (enforce­able by law) and steer­ing mech­a­nisms (social con­tracts). Our analy­sis iden­ti­fies the con­trol points to be the estab­lished exclu­sive rights of copy­right, trade­marks, and prop­erty own­er­ship (but not patents) and the steer­ing mech­a­nisms to be social lead­er­ship, devel­op­ment process, and strate­gic posi­tion­ing. The arti­cle sum­ma­rizes the prac­tices around these mech­a­nisms.


I’d like to thank my Ph.D. stu­dents Han­nes Dohrn, Carsten Kolassa, and Michel A. Salim for pro­vid­ing thoughts and feed­back that helped improve this arti­cle.


[1] Euge­nio Capra, Anthony Wasser­man. “A Frame­work for Eval­u­at­ing Man­age­rial Styles in Open Source Projects.” In Pro­ceed­ings of the 4th Inter­na­tional Con­fer­ence on Open Source Sys­tems (OSS 2008). Springer, 2008: Page 1–14.

[2] Mark Dri­ver. “Key Issues for Open Source Soft­ware, 2010.” Gart­ner Research: 2010.

[3] Jef­frey S. Ham­mond. “Open Source Soft­ware Goes Main­stream.” For­rester Research, 2009.

[4] Greg Kroah-Hartman. “The Linux Ker­nel Dri­ver Inter­face.” Blog entry posted on Decem­ber 3, 2004.

[5] Marten Mickos. “Open for Busi­ness.” Pre­sen­ta­tion given at PARC on April 8, 2010.

[6] Dirk Riehle. “The Single-Vendor Com­mer­cial Open Source Busi­ness Model.” Infor­ma­tion Sys­tems and e-Business Man­age­ment. Springer Ver­lag, 2011. Forth­com­ing.

[7] Dirk Riehle. “The Eco­nomic Case for Open Source Foun­da­tions.” IEEE Com­puter vol. 43, no. 1 (Jan­u­ary 2010). Page 86–90.

[8] Dirk Riehle. “The Eco­nomic Moti­va­tion of Open Source: Stake­holder Per­spec­tives.” IEEE Com­puter vol. 40, no. 4 (April 2007). Page 25–32.

7 thoughts on “Control Points and Steering Mechanisms in Open Source Software Projects

  1. Pingback: Tweets that mention Control Points and Steering Mechanisms in Open Source Software Projects --

  2. Pingback: Tweets that mention Control Points and Steering Mechanisms in Open Source Software Projects --

  3. Andreas Kuckartz

    Trade­mark own­ers can stop third par­ties from using trade­marked open source soft­ware as is, requir­ing the poten­tially expen­sive removal of the trade­marks.”

    This is not that sim­ple because remov­ing trade­marks is also poten­tially not legal. A trade­mark owner might argue that the removal of his trade­mark and the dis­tri­b­u­tion of the result­ing source code amounts to unfair com­pe­ti­tion. I am not aware of such a case involv­ing Open Source soft­ware but such dis­putes involv­ing other prod­ucts have hap­pened. Search for “Teer­spritz­maschi­nen BGH” and you will find some­thing in Ger­man.

  4. Dirk Riehle Post author

    Wow, didn’t know this, thanks! I think today most dis­trib­u­tors in open source are try­ing to be “nice” and don’t object logo removal or make it par­tic­u­larly hard. Cen­tOS seems to be track­ing Red Hat eas­ily. But of course the poten­tial threat will already deter some poten­tial com­peti­tors…

  5. Pingback: Tweets that mention Control Points and Steering Mechanisms in Open Source Software Projects --

  6. Pingback: Control Points and Steering Mechanisms in Open Source Software Projects by Professor and Dr Dirk Riehle « surflightroy

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

Leave a Reply