Hacking the world
We recently bought a Sun X4200 server, which should come as no surprise to regular readers, nor should our installing the open-source Solaris 10 operating system. Like the latest models from all major manufacturers, this machine comes with an integrated lights-out management (ILOM) module that can be used to manage it remotely, but what did surprise me when upgrading its firmware was an option to download the ILOM source code.
The firmware was open source because there’s a cut-down Linux system running on the embedded ILOM hardware within the Solaris box. Now, I doubt that many people will want to tweak their server ILOM firmware (although there are bound to be a few installations where it might be required), and if anyone did I wouldn’t want to use their revisions – but that isn’t the point. The point is that if a product incorporates open-source software, people are at liberty to change the way that product works. In this column, I’ll check out how open-source is being used in commercial products, and how people are tweaking those products as a result.
Why do companies use open source?
The most obvious reason to use open-source software is cost – if you neither have to buy the software nor spend development time yourself then you must save money. This doesn’t have to be an all-embracing policy; for example, Linksys famously uses Linux in some of its router products, but employs a bought-in third-party embedded operating system in others. A closed-source alternative may, for example, make more efficient use of scarce hardware resources. Just because a piece of software is open source doesn’t mean it will just work in your product: the person applying it will need to do some work, and that may be a barrier to implementation.
Also, there’s the factor of licensing. We’ve discussed the merits and demerits of the various open-source licence models in the past: what most of them share is the moral (if not legal) obligation to distribute the source code to your own application if you use open-source materials in a commercial project. What precisely that obligation is will depend on the particular open-source product you used and how you’ve used it. For example, using an open-source library to build your application may not oblige you to distribute your whole source, but only require you to announce that it includes that open-source library. Whether there’s a legal obligation is a moot point, since the majority of open-source licences have never been enforced and therefore have never been tested in the courts. However, that situation does seem to be changing, as a number of manufacturers that have used open-source code in their products are currently being taken to court by various open-source organisations. It seems likely these manufacturers will lose, so we’ll see more companies having to release the source code for their products.
To many manufacturers, the open-source licence is going to be a commercial barrier, as increasingly the personality of products comes not from their hardware components but the software that runs them. For example, Apple products such as the iPod and iPhone are created from commodity electronic components, but Apple’s software and firmware make them what they are; in the case of the iPod, the software may not even belong to Apple. Giving away the software that makes your product work may be too much for some firms, but for others it’s worked. Even if the software in your product is open-sourced, you can still prevent people from taking advantage of its openness – a threat to void the warranty is enough to put off many people from running unapproved software (I’ll admit it’s stopped me from braving any open-source applications on my iPhone yet).