The continued creation of me-too startup incubators reminds me of the (South Seas’) cargo cult. Richard Feynman tells the story this way: The cargo cult people were natives of the South Seas who, during the world war, benefited from Western civilizations bringing cargo to their land. After the war ended, and the cargo stopped coming, the natives built wooden artifacts that looked like planes in an attempt to bring back the good old days of free supplies. Obviously, it didn’t work.
I was recently asked why I argue against company-internal marketplaces for software components yet emphasize the need for pricing components that cross company boundaries within the same holding company (also known as transfer pricing). The answer is simple: Setting up an internal marketplace is a managerial choice and pricing the movement of code (IP) across company boundaries is a taxable event that you need to deal with: It is not a choice.
Let me take it in steps.
Digital Ocean just published a survey of developers that indicates how companies are getting more comfortable with using open source, but remain much less comfortable with contributing to open source. Matt Asay and Chris Aniszczyk picked up on this, suggesting that open source will become more sustainable if we get those contribution numbers up. What is it that is keeping companies from letting their developers contribute?
Here is a representative experience from some recent consulting activity of mine. I asked:
So what about your open source policy?
The first manager answered:
Uh, I don’t think we have one.
The second manager:
Not true, our policy is not to do it.
The third one, somewhat puzzled:
Uhm, what about this Eclipse plug-in we are developing?
This is obviously wrong. The use of dual licensing and the ability to provide superior service for open source are unrelated forms of competitive advantage, and without further circumstances, a business should exploit both advantages. Let me explain.
Dual (or multiple) licensing is a strategy, in which a company develops software, releases it under an aggressively reciprocal (“viral”) license like the AGPLv3 and then offers commercial customers who don’t like the open source license the option to acquire a proprietary license for the software. This is a positional advantage of the vendor, because it is the only company that can apply this strategy (courtesy of being the copyright holder). While I mix things up a bit, it is closely related to what’s been called the open core model or single vendor open source. To maintain this positional advantage, vendors need to follow the commercial open source intellectual property rights imperative.
Update 2018-10-16: MongoDB is facing the same problem and decided to go closed source, see the press release.
The brouhaha around Redis Labs taking some enterprise modules of its popular open source in-memory database Redis closed source has somewhat calmed down. However, I didn’t see any discussion of what I thought was the most interesting conclusion of the affair: A core strategy of commercial open source,
the dual-licensing of the software under an aggressive copyleft and a commercial license may not work when cloud providers are involved.
Open source is a viable business strategy for software vendors to disrupt existing markets and conquer new ones. Just why is it easy in some markets and hard in others? I argue that you need to cut the product in such a way that there is a clear separation between what a never-paying community-user wants and what a commercial customer needs. In addition, you need to tie the commercial features closely to your company’s intellectual property and capabilities to keep competitors at bay. If you can do that, you are in the right place. If you can’t, you may want to get out of there.
Redis is a popular open source database. Its proprietor, Redis Labs, recently announced that some add-on modules will not be open source any longer. The resulting outcry led to a defense and explanation of this decision that is telling. I have two comments and a lesson about product management of commercial open source.
The two comments are about messaging, both ways: What Redis Labs is telling the world and what the open source world is telling Redis Labs and the rest of the world.
Am 18. September 2018 findet in Erfurt das 2018 Bitkom Forum Open Source statt. Thema ist die Werkzeugunterstützung von Open Source Governance und Compliance in der Softwarelieferkette. Meine Forschungsgruppe wird mit einem Vortrag zu Anforderungen an Open Source Governance and License Compliance vertreten sein, basierend auf einem gleichnamigen auf der OSS 2018 präsentierten Papier. Please come and join us!
For my AMCIS 2009 talk on the single-vendor commercial open source business model, first the abstract, then the slides:
Commercial open source software projects are open source software projects that are owned by a single firm that derives a direct and significant revenue stream from the software. Commercial open source at first glance represents an economic paradox: How can a firm earn money if it is making its product available for free as open source? This paper presents the core properties of commercial open source business models and discusses how they work… [more]
For a discussion of the talk’s contents I recommend reading the original article.
I guess everybody knows it but nobody ever named it, as far as I know, so I’m doing it here:
The Intellectual Property Rights Imperative of Single-Vendor Commercial Open Source Always act in such a way that you, and only you, possess the right to provide the open source project under a license of your choice.