The fiercer the competition, the more companies open source

How come that companies like IBM, Oracle, and Microsoft are leading so much open source these days? How is it possible that they harmoniously (most of the time anyway) collaborate with each other at the Apache Software Foundation or even Linux Foundation, while they fight each other to the bone in front of the customer?

Continue reading “The fiercer the competition, the more companies open source”

Code of conduct for code reviews

On Twitter, @arkwrite suggested that a code review should always say something nice and @chaos_monster commented that we need a code of conduct for code reviews. All of this makes sense to me, however, I suggest that we first have a general code of conduct of productive discussions (and most companies have something like it). The two main rules that come to my mind are:

  1. Separate the person from the issue
  2. Praise liberally, criticize specifically

Separating a person from the issue makes sure that you focus on the technical problem, not the person. Praising liberally is just good practice, showing how you value a person’s contribution. If you have to criticize for good reason, be specific so that the underlying technical issue is clear and provides a chance to respond.

Continue reading “Code of conduct for code reviews”

Who writes and prioritizes user stories?

I updated this post after I realized that it is more about prioritizing user stories than it is about writing them well.

In Scrum, a product owner writes user stories to capture requirements and prioritizes them in a product backlog as the upcoming work queue for developers. The main question on my mind is:

Who has the capabilities and competencies to write good user stories and prioritize them in a product backlog?

The INVEST criteria list quality measures (of sorts) that determine what a good user story is. It should be Independent, Negotiable, Valuable, Estimatable, Small, and Testable. While fundamentally correct, there is much more to say. For example, in a product backlog, user stories should use a consistent vocabulary, based on a shared domain model (or glossary, at a minimum).

Continue reading “Who writes and prioritizes user stories?”

Product manager vs. product owner

Random photo

Alistair Cockburn pointed us to an excellent article by Melissa Perri about the differences between a product manager and (Scrum) product owner. The article clarifies some confusion. I’d like to repeat and emphasize some points that have been omitted (and where I also disagree).

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.

Continue reading “Product manager vs. product owner”

Professors and startups

Random photo

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.

Let me illustrate this using two experiences:

Continue reading “Professors and startups”

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?”

Why don’t companies open source more of their in-house code?

John Mark Walker, in a thread started by Matt Asay, nudged me to provide my opinion on the subject matter. Here we go as a Twitter thread. (I’m trying out Twitter collections and threading for the first time; advice on how to do it better is appreciated.)

Why companies don’t always freeride 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 freeride on open source projects”