Linux Today: Linux News On Internet Time.

Community: Beyond an Open Source Java

Feb 24, 2004, 16:00 (131 Talkback[s])
(Other stories by Ganesh Prasad)

By Ganesh Prasad
Guest Contributor


The Open Source community would be overjoyed, and the Java user community would be relieved, if Sun were to guarantee the perpetually open nature of Java by Open Source-ing its implementations. But what's in it for Sun?

Quite a bit, actually, because as things stand, Sun is poised to lose big in its upcoming showdown with Microsoft's .NET in the enterprise. A world where Windows reigns supreme is a world where Sun is greatly diminished. Sun needs to do some radical things to improve its chances of survival, and all of them involve Open Source in some form or the other.

The first step is dual licensing, with Sun's Java code simultaneously released under an Open Source and a commercial license. By this, Java will gain fresh appeal and can piggyback on the proliferating Linux OS. Dual licensing, as opposed to mere Open Source-ing, will also allow Sun to profit commercially from its creation. Of course, the only Open Source license radical enough to make dual licensing work is the GPL. The GPL is also the only Open Source license that can keep Microsoft from "polluting" Java.

However, Open Source-ing Java isn't the only thing Sun needs to do to cap and roll back the gains made by its most dangerous enemy. To effectively neutralise Microsoft, Sun needs to make J2EE more affordable, support a more productive development environment, and work to make the web user interface richer.

Sun needs Open Source for every one of these tasks, so it's not a one-way street.

Rephrasing Eric Raymond

Eric Raymond's recent plea to Sun to Let Java Go is a fundamentally sound one. But his challenge is meaningless ("Sun should do this to prove that they are really a friend of Open Source"). C'mon Eric, do Sun's shareholders even care? Should they? Raymond implies that merely Open Source-ing Java will help Sun, but he doesn't spell it out in a way that will gain Sun's interest.

Raymond also makes some incorrect assumptions and factual errors that damage his case. Comparing Red Hat's share price to Sun's is an embarrassing non sequitur, revealing that though he may be a hacker and chronicler extraordinaire, he's no corporate finance type. And anyone actually working in the IT industry today knows that Perl and Python are hardly competitors to Java, so warning Sun about Java's impending loss of market share to these two scripting languages is laughable.

However, Raymond's plea is too important to be dismissed on these grounds, and deserves to be repeated. But only an appeal to self-interest will get Sun to listen.

It is definitely in Sun's own interests to open up Java. This goes far beyond Open Source-ing the Java libraries, as we will see. Making the Java language and platform more affordable and friendly will make them more popular than their rivals (not Perl or Python, but C# and .NET).

But Sun has an indisputable right to exploit its creation for its own commercial gain. In fact, it would be illegal for Sun's management to sell out its shareholders by giving away the company's crown jewels.

Raymond recognises the problem, but poses it as an either-or choice. That implies a zero-sum way of looking at things. But it's not about ubiquity versus control at all. It's about ubiquity with commercial advantage.

As Open Source advocates, we know ways by which Sun can achieve both objectives.

We are not going to ask Sun to do something for Open Source (at least, not directly). We will show Sun how they can help themselves by making Java even more widespread than it is, and by harvesting it commercially. We will also show that if they continue to do nothing, they will pay a heavy price.

If, in the process of helping themselves, Sun proves to be a friend of Open Source, that's a bonus.

The Threat

J2EE (Java 2 Enterprise Edition) is acknowledged as the most robust, scalable and secure framework for building enterprise applications today. It has replaced CORBA as the way to go for large, distributed enterprise apps. Most large organisations (and even a number of smaller ones) have adopted it as their enterprise standard. However, if you put your ear to the ground, you will discover that Microsoft's .NET framework is finding its way even into such organisations as a "tactical solution" for smaller, departmental level projects. It is dangerous for Sun to ignore this trend. In the early nineties, Sun's workstations were far more capable (and far pricier) than the humble PC powered by a lowly Microsoft OS called DOS. Today, Sun has lost the workstation market to an evolved PC, running an evolved Microsoft OS, in spite of its initial advantages in power and openness. The main reasons were price and user-friendliness. Similarly, today, .NET is less mature than J2EE, to be sure, but Sun's complacency can prove to be its nemesis once more.

