One result of our recent case study research on inner source is that companies may not always need platform organizations to get to a platform of shared reusable assets. They will certainly need platforms, but they won’t need a dedicated organizational unit to develop and maintain this platform.
You don’t have to read the research paper to come this conclusion; common sense is just fine: Through the Apache Software Foundation (ASF), for example, companies like IBM, Oracle, and SAP are able to collaboratively develop the infrastructure of the Internet. The ASF has almost no employees; all work is done by the participating companies (and a few individuals). If companies like these, who fight each other to the death in front of a customer, can join hands to develop competitively non-differentiating software, why can’t organizational units inside software companies do this?
This is the idea of inner source: You don’t always have to have a dedicated organizational unit to work on a particular component. If the component is of broad enough interest within the company, users of this component might as well chip in and collaboratively develop the component. In the extreme case, and perhaps this is also the best case, no dedicated organizational unit is needed any longer for the development of shared reusable components.
The idea of doing away with a platform organization flies in the face of conventional wisdom. Given that textbooks tell you that product line engineering requires a dedicated platform organization, and leading companies are typically set-up this way, doing away with the platform organization may indeed prove to be too disruptive in the short-term. For this reason, we have developed several solutions that let companies keep their platform organizations.
Read more in the paper or contact us through my group’s homepage for research or my company’s homepage for commercial consulting.
I just attended FSE 2016, a leading academic conference on software engineering research. As is en vogue, it had a session on why so much software engineering research seems so removed from reality. One observation was that academics toil in areas of little interest to practice, publishing one incremental paper of little relevance after another. Another observation was that as empirical methods have taken hold, much research has become as rigorous as it has become irrelevant.
My answer to why so much software engineering research is irrelevant to practice is as straightforward as it is hard to change. The problem rests in the interlocking of three main forces that conspire to keep academics away from doing interesting and ultimately impactful research. These forces are:
- Academic incentive system
- Access to relevant data
- Research methods competence
I’m giving an invited research talk (“journal-first”) at FSE 2016 in Seattle today, Nov 15, 2016. It is in Session 5, right after lunch. The underlying Transactions on Software Engineering (TSE) paper is available here. More on inner source here.
With all the hoopla on Google Daydream coming up, I thought I’d share two photos of people high on Samsung’s Gear VR. I think Samsung chose a better name for their product. The second photo clearly shows a person with a gearface. Can’t imaging calling this a daydreamface. The future is so bright, you’ll have to wear a mobile.
Für Uni1 (http://uni1.de) suchen wir mind. einen weiteren techn. Mitgründer (oder frühen Angestellten, wenn weniger Risiko gewünscht ist).
Uni1 will die Zusammenarbeit zwischen Unternehmen und Hochschulen weltweit revolutionieren. Uni1 hat bereits Kunden und basiert auf einem erprobten Konzept. Wir können zur Zeit wg. (noch nicht) ausreichender Softwareunterstützung leider nicht skalieren.
Bei Interesse bitte Email an mich.
Dirk Riehle, firstname.lastname@example.org
Abstract: Inner source software development is firm-internal software development that uses the principles of open source software development to collaborate across intra-organizational boundaries that would otherwise hinder any such collaboration. Inner source breaks down the barriers to collaboration across development silos by setting up an internal ecosystem of readily available software components. To get started with inner source, companies need to define their goals and then set up a governance structure for an inner source program and the projects within to reach those goals. This governance structure is often codified in the form of a charter document. This technical report presents an example charter for an inner source program. The goal is for companies to be able to copy and adjust this charter for their own needs. Towards this purpose, the charter leaves open the many decisions to be made, but outlines the options that any company needs to decide upon when establishing an inner source program.
Keywords: Inner source, inner source charter
Reference: Riehle, D. (2016). An Example Charter for Inner Source Programs. Friedrich-Alexander-Universität Erlangen-Nürnberg, Dept. of Computer Science, Technical Reports, CS-2016-05, August 2016.
The paper is available as a PDF file.
More unexpected fallout from the #brexit campaign. Story here (in German). Basically, a German party send an ad-mobile to London to advertise Berlin as the new home for startups.
So the Echo Dot seems like a good addition to a larger apartment or house. In addition, Amazon promises you can order it through your existing Alexa device. So I tried:
Me: “Alexa, order an Echo Dot.”
Echo: “I can only order product for Prime members. So I added Echo Dot to your shopping list. Please get a membership.”
Me: “Alexa, f#$%^@ you.”
Echo: “That’s not very nice to say.”
Me: “OK, how about that: Alexa, scr#$%# you.”
Echo: “Well, thanks for the feedback.”
I may be in the subscription business myself, but I generally try to avoid to be on the receiving end…
You may also like The Humor that is Alexa 1 / 2. If so, don’t forget to subscribe to this blog by email (subscription form to the right) or by RSS feed.