How to Capture Open Source User Consortia 4/4

tl;dr: Foundations need a new kind of incubator to capture budding user consortia.

An open source user consortium is a consortium of companies who sponsor, steer, and possibly also develop open source software for their own use rather than as part of software products they sell. As explained previously, this phenomenon may not be widely understood yet, but the opportunity is large. The user consortia and their members stand to benefit, and so do those existing open source foundations that are able to capture this thrust and prevent the creation of separate consortia but rather manage to integrate these interests with their own governance structure.

Continue reading “How to Capture Open Source User Consortia 4/4”

The Scope of the Opportunity 3/4

tl;dr: The scope of the opportunity at hand is large, much larger than today’s impact of open source.

The software industry is large; all other industries together that need software are larger. Much larger.

Today’s open source software is mostly serving the needs of software vendors. When you look at the projects guided by the ASF, the EF, or the LF, you’ll see a lot of infrastructure, technology, and utility components for the software industry. There are not a lot of components for application domains, be it banking, energy, logistics, or agriculture.

Continue reading “The Scope of the Opportunity 3/4”

Does the Incorporation Type Matter to Open Source Foundations? 2/4

tl;dr: It doesn’t really matter how a foundation incorporates; what matters is the actual governance.

A typical response to the creation of new open source foundations is to decry them as “vanity foundations”. In a few instances, that may be true, but I think as a generalization it is not correct.

Usually, companies think first before spending significant money on something, in particular if it is of high visibility and might turn into an embarrassement. This doesn’t mean they always fully understand what they are doing. In fact, I believe that the understanding of companies of what open source means to them and how they want to support and steer its development is ever evolving. After a learning period these “vanity foundations” might just end up with a project and governance structure like the ASF’s.

Continue reading “Does the Incorporation Type Matter to Open Source Foundations? 2/4”

The Apache Software Foundation (@TheASF) is Missing Out 1/4

tl;dr: The ASF is not serving the needs of companies from outside the software industry well.

The Apache Software Foundation (ASF) is the original gold standard of open source foundations. Yet its project and governance model takes a one-size-fits-all approach that is holding beginners to such high standards that they may never get started with the ASF. Because of my high regard for the ASF, it is utterly frustrating to me that the ASF is missing out on major developments in the open source space. Hence this thread.

Continue reading “The Apache Software Foundation (@TheASF) is Missing Out 1/4”

On the Importance of an Open Standard Exchange Format for QDA Projects

I just returned from the Berliner Methodentreffen. One of the initiatives that was most interesting to me is a new attempt at agreeing on and standardizing an open exchange format for qualitative data analysis projects between the different QDA tools. As of today, it is not possible to take your data from one vendor’s tool to another; you are locked-in to one product. The Rotterdam Exchange Format Initiative (REFI) is trying to change that using the budding QDA-XML format.

There are three common reasons for why such an exchange format (and hence the initiative) is important.

Continue reading “On the Importance of an Open Standard Exchange Format for QDA Projects”

The 120 Seconds Open Source Pitch

I often have to “sell open source” and the pitch for this is ever changing. Here is the current one; it stands at 120 seconds. It is aimed at the German Mittelstand, but it should work for any product vendor where software is just one component of several.


“Software is eating the world” says a Silicon Valley venture capitalist. This is not just American hyberbole. Not only is software its own industry with its own products, it is also taking over the world of physical and other products.

Continue reading “The 120 Seconds Open Source Pitch”

The Meaning of Digitalization 1/2

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.

Continue reading “The Meaning of Digitalization 1/2”

Why You Should not Let Developers Scan Their Code for Open Source Violations 4/4

As discussed in prior posts [1] [2] [3], 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.

The Challenge of Scanning Your Product Code for Open Source 3/4

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.

Continue reading “The Challenge of Scanning Your Product Code for Open Source 3/4”