There are two statements that are often made in the context of J2EE and .NET, and neither is favourable to J2EE: "J2EE is too expensive" and ".NET delivers greater productivity". Microsoft has sufficient numbers of supporters (even in organisations that have committed to J2EE) to ensure that these statements are whispered frequently enough into the ears of decision makers.

At a superficial level, both statements are true, and decision makers generally don't dig much deeper.

High Cost

As long as J2EE is associated with application servers like WebSphere and WebLogic, with price tags of the order of $100,000 per CPU, it will continue to be seen as a high-cost solution. .NET has a much lower cost of acquisition (the costs of getting out of its vendor lock-in are another matter). Decision makers look really hard at acquisition costs, especially when budgets are tight.

That's why so many .NET implementations are okayed, even though they may not conform to an organisation's strategic architecture ("Don't worry, Mr. CIO, .NET can interoperate with J2EE using Web Services"). Hasn't anyone learnt the lesson that when Microsoft begins to dominate a market, interoperability will be the last thing its platform will deliver? It appears not, so J2EE has to address cost, and urgently.

High Complexity

J2EE development, on the face of it, is also complex. An Enterprise JavaBean (EJB), which is a component containing business logic, typically requires 5 to 7 supporting files to deploy. Most development tools (IDEs) generate these automatically, but each in its own proprietary way. If Sun doubts that this complexity is a problem, they should listen in on some of the Java developer sites to hear what the developer community has to say about EJBs.

