Open Collaboration within Corporations Using Software Forges

Update: What we call “firm-internal open source” in this paper, is now gen­er­al­ly being called “inner source”. You might be inter­est­ed in read­ing more about the ben­e­fits of inner source, in par­tic­u­lar in product-line engi­neer­ing.

Dirk Riehle, John Ellen­berg­er, Tamir Mena­hem, Boris Mikhailovski, Yuri Natch­etoi, Barak Naveh, Thomas Oden­wald

Soft­ware forges are tool plat­forms that orig­i­nat­ed in the open source com­mu­ni­ty. Many cor­po­ra­tions are improv­ing and extend­ing their soft­ware devel­op­ment prac­tices by adopt­ing forges inter­nal­ly.

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

Over the past 10 years, open source soft­ware has become an impor­tant cor­ner­stone of the soft­ware indus­try. Com­mer­cial users have adopt­ed it in stand­alone appli­ca­tions, and soft­ware ven­dors are embed­ding it in prod­ucts. Sur­pris­ing­ly then, from a com­mer­cial per­spec­tive, open source soft­ware is devel­oped dif­fer­ent­ly from how cor­po­ra­tions typ­i­cal­ly devel­op soft­ware. Research into how open source works has been grow­ing steadi­ly [1]. One dri­ver of such research is the desire to under­stand how com­mer­cial soft­ware devel­op­ment could ben­e­fit from open source best prac­tices. Do some of the­se prac­tices also work with­in cor­po­ra­tions? If so, what are they, and how can we trans­fer them?

This arti­cle describes our expe­ri­ences using open source soft­ware devel­op­ment prac­tices at SAP. SAP is a major soft­ware devel­op­er and lead­er in busi­ness appli­ca­tions. We’ve found that open source prac­tices can com­ple­ment tra­di­tion­al top-down soft­ware devel­op­ment with bottom-up col­lec­tive intel­li­gence. Soft­ware forges offer a mech­a­nism for advanc­ing the adop­tion of open source best prac­tices with­in cor­po­ra­tions (see the Side­bar, “What Is a Soft­ware Forge?”). We illus­trate our expe­ri­ences using SAP’s own inter­nal soft­ware forge, called SAP Forge, and com­pare our expe­ri­ences with those from oth­er large soft­ware com­pa­nies.

Open Source Best Practices

Eric Ray­mond com­pared most cor­po­rate soft­ware devel­op­ment to build­ing a cathedral—planning, man­ag­ing, and exe­cut­ing the care­ful­ly craft­ed work of skilled indi­vid­u­als from the top down [2]. In con­trast, Ray­mond described open source devel­op­ment as a bazaar: no mas­ter plan, diverse agen­das, and much redun­dant effort.

Many open source best prac­tices fly in the face of tra­di­tion­al soft­ware devel­op­ment meth­ods [3] [4]. For exam­ple, open source projects don’t hide the source code from users; instead, they treat users as beta-testers. They also fre­quent­ly release incom­plete sys­tems and, in gen­er­al, don’t view users as cus­tomers who expect a pol­ished pro­duct. Rather, they empow­er users to become co-developers [5].

A case study by Vijay Gur­bani and his col­leagues shows how com­pa­nies can ben­e­fit from apply­ing open source prac­tices inter­nal­ly [6]. Gur­bani and his col­leagues devel­oped an inter­net tele­pho­ny server at Lucent using an open source approach. Through mul­ti­ple stages, the ini­tial research project evolved into the back­bone of mul­ti­ple com­mer­cial prod­ucts, all based on the same server soft­ware. Gur­bani pro­vid­ed the server soft­ware as a shared inter­nal asset, includ­ing the source code. Over time, sev­er­al pro­duct groups con­tribut­ed to the project, with­out any top-down com­pa­ny­wide project plan­ning. The project fol­lowed the Lin­ux devel­op­ment mod­el of “benev­o­lent dic­ta­tor” with “trust­ed lieu­tenants.” The result was high-quality, broad­ly used soft­ware that met user expec­ta­tions and could be eas­i­ly cus­tomized to dif­fer­ent needs.

