Access to source code

In the years to come, people will identify ways in which the software business changed fundamentally post-Linux. One of the ways it will be seen to have changed is that (non-end-user) buyers will increasingly demand access to source code for modules/components of the product that are purchased from other vendors. One example would be requiring embedded OS vendors to release or at least share their source code.

Anecdotal example: one company I know was considering migrating from an open source-based module that had been under internal development to an externally-supplied substitute. The main reason they rejected the substitute was that it wasn’t open source (or even shared source). What happened was that they started out with an open source version. Over time, they invested effort and resources in improving it to the point where they had it doing what they wanted it to do (in the process improving the set of core competencies that they had in-house). At some point, when the requirements evolved, they were faced with a make-vs-buy decision between staffing to add the new functionality versus buying a third-party software product. The one third-party product that met nearly all the feature requirements was a closed-source, binary-only, application. Having had experience with the open-source version and having had to debug the issues that arose with it, they felt that they really needed to have to have access to the source code for any module they would purchase from a 3rd party – if you have certain competencies in-house, it is much more efficient to identify and remove the software defect yourself than to have to wait for your supplier to fix the problem.

This is just one example. Having access to source code is very powerful:
* greater transparency
* better ability to debug and troubleshoot issues
* ability to make application-specific tweaks to the software module (as an example, a router vendor might value the ability to tweak the OS to improve packet forwarding performance)
* ability to make continual improvements in terms of features and functionality.

While end-user buyers of software are unlikely to care as much about the availability of source code (how many people are really going to want to tinker with their desktop OS or their spreadsheet tool? A vanishingly small fraction), I can see a good justification for systems vendors desiring or even requiring source code from their software suppliers. I would guess that this is the direction in which the embedded software space is going to evolve, which is one reason why WindRiver’s old model (proprietary, closed-source OS) is becoming obsolete and why their recent statements re: Linux are signs of a good move.