This is the third of four questions posed to me by a journalist about open source and the public sector.
The economists have an answer for this. At any point in time should you evaluate the total life-time value of the various alternatives at hand and then chose the one that has the best value.
When making this calculation for a switch from proprietary to open source software, the switching costs have to be added to the cost of using an open source solution. It may well be the case that the open source solution, in itself, is much better than the proprietary solution, but with the switching costs added, becomes less desirable. Then, the rational choice is to stay with the proprietary solution.
This of course is maddening to open source enthusiasts, because a superior open source solution suddenly loses out to an inferior proprietary solution, because of the existing lock-in. However, this is simply economics.
Thus, the full answer is: It depends. In some cases, existing proprietary software should be replaced with open source software, and in other cases it should not.
It should be noted that switching costs are one-time costs, while cost savings through open source software are recurring. Thus, for a proprietary solution to keep winning over an open source solution, it must be significantly better and/or the switching costs quite high.
Next up: Shouldn’t a public government stay out of the software market?
This is the second of four questions posed to me by a journalist about open source and the public sector.
I was not involved with the Munich decision at all, so I can only speculate and provide the usual reasons that have been reported about why such failures happen.
First of all, it is nothing unusual if a company or a public government switches products. The particular Linux and LibreOffice implementation in Munich is somehow taken as a representative of all of open source, which is wrong. Munich bought into a particular Linux and LibreOffice and particular companies servicing it and maybe this, taken as a product, did not work as well for them as Microsoft Windows + Office.
Continue reading “Why Did Munich Drop Linux and LibreOffice for Microsoft Windows and Office?”
I was asked several questions by a journalist about open source and the public sector. I’m answering them here in sequence. This is the first of four blog posts and the first question was: Should the public sector use open source software?
The public sector and public governments should use the software that lets them provide the desired services best, long-term. How much open source software this involves is secondary, in my opinion.
That said: Like any industry, the public sector already uses substantial amounts of open source software by way of open source components built into commercial proprietary product. Estimates of the percentage of open source code in commercial products and services go as high as 80-90% of the total code. Open source is everywhere, including in Microsoft Windows and Office.
Continue reading “Should The Public Sector Use Open Source Software?”
Almost all software products today incorporate open source software either directly or through software supply chains, but many companies are not properly governing their use of open source, incurring potential risks. Since 2016, I have been researching industry best practices and processes around open source governance, focusing on software supply chains. I have interviewed 20+ experts from industry-leading companies to derive their best practices. We are currently implementing some of these best practices at three companies that serve as case studies for our research. In this talk I will cover the results of our study and share some best practices with you.
Continue reading “Upcoming Talk on Industry Best Practices for Corporate Open Source Governance of Software Supply Chains at UC Santa Cruz”
The most important long-term trend, and my number #3 for the foreseeable future, is the sponsorship and management of open source software development by users, not vendors. The trend towards ubiquitous digitalization is leading users of software to take their software fate into their own hands, establishing informal communities or incorporating as non-profit user consortia to manage the development of the software they need. The Eclipse Foundation has been picking up this trend, supporting it with what they call Industry Working Groups; the Linux Foundation is also supporting this. Open source like this will not remove the need for commercial support, but it will reduce the effects of vendor lock-in, because products that are built on community open source can be switched more easily. Continue reading “My Top Three Trends for Open Source in 2019 (3/3)”
Trend #2 for 2019 in my book is making single-vendor open source, also known as the open core model a.k.a. neo-proprietary open source, work in the world of cloud computing. In this model, a software vendor goes to market using an intellectual property strategy that combines open sourcing of the product with an aggressive copyleft license. This approach nudges potential customers to moving from the free version to a paid-for proprietary version. In 2018, it visibly broke down when industry consensus emerged that cloud providers aren’t affected by copyleft licenses. Software vendors are now working on licenses that close this (so perceived) loophole. Thankfully, the Open Source Initiative remains the main arbiter of what constitutes a valid open source license. While some scoff at this business model, I think it is an important part of the overall open source community as it is the main way to channel venture capital into the creation of open source components.
Continue reading “My Top Three Trends for Open Source in 2019 (2/3)”
Trend #1 that took root in 2018 and will continue in 2019 is the clean-up of the open source supply chain. According to some lawyers, there is little legally valid software left, mostly because of unclear copyright and licenses of open source code in products and components. To clean up this mess, all open source code that makes it into products needs to be labeled and tracked correctly along the supply chain, so that the final product has a chance of being license-compliant. The OpenChain and related projects of the Linux Foundation are trying to do this. This mess is less plastic (pardon the pun) than the garbage pile in the pacific and on our beaches, but probably equally big.
Continue reading “My Top Three Trends for Open Source in 2019 (1/3)”
The terms project and product are used with continued confusion. Both open source and agile methods are particularly bad offenders, leading people astray. Adapted straight from the textbooks:
- A project is a human undertaking with the goal of creating an artifact. Its life-cycle is determined by a start date and an end date.
- A product is a human-made artifact for a market of customers with an open-ended llfe-cycle. It is born with no end date in sight.
Not always, but typically, a project is used to create a custom artifact, while a product is (by definition) made for a market, that is, many different customers.
Continue reading “How Project vs. Product Confuses Open Source Terminology”
We are researching the governance of open source software foundations. We are specifically interested in what we call open source user consortia, that is, open source foundations where the users of the software are in the driver’s seat.
Continue reading “Looking for Examples of Open Source User Consortia”
Open source software and patents are a tricky topic and resolution of the many hairy issues may need new and/or revised laws. Fraunhofer Gesellschaft is currently running a survey for the European Union to gather broad stakeholder input on the topic. I encourage participation. Deadline is Nov 30th, 2018.