At SAP, we want­ed to use an open source approach to make research-to-product suc­cess­es like Gurbani’s server soft­ware hap­pen more often and smooth­ly. To achieve this, we first need­ed to under­stand open source bet­ter.

Principles of Open Collaboration

Open source is said to be based on mer­i­toc­ra­cy [7]. We found this prin­ci­ple to be used as an umbrel­la term for the­se more speci­fic prin­ci­ples of col­lab­o­ra­tion in open source projects:

  • Egal­i­tar­i­an­ism. Every­one can con­tribute. Open source projects are acces­si­ble on the Inter­net, and the project com­mu­ni­ty typ­i­cal­ly includes any­one who wants to help.
  • Mer­i­toc­ra­cy. Con­tri­bu­tions are judged trans­par­ent­ly on the basis of their mer­its. All deci­sions are dis­cussed pub­licly on mail­ing lists and can be looked up for ref­er­ence.
  • Self-organization. Typ­i­cal­ly, no defined process is imposed from the out­side. The project com­mu­ni­ty itself deter­mi­nes how to go about its work.

We call the­se the prin­ci­ples of open col­lab­o­ra­tion. They con­trast stark­ly with how most cor­po­ra­tions man­age their inter­nal soft­ware devel­op­ment process­es:

  • Assigned jobs. Top-down resource assign­ment deter­mi­nes who works on what project or which piece of soft­ware.
  • Sta­tus rather than mer­it. A hier­ar­chy of junior and senior devel­op­ers and archi­tects implies sta­tus and usu­al­ly deter­mi­nes who has the final word in design and imple­men­ta­tion deci­sions.
  • Imposed process­es. A process-definition depart­ment in the orga­ni­za­tion deter­mi­nes which soft­ware devel­op­ment process to fol­low, and it’s bind­ing on all projects.

Per­haps the most impor­tant ben­e­fit of open col­lab­o­ra­tion is the emer­gent phe­nom­e­non of vol­un­teer soft­ware devel­op­ers who find and con­tribute to a project by their own choice.

Benefits of Internal Open Collaboration

Although the prin­ci­ples of open col­lab­o­ra­tion are hard­ly typ­i­cal of tra­di­tion­al soft­ware devel­op­ment orga­ni­za­tions, they offer ben­e­fits that account for cor­po­rate inter­est in them:

  • Vol­un­teers. Even with­in tra­di­tion­al top-down struc­tured soft­ware devel­op­ment orga­ni­za­tions, projects can gath­er inter­nal vol­un­teer con­tri­bu­tions.
  • Moti­vat­ed con­trib­u­tors. Vol­un­teers choose projects accord­ing to their own inter­ests rather than by assign­ment. The deci­sion to con­tribute is theirs and gives them oppor­tu­ni­ties to gain rep­u­ta­tion and vis­i­bil­i­ty in the com­pa­ny beyond their assign­ments.
  • Bet­ter qual­i­ty through quasi-public inter­nal scruti­ny. When devel­op­ment with­in the cor­po­ra­tion is open, devel­op­ers typ­i­cal­ly feel an extra incen­tive to strive for high-quality con­tri­bu­tions.
  • Broad exper­tise. Because vol­un­teers can join from across the orga­ni­za­tion, they can sig­nif­i­cant­ly broad­en the exper­tise avail­able to a project. This helps projects reach goals more quick­ly at high­er qual­i­ty. Specif­i­cal­ly, it can help fix prob­lems more quick­ly and either pre­vent mis­takes or cap­ture them ear­lier.
  • Broad sup­port and buy-in. With vol­un­teers from across the orga­ni­za­tion, projects find a broad­er base and sup­port in the orga­ni­za­tion.
  • Bet­ter research-to-product trans­fer. Research projects can get exper­tise and vol­un­teers from down­stream pro­duct units, which can ease the research-to-product tech­nol­o­gy trans­fer.

