By Ganesh Prasad
Guest Contributor
Synopsis:
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?
- WebLogic Workshop
- WebSphere Studio Application Developer (WSAD)
- Borland JBuilder
- IntelliJ IDEA
- IBM’s Eclipse
- Sun’s NetBeans
- 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:
- Sun has lost control of the Java development space. It does not
provide leadership anymore or set the agenda. Open Source
does. - 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.
Conclusion
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.