When compared with hardware, software has been only a recent addition to products. Companies have been reorganizing ever since to better deal with software development.
My engineering colleagues are sometimes sarcastic about the (many) on-going “digitalization” initiatives: “Didn’t we do this 20-30 years ago, when we switched from analog to digital?” I guess, they are talking about digitization, not digitalization.
Different from digitization, today’s digitalization initiatives are about giving software an equal seat at the table, in the line of business, whatever the application domain. In the past, for many products, software was a cost center, today it is (at least should be) a profit center, because many interesting new products can only be thought of and realized with software as a key part of the innovation process.
As discussed in prior posts   , companies need to take stock of the open source software code in their products. Otherwise, they will not be able to correctly comply with the licenses of the open source code they use. Taking stock means scanning and analyzing your product code, and who else to turn to but your current developers who wrote the code?
The problems start, if such a clean-up is not properly budgeted for. On top of regular feature development, developers are now supposed to sift through old code, analyze it, and possibly even replace unwanted open source code? This is unlikely to lead to the desired results. The obvious conflicts of interest are:
- Developers don’t have time. Cleaning up does not deliver new business value and is therefore rarely adequately budgeted for. The result is hasty work, if any work at all.
- Open source clean-up does not help reaching performance goals. Similarly to not getting the time to do a proper job, a clean-up rarely makes it into performance goals, leading to low incentives.
- Developers may hesitate to correctly identify policy violations. Identifying unwanted open source code creates new work, because it is now apparent that the violation needs to be fixed.
- Developers may want to cover up past sins. Many companies still have a “no open source policy” and hence, if a developer put open source code into product code, they violated corporate policy.
- Developers may not know what they are doing. Without proper education, developers are unlikely to do a good job, simply because they don’t know what they are doing. “If it is on the web, it is free to use, isn’t it?” is still a common (but obviously wrong) sentiment.
For these reasons, I advise against letting developers scan their own code. Typical indicators that your developers may not have done such a stellar job are blanket exclusions of directories from scanning, or even more obviously, no findings at all. If you are serious about taking stock, you should give the job to unrelated developers within the company or go straight to a third party.
There is a lot of open source in pretty much every software product these days. Engineering managers are often surprised about how much (in particular, if they have a policy of “no open source”). Taking a look is not just an exercise in curiosity, it is actually a necessity to know exactly what open source code is in your products. Without this knowledge, you don’t know which open source licenses you need to comply with, and if you are not compliant, you cannot legally correctly ship your product.
Open source license compliance is the process of ensuring that any product that you deliver to customers (more precisely, any distribution you make to recipients) complies with the licenses of the open source code used within that product. As it turns out, this is both a simple process (at 10000 feet) and a rather complicated process when it comes to details. Here is the 10000 feet perspective.
Step 1 is to know what is in your code. If you never took stock, you don’t know, trust me. If you don’t know, you need to create a so-called bill of materials, that is a list of open source code snippets and components that made it into your product. You can try to do this by hand, but will probably fail in any but the most trivial cases. Tools can help you to walk through your code, identify license texts, and point out similarities to known open source code, so that you can determine your product’s bill of materials.
The times are changing: More and more companies are finally taking stock of the open source code embedded in their products. The main driver is to be (finally) compliant with the requirements of the licenses of the open source code. I see three main reasons for why companies are finally shaping up:
Georg Grütter of Bosch recorded my keynote at the Inner Source Commons summit in Renningen, Germany, on May 16th, 2018, and put it on Youtube. Please watch it below (original video, local copy).
According to Georg, the video is licensed under CC BY-SA 3.0 (for the Bosch part) and I agree (for my part). Hence © 2018 Dirk Riehle, Robert Bosch GmbH (Georg Grütter and perhaps some other undetermined parties). The original title of the video recording that Georg gave it is “Prof. Dr. Dirk Riehle on the ISC.S6 – Ten Years of InnerSource Case Studies And Our Conclusions”.
In our research, we often work with industry. In software engineering research, this is a no-brainer: Industry is, where there the research data is. That’s why we go there. For many research questions, we cannot create adequately, in a laboratory setting, a situation that lets us do our research.
Once a researcher realizes this, they need to decide on whether to charge the industry partner for the collaboration. Many researchers don’t, because sales is not exactly their strength. Also, many shy away from asking for money, because it is an additional hurdle to overcome, once an interested industry partner has been found.
I often discuss with my Ph.D. students how to structure their work and publish the results. There are many pitfalls. It gets more difficult, if we bring in other professors, who may have a different opinion on how to structure the work. Over time, I have found there are really only two main dimensions, though:
- Separate work into theory building and theory validation, and publish one or more papers on each topic
- Merge work on theory building and validation for an important aspect (hypothesis) into one and publish that
A researcher-friend recently complained to me that her research paper had been rejected, because the reviewers considered it “boring”. I recommended that she complain to the editor-in-chief of the journal, because in my book, “boring” is no acceptable reason to reject a paper. (“Trivial” may be, but that is a different issue.)
The reasoning behind rejecting a paper, because it is “boring”, is as follows: Research should be novel and provide new and perhaps even unintuitive insights. Results that are not surprising (in the mind of the reviewer, at least) are not novel and therefore not worthy of publication.