On a recent trip to Montreal, I reconnected with Marc Laporte, leader of the WikiSuite project and an old friend and fellow wiki enthusiast. Naturally, we talked about open source business strategies and he pointed me to one way of how commercial open source companies make money: They don’t provide you with a free upgrade path from one version to the next; you only get an upgrade if you pay.Continue reading “From the Bag of Commercial Open Source Tricks: Paying for the Upgrade”
Here is the simplest eye-opener that I have found in my consulting practice to convince management of the need for an open source program office:
Ask your manager to look at the open source license section under legal notices on their mobile phone. Ask them to scroll down to the end (they’ll never finish). Then point out that your product needs the same but doesn’t have it yet (if it doesn’t).
The reasoning behind this recommendation is that many managers simply don’t understand the extent to which open source is in their products. There is no better demonstration than to show them using a device they use frequently.
I view open source mostly from an economic perspective. From this point of view, some of the words people use are curious. For example, people like to talk about “giving back” to the community or “donating a project” to the public. These idioms have community building power, like insider speak among those who speak it, but to non-insiders, they are mostly confusing.
I feel pretty certain that these idioms slowed down the growth and adoption of open source. So let me use the two I just picked as an example and translate them.Continue reading “Time to Curb Your Open Source Wording”
I’m very much interested in the governance of open source projects, in particular if these are user-led projects. With this post, I’m proposing a basic terminology to talk about the formal organizational structure underlying the governance of such open source projects.Continue reading “A Simple Model of the Organizational Support of Open Source Projects”
Any non-trivial university has a legal department, often several (at least one for matters of teaching and one for matters of fundraising). The legal department concerned with teaching has to protect the university from lawsuits by students. By extension, this department protects students from professors who ask too much of them. Often, there may be good reasons for this. Sometimes it gets in the way of effective teaching.Continue reading “How Software Engineering Teaching and the Legal Department Collide”
Most people believe that scientists first perform basic (“fundamental”) research and then perform applied research. Basic research delivers the fundamental insights that then get detailed and refined as they hit reality in applied research. Along with this comes the request that basic research funding should be provided by the country (because few companies would ever pay for it) before industry kicks in and supports applied research. Nothing could be further from the situation in my engineering process research.Continue reading “Inverted Research Funding”
It is no secret that software is everywhere. No traditional product has remained untouched, whether the product is being produced using software or whether software is an integral part of it. As part of this wave of digitization, established vendors from outside the software industry need to avoid that someone else will reap all the profits from their products. That someone else would be software companies that supply needed components. In particular software platforms can have such network effects that their providers can reach a monopoly position so that dependent vendors who need the platform will face a diminishing profit margin.Continue reading “Why Open Source is Good for Your Economy (FOSSC19 Recap)”
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”
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.