FYI, I just published an article in Java Developers Journal: The Rich Client Strikes Back.

We are being bombarded these days about the increasing threat of security. Microsoft has long been a target in this area, as have Java, and Flash, but now Linux is also coming under attack. The attacks are coming with greater frequency and with greater destructive power, and they are coming in the form of malicious code, or "malware".

In order to make significant headway in the struggle against malware, we need to fundamentally change the rules of the game. In a recent article for CNET News.com, "Inherent Insecurity", I argue that fat-client architectures are inherently vulnerable to attack, and that by switching to a thin-client model we can cut down on the amount of raw material that malware has to attack. In another article, "Fencing In" for ZDNet, I argue that we need to change our basic security posture and actively contain threats rather than huddle in our bunkers. I cite early examples of fence in strategies being used against viruses, hackers, and spam. Interestingly, I just came across another application of the fence in approach being suggested for flu vaccinations.

I have already amply talked about Microsoft's battles with the Java camp (which are still just in the warm-up stages). That battle brings the software titan into conflict with IBM, Sun, BEA, Oracle, and host of others. Battles in the database arena redouble that conflict with IBM, Oracle,and others. But although the conflicts between these vendors are taking on new shape, they have certainly been raging for some time

Now, I just noticed a couple of articles that outline Microsoft's emerging conflict with new types of competitors, namely its tussle with SAP in the business applications space and its rivalry with Sony in the game console arena.

I watched an interview with Steve Ballmer, maybe a year or so ago, in which he announced that Microsoft was fighting a 7 front war. It does make sense. Microsoft needs to find new markets in order to maintain its phenomenal growth. It is also betting on the value of synergy between its products in different markets: if people's lives are made better by Microsoft technology being truly ubiquitous, then Microsoft locks in further advantage.

But then 7 fronts is a lot of fronts. Microsoft is very powerful, and undoubtedly feeling very powerful, these days. But even a superpower that seems to have the strength to take on all other contenders at once can run into difficulty in unexpected places. The payoff side of Microsoft's game is clear. The risk side is that by spreading itself too thin, or by turning against key allies, it becomes vulnerable in a core market.

I often rant about the epic battle that is brewing between Java and .NET. But there is another battle, not necessarily less significant, that has long been brewing within the Java camp. It is a battle between Sun and IBM over the control of Java. Although the two have long been fierce competitors in the area of systems, the struggle over Java has so far been largely a cold war, veiled under a veneer of cooperation.

But recent moves have brought the battle more into the open. Since Sun decided to make Java an “open standard” and turn its stewardship over to the JCP, Sun gave up a certain level of control over Java. But it still retains sole rights to the name and gets to decide what is called Java and what is not (this is the same leverage that Linus Torvalds holds over Linux). Earlier this year, Sun made the decision to become more aggressive about exerting that right by renaming its core product stacks the "Java Enterprise System" and the "Java Desktop System", even for components that have little or nothing to do with Java. This move angered a number of Java partners, but Sun undoubtedly hopes that it will more strongly tie the identity of Java to Sun.

The other open battle is in the area of Java tools. IBM and Sun each push toolsets that are built on open source foundations -- Eclipse for IBM and NetBeans for Sun. There was talk about Sun joining the Eclipse consortium, but now Sun has made it clear that it will rather support NetBeans to the bitter end, and is instead arguing for a standard to improve interoperability between tools from different vendors, a proposal that IBM has rebuffed. Aligned with each of these tools is a separate GUI toolkit -- Swing for Sun/NetBeans, SWT for IBM/Eclipse. The passions surrounding this schism run deep. At a recent conference, I witnessed Swing developers vociferously laying into IBM execs about IBM's insistence on building Eclipse with SWT, even though Eclipse can build Swing applications.

The battle between Sun and IBM certainly predates Java, and even today it ranges beyond Java. Web services and support for Linux are two other areas in which the two systems companies have been engaged in open and behind-the-scenes tussling.

