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.
What is it about Linux and open source that these vendors can use to create a better business? For starters, Linux is free. Not free as in "free beer," but free as in "free speech." No one owns Linux, which is good if you want to use it to change your business. You don't want your business beholden to any third party that you don't control, or you may find your business held hostage by an erstwhile "partner" in the future. Second, Linux is flexible. It can be tailored to maximize the performance of your application. There are also an almost unlimited number of free software utilities that can be readily added to Linux to enhance the value of your application. Apache, Tomcat, and Struts are just a few good examples. Third, Linux runs on industry standard hardware, so there's no threat of customer lock-in from proprietary hardware vendors.
Given these lessons from the market, it still is not obvious how independent software vendors might win their freedom. There are legacy issues to consider. It's impractical to discontinue support for existing deployments on "independent" systems. And there's the issue of revenue recognition. Moving to a subscription model probably means deferring revenue, which in turn creates a mismatch between revenue and operating expenses on an income statement. Finally, not all applications can be delivered as multi-tenant, on-demand services over the network, and it does not make sense for all software vendors to consider delivering a hardware appliance solution because their customers do not want to add another hardware platform to receive the value of the application.
One transition approach for software vendors to consider to lose their independence and gain their freedom is the software appliance concept. Think of a software appliance as a hybrid of the on-demand application model and the network appliance model. The customer receives an integrated solution that combines the application with a streamlined operating system. The software appliance might install natively on the hardware via an installation CD or DVD, or it could be delivered to the customer in a virtual machine format that runs atop another OS or atop a standard virtualization layer like VMware's ESX server. Maintenance for the entire solution is received from the application provider via a simple web user interface. Since maintenance comes from the application provider, it is pre-tested and certified in the exact environment the customer has deployed, so there are no more mismatched maintenance streams from various vendors.
Many will argue that Windows-based apps benefit from the concept of a "universal" platform. Not true. Microsoft doesn't allow the OS to be stripped of all components except those required to support your application (Microsoft even argued in court that a browser was an integral part of an OS), nor does it let you pass judgment on its maintenance stream before releasing it to your customer base. Microsoft has a "one size fits all" mentality that's inconsistent with the concept of a software appliance. The operating system should be secure, reliable, small, and practically invisible. It should also be free so that your application is never held hostage to the technical or economic whims of another vendor. These are not attributes that describe Windows.
Parting Thoughts
Linux, open source
infrastructure, and virtualization provide application vendors the
historic opportunity to lose their independence and free their
customers from the hassles of assembly and maintenance of complex
software solutions. The initial transition is likely to require an
investment in an optimized port for Linux, and some decisions regarding
when and how to transition customers from legacy platforms will
certainly be difficult.
It is inevitable, however, that customers are demanding lower starting costs and faster time to value from application vendors, and the legacy method of delivering software applications is not going to be acceptable. The great news is that engineering expense that used to be spent on context issues can be redirected to investments in product features, sales, and marketing. Lower cost of entry also tends to expand the available market, opening up customer opportunities that were previously unreachable due to the expense of complex assembly and maintenance routines. It's time to stop thinking of Linux and open source as a threat or simply another application port. It's time to embrace the open source trend as a strategic opportunity to improve the economics and market position of the software application business.