An Example Charter for Inner Source Programs

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.

Re: Your unsolicited email / our joint problem

To: ana.tackett@orcapr.com, eastonjohnston@iodimpact.com, digitalpragency@gmail.com, RobertP@informationhub.biz, gina@bloc.io, pms990@gmail.com, jillr@blackswansmedia.com, davidf@lfpr.com, khurst@harriswilliams.com, nancyt@vorticom.com, james@planet-dm.com, …

Dear PR professional:

With respect to our joint problem, Stanford researchers have found a solution!

Please see here for the answer: http://www.scs.stanford.edu/~dm/home/papers/remove.pdf

With kind regards,

Dirk Riehle

PS: If the research paper above doesn’t load, please see this copy: http://dirkriehle.com/wp-content/uploads/2016/06/remove.pdf

The Humor that is Alexa 2 / 2

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.

The Humor that is Alexa 1 / 2

I was watching an old TV show rerun with a character in it called Alexa. My Amazon Echo (trigger word is Alexa) was also listening:

TV set: “Alexa, stop doing that!”
Echo: “Sorry, I don’t understand what you are saying.”
TV set (raised voice): “Alexa, don’t talk to me like that!”
Echo: “Sorry, I still don’t understand what you are saying.”
Despite a few more “Alexa, …” it fell quiet.

I’m amused. Ever since I have wondered what a mischievous screen writer could do given that the Echo can control a garden variety of devices in your house. Or order stuff. How about:

Mischievous character in TV show: “Alexa, open the blinds. Alexa, switch on the lights” (probably most effective a 1am or 5am)
Domino avatar on TV show: “Alexa, order 17 frutti di mare pizzas”

The possibilities seem endless.

Inner Source in Platform-based Product Engineering

Abstract: Inner source is an approach to collaboration across intra-organizational boundaries for the creation of shared reusable assets. Prior project reports on inner source suggest improved code reuse and better knowledge sharing. Using a multiple-case case study research approach, we analyze the problems that three major software development organizations were facing in their product line engineering efforts. We find that a root cause, the separation of product units as profit centers from a platform organization as a cost center, leads to delayed deliveries, increased defect rates, and redundant software components. All three organizations assume that inner source can help solve these problems. The article analyzes the expectations that these companies were having towards inner source and the problems they were experiencing in its adoption. Finally, the article presents our conclusions on how these organizations should adapt their existing engineering efforts.

Keywords: Inner source, inner source foundation, product-line engineering, software platforms, engineering productivity

Reference: Riehle, D., Capraro, M., Kips, D., & Horn, L. (2016). Inner Source in Platform-Based Product Engineering. IEEE Transactions on Software Engineering vol. 42, no. 12 (December 2016), 1162-1177.

The paper is available as a PDF file.

Using Students as a Distributed Coding Team for Validation through Intercoder Agreement

Abstract: In qualitative research, results often emerge through an analysis process called coding. A common measure of validity of theories built through qualitative research is the agreement between different people coding the same materials. High intercoder agreement indicates that the findings are derived from the data as opposed to being relative results based on the original researcher’s bias. However, measuring such intercoder agreement incurs the high cost of having additional researchers perform seemingly redundant work. In this paper we present first results on a novel method of using students for validating theories. We find that intercoder agreement between a large number of students is almost as good as the intercoder agreement between two professionals working on the same materials.

Keywords: Qualitative Data Analysis, Theory Triangulation, Intercoder Agreement, Distributed Coding, Collective Coding

Reference: Andreas Kaufmann, Ann Barcomb and Dirk Riehle. “Using Students as a Distributed Coding Team for Validation through Intercoder Agreement.” Friedrich-Alexander-Universität Erlangen-Nürnberg, Dept. of Computer Science, Technical Reports, CS-2016-01, April 2016.

The paper is available as a local PDF file and also on FAU’s OPUS server.

Das Uni1 Projektkonzept (2016)

Abstract: Die­ses Pro­jekt­kon­zept schil­dert, wie Hoch­schu­len mit Unter­neh­men Pro­jekte mit Stu­die­ren­den zu beid­sei­ti­gem Gewinn durch­füh­ren kön­nen. Unter­neh­men pro­fi­tie­ren durch Recruit­ing, Out­sour­cing und Inno­va­tion („ROI“), wel­che sich durch die Pro­jekte erge­ben. Hoch­schu­len gewin­nen neue Part­ner, ver­die­nen an den Pro­jek­ten und bie­ten attrak­ti­vere Lehre.

Keywords: Industrie-Hochschul-Kooperation, Forschungstransfer, Geschäftsmodell

Reference: Dirk Riehle. “Das Uni1 Projektkonzept (2016).” Friedrich-Alexander-Universität Erlangen-Nürnberg, Dept. of Computer Science, Technical Report, CS-2016-04. Erlangen, Germany, 2016.

The paper is available as a local PDF file and also on FAU’s OPUS server.

See also the Uni1 website.

Lost over Call for Open Access for all Scientific Papers

I’m at a loss over the recent reports on the requirement for all research publications to be open access by 2020. Open access means that the research papers are accessible openly without a fee. There are plenty of confusing if not outright wrong statements in the press, but I’m not so much concerned with poor journalism than with the actual proposed policies.

Sadly, I couldn’t find more than this one sentence on page 12 of the report linked to from the meetings website:

Delegations committed to open access to scientific publications as the option by default by 2020.

I’d like to understand what this means and then how this is supposed work. Specifically, I’d like to know how this is not going to either break free enterprise or make predatory publishers like Elsevier laugh all the way to the bank.

Continue reading