For us who develop in Java, the critical issue is what bearing this battle will have on the future of Java and whether it will weaken Java in the face of an onslaught from Microsoft .NET. Java is a grand experiment. Is it possible that many independent vendors, who normally compete with one another, can come together and work for the betterment of something as complex and with as many facets as Java? The answer to that may be key to whether the larger grand experiment of open standards for software will prevail.

Microsoft is placing its bets that fat clients represent the future of software, not browser-based thin clients. In fact, they are phasing out development of a stand-alone Web browser. Longhorn will have HTML viewing/browsing capability built right into the OS, and there will no longer be an Internet Explorer.

I’m not surprised by this. Web clients have never been strategic to Microsoft, which needs to ensure that the Windows desktop remains supremely relevant. The core idea behind HTML browser applications is that they can run equally well on any client-side platform, which thus makes the specific features of Windows unimportant. There is growing customer dissatisfaction with the ergonomics of HTML for enterprise applications, and a number of vendors are offering “rich client” alternatives. Microsoft is offering .NET Smart Clients as its rich client solution, which also happens to be a fat client architecture that runs only on Windows desktops.

That all makes a lot of sense from Microsoft’s point of view. The big question, however, is what will happen to the many Web applications that exist today and to technologies that are dependent on the browser. If Microsoft wants to encourage a Smart Client architecture, will DHTML be phased out?

"Microsoft wants enterprises to write browser applications that take advantage of Longhorn application programming interfaces (APIs), which means that they won't work on non-Longhorn browsers," [Michael] Silver, [an analyst at Gartner], wrote in a research report last week.

At Microsoft's developer conference, for example, Amazon.com showed how it has used the Avalon graphics technology and the WinFS file system in Longhorn to create an improved shopping site.

Amazon's chief technology officer, Allan Vermeulen, showed how a Web shopper can do a number of tasks that could not easily be done from within a browser, such as rapidly filtering search results for cameras and viewing a photo of a camera as a three-dimensional object. Information from the e-commerce site could also be easily shared with a person's calendar application.

Microsoft’s competitors, IBM, Sun, Oracle, and others, have been rallying around the Web-based Portal as the primary means for enterprise application delivery. Microsoft’s moves call into some question the future of the standard Web portal, even as Microsoft has started pushing its own SharePoint portal software hard in the market.

Microsoft continues its strategy to cut off Java from end users.

My last entry evoked a certain amount of name-calling in the arena of open standards. Today I'd like to explore just what "Open Standards" might mean. This will seem very simplistic to many of you, but I hope it’s helpful to sort things out in a simplistic way.

I’d like to start with some definitions:

Open - Open for third parties to support and create products to (opposite is Closed)

Proprietary - Legally owned by a company, individual, or private group (opposite is Public Domain)

Community - Administered by a group, not just a single company (opposite is Sole-Stewardship)

One minor note that some people seem to miss is that open and proprietary are not opposites. A standard may be both open and proprietary at the same time. A "closed standard" is an oxymoron. You can have "closed systems" which do not allow third-party integration, but you cannot have a meaningful closed standard.

A standard that is not legally owned by any company or person is said to be in the public domain. Examples of this include: HTML, SNMP, etc.

A proprietary standard is owned by a single company and may be administered solely by that company, as Windows and Solaris APIs are, or it may be administered by a community, as Java is. Some communities are have their own bodies for collaboration (JCP), and some rely on standards bodies, such as the W3C, OASIS, ECMA, and so on, to handle community collaboration and be the official keepers of the spec.

An "open source" standard is one in which the source code as well as the APIs are included in the specification of the standard, meaning that third-parties can extend the product at the source code level, not solely by working through an API. Open source is considered by many to be the purest form of open standard. But again, that doesn't mean it can’t be proprietary. Linux, a favorite open source example, is not in the public domain. The Linux GPL license does not require a monetary fee, but it does make other requirements which it imposes with a copyright. For instance, all source code for modifications made to Linux must also be freely available. Linus Torvalds explicitly owns the registered trademark "Linux". FreeBSD, as a counter-example, is also free of charge and open source, but does not impose the requirement of sharing enhancements with anyone else.