Microsoft, in contrast, has historically been known for the ease of use of its development tools. They make things simple (though sometimes simplistic), and developers love that. The vast installed base of Visual Basic applications (in spite of VB's clear deficiencies as a development language) is testimony to that. Visual Studio.NET continues the tradition with its promise of making .NET development a drag-and-drop experience. (If anyone is skeptical of the claim, they should try talking to a .NET developer.) Java development tools are catching up in developer-friendliness, but as we will argue later, they're moving in the wrong direction.

Anaemic User Interface

There is another difference between J2EE and .NET, -- again, one that favours .NET.

J2EE is a purely server-side technology. .NET boasts components on both the client and the server. It is a far richer framework, for the simple reason that it can do all that the J2EE model does, and more.

Nobody owns the server, and so it's neutral territory in which both Java and .NET can play, but the browser is really Microsoft territory, in spite of the W3C's best efforts, because over 90% of the browser market is owned by Internet Explorer. Microsoft is free to leverage this market share by exploiting IE-specific features in .NET. One can call this unfair and non-standard, of course, but then, how many divisions has the W3C?

Already, there are ISVs that are delivering .NET-based web applications, and they have a far friendlier and richer interface than traditional thin-client applications. Decision makers like pretty interfaces, never mind what goes on behind them.

J2EE has lost the beauty contest, and the heavyweight title isn't far behind.

.NET's Triple Whammy

Going by Sun's business-as-usual attitude, they are in grave danger of being blindsided by the .NET revolution. That is the single biggest threat that Sun faces in the medium term. Competition from IBM is a walk in the park by comparison.

The Opportunity

Sun has the opportunity to wrest the initiative back from Microsoft by positioning J2EE as a low-cost, high-productivity solution with rich user interface components.

Interestingly, all three of these elements involve Open Source. They also involve courage.

Low-Cost J2EE

J2EE is a set of specifications, not any particular implementation. There can be pricey implementations, and there can be affordable ones. The trouble is, the pricey ones have the mindshare (IBM WebSphere, BEA WebLogic). There are far cheaper implementations, but who has heard of them? Orion or Pramati, anyone? And of course, there are Open Source implementations as well (e.g., JBoss), but JBoss (as of February 2004) is not yet a certified J2EE server, and its fledgeling commercial support organisation (the JBoss Group, now called JBoss Inc.) often lacks the clout to open many corporate doors.

It is in Sun's own interests to make prospective J2EE users aware of cheaper options and to make them attractive.

It would also greatly help if Sun stopped muddying the waters and killed its own lame offering called SunONE (earlier called iPlanet). Nobody will buy SunONE. Nobody will take it for free. Even if Sun offers a wad of money with it, people will take the money but ignore the product.

Loud message to Sun: SunONE will not fly. It is distracting and a waste of time and money. Kill it. Help JBoss attain J2EE certification. Make JBoss the reference implementation of J2EE. Arrive at a commercial understanding with JBoss Inc. to provide Sun's support umbrella for the product, at a reasonable price. And trumpet this from the rooftops. No corporate decision-maker must be left unaware of the fact that a fully certified, Open Source application server is available with full support from Sun, all at a much lower cost than any competitor.

That, taken together with J2EE's openness and vendor-independence, is essential to halt the advance of .NET.

High-productivity J2EE

Snap Quiz: What's the answer to Microsoft's Visual Studio.NET?

  1. WebLogic Workshop
  2. WebSphere Studio Application Developer (WSAD)
  3. Borland JBuilder
  4. IntelliJ IDEA
  5. IBM's Eclipse
  6. Sun's NetBeans
  7. None of the above

"None of the above" is right. The IDE (Integrated Development Environment) is the wrong thing to emphasise in the year 2004.

Sun is probably aware of Open Source tools called Ant, XDoclet and JUnit that are being used by Java developers around the world, and that have been developed independently of Sun and the JCP (Java Community Process). This illustrates two facts:

  1. Sun has lost control of the Java development space. It does not provide leadership anymore or set the agenda. Open Source does.
  2. There is a wellspring of innovation in Open Source that beats the productivity of Microsoft's friendly tools.

Apache Ant is the backbone of the development process in any modern Java development shop. Based on an open XML-based script, it controls the build and deployment process. It can talk to version-control systems like CVS. It can generate the 5 to 7 extra files that a business component needs, by leveraging another Open Source tool called XDoclet. It can compile code using any Java compiler. It can coordinate unit testing at different tiers by running tests written to Open Source testing frameworks such as JUnit and its derivatives, HttpUnit and JUnitEE. It can package and deploy J2EE applications to any application server. Best of all, its script-based model means greater reuse, a faster learning curve for fresh developers and a higher average level of quality in a development team.

Most graphical IDEs now have support for Ant. Good development practice nowadays is to ignore the IDE's own code generation, compilation and packaging features, and to use Ant's equivalents instead.

The ultimate endorsement of Ant is that Microsoft now has an Ant lookalike called MSBuild as the build platform for Visual Studio.NET. To those who weren't paying attention, this is an example of Microsoft chasing Open Source's tail-lights (Jim Allchin, I hope you're reading this).

This is the reality of a modern J2EE development shop. Is Sun aware of this reality? Not if their public statements are anything to go by. It's all about NetBeans and Eclipse, isn't it? Not a whisper about Ant, except for this solitary page, loaned out to an Ant developer for a trivia-style quiz. Why does Sun pretend these tools don't exist? Not Invented Here?

Sun needs to trumpet the use of the Ant-XDoclet-JUnit triad of tools as Java Best Practice. It needs to position its own (Open Source) NetBeans and rival IBM's Eclipse as mere IDEs that support the Ant way of building applications. It needs to inform decision makers that end-to-end development productivity comes from scriptability and the quality control and repeatability that it delivers, not so much from fancy graphical interfaces.

That's the only way to combat the perception of .NET's productivity edge. It's ironical that Ant's productivity advantages are accruing to .NET at a time when its own native platform is being passed over for delivering low productivity!

Java-based Rich User Interfaces

Sun needs to address the problem of J2EE's anaemic user interface very quickly. In the year 2004, it's no longer acceptable to thread a client-side needle by operating levers from the safety of a web server. It's clumsy, inefficient and a lousy user experience. But that's what every Java-based web framework does, including Sun's new JavaServer Faces (JSF). Just because Microsoft once beat back Sun by poisoning the Java Virtual Machine on Internet Explorer doesn't mean Sun should keep licking its wounds in its server-side cave forever.

Sun and the Open Source community together need to take back the client (No, no, not Java applets!) We need server-side Java libraries that will generate dynamic browser-based components conforming to W3C standards. These will run on the client side and provide high interactivity, referring back to the server only when necessary. This is the way Microsoft is attacking the web application market today. Microsoft's rich XML-based but IE-specific user interface language (XAML) is their client-side weapon. Doesn't the non-Microsoft world have anything similar? Well, if Microsoft releases an "innovation", it's a safe bet that someone else thought of it first. Sure enough, the inspiration for XAML can be seen to be an Open Source rich client framework from the Mozilla Foundation, called XUL.

XUL, at the most superficial level, provides richer widgets than HTML, such as scrollable tables, collapsible trees and tab folders. It is a brilliantly-architected rich client that happens to be thin as well, because it's based on XML. Microsoft, as usual, has seen the light early, and has "innovated" XAML based on XUL's pioneering features, but Sun and the rest of the industry are still caught in a user-interface time warp.

XUL only works with the Mozilla browser, but that's not as great a disadvantage as it sounds. Even the Linux desktop is no longer an unthinkable concept today. Organisations will certainly install a free browser if they have to, to gain the advantages of a rich user interface without paying the Microsoft tax. But they need the solution to have credibility.

Sun can lend credibility to Mozilla and XUL.

Sun should work with the Mozilla Foundation to get XUL endorsed as a W3C standard. Rich web applications, exploiting XUL and other W3C-endorsed technologies such as SVG (Scalable Vector Graphics) and SMIL (Synchronised Multimedia Integration Language), should feature in the next version of the Java Desktop System (By the way, Sun, we forgive you for not calling it the Linux Desktop System, which it really is).

This is the only way to win the beauty contest.

Getting the Knives Out for Microsoft

(The following section contains graphic images of gore and violence, and is not suitable for young children, squeamish adults or Microsoft sympathisers)

Microsoft has never been more vulnerable. Look at their financial statements, especially their latest 10-Q filing with the SEC.

Note 12 (Segment Information) of the report is particularly entertaining. Microsoft breaks up its profits and losses by division on this page, comparing 3-month and 6-month periods this year with the same period last year. One can see that each division has posted either a bigger profit or a smaller loss compared to the previous year, which seems extremely healthy. But curiously, there is an innocuous item at the end called "Reconciling Amounts", which is such a whopping loss that the net effect of it is to reduce Microsoft's profit compared to last year, no matter which period you take. It's not a one-time charge, either. They posted a loss under "Reconciling Amounts" last year as well, but that loss wasn't as large as this year's. The net profit figures for the last 3 months show a sharper drop (compared to the same period last year) than those for the last 6 months, indicating that the fall in profits is accelerating.

It's very clear when you tie it in with the fact that large users like the Newham City Council and the Israeli and Thai governments have been wrangling large price cuts from Microsoft in recent times. The days of 80% profit margins on revenue for Windows Client and MS-Office are gone, and that's showing in Microsoft's financial returns (albeit disguised as "Reconciling Amounts"). (I guess it means they're still trying to reconcile themselves to the loss of their monopoly and ability to set prices.)

Yes folks, Microsoft is not just bleeding, it's haemorrhaging. Sure, it's not red ink yet, but a sharp and accelerating leakage of black ink should have the same effect on their share price and investor confidence. However, a weird conspiracy of silence among Wall Street analysts prevents them from telling us that their beloved emperor's new clothes are just blood-soaked bandages. (Oh well, just give their firms time to gently offload their own holdings of MSFT stock, and then they'll let us know.)

