Open Collaboration within Corporations Using Software Forges

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


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

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

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 adopted it in stand­alone appli­ca­tions, and soft­ware ven­dors are embed­ding it in prod­ucts. Sur­pris­ingly then, from a com­mer­cial per­spec­tive, open source soft­ware is devel­oped dif­fer­ently from how cor­po­ra­tions typ­i­cally develop soft­ware. Research into how open source works has been grow­ing steadily [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 these prac­tices also work within 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­oper and leader in busi­ness appli­ca­tions. We’ve found that open source prac­tices can com­ple­ment tra­di­tional top-down soft­ware devel­op­ment with bot­tom-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 within 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 other 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­fully crafted 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­tional 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­quently release incom­plete sys­tems and, in gen­eral, don’t view users as cus­tomers who expect a pol­ished pro­duct. Rather, they empower users to become co-devel­op­ers [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­nally [6]. Gur­bani and his col­leagues devel­oped an inter­net tele­phony 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­vided the server soft­ware as a shared inter­nal asset, includ­ing the source code. Over time, sev­eral pro­duct groups con­tributed to the project, with­out any top-down com­pa­ny­wide project plan­ning. The project fol­lowed the Linux devel­op­ment model of “benev­o­lent dic­ta­tor” with “trusted lieu­tenants.” The result was high-qual­ity, broadly used soft­ware that met user expec­ta­tions and could be eas­ily cus­tomized to dif­fer­ent needs.

At SAP, we wanted to use an open source approach to make research-to-pro­duct suc­cesses like Gurbani’s server soft­ware hap­pen more often and smoothly. To achieve this, we first needed to under­stand open source bet­ter.

Principles of Open Collaboration

Open source is said to be based on mer­i­toc­racy [7]. We found this prin­ci­ple to be used as an umbrella term for these 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­nity typ­i­cally includes any­one who wants to help.
  • Mer­i­toc­racy. Con­tri­bu­tions are judged trans­par­ently 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-orga­ni­za­tion. Typ­i­cally, no defined process is imposed from the out­side. The project com­mu­nity itself deter­mi­nes how to go about its work.

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

  • 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 merit. A hier­ar­chy of junior and senior devel­op­ers and archi­tects implies sta­tus and usu­ally deter­mi­nes who has the final word in design and imple­men­ta­tion deci­sions.
  • Imposed processes. A process-def­i­n­i­tion 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 hardly typ­i­cal of tra­di­tional 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 within tra­di­tional top-down struc­tured soft­ware devel­op­ment orga­ni­za­tions, projects can gather inter­nal vol­un­teer con­tri­bu­tions.
  • Moti­vated 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­ity in the com­pany beyond their assign­ments.
  • Bet­ter qual­ity through quasi-pub­lic inter­nal scrutiny. When devel­op­ment within the cor­po­ra­tion is open, devel­op­ers typ­i­cally feel an extra incen­tive to strive for high-qual­ity 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­cantly broaden the exper­tise avail­able to a project. This helps projects reach goals more quickly at higher qual­ity. Specif­i­cally, it can help fix prob­lems more quickly 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 broader base and sup­port in the orga­ni­za­tion.
  • Bet­ter research-to-pro­duct trans­fer. Research projects can get exper­tise and vol­un­teers from down­stream pro­duct units, which can ease the research-to-pro­duct tech­nol­ogy trans­fer.

At the root of these 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]. These researchers found the join­ing process for vol­un­teers to be grad­ual, com­pared to paid devel­op­ers who undergo a rather abrupt, fully 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­eral large soft­ware ven­dors have taken 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 Dinkelacker 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­ported the pro­vi­sion of HP Labs research projects as inter­nal open source projects. Cre­at­ing com­mu­ni­ties around these projects was key to their suc­cess. The com­mu­ni­ties con­sisted 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 cus­tom-built soft­ware [12]. SAP also adopted 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­quently 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­grated CASE tool [13]. It pro­vides a pre­de­fined but exten­si­ble set of tools that all play together 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­grated nor com­plete, so projects tend to install their own project-speci­fic tools. Con­se­quently, impor­tant project infor­ma­tion is stored on dif­fer­ent servers and is fre­quently lost as a project moves on in its life cycle. Soft­ware forges and CASE tools address these issues by giv­ing devel­op­ers one defined place with all the tools they need.

Thus, they both make eco­nomic sense. Among other 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-speci­fic Web server and bug tracker.

Critical Forge Design Issues

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

Open source projects tend to be resource-starved, so most projects must attract vol­un­teers. Con­se­quently, 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-speci­fic 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­ity fre­quently hides projects on sep­a­rate servers, unin­dexed and with a cryp­tic URL. CASE tools are also typ­i­cally project-cen­tric 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 proper audience—by default, any­one who can access the forge. These 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­ily 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­tional projects fre­quently occur in meet­ings or on the phone. They’re sparsely doc­u­mented, if at all. Fre­quently, 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­culty 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 quickly because the tools are used repeat­edly 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­cally pro­vides a defined tool set, we’ve found that many orga­ni­za­tions have dif­fi­culty 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­pany. This makes it hard to con­tribute quickly to a speci­fic project, thus inhibit­ing vol­un­teerism. In addi­tion, tra­di­tional 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 within the cor­po­rate firewall’s bound­aries.

We based SAP Forge on the GForge (www.gforge.org) 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-remem­ber com­pany-inter­nal URL. Every­one within the corporation’s fire­walls can access it. Every­one who’s inter­ested can become a devel­oper on the forge, and every­one can reg­is­ter a new project with­out going through a lengthy approval process. Unless explic­itly requested, all projects are open and acces­si­ble to every­one who cares to look.

SAP Forge has grown steadily since the com­pany 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­oper 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­vided the IBM data, and Andrew Begel pro­vided the Microsoft data. SAP Forge has a sub­stan­tially larger num­ber of smaller 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­nally 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­oper Dash­board. Each devel­oper on the forge has an indi­vid­ual dash­board that shows his or her cur­rently active projects. (The data dis­played here is fic­tional.)

After the devel­oper switches to a speci­fic project, SAP Forge pro­vides the expected tools such as bug track­ing, con­fig­u­ra­tion man­age­ment, task man­age­ment, forums, mail­ing lists, and wikis.

Project search, devel­oper infor­ma­tion, and project pub­lic­ity 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­ested 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 finally, SAP Forge gives users var­i­ous gen­eral sta­tis­tics, such as the most active or most pop­u­lar projects. These 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-qual­ity work.

An Example SAP Forge Project

One early 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 nearby stores—for exam­ple, infor­ma­tion about an ongo­ing sale. In addi­tion, users can vol­un­tar­ily 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­pany. The project was already a suc­cess, but mov­ing it to SAP Forge dras­ti­cally increased its reach and speed. The orig­i­nal devel­op­ment team con­sisted of three researchers. Four­teen months later, 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­tional 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 reputed ben­e­fits. Specif­i­cally, 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­tional con­trib­u­tors. These con­trib­u­tors aren’t full-time resources, but they do con­tribute actively and help the project move for­ward.
  • Moti­vated 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-aver­age qual­ity.
  • Broad exper­tise. The vol­un­teers brought exper­tise from across the orga­ni­za­tion. Many of them are work­ing on related 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 broader sup­port for the project across the orga­ni­za­tion. The project got such good pub­lic­ity 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­ity. 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, broader inter­est, and raised project pro­file imply addi­tional val­i­da­tion of its sig­nif­i­cance for the com­pany.

The project lead­ers also expect an improved research-to-pro­duct trans­fer. The Mobile Retail Demo was a research project, but the vol­un­teers it attracted included some of the more fore­sighted devel­op­ers from pro­duct units. We expect this early buy-in from devel­op­ment to ease the tech­nol­ogy trans­fer by align­ing research inter­ests and pro­duct needs early.

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­cantly more suc­cess­ful than would have been pos­si­ble using only tra­di­tional 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) reported that they looked out­side their silo, brows­ing for other projects that inter­ested them, and 24 per­cent stated that their project received out­side help, mostly bug reports and sug­ges­tions for improve­ment. Another 12 per­cent said they helped other projects on the basis of per­sonal inter­est.

