Choosing The Platform Comments OffCat.: Then they laugh at you...
28. August 2005
This is a two-parter in two parts.
A few months ago I became partial owner of a small technology company. A long time friend and colleague had started in on a set of web applications for managing (US) health benefits (wait - don’t go anywhere yet, this will get on topic in a second) and succeeded in convincing me that this was an area of business IT that could benefit excessively from being part of the web. About 60% of this particular application’s functionality was there when I signed on and was built using Microsoft’s .NET, SQL Server, and IIS. My partner had little experience with the technologies I tend to recommend on this site and so the decision was made to move forward with the safety of .NET while researching potential alternatives for future work.
My days have been spent refining and growing the .NET app while my
nights were spent researching and assembling a platform that would allow
us to work in a much more agile environment. I have a fair bit of
experience working with LAMP (where “P” is for
Python and “M” is for
PostgreSQL). That experience served as a
starting point but what I’m after is much more than a simple running
environment. I’d like to pull together the various tools necessary to
develop, test, manage, maintain, and deploy applications built on the
LAMP foundation. That means everything from Subversion to Mailman, Trac
to Wordpress, and on down into the guts of a hacking environment like
build tools (
make, etc.), automated documentation utilities,
continuous integration and testing, etc.
That’s the briefest possible history to bring us up to present time where I’d like to talk about two important observations I’ve made over the past few months of being in this situation. I’ll be talking primarily about Microsoft but everything here is applicable to the Java platform and, in some cases, is more so because I’ve made a few assumptions about what is available for .NET based on Java experience (for instance, I’ve barely used Nant or NUnit but assume they’re roughly on par with Ant and JUnit).
The first observation (and the one I will be exploring for the rest of this post) comes from being in extremely close, and somewhat handicapped, competition with the Microsoft platform. Please remember that I am partial owner of this company, have a working application written in .NET, and feel extreme amounts of pressure to create revenue quickly while keeping cost (in both time and money) at a minimum. This situation has forced me to use extreme prejudice when evaluating tools and technologies. In some ways I’ve inherited the responsibility of championing Microsoft’s platform (if only to myself) as my situation requires that I provide real evidence that shows not only that gains can be had by using something different but that these gains are significant enough to justify the cost of that change. In general, the situation just plain sucks - I have to work much harder than if we were to secure a couple million in R&D budget for the year or were juiced up on venture cap. I’m not saying that because I wouldn’t give 100% of my capacity in those situations but it’s hard to imagine manufacturing the level of discipline created when your house is sunk into something.
Back to Microsoft’s platform: they have all the major pieces in one place, are fairly organized, and are extremely accessible. However, time and again I’m finding that I can beat them in almost any given area with lightweight F/OSS technology but I can’t beat the platform as a whole. It’s just all there. The sense of safety this creates cannot be ignored (I’ve tried).
I want to be absolutely clear about that last point because I’d hate to be misrepresented: in a great number of cases, I’ve found individual F/OSS technologies to be superior to their Microsoft counterparts but the lack of an overall platform whole is distressing. I don’t care about indemnity, paid support, certification, finding people to hire, TCO (blech!), etc. because I already understand the F/OSS answer to those questions and they are compelling. I do care about being able to answer the phone, talk to a customer, and feel confident in what and when I can deliver. Microsoft either gives me that ability or gives me the illusion of having that ability - it’s assuring and troubling at the same time.
All this is to say that Kevin Barnes’ Freedom Languages really hit a chord with me. I have very little doubt in the area of language: Python or Ruby just completely destroy any of the mainstream .NET languages and Java to boot. What makes me feel safe is the consistency of the rest of the tool-chain, the massive amount of component libraries, and the breadth of the core platform.
I keep going back to Kevin’s idea of measuring things on the axes of Freedom vs. Safety, where “freedom” isn’t so much GNU-freedom-type-freedom but rather a sort of aggregate measure of the qualities we find most compelling in software design and architecture. Weighing things on this scale helps explain some of the intuition I’ve been feeling over the past months. If we measure the three major platforms competing for business mind-share, I think you find first that Microsoft is extremely safe while offering the least freedom. Next we have Java, which is pretty safe too but the established F/OSS communities (e.g. Apache, Codehaus, etc.) and even the vendor’s (Sun, IBM, BEA, etc.) positions provide a bit more freedom. We then arrive at LAMP and friends which tend to sacrifice safety but provide unmatched freedom and thus, when measured along the web’s core axioms, quality.
Given those basic metrics, choosing a platform comes down to making two key decisions: where do you fall on the safety/freedom scale and in what manner would you like to proceed? Your remaining time (e.g. forever) will be spent doing one of two things: making the platform more safe or making the platform more free. You have infinitely greater control over one of these situations.
We played the fence but I believe we’re arriving at a turning point. I’ll talk about that in part two because the areas explored there are different enough to warrant a separate URL - mainly my experiences in making the LAMP platform more safe and complete but with twists and turns that will eat your brane.