We are researching the governance of open source software foundations. We are specifically interested in what we call open source user consortia, that is, open source foundations where the users of the software are in the driver’s seat.
Open source software and patents are a tricky topic and resolution of the many hairy issues may need new and/or revised laws. Fraunhofer Gesellschaft is currently running a survey for the European Union to gather broad stakeholder input on the topic. I encourage participation. Deadline is Nov 30th, 2018.
Ever since Oracle got their hands on Java (by way of acquiring Sun Microsystems), it has worked hard on making money of it. As far as I can tell, it has been as unsuccessful at this as the prior owner, Sun. Compared to Sun, Oracle upped the ante by way of suing Google over Dalvik, making it harder to get JDK certification, etc. The main lever Oracle has is the ownership of the Java trademark.
Like many I assumed that Java is dying a slow death now, eventually to be replaced by the next successful initiative. Scala, Go, and others are attempts at that, though (not yet) successful ones.
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.