What is Open Communication?

Open source collaboration requires open communication, they say. Just what is open communication, exactly? Drawing on past research [1], here are the four principles that make communication open. Open communication is communication that is

  • Public: All communication takes place in the public eye, and none or very little behind closed doors; private side-discussions are discouraged.
  • Complete: All communication is complete to the extent possible. Assumptions are made explicit and conclusions of discussions are summarized.
  • Written: All communication is in written form, allowing folks to participate at their own pace; any non-written communication will be transcribed.
  • Archived: All communication is archived for search and later retrieval. This documents communication for those not around (or awake).
Continue reading “What is Open Communication?”

The GNU Public License v2 in the Land of Microservices

Another question I get asked is how containers and new architectural styles like microservices-based architectures relate to copyleft licenses, in particular the GPLv2 license.

First things first: I don’t recommend taking a “let’s work around this pesky license” approach. You should follow both a license’s spirit and letter; license evasion (“Umgehungsversuch”) may not hold up in court. Someone is trying to do you well, but only under certain conditions, so take it (properly) or leave it.

With that: If you package copyleft-licensed code in a container image and distribute this image, does the copyleft-licensed code affect any other container it communicates with?

Continue reading “The GNU Public License v2 in the Land of Microservices”

Open Source License Compliance and Work-for-Hire

A common question that I am asked in my seminar on license-compliant delivery of products that contain open source software is:

But what about a work-for-hire? We are a consulting company: As we work for our clients, and use open source software, do we have to create all those legal notices?

The answer, as so often is: It depends. With that, let’s tease the different situations apart.

Continue reading “Open Source License Compliance and Work-for-Hire”

CTO vs. VP of Engineering

In tech companies, startups and large companies alike, of the many roles you need to define, two seem to be particularly confusing to German startups: The CTO and the VP of Engineering role. Many German startups I’ve seen simply have a person titled CTO who does both (and sometimes neither). These two roles are very different! They require different skill sets and while temporarily one person may be able to fill both shoes, longer term they are better filled by two different people. In more detail:

Continue reading “CTO vs. VP of Engineering”

Escalating Levels of Complexity in Inner Source Projects

Yesterday, I discussed what makes a good pilot project in inner source. The main thrust of the suggestion was not to start with a big bang but rather to choose a relevant but not too large project. This begs the question of complexity of projects, specifically viewed from an inner source perspective. How should you escalate and grow your ambition for inner source projects? I see a 1 + 3 structure of levels.

Continue reading “Escalating Levels of Complexity in Inner Source Projects”

The Argument For a Moral Machine in Autonomous Driving

I have a strong aversion against letting people drag their feet from being responsible for their actions. I feel particularly strongly about this when delegating work to machines, which are not able to act using an appropriate moral value system. Starting a car and letting an autonomous driving unit take over is one such example: When faced with an impossible situation (run over an old lady or three children or commit suicide), it still has to be the driver’s decision and not a machine’s.

Continue reading “The Argument For a Moral Machine in Autonomous Driving”

Too Many Points of Failure (at Theranos)

I just finished reading John Carreyrou’s book Bad Blood, which presents the story of the rise and fall of one-time Silicon Valley unicorn Theranos through his eyes as the journalist who broke the story. In case you missed it: Theranos was a healthcare company promising to sell a machine that could perform quickly and reliably a large number of blood tests needed by medical doctors to aid their patient care. The hitch: The technology never worked and Theranos managed to hide this from investors and the public for a long time.

Continue reading “Too Many Points of Failure (at Theranos)”