Open source license compliance is not for the faint of heart. Among many things, a company needs to tell the recipients of a distribution which open source software is used in their products. In the case of mobile apps, free or not, the user is the recipient and the app is the distribution. Downloading an app from the app store makes me a user. Lets see what we can learn about open source using an example app.
The following four screenshots show how I made my way from finding an app through installing and starting it. I could not find any information about the distributed open source code along the way.
tl;dr The software development contexts that I deal most with these days are open source projects and fast-moving startups; both don’t seem to have much use for what is traditionally taught in software architectures courses.
Let me start by saying that I love a good software architecture as well as software architecture in general. My dissertation was on better modeling object-oriented frameworks and I have played the architect role for most of my engineering days. I even started a traditional software architecture course at my university. However, I got bored quickly and couldn’t connect it to the practice I dealt with, so I passed the course on to a colleague who is now teaching it. I do teach, however, the associated software architecture project, in which student teams perform some analysis and provide recommendations on a real-world architecture provided by an industry partner.
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.
You may have seen the video below by Boston Dynamics. It shows a robot dog dancing to Uptown Funk by Bruno Mars. It is fun and funny to watch, but people also expressed serious worries about robot inroads into human behavior. However, there is no explanation by Boston Dynamics and it is not at all clear whether this is a simple magic trick created to fool the onlookers or real artificial intelligence (AI) progress.
as causes for problems in software product line engineering. Of several more, I want to pick a third and final one, before we turn to the root cause of it all in the next blog post. This third cause is the political power play between product units as they try to prioritize requirements for the platform organization.
As previously posted, we analyzed current problems in product line engineering. One case study was a healthcare software product line, one was a business software product line, and one was a telco carrier software product line. All developers in their respective product line were homogeneous in time and culture (one main location, one social culture), that is, we had no problems of globally distributed software development. This both made the analyses easier but also limits the generalizability of our conclusions.
We presented our analysis using cause-and-effect chain diagrams. The following figures shows an excerpt of these diagrams.
A few years ago we analysed several highly successful software product lines. You can find the details in our corresponding publication. We had been brought in, because the business owners of each product line felt that something was amiss and that productivity could still be improved. In this short blog post series I’ll discuss the problems we found and what to do about it.
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.
Not surprisingly, this huddling panel at the 2018 Berlin Open Data Day came to no specific conclusion, just different opinions on business models and who should earn what income.
Some nuggets of insight: Leave it to public institutions to decide for themselves — open data should be freely available, otherwise some commercial business models break down — cities should be neutral to startups and establish collaborations for everyone’s benefit — leave it to companies to generate value from open data and they will give back #muwhaha — don’t monetarize open data at all — if users don’t pay, public institutions won’t have the funds to provide open data — open data should be considered public infrastructure and follow established practices — the data belongs to the public anyway — selling data is too expensive for a city.
In related news, some cheap laughs for public institution bashing from one panelist. Personally, I find this less than helpful.