Most of my software development is through my professorship, where I guide my student teams in developing (mostly) open source software. We have clear rules in place for how and which open source can be used in our projects and which can’t, like any competent organization. Mostly, it is about license compliance. We owe this to the users of our open source projects as well as our industry partners.
As a small organization, we rely on rules rather than lengthy approval processes, component repositories, and the like. One rule is to look at the source (location) of the open source project and see whether we have it white-listed, gray-listed, or black-listed. The Apache Software Foundation website is white-listed and Stackoverflow is black-listed. Github is gray-listed, meaning “it depends”.
When the Open Source Initiative defined open source, it focused only on the license, and ignored the process. Smart entrepreneurs quickly discovered that they could provide to the world their product as open source code and benefit from it, while strictly controllling the process to keep competition at bay. This is called single-vendor open source.
Single-vendor open source is not closed source, not even “the new” closed source. The following 2×2 matrix illustrates the distinction between license and process:
Software vendors need to manage the dependencies of the open source components used in their products. Without this management, license compliance would be impossible, export restrictions could not be maintained, and security vulnerabilities would remain unknown to the vendor. The management of these dependencies has grown in an ad-hoc fashion in most companies. As such, vendors find it hard to learn from each other and improve practices. To address this problem, we performed exploratory single-case study research at one large established software vendor. We gathered and analyzed the key challenges of tracking and documenting open source dependencies in products. We wanted to understand whether these ad-hoc solutions could be based on a single unified conceptual model for managing dependencies. Our study suggests that underlying the various point solutions that we found at this vendor lies a conceptual model that we tentatively call the product (architecture) model. In future cross-vendor work, we will investigate whether this conceptual model can be expanded to become a unifying model for all open source dependency management.
Companies without expertise in software development can opt to form consortia to develop open source software to meet their needs, as an alternative to the build-or-buy decision. Such user-led foundations are little understood, due to a limited number of published examples. In particular, almost nothing is known about the ecosystems surrounding user-led foundations. Our work seeks to address this gap, through an exploratory qualitative survey of openKONSEQUENZ, from the German energy sector. We find that the technological goals are quite homogeneous, independent of a participant’s role in the ecosystem, but that economic conflicts exist between foundation members and supplier companies due to the consortium’s efforts to transform the software market structure to limit dependency on specific vendors.
It is the year 2020 and my Twitterverse and other professional time sinks are still full of … comments about Copyleft. So for the first time ever, I decided to venture into that pit. I see four observable behaviors when it comes to complying with copyleft.
In this talk, I explain the single-vendor open source business model (also: multi-licensing, open core) and in particular its intellectual property strategies. This is the slide deck of a previously posted video.
In this talk, I explain the significance of the software industry for a country’s economy and how to strengthen it using open source. It is directed at public policy makers and the general public. This is the slide deck of a previously posted video.
In this video, I explain the single-vendor open source business model (also: multi-licensing, open core) and in particular its intellectual property strategies. This talk is partly a reaction to the recent licensing changes by commercial open source firms and the resulting confusion. An upcoming article will go into more detail next year.