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”

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”

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”

Getting Started With Open Source License Compliance 2/4

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”

CeBIT Forum on “Open Source und Smart Services”

Today, I’ll be at the CeBIT Forum on open source and smart services to discuss business models based on open source and review a few examples, together with always fabulous Peter Ganten, CEO of Univention, a German Linux distributor. Catch me at 1pm today (2018-06-13) in room München (Munich) on the (CeBIT) Hannover Messegel√§nde (i.e. the convention center).