Don't Forget About The People Costs

Licensing and support costs
Due to a significant standardization level of J2EE (now Java EE) technologies, cost structures of application server platforms have thoroughly changed in the last five years. Standardization processes have led to development of a number of freely available components that are reused either unchanged or in lightly modified form by middleware vendors. Vendors who chose to develop their own found that the result was higher costs and lower quality, with more bugs than those that are commonly developed and used by all other application server platforms. For example, it is rare to find a middleware vendor that develops a proper XML parser or an application server platform with absolutely no Apache software components integrated. As such, the price paid for using an application server platform is defined by the vendor’s cost of designing a suitable architecture for component assembly; the cost of maintaining commonly developed parts; the cost of assembling parts into a well-tested, fully functional application platform; and finally, the cost needed to build a sales infrastructure and maintain relationship to customers (users).
Incumbent vendors may leverage the inherent risk and uncertainty in changing application platforms to increase their profit margins--essentially profiting from vendor lock-in. Commercial vendors will leverage these margins as reserves if challenged by an open source vendor, at times significantly discounting or even giving products away at a zero license cost. Based on this experience, it seems prudent to stop emphasizing initial licensing costs as the sole cost factor. A mixed model that combines license, support, and ongoing people/productivity costs seems to be more suitable for the today’s market. A vendor can choose to waive license fees and even significantly discount support fees to remain competitive in an account, especially if there are other hardware or software products or professional services in play. But, a vendor, however, cannot adjust the relative number of developer resources required to achieve the same level of productivity on a given application server platform when compared to other application server platforms.
Degree of technical coverage of standards
The degree of compliance to standards is mostly relevant for products and components intended to be ported or deployed on different application server platforms. For the need of an organization developing software components for their own internal use, the common set of standards provided by most leading application server platforms is mostly sufficient. This is due to the intensive re-use of commonly developed, standards-based, freely available, and well-tested parts in the assembly-oriented production process of ap¬plication server platforms. For the modest need of a consuming company, degree of compliance to stan¬dards is no longer an issue. Standards compliance is not just about which standards are supported but also which proprietary functionality is layered on top of the standards. These proprietary hooks can increase vendor lock-in, even on standards-compliant platforms.
Vendor viability
Vendor viability has traditionally played a big role in the selection process. This was reinforced as freely available components started gaining the attention of decision makers. From a risk management perspective, it is still reasonable to consider vendor viability as an important issue since any disruption in the vendor’s business might have an impact on the customer’s investment. That said, “vendor viability” as a decision criterion must be modified in a modern decision making processes.
The more accurate way to measure viability for enterprise middleware is not to look at the market capitalization of the vendor, but rather the viability of the components and code that the vendor provides and the quality of the services that vendor wraps around the code. Even closed source vendors that offer products via a traditional license model are leveraging open source components or releasing into open source some of their previously closed source components. Since open source code will live on in a community even if a vendor disappears, it seems prudent to measure not only to what extent a particular platform leverages open source, but how that platform is licensed. Do you actually have access to the source code? If so, the viability of the platform would be considered quite high.