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.

Why Companies Don’t Always Free-ride on Open Source Projects

I presented on open source foundations earlier this week to economist friends at TU Munich. I naturally got the question about freeriding: Why does anyone contribute to open source projects, if they could do something else with their time? The cinch: This time we are talking about companies, not invididual people, so the arguments about altruism and signaling don’t apply. So, why do companies contribute and don’t just freeride? I don’t think this question has been answered well yet in economics, and I’m not sure established theory has a ready answer.

To make it short: I believe the most direct reason why companies contribute to open source projects is to lower their cost of consumption of that very project. Specifically, contributing to a project builds competence in that project, and employing committers builds additional foresight and influence. General compentence makes the company use the software more effectively, avoiding costly bugs and rework. Foresight and influence helps the company avoid misalignment of their products with the evolving open source software they depend on. Such misalignment can also lead to costly rework and missed market opportunities.

I’m not aware of any RoI model that helps an engineering manager determine how much to contribute to achieve how much lower consumption costs and risks. Because of the step function from contributor to committer status for the involved employees, the investment return is not a linear function, that much we can say. The rest remains imperfect science for now.

Continue reading “Why Companies Don’t Always Free-ride on Open Source Projects”

Call for Papers: 1st Workshop on Innovative Software Engineering Education (ISEE 2018)

http://www1.in.tum.de/isee2018

In conjunction with the Software Engineering Conference 2018 in Ulm, March 6, 2018

Motivation

The number of students continuously increases and presents ever greater challenges for instructors in software engineering. In courses with a huge number of students, it is particularly difficult to motivate students to actively participate. At the same time, practice-oriented and project-related training is becoming increasingly important, but project courses in cooperation with industry are often associated with high costs.

Digital teaching, online courses and new teaching concepts complement the curriculum. They offer a wide range of possibilities for modern and attractive teaching, but pose methodical, technical and organizational challenges for instructors.

Continue reading “Call for Papers: 1st Workshop on Innovative Software Engineering Education (ISEE 2018)”

Call for Papers: 3rd Workshop on Continuous Software Engineering (CSE 2018)

http://cse2018.swc-rwth.de/

In conjunction with Software Engineering 2018

Ulm, March 6, 2018

Scope of the workshop

In order to develop and deliver high-quality products to their customers, software companies have to adopt state-of-the-art software development processes. To face this challenge, companies are applying innovative methods, approaches and techniques like agile methods, DevOps, Continuous Delivery, test automation, infrastructure as code or container-based virtualization.

Continue reading “Call for Papers: 3rd Workshop on Continuous Software Engineering (CSE 2018)”

License Clearance in Software Product Governance

I recently participated in an NII Shonan workshop on open source ecosystems. As a follow-up, we are preparing a book of articles. I’m contributing a chapter on “license clearance in software product governance”. Obviously, open source plays an important role. Please find abstract and paper below.

Abstract: Almost all software products today include open source components. However, the obligations that open source licenses put on their users can be difficult or undesirable to comply with [25] [14] [20]. As a consequence, software vendors and related companies need to govern the process by which open source components are included in their products [21] [7]. A key process of such open source governance is license clearance, that is, the process by which a company decides whether a particular component’s license is acceptable for use in its products [19] [4] [15]. In this article, we discuss this process, review the challenges it poses to software vendors and provide unanswered research questions that result from it.

Read the full paper as HTML or as a PDF. The final reference will be announced once the book has been published.

Inner Source Definition, Benefits, and Challenges

Abstract: Inner Source (IS) is the use of open source software development practices and the establishment of an open source-like culture within organizations. The organization may still develop proprietary software but internally opens up its development. A steady stream of scientific literature and practitioner reports indicates the interest in this research area. However, the research area lacks a systematic assessment of known research work: No model exists that defines IS thoroughly. Various case studies provide insights into IS programs in the context of specific organizations but only few publications apply a broader perspective. To resolve this, we performed an extensive literature survey and analyzed 43 IS related publications plus additional background literature. Using qualitative data analysis methods, we developed a model of the elements that constitute IS. We present a classification framework for IS programs and projects and apply it to lay out a map of known IS endeavors. Further, we present qualitative models summarizing the benefits and challenges of IS adoption. The survey provides the first broad review of IS literature and systematic arrangement of IS research results.

Keywords: Inner source, inner source definition, inner source benefits, inner source challenges

Reference: Capraro, M., & Riehle, D. (2017, February). Inner Source Definition, Benefits, and Challenges. ACM Computing Surveys, vol. 49, no. 4, article 67.

The paper is available as a PDF file.