Whether software costs money, and what it costs, are economic/strategic decisions made by the owners of the software / standard. 0 is a price, just like 5 or 745. 0 just carries more psychological weight than other numbers. The underlying license and source code for Linux are free, but distributions of Linux do not have to be free. Companies can charge whatever they want for them.

The relative advantages of these are not moral. They are rooted in various benefits they give to the owners and users of the standards. One of the benefits of using open community standards is vendor-independence: multiple vendors can create competing products that implement the same standard, thus giving customers more choices. Cost, ability to extend, and ability to debug are common reasons that customers choose open source software, but keep in mind that many “closed-source” solutions do provide source code to their paying customers for debugging purposes. One might say that a sole-stewardship standard carries the risk to users that the single company administering the standard can potentially change that standard to suit only its own needs, thus causing damage to third-party users of the standard. Conversely, since a community-administered standard must reflect the interests of a group of different constituencies, it is unlikely to change capriciously or quickly. This distinction is the heart of the Microsoft / Java war of words.

The flip side of that is, of course, that since community standards are slow to change, single-stewardship standards can be much more nimble and capture the changing realities of the marketplace in a more time-sensitive way. When a standard is too slow to change, then vendors supporting the standard are sorely tempted to add one-off extensions for functionality that is not yet standardized, which erodes the value of the standard.

Customers make choices about their adherence to standards based on what they need to achieve and the risks they perceive.

There was an article in yesterday’s Wall Street Journal, Cloud Over Sun Microsystems: Plummeting Computer Prices, which dissects Sun’s current financial and strategic challenges.

One of the interesting claims in the article is that "Scott McNealy, Sun's chief executive for the past 19 years, long resisted the standardization trend sweeping across the tech industry." The articles asserts that "The wager paid off, making Sun the dominant provider of the server computers that power Internet sites and corporate computing. But now the company is paying a big price for bucking the tech mainstream -- and scrambling to keep customers and stay afloat."

It's ironic to see Sun portrayed as a company that has consciously flown in the face of standardization, when in practice Sun champions open standards precisely as a way to differentiate itself from Microsoft.

So, which company does this article say represents mainstream standardization? Microsoft. "Sun appears to be the latest casualty of the rising tide of tech standardization, led by Intel and Microsoft. Many companies in the history of high-tech -- Digital Equipment Corp. and Apple Computer Inc., among others -- believed they could resist standard designs and thus ultimately charge a premium for their products. In the end, a lot of these companies were either acquired or hang on in the industry as smaller players."

In yesterday’s post, I mentioned that all too often tools that help developers put out a really quick version of their application are frustrating to use when trying to create a sophisticated production version of the same application. This forces the developer to back-track and gives rise to the concept of the "throw-away" prototype, meaning that any effort put into the prototype has to be chalked up solely for the purpose of getting early feed-back but has to be tossed when it comes time to build the "real" system.

Today I'd like to illustrate what I mean with two very common examples of this phenomenon: visual GUI builders and data-aware controls. I have a love-hate relationship with them both.

By visual GUI builders, I mean WYSIWYG editors for laying out components in an application window. It's great to be able to sit down at a blank project and just start grabbing controls and laying them out on the screen, one after the other, changing positions if you change your mind about the layout, setting properties and seeing those properties immediately reflected in the representation of the window you are building. It is very satisfying to be able to put together a window so quickly, and it is much easier than instantiating all those widgets and setting their properties in code.

However, building the GUI through code does have some big advantages, and, personally, I almost never use a GUI builder for a production application. Here’s why. GUI builders give developers a component-by-component interface onto the window and treat properties as literal values. So, if I want to set the background color of a bunch of my components to red, I have to go and set the background color property of each of those components manually in the GUI builder. And, if I want to change the background color of all those components to something else, say orange, then I have to go through and change them all manually again. The GUI builder gives me a really quick way to put the window together but ends up with a pretty brittle design that requires lots of manual labor to make subsequent changes.