The man­agers of research projects are gen­er­ally 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-pro­duct trans­fer process. The man­agers of vol­un­teers from reg­u­lar pro­duct units are typ­i­cally 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 early engage­ment with research projects.

The biggest hur­dle to wide­spread adop­tion of SAP Forge is its lim­ited com­pli­ance with tools manda­tory for SAP’s gen­eral 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­tially, as a vol­un­teer effort, we didn’t have the resources to inte­grate the forge with these 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 processes. 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­ested 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­ever 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­racy prin­ci­ple). Finally, SAP has well-defined soft­ware devel­op­ment processes, 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-orga­ni­za­tion 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-speci­fic 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 other activ­i­ties. With an inter­nal forge, we’ve found that enthu­si­as­tic devel­op­ers with time, energy, and moti­va­tion are more likely to spend their effort for the good of the com­pany than for out­side projects.

References

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: Voices 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 Model,” 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­nity, Join­ing, and Spe­cial­iza­tion in Open Source Soft­ware Inno­va­tion: A Case Study,” Research Pol­icy, vol. 32, 2003, pp. 1217–1241.
9. I. Her­raiz et al., “The Processes of Join­ing in Global Dis­trib­uted Soft­ware Projects,” Proc. 2006 Int’l Work­shop Global Soft­ware Devel­op­ment for the Prac­ti­tioner, ACM Press, 2006, pp. 27–33.
10. J. Dinkelacker 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. hpts.ws/papers/2005/agenda.html.
13. S. Jarz­abek and Riri Huang, “The Case for User-Cen­tered 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 (sourceforge.net) is the best-known exam­ple on the Inter­net, host­ing the largest col­lec­tion of open source projects of any forge. Other exam­ples are BerliOS (berlios.de), Code­haus (codehaus.org), and Tigris (tigris.org). A soft­ware forge has two main views:

  • a project port­fo­lio view that lets a devel­oper browse and find projects, and
  • a project view that pro­vides the devel­oper 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-speci­fic view, which typ­i­cally has two parts:

  • a list­ing of the dif­fer­ent tools avail­able for the project, and
  • a view speci­fic to a selected 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 these 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­ily 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 happy to see that there is some hard data pro­vided to con­firm my obser­va­tion. Most impor­tantly. 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 another pin­gack from me 🙂

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

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

Leave a Reply