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”
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”
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”
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”
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”
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.
Continue reading “The Challenge of Scanning Your Product Code for Open Source 3/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”
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”
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).