If, on the other hand, I set the background color of those properties in code, I can simply make a variable that represents the background color, set the color properties of those components to the variable, and then set the variable to red. It takes more time to set this up, and it’s a non-visual development process, but my design is now more flexible and I can change the background color of all those components by simply resetting the value of the variable to orange. This is exactly the benefit that Web apps get from CSS, and Joshua Marinacci posted a great article yesterday, CSS and Swing, about how you can achieve similar results to CSS in a Swing app by making a properties file that is read in at run-time. The problem, however, is that this takes you out of the GUI builder and into the code. I want a GUI builder that can handle this for me. Fortunately, many GUI builders generate source code which allows you to take a hybrid approach: use the GUI builder to generate basic component instantiations and properties, and then modify the generated code by hand from there. Still, I wish I didn't have to switch modes -- and that approach is generally a one-way street.

This problem can be more much sophisticated than just setting properties on components. I find that I often want to create bunches of components programmatically, with a loop, reading component specs from a database or config file or based on some algorithm. At that point, even a CSS mechanism can’t help me. I long for a GUL builder that can give me a visual environment to see what my window looks like at all times but to be able to create and manipulate components algorithmically as easily as I can create and manipulate them visually.

I feel similarly about data-aware controls. Manually wiring up GUI controls to database values is admittedly a pain, so data-aware controls are also a great boon in helping developers get a basic version of their app up and running quickly. However, I have rarely written a sophisticated data-driven app where I didn’t need to massage data while reading or writing from/to the database. Hard-wiring controls to the database tends to be pretty brittle. So, once again, for production-quality apps, I have to abandon the data-aware controls for a manual, code-intensive process that gives me the flexibility I need.

I would sorely love to have versions of these tools that can support the flexibility I need for production systems as well as the RAD capabilities I value for prototypes without having to backtrack and change gears along the way. Maybe such things exist, but I haven’t seen them.

There are three main factors that affect the ROI of any UI technology: ease of use of the application, ease of deployment and on-going maintenance, and ease of initial development. Based on the total cost associated with each of those factors, they should be assigned the following order of priority:

1. Ease of Use: The usability of an application affects the bottom line of a company every day and that effect is multiplied by the number of users the application has.
   
   
2. Ease of Deployment and Maintenance: The costs associated with the deployment and maintenance of applications affects a company’s bottom line on an occasional but usually repeated and perhaps regular basis. These costs are incurred whenever an application needs to be deployed to new users, upgraded with new features, and have bugs fixed.
   
   
3. Ease of Initial Development: The costs associated with the initial development of a new application affect the bottom line of a company only once per app, and they scale with the number of developers involved, which for the vast majority of applications is far less than the number of users of the application.

The temptations of the immediate gratification of fast initial development can be so strong, in fact, that some UI development tools focus entirely on the ability to put together a good-looking but simple application really quickly. This is valuable for getting early user feedback. However, many of these rapid development systems are ironically difficult and time-consuming for creating sophisticated applications, because of an inherent lack of flexibility. A good UI technology will enable rapid prototyping but won’t do so at the expense of production version development.

Therefore it is imperative that companies apply sufficient discipline in their technology selection and implementation to ensure that an economically correct ordering of priorities is followed.

Microsoft is renowned for its "embrace, extend, extingish" strategy which involves enthusiastically embracing and championing a new standard, as a way to become the market leader in that standard, then extending that standard with proprietary technology that lets Microsoft lock in customers and lock out the competition, and lastly to let the standard die on the vine or be replaced by an entirely Microsoft-proprietary alternative. Microsoft has famously done this with Java, which in its final stage has now been replaced by C# in the Microsoft view of the world.

In an earlier post, I suggested that Microsoft makes money from Windows desktops, not browsers, and that a powerful browser platform is in fact a threat against the Microsoft-preferred fat-client model which is more firmly symbiotic with the Windows desktop.

It seems there is growing evidence that Microsoft may in fact performing a slow embrace, extend, extinguish on the Web browser.

