Foremost, a product manager works on products for a market (i.e. many customers). I have never seen a product manager work on a project with one customer. For a product owner this is undefined; they could be working on a product for a market or on a project for a specific customer.

My primary goal in becoming a professor was to turn my (hoped-for excellent) research and teaching into startups. For that reason I created the Startupinformatik program and set-up my teaching to support it. Sadly, I’ve been noticing over the years that things don’t seem to get easier but harder. Specifically, “the system” (I’ll explain below) seems to view professors with mistrust rather than as the natural allies they should be when it comes to leading students to create a startup.

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?

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.

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.

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