The acronym ISV stands for Independent Software Vendor. Historically, independence was important to protect customers from the proprietary lock-in associated with third-party components such as hardware or system software. A greater choice of interoperable components gave customers greater flexibility to procure and assemble a system that met their needs. Microsoft alleviated some of this concern with the Windows platform because customers could always choose multiple hardware providers when selecting applications that ran on Windows. Of course, an application that only runs on Windows isn't exactly an "independent" application, but customers seem to accept hardware independence as sufficient freedom. (More on Microsoft and Windows later.)

Unfortunately, independence has a high cost these days. Customers are burdened with the expense of assembling and maintaining components that are sub-optimal because they are not engineered as integrated solutions. Application providers are burdened with the engineering and customer service expense of delivering multiple implementations of their software for multiple operating systems. The costs associated with engineering, assembling, and maintaining the application across multiple operating system environments do not add any value for the customer.

The market is responding to the inefficiency of this legacy software approach by rewarding vendors who remove the burdens of assembly and maintenance from the customer by engineering an integrated solution. The amazing popularity of on-demand software as a service (SaaS) solutions (e.g., salesforce.com) and integrated hardware appliances (e.g., google mini) can be largely attributed to the simplicity and ease of use these solutions offer to customers. By sacrificing their independence from the operating system and embracing Linux and open source, software providers such as salesforce.com and google can offer their valuable applications to customers without the legacy hassles of assembly and maintenance.

Ten years ago, the first-generation on-demand SaaS providers were launching their products into the robust software market created by the Y2K frenzy. Typically, they were re-hosting third-party applications from vendors such as PeopleSoft or SAP or Oracle on proprietary Unix platforms such as Sun Solaris or HP-UX. None of these first-generation SaaS companies was a success because they couldn't profitably offer customers a lower price. Some may argue that they failed because the solution's performance was poor because of an immature Internet infrastructure and an application architecture that was not Internet-friendly, but I think they would have failed anyway. Customers still paid for the software licenses, hardware, and system administration, but they paid for it monthly. Also, the SaaS provider deployed the application exactly as the customer would have deployed it in his data center. These early SaaS companies didn't provide any economies of scale associated with higher system utilization because each customer had dedicated systems with dedicated licenses. The only resources they shared were the network infrastructure, data center infrastructure (power, cooling, etc.), and system administrators.

By contrast, the current crop of on-demand SaaS companies is very successful because they've changed the economics of software.

How are these new SaaS providers so different from the failed SaaS companies of the late '90s?

For starters, they own their application code, so they're not simply passing along a license from a third party in the form of a lease. Also, by owning the code, they can architect the application for high utilization of capital assets. Not only do these applications universally run on Linux, they also leverage other open source infrastructure such as Apache and Tomcat. In addition, they use low-cost industry standard hardware and they have a multi-tenant architecture so that multiple customers can share the same hardware assets. The result is an infrastructure that's tuned for high performance and high utilization of assets.

But there's even more value for customers in this model. Because these application providers are not "independent" from the infrastructure, customers benefit from a lower cost of engineering and customer service as well. The typical ISV will spend between 25% and 40% of engineering and customer service expense on "context" issues as opposed to "core" application features. "Context" issues are things such as installers, multi-platform and multi-version operating system ports, and system configuration. The on-demand providers don't have any of this "context" overhead, so they can focus exclusively on the "core" issues of application performance and features. Customers get a better application with fewer integration hassles at a lower cost. The SaaS provider gets a business model superior to the historical ISVs. They can focus their resources on the features that add the most value for the end user.

Also consider the case of the hardware appliance vendors that market integrated systems for tasks such as network security, authentication, data storage, and spam control. These aren't low-margin undifferentiated hardware products. Their gross margins look much more like those of a successful software franchise because the value they provide is the application functionality they deliver. Yet rather than be "independent" and foist the integration problem onto their customers, they choose to deliver an integrated solution that's easy for the customer to deploy and manage. Like the on-demand SaaS providers, most of these vendors choose Linux or FreeBSD as the operating system of their "appliance" to gain the benefit of rock solid system services and industry standard hardware compatibility. Linux and FreeBSD are also flexible so that the platform can be tuned to the application's needs. Finally, Linux and FreeBSD are free from the distribution restrictions that might challenge the "independence" of these integrated solution providers. The freedom of open sourcde provides true independence.

The final nail in the coffin of independence for software vendors may be the availability of high-performing virtualization technology for industry standard hardware. Virtualization technology such as that provided by VMware and the free software project Xen not only addresses the issue of asset utilization by allowing multiple "systems" to run on a single server, it also addresses the issue of interoperability by allowing those "systems" to be different without creating incompatibilities. "Certification" will simply mean that the application comes in a system form that's compatible with the underlying virtualization layer, thereby allowing it to interoperate over sockets with all other applications on the system. With virtualization as the standard for application integration, customers can simply require that their application providers deliver an integrated virtual software appliance that's compatible with their virtualization layer standard. The only "context" engineering the application providers have to manage is the interface between their system and the customer's virtualization standard.

Given the success of these two models in the market, it's amazing that most ISVs simply treat Linux like "yet another OS" that they must support based on customer demand. Another port means more engineering expense, and perhaps a negative impact on revenue for certain CPU-based licensing models. Since Linux runs on processors that are often two to three times faster than proprietary Unix platforms, a customer might only need half to a third the number of application licenses for a given workload. For these vendors, Linux is a miserable combination of lower revenue and higher costs because they do not consider how it might be used to completely change their business.