Embrace: When Netscape introduced the first commercial browser, along with the promise that the Web would make the desktop environment irrelevant, Microsoft quickly jumped to develop Internet Explorer and used a wide array of competitive tactics to ensure that IE grabbed overwhelming share of the market and eventually pushed Netscape out of business.

Extend: For a while, Internet Explorer supported all the W3C standards for Web pages, but also added its own additional capabilities that let Web designers do things that the official standards did not support. This seemed like a helpful feature for developers, but had the inevitable effect of locking developers in to the IE platform. I recently met with an ISV that has a Web-based application that depends on the IE 6 extensions. This meant that the ISV required all their customers to access their application through IE only. But now, since a significant segment of this ISV's customers use Apple Macs, and since Microsoft no longer supports IE 6 on the Mac, the ISV is left high and dry.

Extinguish? I read an article this morning titled "Has Microsoft Forsaken IE?" in which developers complain that Microsoft is falling behind in supporting new Web standards.

"While it is true that our implementation is not fully, 100 percent W3C-compliant, our development investments are driven by our customer requirements and not necessarily by standards," said Greg Sullivan, a lead product manager with the Windows client group.

When it was pointed out that the most vocal critics of IE's CSS support are Web developers and authoring tool makers, rather than standards bodies, Sullivan said those critics were comparatively few.

I recently spoke at a technology conference as a part of a panel, and one question from the audience was about which open standards were most important. My response was that there are many important open standards, but that one crucial capability that customers are looking for from open standards is the ability to make application decisions independently from infrastructure decisions.

The reason it’s valuable to be able to decouple those two decisions is that they are typically made by different groups within the enterprise and they are made for different reasons. Infrastructure decisions are made by the IT organization and are based ideally on price / performance. Application selection is typically made by line of business users, and functionality is the primary driver.

If a company cannot treat each of those layers independently then an application decision becomes simultaneously an infrastructure decision, which means that all the factors of functionality, price, and performance need to be considered together and the decision needs to be made by a combination of business people and IT folks, which complicates the process and potentially ends back up in “silo” structures that companies today are trying hard to escape.

There is a lot of buzz in the Microsoft community these days in advance of the first public educational events around 'Avalon', one of the many new pieces of the Longhorn version of Windows. Avalon is the new Windows API, and it apparently represents a major jump in UI capabilities. Part of its value proposition is in the ease of use to developers and part in the experience for end users.

In order to increase developer productivity, Avalon will rationalize and reduce the number of APIs in the Win32 stack from over 70,000 down to 8,000.

On the user experience side, Avalon will feature advanced support for 2D and 3D vector graphics as well as standard GUI widgets. Some descriptions of Avalon suggest that it is more comprehensive than just the graphics layer, and will incorporate support for paradigm-shifting "task-oriented" UIs.

Microsoft has already said that they will be releasing a version of Microsoft Office for Longhorn based on Avalon, which should help drive user demand for Avalon’s capabilities.

I see several immediate ramifications for this:

