» tagged pages
» logout

(Feed found, click Add Page to syndicate.) Error finding feed, please try again » Find feed title

A Blog Page allows you to add entries, for news or other time sensitive postings

(Login required to save to your tagged pages.)
(or Cancel)

Recent Edits

created by 67.183.221.76

Reining in Bloatware

March 21, 2006
The page was created.
User:byron J2EE
Reining in Bloatware
Article

One of the issues with the "traditional" software world is the constant incentive to add more and more features to a product...

» complete change

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 :-)

Undo this change because:
Username:
Password:
(or Cancel)