But what if someone steals my inner source code?

During my talk at the inner source summit, I was asked about the following worry with establishing inner source at a company:

But if we lay all source code open within the company, don’t we run the risk that a disgruntled employee has it too easy to steal all code and publish it on the web?

The main answer to this question is to weigh benefits against risks. The benefits of inner source have been explained elsewhere, for example, in said talk of mine. The risks may seem less clear. So, could it happen that an employee steals all source code? What damage would it do?

Continue reading “But what if someone steals my inner source code?”

Slides for Keynote at Inner Source Commons Summit at Bosch

Today, I gave a keynote at the 2018 spring Inner Source Commons summit at Bosch, in Renningen, Germany. I talked about our experiences with ten years of inner source projects at the companies we have been working with. The slides are available as a PDF.

The photo above is from the first keynote of the day, by Stefan Ferber, CEO of Bosch Software Innovations, celebrating the diversity and global distribution of software development at Bosch.

FOSS Compliance Intensive Seminar June 14-15th, 2018 in Berlin (in German)

Catharina Maracke’s Software Compliance Academy writes to us:

Die Bedeutung der Open Source-Lizenzen und die Frage der Open Source Compliance hat in den vergangenen Jahren vor allem in der IT-Wirtschaft an Bedeutung gewonnen. Aber auch andere Industriezweige sehen sich zunehmend mit Fragen rund um den Einsatz von Open Source-Software konfrontiert:

  • Welche juristischen Vorgaben gilt es beim Einsatz von Open Source-Software im Unternehmen und vor allem in kommerziellen Produkten zu beachten?
  • Welche Anforderungen sind an das Lizenzmanagement zu stellen und welchen Beitrag kann ein standardisierter Lizenzmanagement Prozess (OpenChain) leisten?
  • Welche Möglichkeiten (und welche Grenzen) bieten technische Ansätze im Bereich Lizenzmanagement?

Sofern diese Fragen auch für Sie oder Ihre Kooperationspartner bzw. Ihr Netzwerk von Interesse sind, möchte ich Sie gerne auf unser kommendes zweitägiges Open Source Compliance Seminar in Berlin am 14. und 15. Juni 2018 hinweisen. Neben den Referenten der Software Compliance Academy wird auch Shane Coughlan, Leiter des OpenChain Projektes bei der Linux Foundation, einen Teil des Seminars übernehmen und die aktuellen Entwicklungen des OpenChain Projektes vorstellen.

Das detaillierte Programm finden Sie unter http://www.scompliance.com/files/uploads/seminare/FOSSCompliance14.u.15.06.2018.pdf

Die Online-Anmeldung finden Sie unter http://www.scompliance.com/seminar.html

Understanding Industry Requirements for FLOSS Governance Tools

Abstract: Almost all software products today incorporate free/libre, and open source software (FLOSS) components. Companies must govern their FLOSS use to avoid potential risks to their intellectual property resulting from the use of FLOSS components. A particular challenge is license compliance. To manage the complexity of license compliance, companies should use tools and well-defined processes to perform these tasks time and cost efficiently. This paper investigates and presents common industry requirements for FLOSS governance tools, followed by an evaluation of the suggested requirements by matching them with the features of existing tools. We chose 10 industry-leading companies through polar theoretical sampling and interviewed their FLOSS governance experts to derive a theory of industry needs and requirements for tooling. We then analyzed the features of a governance tools sample and used this analysis to evaluate two categories of our theory: FLOSS license scanning and FLOSS in product bills of materials. The result is a list of FLOSS governance requirements based on our qualitative study of the industry, evaluated using the existing governance tool features. For higher practical relevance, we cast our theory as a requirements specification for FLOSS governance tools.

Keywords: Open Source Software, FLOSS, FOSS, Open Source Governance, FLOSS governance tools, company requirements for FLOSS tools

Reference: Nikolay Harutyunyan, Andreas Bauer, and Dirk Riehle. 2018. Understanding Industry Requirements for FLOSS Governance Tools. In OSS ’18: 14th International Conference on Open Source Systems, June 8-10, 2018, Athens, Greece. Springer, IFIP Advances in Information and Communication Technology, 12 pages.

A preprint of the paper is available here as a PDF file.

Research papers vs. blog posts

A short Twitter thread:

Scientific research papers cite other research papers for related or prior knowledge they build on; they cite blog posts as primary material to work with in theory building; two very different things 1/4

A blog post needs to (a) properly use the scientific method and (b) be socially validated by peer review to be considered a scientific research article; for (b) it needs a traditional journal 2/4

The problem with research papers are for-profit publishers and the to-pay open access model; publishers are bottom feeding to increase revenue, hurting the reputation of science with low quality papers 3/4

Please don’t start another journal unless you have an answer that solves the conflict between for-profit publishing and academic publishing incentives @timoreilly 4/4

The Patch-Flow Method for Measuring Inner Source Collaboration

Abstract: Inner source (IS) is the use of open source software development (SD) practices and the establishment of an open source-like culture within an organization. IS enables and requires developers to collaborate more than traditional SD methods such as plan-driven or agile development. To better understand IS, researchers and practitioners need to measure IS collaboration. However, there is no method yet for doing so. In this paper, we present a method for measuring IS collaboration by measuring the patch-flow within an organization. Patch-flow is the flow of code contributions across organizational boundaries such as project, organizational unit, or profit center boundaries. We evaluate our patch-flow measurement method using case study research with a software developing multi-industry company. By applying the method in the case organization, we evaluate its relevance and viability and discuss its usefulness. We found that about half (47.9%) of all code contributions constitute patch-flow between organizational units, almost all (42.2%) being between organizational units working on different products. Such significant patch-flow indicates high relevance of the patch-flow phenomenon and hence the method presented in this paper. Our patch-flow measurement method is the first of its kind to measure and quantify IS collaboration. It can serve as a base for further quantitative analyses of IS collaboration.

Keywords: Inner source, internal open source, inner source measurement, patch-flow, open source, open collaboration, software development collaboration measurement, inner source metrics

Reference: Maximilian Capraro, Michael Dorner, and Dirk Riehle. 2018. The Patch-Flow Method for Measuring Inner Source Collaboration. In MSR ’18: 15th International Conference on Mining Software Repositories , May 28–29, 2018, Gothenburg, Sweden. ACM, New York, NY, USA, 11 pages.

A preprint of the paper is available here as a PDF file.

Research Questions on Product Management of Open Source in Commercial Products

I’m seeking advice on how to frame the research question for a research project (Ph.D. thesis) on software product management and open source. The simple heuristic “non-differentiating -> open source it, competitively differentating -> keep it closed” doesn’t cut it because of secondary effects like development efficiency resulting from open sourcing, market opportunities resulting from platform compatiblity, etc.

The best I could come up with so far are three different but related questions. These are:

  1. For a non-differentiating function, which open source component to use?
  2. For a chosen open source component, how to manage this dependency?
  3. For a competitively differentiating function, when to open source?

Questions 1 and 2 are well-defined. Question 3 remains unwieldy. The heuristic mentioned above would answer “never”, but this is not true, as explained. Overall competitive situation and compatibility considerations may still lead to open sourcing unique intellectual property.

I’m seeking comments as to how practitioners (or other researchers) would look at this question. Any comments are appreciated.