The death of the Platform
I was listening to the Gilmore Gang the other morning (sitting as I do most weekday mornings, on the beach, drinking my coffe, with the iPod on.) I'm pretty sure it was the Ray Ozzie episode. Of of the gang kept going on about "platform". I think he's living in the 90s, trying to interpret the world though now presbyopiatic eyes.
At Microsoft, the companies that attempt to emulate them, and the analysts that cover both, the prevailing assumption seems to be:
1) Platforms are great because they are "black holes". The more functionality they have, the more they suck in users and the more users they have the more functionality they suck in, and ...
2) To get this functionality, the Platform has to be as extensible as possible. The result is that extensibility, not ease of development is the priority for API's.
3) Since the rest of the world often finds these API's complex and/or arcane, and since most of the rest of the world builds the "apps" that both corporate and non-corporate types use, there normally exists a layer above the API's called a Framework which serves to hide the complexity of these APIs, and provides a kindler simpler gentler programming paradigm. (Examples include VB and MFC, as well as Java's Struts, Cocoon, and Tapestry.)
4) If everyone who can code uses these Frameworks, then these everymen end up building a plethora of applications locked into the Platform and, hey presto, instant "stickiness" followed by the desired lock-in. Thus building an IDE and a Framework was the sine qua non of a Platform.
I doubt these syllogisms about "platform" are still true.
Free/Open Source has shown us that well understood software can and will be commoditized. The operating system, the web server, the applications server (to the extent anyone needs one) and message buses are available as, or being written as free or open source. The entire XML processing stack is available as free or open source. The browser can be had as open source.
It follows that the value in "well understood" software is in support and services, not the code or act of coding. The communities that form around free and open source software seem more than able to perform the job of educating themselves, so any application that is "interesting" will soon be "well understood", and shortly thereafter will become available as free or open source. The real value in IT infrastructure has moved from the software to information and the community.
Thanks to free and open source software, Microsoft doesn't have the platform lock-in it used to have. I cannot envision how Longhorn and Avalon or even Indigo can do anything to perturb this value chain in any direction.
These will ship in due time, but they won't be any more relevant than any other Platform, their ability to attract and trap developers, and therefore users has been lost, not because they're late, but because the platform of this decade isn't going to be about controlling hardware resources and providing a rich UI, and they will cost real money. In the very near future, I doubt anyone will be able to charge for the platform per se. Rather, the things people will pay for will be the things they're interested in, the things they want to be involved with or are interested in involve access to community, collaboration, and media. Services, not boxes, are what will rule the next decade.
I postulate, still, that with the DOM 95% of the UI required for this world will be delivered over the browser for the same reason that we all still use a steering wheel in a car or have stayed with << < | > >> for so long. Everybody gets it.
These days its possible to build a fully-capable spreadsheet, word processor and presentation tool in DHTML. The three browsers I give a whit about (Safari, Mozilla, and IE, in that order), all now support XMLHttpRequest, which makes doing an asynchronous HTTP GET from within a Javascript event handler pretty trivial. Such is the stuff that interactive applications are made of. With XMLHttpRequest, and a bit of Javascript, its straight-forward to build a handler function on a web UI that makes a request in the background, which the webserver can respond to by returning a new version of any part of the current page that it likes. That part of the page gets swapped out seamlessly for the new version. The thing I like about this is that it gives all the power to the server side: only after having processed the request does the decision have to be made about what parts of the page are affected and need to be redrawn, and those parts can be sent back to the client.
And of course, Google Suggest is the new darling of the cognoscenti, but it doesn't do anything more than I've outlined above. In five years, HREF will be considered the GOTO of web programming, since it will break what people consider the normal flow of a web-centered set of applications.
Think about that for a good long moment. All the interactivity of the apps you use today, but with all of the heavy-weight processing^Wdecision-making done on the back-end, and links, as we use them today, will be tomorrows day-old newsprint.
Jim on 12.13.04 @ 03:02 AM PST [link]
