Related link: http://www.oreillynet.com/pub/wlg/1992

I enjoyed reading Ted Neward’s weblog on The Success of Java, but I disagree with his conclusions and I have an alternative proposal.

I agree with one of the reader comments on Ted’s article, which says that creating GUI code is not something open source projects have done particularly well. The reader points to shipped GUIs like GNOME and KDE, and certainly there are other examples in this vein. I would go a little further and say that GUI APIs are probably even more removed from the strengths of an open source project model. Not only must the API itself be internally consistent and easy to use, the effects it creates — that is, the look and behavior and defaults — must be externally consistent as well. I certainly would say an open source project could succeed at such an effort; but I would also say I haven’t seen it happen yet, and it would take more — much more — than Sun dumping a ton of code into the ether for it to happen.

(As a side note, I think there’s a very interesting project waiting to be done: an analysis of the governance and participation models of various open source projects. I’ve suggested this to Tim O’Reilly in the past and I would do it myself if I had more time. Linux and Perl and Apache, three of the most widely-referenced open source successes, have three incredibly divergent models for controlling change and inviting participation. The leadership models are radically different, the histories are rich, and arguably the nature of progress and evolution varies between them. I’d love to see in-depth interviews with participants in these and other projects, with some resulting prescriptions for how to run projects under the models suggested by Linux’s “benevolent dictatorship,” Apache’s “meritocratic representation,” Perl’s “monarchy and prime ministry,” and others. Relevant to the Swing discussion, an open sourcing of Swing would need, in my view, either a benevolent dictator or a monarch and prime minister model — the representative governance of Jakarta seems the worst-suited to the level of consistency and integration needed for GUI development. The closest analog is Perl, not Tomcat.)

In any case, we could argue about whether an open source GUI project would succeed or fail. We could even argue whether the development of Swing is really a problem — I think Swing is an excellent API hobbled by the horrible desktop performance of Java. Instead, I’d like to set this aside and make an alternative proposal for Sun and the open source community around UI development and the Java libraries.

One of the most tantalizing things I’ve found in C# and the .NET platform is the close relationship between Windows Forms (the .NET analog of Swing) and Web Forms (the .NET analog of JSP). When you look at these two APIs, you can see that Microsoft is pushing them as closely together as possible. Why? Well, here’s what Microsoft says on the topic:

The next generation of Visual Studio will dramatically reduce the complexity of creating the next generation of Web applications. Visual Studio developers will be able to develop applications targeting the Web using the same paradigms with which they build Visual Basic applications today. With new, simplified techniques for Web application development, and with inherent support for industry standards such as XML and SOAP, Microsoft will help Visual Studio developers create the next generation Web.

In other words, bringing the Web and desktop GUI APIs closer together will allow developers and applications to easily move between these two paradigms. I think this is an incredible benefit of C# and the .NET platform: you develop your UI in a common, easy to learn API model, and that model can be applied to Web (thin-client, connected access) interfaces and Windows (fat client, disconnected access) interfaces with a trivial amount of work. Your application operates the same way for your users, depending on their needs and environments.

Let’s take an example of a sales database. In the office, the sales database is a Web application, accessible from any intranet browser and updated instantly with every piece of customer data. That’s great — as long as you’re in the office. Salespeople, of course, travel all the time. With a Web Forms to Windows Forms port (and some help from ADO.NET, an elegantly complementary data access technology in .NET), your salespeople can use the same application in the same way, sitting at their desks in the office or disconnected on their laptops while flying from New York to L.A. Development porting time is limited, user education is minimal, and the benefits are clear.

Great stuff if you’re a Windows developer and you can get the benefits of Windows Forms. What if you’re a Java developer? Well, you’re out of luck — Swing and JSP are radically different, almost unrelated models. Taking a Java-based Web application and turning it into a Swing app is almost a complete rewrite of the interface.

Here, then, is a project where Sun and the open source community could work well together. The Jakarta project has done exceptionally well with server-based interface toolkits like Struts; Sun has done very well in creating a usuable and consistent desktop GUI API in Swing. These two groups should work together to meet the challenge of Windows Forms and Web Forms. Use Swing and its API as the model, and create a “port” of this existing, consistent API to the Web model (providing a desperately needed alternative to JSP in the process). This sort of porting effort is very well suited to an open source project. In addition, such a project could again show Sun’s customers the benefits of working in a development environment supported by the open source community — namely, that the growth of the environment is not limited to a single vendor’s ideas and needs, but instead is fueled by collaboration of many companies and communities.

If Sun does nothing to address the strengths of Microsoft’s Windows Forms/Web Forms model, that model might wind up being a wedge for Microsoft to break Java’s server-side dominance. Show our hypothetical salesperson that they can get the benefits of a Web application with the interface of a Windows application, and they may never want to go back.