eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Pressure has been building on Sun Microsystems for months, if not years, to address open-sourcing Java. In an open letter to Suns Rob Gingell, IBMs Rod Smith offered to help Sun move toward that goal. Now, Sun is hosting a debate on the issue at its annual JavaOne developer conference this week in San Francisco.
In an exclusive conversation with eWEEK Contributing Editor Steve Gillmor, Sun president and chief operating officer Jonathan Schwartz discusses Suns nuanced position on open source and the Java community.
When you and I have talked about this in the past, Ive expressed a position somewhat similar to JBoss CEO Marc Fleurys: If its not broken, dont fix it.
I agree. I probably tend more toward that side of the debate. But on the other hand, we want to make sure that we get the issues out on the table. Theres a lot of FUD [fear, uncertainty and doubt] about what exactly is open source. Does it in fact cure cancer?
Theres been some evolution in terms of open-source projects in the Java space over the past couple of years, including BEAs moves in recent weeks around the Apache Beehive project and their announced intention to open-source some of the Alchemy framework. The fact that theyve aligned with Apache on Beehive seems to suggest that theyre going to get some traction.
What is critical for us is maintaining an active and productive dialogue with developers. And as you point out, developers run the gamut from those that believe that if its not open source, theyre not going to touch it—or maybe even farther to the left than that, if its not GPL [GNU General Public License] they wont touch it—to those who are less concerned with whether or not the source code is available and more concerned with whether the product actually runs quickly and with performance and is guaranteed to be maintained, stabilized and life-cycled by a vendor.
In the developer world, you dont get to pick your friends, because if you do, then you end up alienating a very important population that may in fact be creating content that you want to run on your platform.
In having the debate, as well as introducing what has turned out to be a bit of a lightning rod on the Solaris side, we want to say, “Were open to the discussion.” Moreover, now, as opposed to historically, its not a matter of expressing an opinion, its a matter of putting plans in place and making sure we get all of the cars on the rails to go get to the destination.
What exactly is your position on the Solaris open-source model?
It gets back to the spectrum of developers. About a week ago in Chicago, I was with a collection of 30 CIOs from the largest companies in North America—folks with collectively billions of dollars of purchasing power—and I was discussing with them the motivation to open-source Solaris and trying to solicit their feedback.
And the No. 1 comment they made to me was, “We dont care if Solaris is open-sourced. In fact, from our vantage point, its a waste of time because we dont want to have our folks mucking in your source code.”
I looked at them and said, “Respectfully, you have to understand that youre not necessarily the target demographic for the plans to open-source Solaris. The target demographic is a developer who is frustrated that he cant get access to the source code, or moreover, a customer thats frustrated with Red Hats support policies and pricing.”
That isnt necessarily a decision a CIO is going to make, thats a decision a developer is going to make. Inside of Sun, we recognize that we talk to multiple constituencies with vastly different preferences, purchasing cycles and purchasing power, and weve got to make sure that were addressing all of them.
Next page: Engaging a community through open source.
Engaging Community
Youre trying to come up with a unifying solution across this rather confusing array of alternatives …
But it may not be unified, Steve. We use the GPL for OpenOffice, but GPL may not be the right answer for Java. The Apache license may be more akin to what we want for Java.
All I want to do is suggest that, as we move forward in our business, were cognizant that there is a very substantial community of developers who prefer having access to the source code. We may in fact not simply limit ourselves to Solaris and Java; we may look more broadly at what else we can open-source.
The BEA open-source strategy isnt really about opening the source code; its more about presenting the opportunity for developers to feel that theres a coherent investment on BEAs part to make sure that the technology gets into the ecosystem, so that developers can count on and therefore invest in it themselves.
Fundamentally, open source is a means of engaging a community. And the motivations of the community youre engaging are going to vary. From day one, with Java we have engaged the community through something called the Java Community Process [JCP].
And as you rightly point out, for the dominant majority of Java developers, the JCP has been a wonderful aligning force that has enabled us to move at a much more rapid pace than even Microsoft. Witness the introduction of Web services into the basic platform, the progress on mobile handsets, the progress on set top boxes.
The Java community is arguably one of the most effective open communities the network has ever seen, and yet there is a portion of the population that has a different perspective on what theyd like to see happen. And our only point, and the point of hosting a debate, is that we are interested in the feedback. We want to make sure that we continue to evolve the JCP as we have from day one. Were already in the second evolution of the JCP.
The motivations to examine our alternatives in the Java world are different than the motivations on the Solaris side. On the Java side, its all about making sure we continue to broaden and focus the community model and the engagement model to as broad a developer base as possible.
On the Solaris side, its somewhat different: Its born of an increasing frustration among Red Hat customers who are upset at the realization that Red Hat has become the exclusive supplier of Linux for the enterprise.
I was just with a series of Wall Street customers, all of whom were pretty crisp in their complaints: that they cant move code from Red Hat Linux to anything else. That their support process is such that they send an e-mail to Red Hat with an issue or a bug, and the next thing they see is a Red Hat employee posting under an assumed name in a community group, exclusively quoting the support problem and asking for help.
The customer is asking, “Why am I paying Red Hat if all the Red Hat employee is going to do is post to the newsgroup? I could post to the newsgroup.”
Next page: Open source versus open standards.
Open Source v
. Open Standards”>
That is actually an incremental market opportunity of a much broader magnitude. If you look back on the past few years, weve really been beaten with this brush that says were proprietary, while Red Hat has ridden under the banner of purity because they have been open source.
As we watch the open-source community mature, a lot of us have realized that open source doesnt equal open standards.
And that provides opportunities for companies that can not only now play in the open-source community—given that theyve got the intellectual property rights to do so—but also engage a community in the evolution of products in ways that we historically havent done.
Is there any impact in the open-source community of developers coming to the Solaris space?
Totally. Developers should realize that if Red Hat is going to exclusively monetize all of the code base, thats not necessarily a worthwhile pursuit, whereas Solaris presents them with a different set of alternatives or capabilities.
For example, a lot of folks are working on managing load on the Red Hat kernel—our scalability is fabulous, 99 percent up into the 100-way systems—and if they can just skip that generation of evolution and go focus on quality of service or service-level policy management. Theres a whole bunch of other things that can be done, that for some portion of the Solaris community was going to be off-limits because they couldnt get access to the code. This will resolve that.
Moving back to Java, you say theres really no reason to open-source Java, even though you do want to establish a dialogue …
It wasnt to say that theres no reason to go do it, its more to question what about the current model isnt in fact already accomplishing it. It was to agree with your point, and also Marc Fleurys point, that if aint broke, dont fix it.
Whats not broke right now is that the Java community is one of the broadest and most inclusive communities out there. If you compare for a moment the evolution of Java with the evolution of Linux, its kind of interesting to see that there are literally thousands of companies that are now making their livelihood off of Java.
Go to Java.com and youll see a massive array of everybody from the NASCAR Speedway to weather and traffic to oximetry monitoring on human beings—theres a huge array of developers who can rely on both innovation and compatibility to run their business.
Whereas in the Linux world, its really up to Linus [Torvalds] to make the call on what fundamentally happens. And its not to say that thats a good or bad thing, its just a fundamentally different model.
Next page: “Quite the antithesis” of proprietary.
Antithesis of Proprietary
But [Sun chairman and CEO] Scott McNealy, in his announcement of your appointment as president and COO, lauded your ability to harness disruptive technologies to gain a market advantage. Whats the disruptive nature of this open-source debate? What are you going to do thats more disruptive than what youve already done? Isnt doing nothing more disruptive than doing something here?
It depends on which community youre talking to. If its the Solaris community …
I get the Solaris community idea. Im talking about the Java space.
The very fact that were engaging in the dialogue has been pretty disruptive, and its clearly absorbed a lot of time and attention thats driven awareness of the Java platform, and better yet, thats driven awareness of the open community model that we already use.
Which has been painted by some companies, mainly IBM specifically, as somehow proprietary and controlled by Sun. Its quite the antithesis. To Mark Fleurys comments, this is a great community that works. It drives compatibility. Were basically the Apache model being driven by a commercial enterprise.
Mark Fleury gives as an example that Sun and JBoss employed some creative thinking to solve some of the licensing issues around J2EEto allow them to join the party. Are you going to see something along those lines around open source and Java?
What youve seen, and are going to continue to see, is an awareness of a broad diversity of developers and a willingness on the part of Sun to evolve the licensing to encompass as broad a spectrum of those developers as possible—with one very significant proviso: We are unwilling to sacrifice compatibility because we dont want what Red Hat is doing to Linux.
There is one supplier of Linux in North America, thats called Red Hat. In the Java world, there are a thousand suppliers of Java, and that is fundamentally creating huge market opportunities for a broad community of companies rather than just one.
A few months ago, [J2 lead architect] Mark Hapner said you were taking this issue private, similar to what you did with JBoss. What youre doing now is not private. Whats the goal of hosting a debate at JavaOne?
To make sure that were as open as possible with everyone about the diversity of perspectives. Its to educate people. Again, I think weve been painted somehow by IBM as controlling the process, and fundamentally one in which they are highly engaged as an executive member. Rather than worry about a bunch of postings on Slashdot that really dont have a lot of factual basis, were just going to make sure that everyone understands that theres a diversity of perspectives here.
And if that means giving airtime to the folks who really are educated on it, then thats all goodness. Were not really interested in getting into a smoke-filled room and having a private dialogue with IBM; thats not how an open community functions. Let me make sure that you understand: Thats different than having a conversation through the media; an open letter is more like that.
This seems to be a response to the thread that was started in the media rather than trying to work through some licensing issues behind the scenes. If this is a political strategy on IBMs part, isnt it unlikely that youre going to get very far either in front of the cameras or behind the scenes in resolving the two positions?
But on the other hand, I think it is incumbent on all parties involved to be as clear and open about their perspectives as possible. Clearly IBM is upset about something, and we want to make sure that we give an audience to those issues so we can walk through them. The basic complaints that Ive heard from IBM are that the JCP is slow, that the JCP is controlled by Sun.
And those are wonderful myths to pop, as soon as you get the data on the table and you prove that youve made more progress in the Java community than arguably any other industry out there, that youve created BEA and IBM and Oracle and SAP and all these companies benefiting from Java, and moreover are managing its evolution.
Were very interested in having an open and frank discussion, but we also want to see a factual discussion with the diversity of perspectives that were trying to serve. The JCP doesnt exist to serve IBMs agenda; the JCP exists to serve the needs of the Java community. Theres no “some companies are more equal than others;” its just a community.
Next page: The leveling force of standards.
Force of Standards
BEA has described its Beehive open-source strategy as not being orthogonal to the JCP, but rather an additional way to get some more speed into the system while at the same time respecting the JCP.
As you can see with JBoss, open source and the JCP are not orthogonal. The open-source process and the process of building a product in the community can be extremely fast or can be extremely slow.
It all depends on who in the community is actually doing the evolution. Were very satisfied with the pace at which the market is evolving. The problem for some of the vendors is the open-source movement is actually causing them competition.
JBoss and Websphere and the J2EE reference implementation are three products that are built in a very different way. I see a pretty significant uptake of the J2EE reference implementation of JBoss, and I see [IBM] having an increasingly difficult time raising [Webspheres] price, and moreover theyre having a difficult time delivering new technology that the JCP has not ratified as a part of the standard.
For more collaboration coverage, check out Steve Gillmors Blogosphere.
Its not so much that theyre having a problem evolving their own technology as that customers are pushing back on them saying, “Look, I really rely on having a standard so I can substitute another product for yours if I am dissatisfied with your price, licensing or support model.”
Thats the leveling force of standards. The standards level the playing field—which if you are a market laggard are a wonderful way of catching up—and if youre the market leader are an unfortunate threat. Its called competition.
Were actually a big fan of competition and have been for a very long time. And if that competition comes from the open-source community or from a vendor that is leading the pack with having the best implementation in the marketplace, so be it.
Are you aware of [BEA chief architect ] Adam Bosworths Alchemy initiative?
No.
Its a caching mechanism that will be open-sourced, turned into a standard that would allow a rich client …
Careful with what you just said. You said open source and thus turned into a standard. Theres a difference between open source and open standards. Open standards are those that are agreed to by a broad segment of the community. Open source is simply a licensing convention.
If you take a look at BEAs strategy for the Apache Beehive project, it is open-sourcing neither the Weblogic Workshop IDE nor the servers. What its open-sourcing is the framework, essentially the runtime. Theres an analogy there with what IBM is doing with the Workplace environment; theyre trying to get the Eclipse runtime on the desktop. Youve already got a runtime on the desktop. Its called the Java Virtual Machine.
Exactly.
Next page: Leveraging the JVM.
Leveraging the JVM
There are some very interesting technologies that not only live in the Java space but also have some application in terms of interoperability across the .Net platform. And it would seem to be of use and some value in regards to many things, including the RSS platform you and I have been discussing, establishing a thick, intelligent client that goes beyond Microsofts lock-in and control of the browser. Are you going to be supportive of this kind of an idea, or is there something about BEAs strategy that you find not particularly conducive to a loosely coupled alliance?
Were very open to partnering with BEA. We have a few common competitors, and weve always been pretty impressed with their innovation and capacity to execute. What you point out, though, is that one of the single biggest challenges in the software marketplace has been and will forever be distribution—how do you get your code out into half a billion desktops? Unless you have ubiquity, youre not going to get people to rely upon your service.
One way around that is to basically take the Google path, which is to say, “Im going to provide distribution by being really good at what I do and relying on no runtime other than that provided by Microsoft.” Now, theres a danger to that predilection: Microsoft could elect to disable your service at any point [with] a simple upgrade to their browser. And thus, Google is worried about Microsofts ability to compete with them.
So, what we do with Java distribution and how we continue to evolve that platform are of acute interest to me and my team, because we already have the distribution, and now, as you rightly point out, weve got to figure out a way of leveraging that distribution in some way other than simply providing a platform for downloads off of Java.com.
But again, what Im suggesting here is that theres an opportunity to …
Partner with BEA …
You dont have to partner with BEA as much as to encourage this loosely coupled framework that would allow a much more high-fidelity and potentially transaction-oriented technology, which by the way also works just as well if not better on [Mozilla] Firefox.
We agree with you.
Yet youre going to have a debate with IBM where youre essentially trying to clear the air, but little else, in terms of being swayed toward any particular practical alternative to the polarized positions that exist right now, when heres an opportunity to be working in a creative way across a number of the vendor constituencies in regards to your desktop strategy.
It seems youre spending some cycles that may or may not be as productive as something that could just happen right away with some support, hooking up Adam Bosworth and Tim Bray, for example, and getting an agreement to support open standards for this kind of caching mechanism.
We may. Just bear in mind, though, that to the extent it involves the evolution of APIs, its going to involve the Java Community Process. Because Im not interested in having support for one companys technologies—whether thats Suns or someone elses—that disrupts the fundamental compatibility and the ability for partners to compete on a level playing field.
Connecting the RSS and the Java world is an interesting discussion, and its certainly something weve spent a lot of time thinking about. Coupled with this notion of massive distribution, theres clearly an opportunity there. Its highly orthogonal to the broader issues surrounding the licensing models for Java and Solaris.
BEA is using open-sourcing of the framework as the vehicle for getting this kind of technology into the ecosystem.
Its a tough row to hoe, just open-sourcing it, assuming you get distribution. Lets face it, the vast majority, the preponderance of clients out there are Windows, and I dont think theres a single company that you can name thats been able to download, especially middleware, onto that client and expect to achieve any level of ubiquity.
I agree that its an interesting technology, but fundamentally what we have to do is figure out whats the right evolution of APIs, and what the business model is around how we can get that.
You mentioned Google having some dependencies on Internet Explorer, and I mentioned that IBM has some issues with its Workplace strategy. How does IBM persuade people to get the Eclipse runtime and put it on their desktops when the JVM is already there?
Exactly.
I guess youre telling me its not in Suns interest to support either of those other models unless it somehow fosters competition. I just dont understand where the opportunity is for partners like BEA to synchronize with you.
Next page: Playing Office politics.
Office Politics
Theres a separation of clients and servers, and a different distribution model for each. We happen to be in the business of delivering servers, so we can, through the dissemination of technology in Solaris, achieve some ubiquity at least in 64-bit systems. The distribution of a client that somehow links up with that server is a wholly different set of issues.
Frankly, I looked at IBM Workplace and thought, this just looks like Domino all over again; theyre trying to deliver SmartSuite through a browser. There are too many things that have failed doing that; I wonder why theyre spending the time?
The most ubiquitous office productivity suite out there is called Microsoft Office, and No. 2 is called OpenOffice and StarOffice. Intersecting Office with Java in a Web services model, whether its for caching or propagation of content, is something weve looked at.
But again, thats got to be coupled with having an ability not only to deliver a runtime in this instance on a client but a whole client, which is why weve evolved to deliver the Java Desktop. Hoping to achieve ubiquity by providing your technology on the Web for free download is a tough row to hoe.
Where does BEA make their money? Its not specific to BEA, its a tough model to do unless you have an overwhelming and compelling value proposition. Most Microsoft Windows users are very happy with Microsoft Office. Frankly, theyre very happy with Microsoft Windows.
Rather than trying to figure out ways of disintermediating Microsoft, they should probably spend their time focusing on delivering value that Microsoft isnt delivering—and Google and eBay, or Amazon for that matter, have done a good job there—rather than figuring out ways to disseminate middleware. Thats a pretty steep hill to climb.
Except you just said it. Alchemy will add persistence, create an offline capability for a browser type of environment.
Sure, and theres about 60 other technologies available that can do the same thing.
Name one.
The .Net framework.
Youre suggesting that the .Net framework is going to be successful in competing for offline capabilities against the entire open-standards community?
I think it will be very successful in competing for the Windows community. But thats different than suggesting its going to be successful in competing for the client community, because there are an awful lot of clients that go beyond Microsoft Windows. People have generated persistence mechanisms, whether its for the .Net framework or for Java, and there are plenty around.
Next page: Making a community successful.
Successful Community
Look, Im not suggesting its a good idea or a bad idea, I just think its a tough row to hoe. A client without a server is a lot more useful than a server without a client. Think of the number of clients out there that are useful on a standalone basis. There are lots to be named. Think of the number of servers that are useful without a client—not so many.
You mentioned Workplace is just Domino all over again. Lotus kept crashing up against this barrier about persistence on the client. When they harnessed Java, they always had the problem of downloading the applets every time.
No, no, no. It all depends on how you look at it. The problem that Lotus had in leveraging Java was that their apps werent very good.
But its stupid to download a Java applet every time you want to run something on your client. Theres no agreed-upon persistence mechanism available. This is an avenue toward getting that. Why wouldnt that be a good idea?
Its a very good idea. But the issue for Sun isnt whether or not BEAs got a good idea. Its whether or not we can drive the community of developers, the Java Community Process, to agree on the same good idea—because thats what the evolution of a standard is called, other than innovation in a specific product.
BEA has done all kinds of magical stuff thats done a very nice job, but weve got to be concerned not simply with making BEA successful, weve got to be concerned with making a community successful.
What you just outlined is exactly the tension that we find in the marketplace. You have a developer, whether its SAP or BEA or IBM, that comes up to us and says, “Weve done something really interesting. You need to make this a standard and distribute it.” And theyre all very frustrated at our intransigence in saying, “No, its got to be compatible across the community.” And thats where they end up saying the JCP slows things down.
It doesnt slow things down; it hastens the evolution of standards, which in the case of those that are seeking to bypass those standards in pursuit of delivering their specific product, is frustrating. But customers really enjoy having a standard because it enables competition.
Check out eWEEK.coms Developer & Web Services Center at http://developer.eweek.com for the latest news, reviews and analysis in programming environments and developer tools.
Be sure to add our eWEEK.com developer and Web services news feed to your RSS newsreader or My Yahoo page