Software Research and the Industry - Page 2 of 54 - Open source, building products, software startups, and industry strategy by Prof. Dr. Dirk Riehle

2020-08-072020-08-07

A Researcher’s Perspective on “Do Developers Care About Open Source?”

Over on Twitter, that endless source of distraction, Matt Asay asked: “Do developers care about open source?” Apparently, he is asking in response to an interview he had with a vendor who claimed that developers don’t care whether their service is available as open source (it is not). According to the vendor, developers just want to use a reliable service (and pay).

2020-08-032020-10-16

Open Source Research Software (Wilhelm Hasselbring et al., IEEE Computer Column)

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

Title	Open source research software
Keywords	Open source software, scientific computing, software engineering, artificial intelligence, licenses
Authors	Wilhelm Hasselbring, Leslie Carr, Simon Hettrick, Heather Packer, and Thanassis Tiropanis
Publication	Computer vol. 53, no. 8 (August 2020), pp. 84-88.

2020-07-202020-07-22

How Non-Software Vendors Fail and How Inner Source Can Help

Slowly but surely, non-software vendors have been waking up to realize that Silicon Valley, specifically, software vendors, are out to eat their lunch. In 2011, Marc Andreessen stated that software is eating the world, in 2015, Geoffrey Immelt said that GE is in the information business, and now in 2020, Volkswagen declared itself to be(come) a software-driven automobile vendor. However, this is more easily said than done, and the path to taking charge of your software future is fraught with possibly serious mistakes. One such mistake is to create your own internal software organisation. A better choice is to leave developers close to the products, but set-up an inner source program to connect them across the organization. Let me revisit this topic.

2020-07-142020-07-14

Why Istio Matters to Google

You may have notices the brouhaha in response to Google’s announcement to hand over trademark management of its popular Istio, Angular, and Gerrit open source projects to the newly created Open Usage Commons (OUC) non-profit. While I gave Google the benefit of the doubt, the vast majority of commentary assumed that Google only had its own interests at heart and tried to add the appearance of openness to its projects without actually delivering. Google dominates the OUC and therefore any decisions.

Here, I want to focus on why people, most notably cloud providers, care. I will ignore sensibilities (broken promises or not) and focus on the business perspective. As I wrote before, of the three projects given to the OUC, the heat is on Istio, a (micro-)services mesh software. Angular and Gerrit may be important projects in general, but don’t matter much to Google’s revenue. So, what is it about Istio?

2020-07-092020-07-09

Interpreting the Purpose of the Open Usage Commons Foundation

Yesterday, the Open Usage Commons (OUC) foundation announced itself. It is a non-profit which wants to ensure free and fair trademark use of the open source projects under its guidance. My Twitter feed was quick to denounce the OUC as a vanity foundation. It certainly is not. A vanity foundation serves to aggrandize its creators, and a name like “The Great Company Open Source Foundation” would then be apt. This is not the case here. Rather the OUC makes specific statements about trademark enforcement, so it has a purpose that is not vanity. Just what is that purpose, and why did existing foundations not fit the bill?

2020-06-302020-07-01

The German Corona Warn App, a Legally Defective Product?

By all measures, the German Corona Warn app is already a highly successful software product. However, from the perspective of open source license compliance, it is defective. Using open source code in your product requires that you fulfill the obligations of the open source licenses of that code, and the Corona Warn app does not do that. Let me explain.

Open source code may be free to use, but it comes with strings attached, which are its licenses. An open source license spells out (1) permissions (you are allowed to use the code for free, among other things), (2) obligations to fulfill to receive the permissions (like giving credit to the original authors), and (3) prohibitions (for example, you are not allowed to claim endorsement of your work by the original open source programmers).

2020-06-292020-07-03

What is Open Collaboration?

Open collaboration was popularized by open source projects, and since has made its way into wikis and Wikipedia, the mix and remix culture and open content, open educational resources, and so forth. Just what exactly is it?

2020-06-282020-07-01

What is Open Communication?

Open source collaboration requires open communication, they say. Just what is open communication, exactly? Drawing on past research [1], here are the four principles that make communication open. Open communication is communication that is

Public: All communication takes place in the public eye, and none or very little behind closed doors; private side-discussions are discouraged.
Complete: All communication is complete to the extent possible. Assumptions are made explicit and conclusions of discussions are summarized.
Written: All communication is in written form, allowing folks to participate at their own pace; any non-written communication will be transcribed.
Archived: All communication is archived for search and later retrieval. This documents communication for those not around (or awake).

2020-06-172020-07-01

The GNU Public License v2 in the Land of Microservices

Another question I get asked is how containers and new architectural styles like microservices-based architectures relate to copyleft licenses, in particular the GPLv2 license.

First things first: I don’t recommend taking a “let’s work around this pesky license” approach. You should follow both a license’s spirit and letter; license evasion (“Umgehungsversuch”) may not hold up in court. Someone is trying to do you well, but only under certain conditions, so take it (properly) or leave it.

With that: If you package copyleft-licensed code in a container image and distribute this image, does the copyleft-licensed code affect any other container it communicates with?

2020-06-162020-06-16

How to Read Open Source License Obligations

Interpreting open source licenses requires considerable skills and experience. Ideally, engineers and lawyers work together: Lawyers know the meaning and consequences of legal terms, and engineers can make sense of it in the context of software. There are some basics, however, that help set your thinking straight.

A critical aspect is: What is a (re-)distribution ? You distribute code (binary or source, doesn’t matter), if you pass it on to another legal entity. Legal entities can be both regular people (“natural person”) or companies (“juristic person”). If the code does not cross such a boundary, it is not being distributed.