Reining in Bloatware

http://creativecommons.org/licenses/by-sa/2.5/ Reining in Bloatware One of the issues with the “traditional” software world is the constant incentive to add more and more features to a product – primarily because this is how “differentiation” is traditionally measured (rather than quality, stability, etc.) The most notable and infamous examples of this are the Microsoft Office Suite – where Microsoft defeated competitiors in the word processing, spreadsheet, and desktop database markets by providing more comprehensive features in the early 90s, and then kept the feature train rolling. In Microsoft’s case, the motivation is to give users a “good” reason to upgrade. Similar phenomina are true in the server software world. Many people never use the “latest and greatest” features in, say, an enterprise database management system. But – very often, they still choose these systems based on feature/functionality. Why? Well, perhaps because information they care about more (like, say, stability of the code base, interoperability, reliability, etc.) isn’t readily available (and in fact many vendors write clauses into their licenses to “prevent” such data from being generated and published.) The issues with bloatware are pretty severe when you’re talking about a large-scale deployment (100s or 1000s of servers) for large applications. “Feature frenzy” means its harder to develop on a platform (too much to learn just to do basic things), harder to test out what you’ve built (dev environments and production environments tend to be very different), harder to manage, and harder to support. Add up all those additional costs, and chances are it far outweighs the benefit of the “latest and greatest” features – even if you do happen to be using them. Open source tends to be different. Take open source Java, for example – a topic near and dear to SourceLabs’ heart. You can get up and running on Tomcat in under an hour, and build simple web applications (it’s some work to download, install and database and configure it correctly, alas…) Compare this to many commercial J2EE application servers. Some of them come on 10s of disks, and can take days to install. I recently encountered one Proof of Concept where it took over 5 system engineers from a vendor ONE WEEK just to install their application server and get it running. Want to do something more complicated? Add the SourceLabs SASH stack to the mix, and you have a platform capable of most things – save distributed transactions. more advanced management capabilities and messaging – than you get from a “full blown” J2EE application server. We have yet to compare the TCO for the two alternatives, but we have several customers who have estimated 20-40% less costs than with a “proprietary” alternative. That’s before you take into account that the license for the open source software is free :-) J2EE user:byron Tue, 21 Mar 2006 21:53:01 -0800 Tue, 21 Mar 2006 21:53:01 -0800