At the root of the­se ben­e­fits are vol­un­teer soft­ware devel­op­ers. Researchers have stud­ied pub­lic open source projects to deter­mine how vol­un­teers join them. For exam­ple, Georg von Krogh and his col­leagues ana­lyzed how vol­un­teers joined the Freenet project [8]; Israel Her­raiz and his col­leagues did the same for the Gnome project [9]. The­se researchers found the join­ing process for vol­un­teers to be grad­u­al, com­pared to paid devel­op­ers who under­go a rather abrupt, ful­ly immer­sive expe­ri­ence.

Software Forges for Open Collaboration

Soft­ware forges make it as easy as pos­si­ble to find a project, under­stand it, and con­tribute to it.

Sev­er­al large soft­ware ven­dors have tak­en steps to estab­lish a con­sis­tent way of bring­ing open source best prac­tices to cor­po­rate soft­ware devel­op­ment.

For exam­ple, Jamie Dinkelack­er and his col­leagues defined Hewlett-Packard’s pro­gres­sive open source pro­gram [10]. As part of this pro­gram, they devel­oped the “cor­po­rate source ini­tia­tive,” which sup­port­ed the pro­vi­sion of HP Labs research projects as inter­nal open source projects. Cre­at­ing com­mu­ni­ties around the­se projects was key to their suc­cess. The com­mu­ni­ties con­sist­ed of not only researchers but also devel­op­ers from pro­duct units [11].

IBM has a sim­i­lar effort, which dif­fers from HP’s ini­tia­tive in using an off-the-shelf soft­ware forge rather than custom-built soft­ware [12]. SAP also adopt­ed this approach.

Gurbani’s expe­ri­ence at Lucent showed that one of the biggest prob­lems to inter­nal open source is that many groups use dif­fer­ent and fre­quent­ly incom­pat­i­ble tools. A good soft­ware forge uni­fies the tool set and sup­ports the whole soft­ware devel­op­ment cycle.

Forges and CASE Tools

In many ways, a soft­ware forge is like an inte­grat­ed CASE tool [13]. It pro­vides a pre­de­fined but exten­si­ble set of tools that all play togeth­er to aid soft­ware devel­op­ers in their project work. Task man­age­ment, issue track­ers, and doc­u­men­ta­tion tools are com­mon in both CASE tools and soft­ware forges.

The soft­ware devel­op­ment tools of many cor­po­ra­tions are nei­ther inte­grat­ed nor com­plete, so projects tend to install their own project-specific tools. Con­se­quent­ly, impor­tant project infor­ma­tion is stored on dif­fer­ent servers and is fre­quent­ly lost as a project moves on in its life cycle. Soft­ware forges and CASE tools address the­se issues by giv­ing devel­op­ers one defined place with all the tools they need.

Thus, they both make eco­nom­ic sense. Among oth­er ben­e­fits, they cen­tral­ize and store impor­tant infor­ma­tion and reduce resources spent on admin­is­tra­tive tasks such as main­tain­ing a project-specific Web server and bug track­er.

Critical Forge Design Issues

Cor­po­rate soft­ware devel­op­ers are the pri­ma­ry mar­ket for CASE tools, along with the peo­ple who define the devel­op­ment process­es. In con­trast, soft­ware forges emerged on the Inter­net, and open source soft­ware devel­op­ers are their pri­ma­ry users.

