On the heels of my talk about the current licensing challenges to single-vendor open source firms, I want to discuss the resulting strategy for vendors selling to developers.
Single-vendor open source firms go to market by providing software they developed to the world under an open source license. The goal is to create a large non-paying user base, from which customers are acquired using a variety of incentives. One type of single-vendor open source projects are application component projects like MongoDB (a NoSQL database) or Confluent Platform (a stream processing platform based on Apache Kafka). It is these types of companies which ran into licensing problems.
Continue reading “Free-to-Use, Unless You Are a Cloud Provider (The New Strategy?)”
In yesterday’s talk I reviewed the current licensing struggle of single-vendor open source firms. Single-vendor open source firms go to market by providing software they developed for free, under an open source license, while also offering a commercially licensed version of this software, possibly with extensions and services that customers may want to pay for. Because of the open source version of this software, large cloud vendors can compete with the original vendor for running this software as a service. They did this so well that some single-vendor firms decided to change their future licensing to a proprietary license to stall the competition, irking the open source community and creating a backlash on many sides.
Continue reading “Why Now? And Who? The Struggle Over Single-Vendor / Open-Core Licensing”
I’ll be giving a presentation on single-vendor open source today at the Linux Foundation Open Source Leadership Summit 2019.
Abstract: Most venture capital funding in open source flows to single-vendor open source firms. With the struggles over licensing in the cloud, these companies find themselves at the crossroads: Stay true to open source or move to proprietary licenses, abandoning the goodwill and opportunities that come with open source? In this talk I will review how this business model works, discuss the challenges posed to vendors by large cloud providers, and review the options on the table.
If you liked the slides, you might like the paper as well.
Next up: Why now? And who? The struggle over single-vendor / open-core licensing.
Another role or function that is often confusing to Germany high-tech companies is product management. Startups tend to get it right these days, but large organizations often remain unfazed by a lack of strong product management.
A product manager is responsible for defining the product innovation and associated business plan (strategic product management) as well as working out features to a level of detail (technical product management) so that they can be passed on to engineering. As the saying goes,
Continue reading “The Importance of Product Management”
A product manager is responsible for building the right product, while an engineering manager is responsible for building the product right.
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”
These photos are of the iconic (and rather ugly) circular footbridge in Causeway Bay, Hong Kong. This location (and many others in Hong Kong) were the set for scenes from the Hollywood movie Ghost in the Shell, an adaptation of the classic Ghost in the Shell anime franchise. The footbridge was the backdrop for a major battle between the heroine of the movie and a tank.
Many of the shots in the life-action movie were made in Hong Kong, presumably because Hong Kong is closer to the Tokyo of anime fiction than, well, Tokyo itself.
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”