In the old days, the same vendor sold you your hardware, OS and apps, and you had no choice. If you still like buying it all in the same place, Sun and IBM are still happy to oblige.
While some people like buying the "best of breed" for various applications, there is also a tendency to like simplified choices. The office suite, for instance, gives you once of each kind of commonly-used desktop software. Not only do customers like this simplified approach but many vendors like it, too.
The software stack presents us with the same sort of problem: best-of-breed or single-supplier? It is widely-distributed industry standards (and open standards) that have pushed the software stack, the ability to pick OS, utility layer, databaseand applications.
The vendor faces the same pressures and choices as you in how the stack is constructed. The crucial difference is that the vendor is likely to wrap his stack tightly to discourage you from tampering with it (that's what his maintenance contract is for). On the other hand it is vital for you to be as modular as possible in designing your own stack so that you can substitute components more easily.
Modularity is a fundamental building block of open source. You can't get experts to volunteer if they have to learn all the intertwined code of a project, rather than just working on one portion of it (it's the project leader who keeps the modules coordinated). By ensuring the components are kept modular, that is, loosely connected with as few interdependencies as possible, you add to your ease in switching them in and out.
Both you and the stack vendor want to keep the cost down, so you will both use open source components at the bottom. The OS will be open source. As you move up the stack, look for open source components that will do the job. As open source and commoditization move up the stack, it becomes easier to find such components.
The components that make the difference and give you a significant ($) business advantage are at the top of the stack. If these components are really cutting-edge and confer a significant benefit, they are very likely proprietary (if everyone could have them for free, how would they give you an edge over everyone else?). If they really earn you more money than free components would, then they are worth paying for.
Or you could build your own high-level, advantage-giving components. Then no one else would have them. Do you have the in-house developer power to do this?
Once again, you are facing the same decisions as the stack vendor. The stack vendor is going to deliver a mixed stack because he believes that the proprietary software will be worth the money to the buyer, and earn him more money than would a stack made up of only open source software. Most solution stacks sold today are mixed proprietary and open source.
Application vendors have to keep adding features to their applications to stimulate buyers to purchase and to upgrade. Now that the action is moving to stacks, they are trying to make their stacks as tall as possible, from OS at the bottom to proprietary apps on top. IBM is an example, so is Sun,and Novell is offering a mixed stack has SUSE Linux on the bottom and IBM WebSphere on top. Because this is a complete solution, the vendor had better be able to show the buyer that not only are the components superb, every one, but that they work so well with each other as to provide a value beyond the sum of their parts.
If you are still building your own stack, then you will have to do all the tuning and testing that you would expect to find in a vendor-supplied stack. Your distro will work only on certain hardware, and your layers and applications above that will be tuned for the distro you choose. So you need to build your stacks from the machine up to make sure they will work properly, and that you will have minimal trouble switching components in and out. Your stack vendor would take care of all this for you, but then you would be locked in, and unable to make fundamental changes in the system.
But if you build your own you can make it work the way you want it to, and hopefully in a way that surpasses your competitors. And because you will not be distributing this software outside your company, you don't have to worry about relations between GPL 2.0 software and other software. Nor will you have to share any secrets just because you are using open source software.
This was first published in November 2006