Like the evil T-1000 in Terminator 2, Microsoft is reeling, hit by a rapid sequence of Open Source gunshots. But if we run out of ammo now, they'll be back from the brink, as dangerous as ever, once .NET claws back their market for them.

Ray Kroc of MacDonald's once famously said, "If you see a competitor drowning, you stick a hose down his throat." A graphically violent description. Worthy of Microsoft, in fact. The company that knifed the baby (Apple's QuickTime), cut off Netscape's air supply and threatened (emptily) to cut Linux off at the knees deserves nothing gentler than to have a hose stuck down their throat when they're drowning.

And it can be done. Sun and Open Source together can do it. If we keep up the pressure, Microsoft will no longer have cash cows to fund their forays into other markets, and will have to close down (or should we say "put a bullet into") their loss-making divisions like MSN, XBox and SmartPhone. The monopolist can be disembowelled.

(End of section filled with violent imagery)

The Way Forward

As a first step, Sun should Open Source all their Java implementations, but under the GPL, and not under a more permissive license, because only the GPL is viral enough to drive commercial users towards any alternate commercial license Sun may choose to offer.

This is, of course, a dual-licensing strategy, and Sun reaps rewards in two ways.

By Open Source-ing Java, Sun lays to rest user apprehensions about Java's future. Users will rest secure in the knowledge that Sun will not start charging them for Java tomorrow in a bait-and-switch attack. They will also be assured that should something untoward happen to Sun (a hostile takeover or worse), Java will be immune to the consequences. That will increase the adoption of Java. It will also ensure a place for Java on the fastest-growing channel to the user: the Linux installation CD. Sun should ensure that they don't miss this boat. After all, IE trounced Netscape by piggybacking on Windows installation CDs. By slowing the adoption of .NET, Sun does itself an obvious favour.

