Software Research and the Industry
Dirk Riehle's blog on everything computer science and more
Open collaboration was popularized by open source projects, and since has made its way into wikis and Wikipedia, the mix and remix culture and open content, open educational resources, and so forth. Just what exactly is it?
Continue reading “What is Open Collaboration?”
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
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”
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”
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”
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”
I received several requests recently for my inner source charter document to provide it in DOC format, after I thought this work had fallen dormant (or perhaps the PDF version was sufficient). So I wanted to add my thoughts on how to take first steps in inner source, in particular in the selection of a pilot project.
Continue reading “Getting Started With Inner Source”
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”
Ever since autonomous driving became a hot topic, I’ve tried to sell to our automotive industry partners the idea of a project to build a moral machine in autonomous driving. My definition of a moral machine (there are others) is:
Continue reading “The Argument Against a Moral Machine in Autonomous Driving”
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.