Posted on

Single-Vendor Open Source Firms (Dirk Riehle, IEEE Computer Column)

I’m happy to report that the seventh article in the Open Source Expanded column of IEEE Computer has been published.

TitleSingle-Vendor Open Source Firms
KeywordsOpen source, single-vendor open source, commercial open source
AuthorsDirk Riehle, Friedrich-Alexander-University Erlangen-Nürnberg
PublicationComputer vol. 53, no. 4 (April 2020), pp. 68-72.

Abstract: This article present a particular business model for commercial open source firms, called the single-vendor open source model. This model has long dominated venture capital funding for open source software firms, contributing to the long-term sustainability of open source. As such, it is of high economic relevance. It is also an excellent example to show how open source licensing and related strategies really are just tools in the design of a business model and not philosophies.

As always, the article is freely available (local copy or HTML page).

Also, check out the full list of articles.

Posted on

Ten Years of Student Startups

A main reason why I became a professor is to create and guide student startups, in general, and from my research projects in particular. It has been a bumpy ride, to say the least, but I guess, every learning curve is. Data points (startups) are still not plenty, but I can nevertheless discern some learnings. Without further ado, the usual bullet list of insights:

Learning is by person. Large companies can talk about organizational memory and capabilities building all they want, in a startup, knowledge walks in the door (and out) by person. A new person basically starts over and makes all the same mistakes the person they replace also made… two years later. So, avoid losing good people.

Continue reading “Ten Years of Student Startups”
Posted on

The Innovations of Open Source Article Republished in IEEE Computing Edge’s April 2020 Issue

IEEE’s Computing Edge magazine is a practitioner-oriented publication that republishes particularly popular content from other IEEE publications. In the April 2020 issue, they republished last year’s The Innovations of Open Source article that I wrote to open the Computer magazine’s Open Source Expanded bimonthly column.

Best of all, it is free! (Original version, local copy.)

I didn’t know about the republication until someone pointed me to it. Check it out, if you missed the article the first time around.

Posted on

Managing Episodic Volunteers in Free/Libre/Open Source Software Communities (Article)

Abstract: We draw on the concept of episodic volunteering (EV) from the general volunteering literature to identify practices for managing EV in free/libre/open source software (FLOSS) communities. Infrequent but ongoing participation is widespread, but the practices that community managers are using to manage EV, and their concerns about EV, have not been previously documented. We conducted a policy Delphi study involving 24 FLOSS community managers from 22 different communities. Our panel identified 16 concerns related to managing EV in FLOSS, which we ranked by prevalence. We also describe 65 practices for managing EV in FLOSS. Almost three-quarters of these practices are used by at least three community managers. We report these practices using a systematic presentation that includes context, relationships between practices, and concerns that they address. These findings provide a coherent framework that can help FLOSS community managers to better manage episodic contributors.

Keywords: Best practices, community management, episodic volunteering, free software, open source software

Reference: Barcomb, A., Stol, KJ, Fitzgerald, B., & Riehle, D. (2020). Managing Episodic Volunteers in Free/Libre/Open Source Software Communities. IEEE Transactions on Software Engineering. To appear.

The paper can be downloaded as a PDF file.

Posted on

Why I Gray-listed Github for Open Source

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”.

Continue reading “Why I Gray-listed Github for Open Source”
Posted on

Please Help Keep our Language Precise: Single-Vendor Open Source is Neo-Proprietary Source, not Closed Source

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:

Continue reading “Please Help Keep our Language Precise: Single-Vendor Open Source is Neo-Proprietary Source, not Closed Source”
Posted on

Challenges of Tracking and Documenting Open Source Dependencies in Products: A Case Study (OSS 2020 Paper)

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.

Continue reading “Challenges of Tracking and Documenting Open Source Dependencies in Products: A Case Study (OSS 2020 Paper)”