In 2009, half of open source code was licensed under the GPLv2 license, the canonical copyleft license. Every other license had less than 10% market share. Over the years, the MIT license and other permissive licenses kept climbing at the expense of the GPLv2. As of today, the MIT license is the leading license with more than 32% market share in absolute numbers, with the GPLv2 license having fallen below 20%.
I was interviewed by Lovis Krüger German radio broadcaster WDR on Huawei’s HarmonyOS and the industry strategies around it. Two audio statements made it into the show: (1) HarmonyOS uses a lot of open source software and (2) Huawei can’t use the Android trademark without Google’s permission. So I thought I provide my notes here.
In a well-working community open source project, many people contribute. In particular, software developers will submit code contributions. As a consequence, without further measures, the copyright in the project’s code will be widely shared among its contributors.
To ensure that a project can be used without fear of violating someone’s intellectual property rights, all project artifacts, in particular the code, need to have a clear open source license, and ideally only one.
An open source distribution is a set of open source components configured and put together to work well as one piece of software. A commercial open source distribution is a product that you pay for, and a non-commercial distribution is freely available software. Commercial distributions may be complex products, but not all complex products are distributions.
Open-Source-Software, im engeren Sinne, ist Computer-Software (Programme), die kostenfrei genutzt, modifiziert, und weitergegeben werden können. Bekannte Beispiele für Open-Source-Software sind das Linux Betriebssystem und der Firefox Web-Browser. Open Source im weiteren Sinne ist ein von Menschen getragenes Phänomen, das uns ungeahnte Möglichkeiten der weltweiten Zusammenarbeit sowie neue Geschäftsmodelle gegeben hat.
Abstract: This article presents a succinct and minimal handbook of best practices of how to create and grow community open source projects. We start with the assumption that the handbook’s user has a minimal but useful piece of software at hand that they want to open source and build a community around.
Keywords: Open source, open source projects, open source communities, creating open source projects, growing open source projects
Reference: Riehle, D. (2020). Creating and Growing Community Open Source Projects. In Proceedings of the 27th Conference on Pattern Languages of Programs (PLoP 2020). ACM, 14 pages.
While a comparatively young industry, the software industry nevertheless has a history, and taking from the playbook of other disciplines, understanding our history is important to understanding our future. So I want to ask:
What (if any) historic periods are there in single-vendor open source firms?
Inner source is the use of open source practices within companies. Engineers generally love it, but any open-source-style collaboration across business unit boundaries will usually get stopped dead in its tracks by the financial compliance department. That’s because financial compliance is likely to worry that to the tax authorities such inner source collaboration will look like attempts at profit shifting.
Below, please find a 20min. presentation on inner source and transfer pricing that I prepared for a workshop at the German Ministry of Finance. It is aimed at non-technical people.
You can also skim the slides, though the video offers significantly more information. Feel free to shoot any questions you might have my way.