Feature heap won't undo LAMP's toll on Microsoft

You've heard of feature creep? The phenomenon that occurs, usually during the specification phase, when extraneous features somehow work their way into software in such a way that can make the resulting product either too complex or worse, impossible to use? Well, now comes feature heap.  This, according to a story by News.com's Martin LaMonica, is Microsoft's strategy for neutralizing the threat that the open source LAMP stack poses to sales of Windows Server 2003 as well as Microsoft's other server-based offerings such as SQL Server.  For more on LAMP (as well as its kissin' cousin LAMJ), check out my last blog about how it's also one of BEA's demons.  According to LaMonica's story, "Microsoft's anti-LAMP strategy is to heap features into its low-end products and to build a comprehensive set of tools--spanning development to management--in the hopes of making Windows Server more attractive."  In other words, give away as much a they can possibly afford to give away with Windows Server in hopes of making the total package a better deal than LAMP, even though there's a commercial license.

To me, this sounds like the exact opposite of what Microsoft should be doing (if that's what it's really doing).  Not only for it to have any hope of deflecting LAMP, but more importantly, to appeal to the logic (or at least part of it) that attracts IT folks to LAMP in the first place.  One key feature of the LAMP stack that attracts IT pros (and many startups) is its modularity.  You don't like the the distro of "L" (Linux) that you started with? Although it's not always that easy, you can substitute SuSE Linux or some other distro for Red Hat (or whatever you started with).  Don't need or want the "M" (the MySQL database)?  No problem.  Have a preference for Python over Perl (the "P")? No worries.  Or, go with PHP.  Or, change the "P" to a "J" as in open source Java or J2EE (ie: JBOSS, JOnAS, etc.).  

Another big attraction to the LAMP stack, in addition to the aforementioned modularity, is the option of simplicity.  Linux, by virtue of its open source nature, doesn't have nearly the layers of stuff hardwired into it that Windows Server 2003 does.   Not that all that stuff -- systems management features, security features, etc. -- aren't great to have.  Under the right circumstances in specific scenarios, it's wouldn't be unusual to take advantage of all of them.  But what if you don't want to?  Depending on where you start your Linux build from (either what a distributor like Red Hat or SuSE gives you, or starting from scratch), you're not stuck with a heap of features just because your vendor says they need to be in every build of your OS.  The degree of bloat is up to you.   And so, there are thousands of very efficiently configured LAMP and LAMJ deployments out there that contain only the componentry needed to fuel the applications they support.

In contrast, apart from the way the clever authors of some technical journal pieces have figured out how to trim some of the fat off of a typical Windows installation, most of the features that come in Windows stay in Windows whether you like it or not.   How many times have you heard of those average users who wants to wipe their hard drive and start from scratch just to declutter their systems?  IT pros are far more anal about that clutter.  They hate it -- especially on their servers. 

So, when I read in LaMonica's story that Microsoft is going to heap more stuff into low-end products in hopes of creating something that's attractive to the type of IT pro that might normally be drawn to LAMP, my instincts are to ask why Microsoft isn't doing the opposite.   Instead of heaping stuff in, make it easier to deconstruct the Windows stack into something that's far less complex and much simpler for IT pros to get their head around.  Easier when it comes to keeping track of what's in the system (fewer things to go wrong). Easier to come up with the standard build that IT departments, consultancies, or outfits like SpikeSource can rubber stamp for certification and production use. 

In some ways, Microsoft's embedded program represents a seedling of promise to those looking for a simpler Windows-based stack.  But, as I learned from embedded systems architect Miles Wade earlier this year, Microsoft has left much to be desired from its embedded initiative for certain types of customers (coincidentally, the same type of customer that the LAMP stack appeals to).   It's been five months since I interviewed Wade, who was considering a move from Windows to Linux.  Things may have improved since then. (And to be clear, it wasn't a server app, but why can't embedded Windows drive server apps?)

Finally, if attacking TCO is what Microsoft is after -- and heaping TCO-reducing features into existing and new products is the way Microsoft thinks it can do that -- one other place Microsoft needs to soul search is its licensing costs.  Without limitation, if an IT shop so desires, licensing fees can be completely avoided when connecting clients to a LAMP or LAMJ stack. (You can always find some non-open source components that trigger a licensing fee of some sort.)  Doing this in a Windows environment can be a bit more challenging.