Platforms but no Platform Organizations

One result of our recent case study research on inner source is that com­pa­nies may not always need plat­form orga­ni­za­tions to get to a plat­form of shared reusable assets. They will cer­tain­ly need plat­forms, but they won’t need a ded­i­cat­ed orga­ni­za­tion­al unit to devel­op and main­tain this plat­form.

You don’t have to read the research paper to come this con­clu­sion; com­mon sense is just fine: Through the Apache Soft­ware Foun­da­tion (ASF), for exam­ple, com­pa­nies like IBM, Ora­cle, and SAP are able to col­lab­o­ra­tive­ly devel­op the infra­struc­ture of the Inter­net. The ASF has almost no employ­ees; all work is done by the par­tic­i­pat­ing com­pa­nies (and a few indi­vid­u­als). If com­pa­nies like the­se, who fight each oth­er to the death in front of a cus­tomer, can join hands to devel­op com­pet­i­tive­ly non-differentiating soft­ware, why can’t orga­ni­za­tion­al units inside soft­ware com­pa­nies do this?

This is the idea of inner source: You don’t always have to have a ded­i­cat­ed orga­ni­za­tion­al unit to work on a par­tic­u­lar com­po­nent. If the com­po­nent is of broad enough inter­est with­in the com­pa­ny, users of this com­po­nent might as well chip in and col­lab­o­ra­tive­ly devel­op the com­po­nent. In the extreme case, and per­haps this is also the best case, no ded­i­cat­ed orga­ni­za­tion­al unit is need­ed any longer for the devel­op­ment of shared reusable com­po­nents.

The idea of doing away with a plat­form orga­ni­za­tion flies in the face of con­ven­tion­al wis­dom. Given that text­books tell you that pro­duct line engi­neer­ing requires a ded­i­cat­ed plat­form orga­ni­za­tion, and lead­ing com­pa­nies are typ­i­cal­ly set-up this way, doing away with the plat­form orga­ni­za­tion may indeed prove to be too dis­rup­tive in the short-term. For this rea­son, we have devel­oped sev­er­al solu­tions that let com­pa­nies keep their plat­form orga­ni­za­tions.

Read more in the paper or con­tact us through my group’s home­page for research or my company’s home­page for com­mer­cial con­sult­ing.

Challenges to making software engineering research relevant to industry

I just attend­ed FSE 2016, a lead­ing aca­d­e­mic con­fer­ence on soft­ware engi­neer­ing research. As is en vogue, it had a ses­sion on why so much soft­ware engi­neer­ing research seems so removed from real­i­ty. One obser­va­tion was that aca­d­e­mics toil in areas of lit­tle inter­est to prac­tice, pub­lish­ing one incre­men­tal paper of lit­tle rel­e­vance after anoth­er. Anoth­er obser­va­tion was that as empir­i­cal meth­ods have tak­en hold, much research has become as rig­or­ous as it has become irrel­e­vant.

My answer to why so much soft­ware engi­neer­ing research is irrel­e­vant to prac­tice is as straight­for­ward as it is hard to change. The prob­lem rests in the inter­lock­ing of three main forces that con­spire to keep aca­d­e­mics away from doing inter­est­ing and ulti­mate­ly impact­ful research. The­se forces are:

  • Aca­d­e­mic incen­tive sys­tem
  • Access to rel­e­vant data
  • Research meth­ods com­pe­tence

Con­tin­ue read­ing

Invited Research Talk on Inner Source at FSE 2016

I’m giv­ing an invit­ed research talk (“journal-first”) at FSE 2016 in Seat­tle today, Nov 15, 2016. It is in Ses­sion 5, right after lunch. The under­ly­ing Trans­ac­tions on Soft­ware Engi­neer­ing (TSE) paper is avail­able here. More on inner source here.

Putting on their #Gearface (no Google Daydream)

With all the hoopla on Google Day­dream com­ing up, I thought I’d share two pho­tos of peo­ple high on Samsung’s Gear VR. I think Sam­sung chose a bet­ter name for their pro­duct. The sec­ond pho­to clear­ly shows a per­son with a gear­face. Can’t imag­ing call­ing this a day­dream­face. The future is so bright, you’ll have to wear a mobile.

Mitgründer für Startup mit existierenden Kunden gesucht

Für Uni1 (http://uni1.de) suchen wir mind. einen weit­eren techn. Mit­grün­der (oder frühen Angestell­ten, wenn weniger Risiko gewün­scht ist).

Uni1 will die Zusam­me­nar­beit zwis­chen Unternehmen und Hochschu­len weltweit rev­o­lu­tion­ieren. Uni1 hat bere­its Kun­den und basiert auf einem erprobten Konzept. Wir kön­nen zur Zeit wg. (noch nicht) aus­re­ichen­der Soft­ware­un­ter­stützung lei­der nicht skalieren.

Ide­al wäre ein Full-Stack-Entwickler mit entsprechen­der Erfahrung in Java + Javascript und Web-Technologien. Sozialkom­pe­tenz und die Fähigkeit in einem schnel­len Umfeld zu arbeit­en sind eben­so wichtig. Als Ort ist Berlin oder Nürn­berg ide­al, aber kein Muss.

Bei Inter­esse bit­te Email an mich.

Dirk Riehle, dirk@uni1.de

An Example Charter for Inner Source Programs

Abstract: Inner source soft­ware devel­op­ment is firm-internal soft­ware devel­op­ment that uses the prin­ci­ples of open source soft­ware devel­op­ment to col­lab­o­rate across intra-organizational bound­aries that would oth­er­wise hin­der any such col­lab­o­ra­tion. Inner source breaks down the bar­ri­ers to col­lab­o­ra­tion across devel­op­ment silos by set­ting up an inter­nal ecosys­tem of read­i­ly avail­able soft­ware com­po­nents. To get start­ed with inner source, com­pa­nies need to define their goals and then set up a gov­er­nance struc­ture for an inner source pro­gram and the projects with­in to reach those goals. This gov­er­nance struc­ture is often cod­i­fied in the form of a char­ter doc­u­ment. This tech­ni­cal report presents an exam­ple char­ter for an inner source pro­gram. The goal is for com­pa­nies to be able to copy and adjust this char­ter for their own needs. Towards this pur­pose, the char­ter leaves open the many deci­sions to be made, but out­li­nes the options that any com­pa­ny needs to decide upon when estab­lish­ing an inner source pro­gram.

Key­words: Inner source, inner source char­ter

Ref­er­ence: Riehle, D. (2016). An Exam­ple Char­ter for Inner Source Pro­grams. Friedrich-Alexander-Universität Erlangen-Nürnberg, Dept. of Com­put­er Sci­ence, Tech­ni­cal Reports, CS-2016–05, August 2016.

The paper is avail­able as a PDF file.