Open source projects tend to be resource-starved, so most projects must attract vol­un­teers. Con­se­quent­ly, soft­ware forges are geared toward mak­ing it as easy as pos­si­ble to find a project, under­stand it, and con­tribute to it.

  • Find­ing projects. A forge offers a pro­duct port­fo­lio view first and a project-specific view sec­ond. Projects are indexed and search­able using one and only one URL as the start­ing point. Find­ing projects is easy on a forge and one of its most impor­tant fea­tures.

    This con­trasts with cor­po­rate soft­ware devel­op­ment, where a silo men­tal­i­ty fre­quent­ly hides projects on sep­a­rate servers, unin­dexed and with a cryp­tic URL. CASE tools are also typ­i­cal­ly project-centric and make a project vis­i­ble only to the devel­op­ers assigned to it.

  • Under­stand­ing projects. A typ­i­cal forge offers project forums and mail­ing lists as a basic fea­ture and makes the dis­cus­sions on them acces­si­ble to the prop­er audience—by default, any­one who can access the forge. The­se dis­cus­sions are how projects on the forge doc­u­ment their deci­sions and soft­ware devel­op­ment. Index­ing and search mech­a­nisms let users eas­i­ly find which deci­sions the project made and why. This doc­u­men­ta­tion approach makes it eas­ier for vol­un­teers to read about a project and get involved.

    In con­trast, dis­cus­sions lead­ing to deci­sions in tra­di­tion­al projects fre­quent­ly occur in meet­ings or on the phone. They’re sparse­ly doc­u­ment­ed, if at all. Fre­quent­ly, this leaves devel­op­ers with no more infor­ma­tion about a deci­sion than the deci­sion itself. Dis­cus­sions repeat them­selves, and devel­op­ers have much more dif­fi­cul­ty get­ting up to speed on a project.

  • Con­tribut­ing to projects. A forge offers devel­op­ers tools that either they’re already famil­iar with from pre­vi­ous work or they can famil­iar­ize them­selves with quick­ly because the tools are used repeat­ed­ly across all forge projects. The first step to get­ting involved can be as easy as click­ing on the reply but­ton in a project’s dis­cus­sion forum and mak­ing a com­ment. This reduces the tech­ni­cal and prac­ti­cal hur­dle of join­ing and becom­ing active in a project.

    Although a well-run soft­ware devel­op­ment orga­ni­za­tion typ­i­cal­ly pro­vides a defined tool set, we’ve found that many orga­ni­za­tions have dif­fi­cul­ty inte­grat­ing them in a coher­ent offer­ing. Devel­op­ers there­fore find dif­fer­ent setups across dif­fer­ent projects, even in the same com­pa­ny. This makes it hard to con­tribute quick­ly to a speci­fic project, thus inhibit­ing vol­un­teerism. In addi­tion, tra­di­tion­al cor­po­rate projects tend to be defen­sive and hide their infor­ma­tion, oper­at­ing on a need-to-know basis rather than a desire to show them­selves.

The SAP Forge Case Study

We’re the lead­er­ship team for SAP Forge, which we designed with the ben­e­fits of open col­lab­o­ra­tion in mind. SAP’s own soft­ware devel­op­ment process pro­vides best-of-breed tool­ing. Since 2006, SAP Forge has enabled projects to acquire and keep vol­un­teers with­in the cor­po­rate firewall’s bound­aries.