Simultaneously offering a commercial license is the other way Sun can profit. Sun can derive a revenue stream from those customers and business partners who want to customise it for their own platforms and extend it in proprietary ways for niche markets.

Dual licensing. Ubiquity and commercial advantage. MySQL AB does it. JBoss Inc. does it (though founder Marc Fleury is still kicking himself for releasing JBoss under the LGPL and not the stricter GPL).

Sun's biggest fear regarding Java has been Microsoft. Microsoft has shown in the past that it wants nothing better than to "pollute" Java and fragment the market, but Microsoft also regards the GPL as a poison pill. A GPL-ed Java would be Microsoft's biggest nightmare. Any extensions that Microsoft makes will have to be made available with source code and under the GPL, in turn. That makes it far easier to backport Microsoft's extensions to the main trunk, if required, neutralising their power to fork the codebase.

The strategy for Sun should not be to Open Source and then abandon Java, but rather to remain as Java's custodian and primary maintainer. Who else has the credibility to do this? Even an arms-length organisation along the lines of the Mozilla Foundation or the Eclipse Foundation will be sufficient to keep the Java standard from being polluted.

Sun continues to paint Microsoft as a bogeyman in arguing against Open Source-ing Java, but such arguments are bogus. Dual licensing under the GPL and a commercial license will effectively de-fang Microsoft. Don't expect us to believe Sun didn't think of that!

As we said before, the story does not end with Sun Open Source-ing its Java implementations. Making J2EE more affordable and easier for developers, and providing richer, friendlier user interfaces are the other essential ingredients for an effective Java strategy.

Sun's hardware revenues, fees for professional services, and its revenue from Java education and certification should not be adversely affected by any of these moves. On the contrary, Sun may see a spurt in revenue from these activities as a result of the increased popularity of Java.


Microsoft is a powerful competitor to Sun that is now showing signs of vulnerability, but it is also busy building its strength in some crucial areas that will render it extremely dangerous to both Sun and the Open Source movement in the future. Everyone with an interest in containing this predatory monopolist must act now to prevent it from regaining ground. Linux, Apache, OpenOffice and Open Source Java tools have all played a part in making Microsoft stumble and fall to its knees. Now it's up to Sun to behead the monster.

About the Author

Ganesh Prasad is an IT industry veteran with 17 years of software development experience. He holds an M.Tech. degree in Computer Science, an MBA and a Graduate Diploma in Applied Finance and Investment. He is a Sun Certified Java Programmer and Sun Certified Web Component Developer. He currently works as a Web Architect with a large Australian bank. The views expressed in this article are his own and do not represent the views of his employer.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found at http://www.gnu.org/copyleft/fdl.html.

Related Stories: