|
|
|
 |
<< Tuesday, October 28, 2003 >> |
|
Avalon isn't about Web/GUI convergence
Edwin Khodabakchian echoes what seems to be a common -- but I think incorrect -- perception that XAML, the XUL-like layout language revealed this week to be a building block of Longhorn's Avalon presentation subsystem, heralds some kind of Web/GUI convergence:
We had prototypes and concepts at Netscape that were very close to what Microsoft is starting to promote with Avalon. One the positive side, it is great to see HTML, XML, CSS and SVG become the foundation of UI development within windows. [Organic BPEL]
My understanding, based on a demo I saw last week, is that although XAML is indeed an XML dialect, it has nothing to do with HTML, CSS, or SVG. It's true that the Avalon presentation engine is Web-like, or to be more precise ASP.NET-like in its separation of layout markup and "code-behind." But it builds no bridges to pre-Avalon clients. The foundation of Avalon's vector-based UI, for example, is Direct3D. I asked whether SVG -- an obviously relevant Web standard -- would be a preferred (or at least a supported) interface to Direct3D, and was told that it would not.
Here, from the newly-hatched Longhorn Developer Center, is another statement which implies a convergence that I don't see in the cards:
Avalon and XAML represent a departure from Windows-based application programming of the past. In many ways, designing your application's UI will be easier than it used to be and deploying it will be a snap. With a lightweight XAML markup for UI definition, Longhorn-based applications are the obvious next step in the convergence of the Web and desktop programming models, combining the best of both approaches. [Longhorn Developer Center: Code Name Avalon: Create Real Apps Using New Code and Markup Model]
To my way of thinking, you don't have "the best of both approaches" unless you have a ubiquitous client. As Jeremy Allaire pointed out the other day, Flash is making a serious effort along these lines, and has -- in Laszlo and the forthcoming Royale -- its own XML-based layout techniques. I've also mentioned Mozilla's cross-platform technique, XUL. Now Microsoft is pitching a Windows-only UI renderer that targets 2006-era desktops and notebooks, while allowing MSIE to stagnate. I can see how and why they arrived at this strategy, but it doesn't seem to be the kind of Web/GUI convergence I'm looking for.
|
|
Open source citizenship
On the world stage, both failures and successes can loom larger than in the corporate cubicle. Developers who plug into the reputation-driven meritocracy of open source -- while advancing the goals of your business -- are a force to be reckoned with. [InfoWorld: Open source citizenship: October 24, 2003]
This column was based on the observation that corporate IT shops are apparently more likely to fork an open source project for internal development and use, than to join and contribute to the project. Some correspondents were puzzled by my comments on licensing, so I'll try to clarify. The open source licensing regime, as Tim O'Reilly has often pointed out, has as its basis the distribution of source code. As we move to a service-oriented software ecosystem, that basis will necessarily erode. If a GPL'd module is copied, modified, and then deployed behind a firewall to power a service that's world-accessible and free (as in 'free beer'), then am I as a user of that service free (as in 'free speech') to modify and share it? In one sense yes, I can wrap the service in a novel service of my own creation -- if the provider's terms of service (a different layer of licensing) allow me to. In another sense no, the internal modifications that make the service more interesting/powerful/useful than the GPL'd original are not available to me for modification and sharing.
I'm not suggesting that a different licensing regime could, or even should, prevent such a scenario. But I am saying that some habits that evolved decades ago will need to be rethought in a service-oriented ecosystem. Another example, which I mentioned in a column on open services a while back, touches on the way tests are bundled with open source projects. Here again there is a presumption of source distribution. But when a user of a service never acquires its source, and invokes the service from a different programming language than the one in which it was written, it may make more sense to deploy tests as auxiliary SOAP/WSDL constructs.
Back to this week's column, here's what I think is really the most salient issue:
Like the Internet itself, the modern enterprise now relies on the fruits of the most successful open source projects. But the commoditization of operating systems, compilers, and servers only scratches the surface of what's possible. All sorts of infrastructure software can benefit from the open source model. Business software, not all of which is necessarily proprietary, is ripe for commoditization too.
If we're going to get substantial commoditization in the business layer, based on an open source development model, it won't be the result of licensing innovation. Rather, it will happen when captive developers are allowed to come out and play, to explore the boundary that separates proprietary intellectual property from sharable infrastructure, and to work together on commoditizing that sharable infrastructure.
Update: A thoughtful follow-up from Matthew Langham.
|
|
|
Recent Entries
|
|
NEWS 
