imho Platforms Melting into a Pool of FUD

All:

Has anybody noticed that that the application platform market is melting down?

I mean that on a couple of levels, one of which is what I said in my recent Network World column "SOA and the death of platforms" (http://www.nwfusion.com/columnists/2004/090604kobielus.html). To summarize, service-oriented architecture (the latest paradigm) refers to techniques for designing shareable, reusable, interoperable Web services. As SOA principles take hold everywhere, they're dissolving the formerly tidy underpinnings of yesterday's computing environments, making concepts such as "platform," "application," and "language" irrelevant in the world of Web services. When all platforms share a common environment (environments that natively implement the growing WS-* stack of standards and specs) for describing, publishing and invoking services, the notion of self-contained platforms disintegrates in favor of SOA, which is essentially a platformless service cosmos.

But SOA and Web services is just one part of the platform-meltdown equation. The platform vendors are also flailing about, not able to achieve the sort of momentum that would place their environment--be it Windows, J2EE, or Linux/Apache/MySQL/PPP (LAMP)--head and shoulders above the rest. All of these platforms are dissolving into a pool of fear, uncertainty, and doubt (FUD) that has enterprise customers scratching their heads, seeing no clear "slam dunk" platform for their current and evolving needs.

Look at Microsoft's tortuous path from .NET (aka the Win2K and Win2K+3 generations) to "Longhorn" and beyond. They've decomposed the new generation into a bunch of incremental releases with various release dates, many of them quite indefinite, strung out over several years, with the strong likelihood of unanticipated delays in the releases to which they commit. Nobody has any confidence that Microsoft will ship any piece of its "Longhorn" roadmap on time, by which I'm defining "on time" as within Software Assurance timeframes that would entitle customers to an upgrade (for which many have prepaid, with no guarantee of delivery). Nobody has any confidence that the resulting "Longhorn" generation platform components, apps, or tools will enable tight security, though no one doubts that Microsoft's working extremely hard on all things security-related.

The rival J2EE camp is slogging through its own field of FUD. One of the biggest issues is whether the J2EE “standard” (actually, an evolving assemblage of standards and specifications developed under the Java Community Process by the collected Java community of vendors) will survive in the face of “rebel” Java-based frameworks that offer simpler development/runtime approaches than the full J2EE 1.3 or 1.4 stacks. There are many rebel Java frameworks, addressing simplified programming in the presentation tier (e.g., Struts, Tapestry, Velocity), business logic tier (e.g., Aspect-Oriented Programming, Inversion of Control), and data tier (e.g., Hibernate). Much of the rebellion has to do with the fact that the most basic Java programming model—servlets—is good enough for most developers. The fundamental fault line in the Java community is between those developers who favor development of POJO (plain old Java objects) vs. those that stress what I call “MOJO” (massive obnoxious J2EE overhead). That’s a spectrum from simplicity to complexity, from lightweight to heavyweight, from loosey-goosey to strict-constructionist Java programming. Though J2EE 1.4 is out and J2EE 1.5 is in the works, thanks to diligent work within the JCP, nobody has any confidence that most J2EE app platforms vendors will support the full evolving “standard” in future releases. In the trenches of real-world development projects and practices, the Java community is busily deconstructing the grand J2EE edifice it took them several years to build up. It’s an exciting trend, but it shows that bloom is off the J2EE rose, perhaps for good. Enterprises that have committed to J2EE are sweating profusely, wondering whether the fabled cross-platform framework is a thing of the past.

The LAMP platform vendor community is still in its heyday—in other words, vendors such as Red Hat, Novell, and JBoss can still claim considerable momentum in new customer wins. LAMP isn’t a platform in the single-vendor governance model (a la Windows) or single-community governance model (a la J2EE). Rather, LAMP refers loosely to application environments built on Linux and other open-source components (including but not limited to the “AMP” components in its name).

One of the biggest FUD issues with LAMP is vendors’ inability to assure customer indemnification against damages that may result from IP infringements associated with various open-source components (though Novell and others claim, unconvincingly, that their crack legal eagles will be able to come to the defense if such suits are filed). Closed-source vendors, by contrast, have always provided indemnification as a standard feature of their licenses, and, before the rise of open source, customers always took this legalese for granted. But with LAMP, it’s like buying a house without title insurance—you pay hundreds of thousands of dollars without any assurance that a long-lost titleholder won't some day be able to evict you from your property. Who can stand that degree of insecurity to their bread and butter?

Another FUD issue is the potential for nasty technical fingerpointing when the inevitable security issues strike LAMP platforms. No two vendors’ LAMP platforms are alike. Each vendor (indeed, each user) can and does assemble their environment from a diverse collection of open source components from diverse open source communities. Any security issue or interoperability glitch that impacts diverse open-source components will be a bear to fix, considering the fact that all the piece-parts of the problem are not under single governance. Contrast this to Windows’ unified governance model (a single vendor owns it all) or even J2EE (app platform vendors own their various implementations of the common framework, and also participate in a more-or-less unified community to work out common issues).

All of these platforms—Windows, J2EE, and LAMP—will survive. All of them will continue to evolve. But none of them will overcome the flood of FUD that cramps their respective futures.

Jim