1. It is a shot across the bow of Macromedia Flash MX. Flash has traditionally been focused on adding real-time vector graphics to Web pages for decoration or on-line advertising. Microsoft played along with Macromedia, bundling Flash into IE, because it never really cared about those fluffy things. But in the last year or so, Macromedia has been actively re-positioning Flash (now called Flash MX) as an alternative for building the user interfaces for enterprise applications -- smack into Microsoft’s home turf. It has been inevitable that Microsoft would respond at some point (there were early rumors that Microsoft might even try to buy Macromedia), and now it seems to be doing that with Avalon. Even though Longhorn isn’t due out until 2005, the mere fact that Microsoft will be baking into Windows the same kind of real-time 2D and 3D vector graphics capabilities that Flash promises, nicely integrated into same API layers as standard GUI widgets, could create enough FUD to slow down companies considering Flash MX. The fact that Flash is a client-side UI execution engine, just like Microsoft technology, means that it doesn’t have a strong differentiation over a Microsoft offering. Strategically, Microsoft can potentially always turn off its bundling deals with Macromedia, leaving them high and dry.
   
   
2. Introducing a major change in the UI API means giving Java a good shake. It is likely that it will take client-side Java long time to support the new capabilities of Avalon. If Microsoft can get its users addicted to the new paradigm (by using it in Office, which they plan), then they make Java look even more out-dated on the client side.
   
   
3. As I have argued elsewhere, Microsoft doesn't really like the idea of browser-delivered apps because it weakens the Microsoft desktop. Just as with Java, if Avalon gives users an amazing experience which is just not available through the browser, then browser-based apps don't seem like such a good idea to users. Alternatively, the browser might support these capabilities, but only through IE when powered by IIS on a Windows server.
   
   
4. Longhorn requires hefty hardware support, so Microsoft will undoubtedly time release to coincide with a price/performance level for new PCs that will allow them to encourage a massive hardware churn. That means that the Longhorn release will likely be coordinated with hardware partners like Intel and Dell.
   
   
5. The depth dimension of the desktop is catching on. Sun’s Project Looking glass uses depth by letting users angle windows away from them, thus using less of the 2D space of the desktop while still giving users an oblique view of what’s in the window. Microsoft’s new desktop, Aero, which relies heavily on the capabilities of Avalon, also makes more use of the 3rd desktop dimension by supporting transparent windows (so you can see the whole stack underneath at once), and also supporting real-time window rotation.

Of course, a rich thin client technology could take advantage of all the advanced features of Avalon and still let the business logic be powered by Java.

In his article, "Why Microsoft needs IBM this time around", Mike Ricciuti argues that "Microsoft needs IBM to legitimize .Net and its entire development plan as a truly cross-platform strategy." While I think that both IBM and Microsoft sincerely want to make a case for the power of Web Services and to demonstrate that it is a cross-vendor effort, I think that neither does Microsoft needs IBM to help drive sales of .NET nor does IBM have any interest in legitimizing .NET.

Web Services and .NET are two very distinct things. Web Services is an open standard for programs to exchange data over a network. .NET is Microsoft's proprietary application development and deployment framework that happens to use Web Services as part of its approach. IBM can support the former without supporting the latter.

Web Services are in fact starting to take off. A number of customers that I work with have started to adopt Web Services as both an internal IT transport layer and even also as a way to make content available to business partners (in very contained ways so far). The fact that Web Services have not yet completely transformed the world by seamlessly interconnecting all supply chains and other business partner relationships is simply a result of:

1. the fact that it take a long time to adopt any new technology, and Web Services is still very young in the grand scheme of things.



2. there are still a lot of issues with Web Services that need to be worked out to make them practicable in the large. Specifically, Web Services need more management, orchestration, transactional efficiency, and security support. These are exactly the areas in which IBM and Microsoft made a commitment last week.

.NET is also being adopted, even without companies necessarily buying into the grand plan for Web Services. So far .NET’s success has primarily been a tools success -- Visual Studio developers are upgrading to Visual Studio .NET. However, I have come across several large Java-oriented enterprises that are now planning on building .NET Smart Clients to their J2EE back-ends because they feel that Java has not given them a viable alternative on the front end.

I suspect that Microsoft's peculiar interest in Web Services is a way to leverage the existing base of J2EE installations in the market without having to do anything specific to support J2EE (which would be anathema to MS). I have argued in an earlier entry that Microsoft plans to use its domination of the desktop to push the client side of .NET and then to use the domination of client-side .NET to push server-side .NET. The challenge that Microsoft faces is that many large corporations currently have big investments in J2EE -- if Microsoft forced them to turn their backs on those investments in order to adopt .NET, then client-side .NET would face a lot of extra friction in its adoption. Microsoft can erase that friction with Web Services and then tackle the server-side (i.e. head-to-head competition with J2EE) as Phase 2 of its strategy.

Just wanted to let everyone know that I wrote an article titled Building software that matters that was published on ZDNet today.