We based SAP Forge on the GForge ( open source soft­ware forge code base. GForge is a pop­u­lar choice in cor­po­ra­tions; for exam­ple, IBM uses it, too.

SAP Forge rep­re­sents one com­mon plat­form found at one speci­fic, easy-to-remember company-internal URL. Every­one with­in the corporation’s fire­walls can access it. Every­one who’s inter­est­ed can become a devel­op­er on the forge, and every­one can reg­is­ter a new project with­out going through a lengthy approval process. Unless explic­it­ly request­ed, all projects are open and acces­si­ble to every­one who cares to look.

SAP Forge has grown steadi­ly since the com­pa­ny launched it in Sep­tem­ber 2006. Projects aren’t required to use SAP Forge; it’s a choice left to the project lead. One year after its incep­tion, SAP Forge had reached more than 100 projects and had more than 500 reg­is­tered users, rep­re­sent­ing about 5 per­cent of the over­all SAP devel­op­er pop­u­la­tion. SAP Forge’s over­all growth has been lin­ear, but we expect it to slow down once we’ve reached a siz­able chunk of all SAP devel­op­ers.

Table 1 com­pares SAP Forge with IBM, HP, and Microsoft forges. Steve Fox and Joe Latone of IBM pro­vid­ed the IBM data, and Andrew Begel pro­vid­ed the Microsoft data. SAP Forge has a sub­stan­tial­ly larg­er num­ber of small­er projects than IBM and HP, which we attrib­ute to a large influx of small research projects that were already com­plete and were look­ing for an easy-to-find rest­ing place. We also believe that devel­op­ers today are more com­fort­able with shar­ing code inter­nal­ly than they were a few years ago—also evi­dent in the par­tic­i­pa­tion data from Microsoft, which launched its forge in 2007.

  Start Date # of devel­op­ers # of projects at age of forge [mths]
IBM [12] Jan­u­ary 2000 ~800 (~4% of pop­u­la­tion) 45 18
HP [10] June 2000 1500 (~7.5% of pop­u­la­tion) 24 18
SAP Sep­tem­ber 2006 706 (~7.1% of pop­u­la­tion) 179 18
Microsoft June 2007 794 (~2.8% of pop­u­la­tion) 406 10

Table 1: Data for the HP, IBM, and SAP forges after 10 or 18 months of oper­a­tion

SAP Forge first gives devel­op­ers an overview of all projects and devel­op­ers on the forge. They can then switch to their dash­board, which shows them all projects they’re involved in (see Fig­ure 1 on the next page).

Fig­ure 1. SAP Forge Devel­op­er Dash­board. Each devel­op­er on the forge has an indi­vid­u­al dash­board that shows his or her cur­rent­ly active projects. (The data dis­played here is fic­tion­al.)

After the devel­op­er switch­es to a speci­fic project, SAP Forge pro­vides the expect­ed tools such as bug track­ing, con­fig­u­ra­tion man­age­ment, task man­age­ment, forums, mail­ing lists, and wik­is.

Project search, devel­op­er infor­ma­tion, and project pub­lic­i­ty were all impor­tant in intro­duc­ing open source best prac­tices to SAP. Users can search project names and descrip­tions to find those they’re inter­est­ed in. They can look at the pro­file and skill sets of devel­op­ers on the forge and search for devel­op­ers with speci­fic skills. This sup­ports and strength­ens the emer­gence of a net­work of devel­op­ers who know whom to turn to for advice and ques­tions. And final­ly, SAP Forge gives users var­i­ous gen­er­al sta­tis­tics, such as the most active or most pop­u­lar projects. The­se sta­tis­tics not only inform peo­ple but also moti­vate con­tri­bu­tions because they imply recog­ni­tion of the project and its devel­op­ers. This in turn moti­vates higher-quality work.

An Example SAP Forge Project

One ear­ly SAP Forge project was the Mobile Retail Demo, a demon­stra­tion project that used the Blue­tooth pro­to­col for mobile shop­ping. The soft­ware lets mobile phone users con­fig­ure what infor­ma­tion they would like to receive on their phones from near­by stores—for exam­ple, infor­ma­tion about an ongo­ing sale. In addi­tion, users can vol­un­tar­i­ly sup­ply infor­ma­tion about their tastes and cur­rent shop­ping list to retail shops. One project goal was to lay a foun­da­tion for a future Mobile Retail Frame­work to fol­low the demo project.

The project began in mid-2006 for demon­stra­tion at an SAP inter­nal con­fer­ence. In late 2006, it moved onto SAP Forge to get wider expo­sure in the com­pa­ny. The project was already a suc­cess, but mov­ing it to SAP Forge dras­ti­cal­ly increased its reach and speed. The orig­i­nal devel­op­ment team con­sist­ed of three researchers. Four­teen months lat­er, 27 devel­op­ers had reg­is­tered on SAP Forge for the project. Most new con­trib­u­tors were vol­un­teers; there was no tra­di­tion­al top-down resource assign­ment.

The Mobile Retail Demo project lead­ers con­firmed that the open col­lab­o­ra­tion more than achieved its reput­ed ben­e­fits. Specif­i­cal­ly, the project expe­ri­enced the fol­low­ing advan­tages from being on SAP Forge:

  • Vol­un­teers. SAP Forge brought the project more than 18 addi­tion­al con­trib­u­tors. The­se con­trib­u­tors aren’t full-time resources, but they do con­tribute active­ly and help the project move for­ward.
  • Moti­vat­ed vol­un­teers. The vol­un­teers joined the project on their own and hence care deeply about it, lead­ing to con­tri­bu­tions of above-average qual­i­ty.
  • Broad exper­tise. The vol­un­teers brought exper­tise from across the orga­ni­za­tion. Many of them are work­ing on relat­ed projects and are famil­iar with the prob­lems of such appli­ca­tions.
  • Bet­ter under­stand­ing of require­ments. In addi­tion to broad exper­tise, vol­un­teers con­tribute insights into require­ments and future appli­ca­tions that influ­ence the project’s pro­duct man­age­ment.
  • Broad sup­port. The breadth of vol­un­teers means broad­er sup­port for the project across the orga­ni­za­tion. The project got such good pub­lic­i­ty in the orga­ni­za­tion that fur­ther resources became avail­able.
  • Test­ing help. Enthu­si­as­tic vol­un­teers who bought into the project became excel­lent human soft­ware testers, pro­vid­ing quick feed­back on prob­lems and bugs.
  • Increased vis­i­bil­i­ty. Being on SAP Forge and get­ting vol­un­teers and broad sup­port raised the project’s pro­file and low­ered the chances of redun­dant com­pet­ing efforts, because every­one in the space knows about the project.
  • For­mal­ized dis­play of sig­nif­i­cance. The con­tri­bu­tions, broad­er inter­est, and raised project pro­file imply addi­tion­al val­i­da­tion of its sig­nif­i­cance for the com­pa­ny.

The project lead­ers also expect an improved research-to-product trans­fer. The Mobile Retail Demo was a research project, but the vol­un­teers it attract­ed includ­ed some of the more fore­sight­ed devel­op­ers from pro­duct units. We expect this ear­ly buy-in from devel­op­ment to ease the tech­nol­o­gy trans­fer by align­ing research inter­ests and pro­duct needs ear­ly.

The project’s expo­sure on SAP Forge and the forge’s sup­port for open col­lab­o­ra­tion have helped make the Mobile Retail Demo sig­nif­i­cant­ly more suc­cess­ful than would have been pos­si­ble using only tra­di­tion­al man­age­ment prac­tices of cor­po­rate soft­ware devel­op­ment.

SAP Forge Benefits and Challenges

The Mobile Retail Demo was a big suc­cess for the SAP Forge, but it wasn’t the only one. In a sur­vey, 66 per­cent of all respon­dents (55 of 83) report­ed that they looked out­side their silo, brows­ing for oth­er projects that inter­est­ed them, and 24 per­cent stat­ed that their project received out­side help, most­ly bug reports and sug­ges­tions for improve­ment. Anoth­er 12 per­cent said they helped oth­er projects on the basis of per­son­al inter­est.

The man­agers of research projects are gen­er­al­ly sup­port­ive of the vol­un­teer con­tri­bu­tions, as they expect to ben­e­fit from out­side help and an improved research-to-product trans­fer process. The man­agers of vol­un­teers from reg­u­lar pro­duct units are typ­i­cal­ly skep­ti­cal in the begin­ning. We’ve found that they became neu­tral or even sup­port­ive once they real­ized the future ben­e­fits of ear­ly engage­ment with research projects.

The biggest hur­dle to wide­spread adop­tion of SAP Forge is its lim­it­ed com­pli­ance with tools manda­to­ry for SAP’s gen­er­al soft­ware devel­op­ment process—in par­tic­u­lar, SAP’s pro­pri­etary Advanced Busi­ness Appli­ca­tion Pro­gram­ming sys­tem. Ini­tial­ly, as a vol­un­teer effort, we didn’t have the resources to inte­grate the forge with the­se exter­nal tools. We’re doing this now, expect­ing to draw even more projects to the forge. SAP Forge isn’t in com­pe­ti­tion with exist­ing tools and process­es. Rather, it com­ple­ments them, uni­fy­ing exist­ing stand­alone tools under one com­mon user inter­face.

Although the SAP Forge tools enable devel­op­ers to vol­un­teer for projects they’re inter­est­ed in, we’ve found the open col­lab­o­ra­tion prin­ci­ples we described ear­lier to be cru­cial to retain­ing them. Projects must exhibit a mind­set that wel­comes who­ev­er comes along to help rather than view­ing vol­un­teers as a for­eign ele­ment (egal­i­tar­i­an­ism prin­ci­ple). Project mem­bers must real­ize that impor­tant input and con­tri­bu­tions can come from across the orga­ni­za­tion and can be based on per­spec­tives that might be unfa­mil­iar to the orig­i­nal devel­op­ers (mer­i­toc­ra­cy prin­ci­ple). Final­ly, SAP has well-defined soft­ware devel­op­ment process­es, but accept­ing vol­un­teer con­tri­bu­tions some­times means adjust­ing to vol­un­teer needs and time­li­nes (self-organization prin­ci­ple).

For vol­un­teers, the main reward of the forge plat­form for open col­lab­o­ra­tion is their suc­cess­ful con­tri­bu­tions to projects of their choice and the recog­ni­tion they receive in doing so. We encour­age project lead­ers to find sim­ple ways to express their appreciation—for exam­ple, hand­ing out project-specific T-shirts and talk­ing to a volunteer’s man­ager before a per­for­mance review.

From an employer’s per­spec­tive, an inter­nal soft­ware forge lets employ­ees work on speci­fic projects that inter­est them and helps avoid los­ing them to oth­er activ­i­ties. With an inter­nal forge, we’ve found that enthu­si­as­tic devel­op­ers with time, ener­gy, and moti­va­tion are more like­ly to spend their effort for the good of the com­pa­ny than for out­side projects.


1. W. Scac­chi, “Free/Open Source Soft­ware Devel­op­ment: Recent Research Results and Emerg­ing Oppor­tu­ni­ties,” Proc. 6th Joint Meet­ing Euro­pean Soft­ware Eng. Conf. and the ACM SIGSOFT Symp. Foun­da­tions of Soft­ware Eng. (ESEC/FSE 07), ACM Press, 2007, pp. 459–468.
2. E. Ray­mond, The Cathe­dral and the Bazaar, O’Reilly, 2001.
3. C. DiBona, S. Ock­man, and M. Stone, Open Sources: Voic­es from the Open Source Rev­o­lu­tion, O’Reilly, 1999. 
4. K. Fogel, Pro­duc­ing Open Source Soft­ware, O’Reilly, 2005.
5. E. von Hip­pel, Democ­ra­tiz­ing Inno­va­tion, MIT Press, 2005.
6. V.K. Gur­bani, A. Garvert, and J.D. Herb­sleb, “A Case Study of a Cor­po­rate Open Source Devel­op­ment Mod­el,” Proc. 28th Int’l Conf. Soft­ware Eng. (ICSE 06), ACM Press, 2006, pp. 472–481.
7. K.R. Lakhani and R.G. Wolf, “Why Hack­ers Do What They Do: Under­stand­ing Moti­va­tion and Effort in Free/ Open Source Soft­ware Projects,” in Per­spec­tives on Free and Open Source Soft­ware, MIT Press, 2005, pp. 3–22.
8. G. von Krogh, S. Spaeth, and K.R. Lakhani, “Com­mu­ni­ty, Join­ing, and Spe­cial­iza­tion in Open Source Soft­ware Inno­va­tion: A Case Study,” Research Pol­i­cy, vol. 32, 2003, pp. 1217–1241.
9. I. Her­raiz et al., “The Process­es of Join­ing in Glob­al Dis­trib­ut­ed Soft­ware Projects,” Proc. 2006 Int’l Work­shop Glob­al Soft­ware Devel­op­ment for the Prac­ti­tion­er, ACM Press, 2006, pp. 27–33.
10. J. Dinkelack­er et al., “Pro­gres­sive Open Source,” Proc. 24th Int’l Conf. Soft­ware Eng. (ICSE 02), ACM Press, 2002, pp. 177–184.
11. C. Melian et al., Build­ing Net­works of Soft­ware Com­mu­ni­ties in a Large Cor­po­ra­tion, tech. report, HP Labs, 2002.
12. D. Sab­bah, “The Open Internet—Open Source, Open Stan­dards and the Effects on Col­lab­o­ra­tive Soft­ware Devel­op­ment,” pre­sen­ta­tion at the 2005 High Per­for­mance Trans­ac­tion Sys­tems Work­shop, 2005, www.
13. S. Jarz­abek and Riri Huang, “The Case for User-Centered CASE Tools,” Comm. ACM, vol. 41, no. 8, 1998, pp. 93–99.

Sidebar: What is a Software Forge?

A soft­ware forge is an exten­si­ble Web-based plat­form that inte­grates best-of-breed soft­ware tools for col­lab­o­ra­tive soft­ware devel­op­ment. Source­Forge ( is the best-known exam­ple on the Inter­net, host­ing the largest col­lec­tion of open source projects of any forge. Oth­er exam­ples are BerliOS (, Code­haus (, and Tigris ( A soft­ware forge has two main views:

  • a project port­fo­lio view that lets a devel­op­er browse and find projects, and
  • a project view that pro­vides the devel­op­er tools for work­ing on a speci­fic project.

Devel­op­ers who nav­i­gate to a par­tic­u­lar project will see a project-specific view, which typ­i­cal­ly has two parts:

  • a list­ing of the dif­fer­ent tools avail­able for the project, and
  • a view speci­fic to a select­ed tool.

A good soft­ware forge sup­ports the whole soft­ware devel­op­ment process from idea gen­er­a­tion, project def­i­n­i­tion, and pro­duct man­age­ment to con­fig­u­ra­tion man­age­ment, build sup­port, and bug track­ing. The forge inte­grates all the tools sup­port­ing the­se activ­i­ties in one inter­face and makes nav­i­gat­ing among them easy. All projects use the same tools, so devel­op­ers can eas­i­ly switch between projects.

Project forges dif­fer from CASE tools in that their design cen­ters on open col­lab­o­ra­tion, mak­ing it easy to find a project, read about it, under­stand it, and con­tribute as a vol­un­teer.

10 thoughts on “Open Collaboration within Corporations Using Software Forges

  1. Pingback: 451 CAOS Theory » 451 CAOS Links 2009.02.13

  2. Pingback: Boycott Novell » Links 15/02/2009: KDE 4.3 Preview; Cuba Uses Sabayon Technology

  3. Pingback: P2P Foundation » Blog Archive » Internal adoptions of open source practices by companies

  4. Pingback: Links 18/2/2010: Lots of KDE 4.4, Review of SimplyMepis 8.0.15 | Boycott Novell

  5. Pingback: Links collection about software forges: status, criticism and new ideas « Libre Software People's Front

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

  7. Andrzej Lisowski

    Great arti­cle. I’m very hap­py to see that there is some hard data pro­vid­ed to con­firm my obser­va­tion. Most impor­tant­ly. It comes from dif­fer­ent com­pa­nies than mine. This will make my pub­li­ca­tion even stronger. There shall soon (I hope) be anoth­er pin­gack from me 🙂

  8. Pingback: Why should you work in the open? | Digital Media Blog

  9. Pingback: Why should you work in the open?

Leave a Reply