The "Open Source Model" is not a religion. It is a very pragmatic way of evolving software in a rapidly changing environment. It harnesses the collective wisdom, experiences, expertise and requirements of its most demanding users to ensure that their needs are rapidly met.

Any software company with expertise, the resources and the will can elect to provide whatever level of support they feel the market will bear. With complete access to the source code nobody has the edge that previously was only available to the owners of the proprietary software. Support is now open to competition. The quality of support is now open to market forces.

Open source software has no such pressures. Often, as second-generation products, their value proposition is that they support the standard very closely. This is their way to differentiate themselves from the other products already present in the market place. They hope to use the consensus achieved in that standard and experiences from multiple product implementations, as a way to stabilize the technology domain, create a commodity item from that technology and thus create another stable building block in the technology layers that make up distributed systems. Users can then move on to other areas, higher up the ladder of abstraction, to advance technology and create new value.

Applications are the true value added software. Middleware should be "low impedance" software for enabling application interoperability and systems diversity. Software historically has moved towards a monopoly, as a way to achieve easy interoperability via uniformity. Within the middleware market there should be enough diversity to foster innovation and yet with sufficient uniformity to enable cooperation. Open source software can act as a break on the natural progression towards a single dominant vendor. A progression, some would say, towards a monopoly.

In open source the users contribute extensions that they want to see in the product. This might include extensions beyond the standard but they are created by a user's need to inter-operate, not a vendor's motivation to lock in. These activities can become the basis for a standards submission as they can prove the viability of an approach and enable many users to validate their utility, in real life situations.