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.
Continue reading “Getting Started With Open Source License Compliance 2/4”
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:
Continue reading “Reasons for Why Companies are Getting Serious About Open Source Licenses 1/4”
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.
Continue reading “Why You Should Ask for Money When Working With Industry”
Actually, I just notice it is the fourth time within the last two months, but tomorrow is the first time I’ll present our research on inner source in a public venue. If you are interested in ten years of case studies on how to use open source best practices within companies (called inner source), come see me at the Bitkom working group meeting on open source at Design Offices, Unter den Linden 26-30, 10117 Berlin.
Traditional science has a clear idea of how research is to progress, rationally speaking: First you build a theory, for example, by observation, expert interviews, and the like, and then you generate hypotheses to test the theory. Over time, some theories will stand the test of time and will be considered valid.
Sadly, most software engineering research today, even the one published in top journals and conferences, often skips the theory building process and jumps straight to hypothesis testing. Vicky the Viking, from the accordingly named TV series of way back comes to my mind: Out of the blue, some genius idea pops into the researcher’s mind. This idea forms the hypothesis to be tested in research.
Continue reading “How the Lack of Theory Building in Software Engineering Research is Hurting Us”
How come that companies like IBM, Oracle, and Microsoft are leading so much open source these days? How is it possible that they harmoniously (most of the time anyway) collaborate with each other at the Apache Software Foundation or even Linux Foundation, while they fight each other to the bone in front of the customer?
Continue reading “The Fiercer the Competition, the More Companies Open Source”
On Twitter, @arkwrite suggested that a code review should always say something nice and @chaos_monster commented that we need a code of conduct for code reviews. All of this makes sense to me, however, I suggest that we first have a general code of conduct of productive discussions (and most companies have something like it). The two main rules that come to my mind are:
- Separate the person from the issue
- Praise liberally, criticize specifically
Separating a person from the issue makes sure that you focus on the technical problem, not the person. Praising liberally is just good practice, showing how you value a person’s contribution. If you have to criticize for good reason, be specific so that the underlying technical issue is clear and provides a chance to respond.
Continue reading “Code of Conduct for Code Reviews”
Researchers often use the term “qualitative research” to mean research without substantial empirical data, and use “quantitative research” to mean research with substantial empirical data. That doesn’t make sense to me, as most “qualitative researchers” will quickly point out, because qualitative research utilizes as much data in a structured way as it can. Everything else would not be research.
Continue reading “On the Misuse of the Terms Qualitative and Quantitative Research”
I updated this post after I realized that it is more about prioritizing user stories than it is about writing them well.
In Scrum, a product owner writes user stories to capture requirements and prioritizes them in a product backlog as the upcoming work queue for developers. The main question on my mind is:
Who has the capabilities and competencies to write good user stories and prioritize them in a product backlog?
The INVEST criteria list quality measures (of sorts) that determine what a good user story is. It should be Independent, Negotiable, Valuable, Estimatable, Small, and Testable. While fundamentally correct, there is much more to say. For example, in a product backlog, user stories should use a consistent vocabulary, based on a shared domain model (or glossary, at a minimum).
Continue reading “Who Writes and Prioritizes User Stories?”