Later this week I’ll be on a panel at the Automotive Computing Conference in Frankfurt. The organizers sent the questions in advance, and sure enough, they were asking how open source could provide viable software components if it is free (of cost). This perhaps is the most common commercial misconception about open source.
Open source is not free. It never was.
More precisely, open source is not free, neither in cost nor in freedom, but it gives you options you didn’t have before. The main new option is to use an open source component where you previously had to either develop the component in-house or purchase a commercial one. All three options have costs associated with it.
If you choose to use an open source component, the default option is to build up competence in-house to be able to use and fix (if necessary) the component. This way, you are incurring labor costs. In many cases, you can purchase service contracts with companies specializing in servicing open source components. Then, you have the costs associated with the contract. A benefit of open source is that it is harder for one service company to lock you in, because you have lower switching costs to another service company for the same open source component, than it is for a commercial company to lock you into their proprietary component. So:
Using open source in products creates a dependency and managing that dependency costs money. There is no free open source.
All the wording of how open source is free is only true for selected aspects, not for the whole package. Since experienced engineering managers are hardly so gullible to believe that they will be given high quality components without strings attached, calling open source free hurts the adoption of open source. Educating engineering managers like above helps, but it needs to be heard to do have its effects.
Subscribe to this blog (in the sidebar) and the IEEE Computer column I’m managing!
The next two articles in the column will be about selecting the right open source component for your needs, by Diomidis Spinellis, and managing the resulting dependency, by Tomas Gustavson.
Leave a Reply