Q&A: Raymond Expounds on Open Letter to Sun, McNealy

By Darryl K. Taft  |  Posted 2004-03-08

Q&A: Raymond Expounds on Open Letter to Sun, McNealy

Eric S. Raymond, an open-source advocate and author of the open-source classic "The Cathedral and the Bazaar," last month called on Sun Microsystems Inc. to open-source Java. In an open letter to Sun Chairman and CEO Scott McNealy, Raymond said Sun should "Let Java Go." Recently, Raymond sat down with eWEEK Senior Writer Darryl K. Taft at the Wharton Technology Conference, put on by the University of Pennsylvanias Wharton School, in Philadelphia. Taft and Raymond reconnected last week following the release of the latest "Halloween" memo regarding Microsoft Corp.s alleged, indirect involvement in The SCO Groups lawsuits.

The most recently unearthed "Halloween" memo that you posted to the Web that has to do with Microsoft allegedly, indirectly funding SCOs Linux lawsuits has been verified as authentic. Do you still stand by your interpretation of it, despite denials by SCO, Microsoft and Baystar Capital of the gist of the contents?

Yes. I believe the Microsoft and SCO spokespeople are lying because the behavior clearly described in the memo is illegal on several different levels, ranging from antitrust violations through stock fraud to barratry.

Well, lets get to the Sun thing. Why did you write that open letter to Sun and McNealy in the first place?

Because Scott McNealy went to an analysts meeting, and he said in front of a bunch of analysts, "The open-source model is our friend." Thats fine. He has every right to say that. But I, as a member of the open-source community, also have a right to say, "Look, if youre going to say the open-source model is your friend, then friendship carries certain obligations with it." And if you dont meet those obligations, were going to call you on it. Now, you make the businesses decisions you need to make. Were not here to dictate your strategy, but if you claim a relationship, youre going to get called on that relationship.

Next page: Suns ill-considered response.

Suns response

So whats been the response? I know Simon Phipps of Sun weighed in …

Heh! Right. The response I got was, first, Simon Phipps came out with some remarks that were perhaps not as well-considered as they should have been. He claims he was misquoted in a distorting way by a reporter, and maybe thats true …

Well, if its the incident I think youre referring to, I am that reporter and I can assure you he was not misquoted. We have a transcript of his keynote and he said everything I reported, just the way I reported it.

Editors note: Simon Phipps contacted eWEEK after this interview appeared and said the misquote was not the responsibility of Darryl Taft nor of eWEEK and was instead attributable to another reporter and publication.

Ah, well, he came out with his remarks; I came back and took his head off in my second letter. But the next thing that happened after that is I was contacted by a high muck-a-muck at Sun who basically said, "Lets talk." And weve had a couple of phone conversations and he has made it clear that he is speaking to me with the concurrence of the people he reports to, and we are having constructive discussions about what Suns going to do next.

Really? In the open-source world?


Whats your take on what theyve done to date?

I think theyve been—as I said in my original letter—theyve been inconsistent. Theyve done things that were very good, like supporting OpenOffice. And theyve done things that, from where I sit, look just dumb, like not open-sourcing Java.

Next page: Details on the dumbness of not open-sourcing Java.

Not open

-sourcing was dumb"> And let me unpack that a little. I want to explain why I think not open-sourcing Java is dumb. Its not because of idealism. Im not here to talk about idealism. I think not open-sourcing Java was dumb because back in 1995 and 1996 when they were putting out the idea of the whole write-once, run-anywhere thing, they put out a design that I think was a very strong design. I was actually involved in the technical review of the first round of the Java documentation. I really like the language. I still like the language. Its one of the better and more credible language designs weve seen in the last 15 years. But, speaking as a developer, I dont want to be a peon on Suns plantation.

So there came a point where they had to make a choice between ubiquity and control, and when it became clear that they were going to make the choice for control, my reaction and the reaction of a lot of developers out there was, "Im out of here."

Right. Michael Tiemann, chief technology officer of Red Hat Inc., calls it the Java apartheid.

Yeah. And thats why I think not open-sourcing Java was dumb, because that really hurt Javas growth prospects. And it may actually have crippled it. It may actually be too late to resurrect Suns original dream. Too much water may have gone under the bridge.

Even if they open-source?

Well, now we have competition from languages that can do some of the things that Java can do and are very good for rapid prototyping. My favorite Java competitor is Python. But thats not the only one. A lot more people like Perl. And youll get technical quibbles about "Theyre not the same kind of language" and blah, blah, blah. But the truth is, when you look at the whole picture from 30,000 feet, what does Java get used for? It gets used for Web plumbing. It gets used for Web services. Primarily, thats its big niche. What do Python and Perl get used for? The same thing. Technically, the way that those languages are embedded in the environment—and they differ in relatively minor ways—but from the overall functional perspective, from the perspective of where the developers are going and where Web services are growing, the ecological niches are not that different, and these languages really are competing with each other.

And it may be also, the other thing thats happening because Java wasnt open-sourced is C#. Thats something else which tends to fragment that Web services-centric language space. Now if Java had open-sourced, or Sun had open-sourced Java from the beginning, I and hundreds of thousands of other programmers would have jumped on that bandwagon really happily, because we knew it was a way to get what we wanted—write once, run everywhere—without becoming peons on Suns plantation. And the language would be much bigger than it is now. And maybe theres still time for Sun to get that back. I dont know.

Next page: IBMs call to Sun to work on open-source Java.


/Sun situation "> So what do you think of this call by IBM for Sun to work with them on an open-source implementation of Java?

Well, I had kind of a dual reaction to that. On the one hand, I thought that their facts and their logic were impeccable. I mean, they were quite similar to mine, so I had a hard time disagreeing with them. On the other hand, I did detect a certain gleeful tone of twisting of the knife in that letter. [Laughter] There was a certain definite subtext of, "Weve got a chance to put the boot in, so lets do it." So you cant ignore that level of the conversation.

OK, so if you had to grade the big guys who are starting to dabble into open source, who would you give the best grades to? Who would you give the worst?

So far IBM has probably made the most significant commitment in terms of money, resources, manpower and results. Their position in that respect is not unassailable. One of the things I have said to Sun is they have certain advantages over IBM which they have failed to use appropriately.

Such as?

Well, one of them is … IBM has become very friendly lately, but they aint family.

Sun was founded by Unix guys and for a long time run by engineers. They have common history with us. Our dispute with them is almost an intra-family one. Its close to that, but its almost in the family. And there are a lot of us who havent forgotten where Sun comes from and theres a lot of that old-time Unix spirit still alive in that company. Thats a natural advantage in building a bridge to the open-source community that IBM doesnt have.

There are some other factors in play too, but thats indicative of the kind of thing I mean.

How about Hewlett-Packard [Co.]?

Id say HP is a company that a lot of people in the open-source community really respect. I think we feel a lot of sympathy for and affection for the classic HP way. You know, the culture that Hewlett and Packard created. So they get a lot of respect, but theyre not family—not really any more than IBM is.

Next page: Microsofts Shared Source Initiative is a "poison pill."

Microsofts poison pill

Then what about Microsoft and its Shared Source Initiative?

[Laughs.] OK, the thing I like to point out about that is that shared source is a poison pill. Its a way for Microsoft to contaminate the minds of your programmers so that they can never compete with Microsoft again. Because they like to make out like its some sort of open-source offering, but in fact they retain … they dont give up any of the IP rights and the control over methods that is associated with that source code. So if you read it, and its known that you read it, and at any time later in the future you go into competition with Microsoft, theyve still got the option to sue you. So thats why I say Shared Source is a poison pill.

Well, theyve got some fine legal talent.

Yeah, and if I were any software development house in the world, I would be absolutely, freakin terrified of ever looking at that code. Because I would be seeing legions of Microsoft lawyers lined up on the hills, ready to sweep down in this vast, pillaging wave the moment I did anything they didnt like.

But given all that, and the position that Suns in. Suns pretty beaten down at this point. And it doesnt want to cede control. So if Sun did [cede control], by open-sourcing Java, do you see that helping business?

Look, I dont see how it could hurt. It isnt a net revenue stream for them. And if you look at their 10-Qs, they aint making any money on it.

Now theres the argument that theyre using the revenue from their Java licensing to support their development costs on the language. But theres a couple ways you can slice that. One is, do we know that that revenues going to go away if they open-source? I mean, people are still going to want to buy the Java brand.

Next page: A commercially viable way for Sun to open-source.

Commercially viable open

-sourcing"> I can tell you that one of the courses that I have recommended to Sun in public in the past—and one of the things Im continuing to discuss with them, though Ill carefully not tell you anything about their end of this—one of the things Im continuing to discuss with them is a strategy whereby they open control of the source. That is, they issue the Java reference implementation under an open-source license, but they keep control of the brand. They keep control of the testing, they keep control of the verification, they keep control of the certification, they retain the right to say this and only this is Java once its passed our compliance tests and its guaranteed interoperable with everything else.

And I can tell you for sure and certain that a model in which the reference implementation was open-sourced and was being collaborated on by Sun and the entire open-source community, but on another level Sun retains the brand and the exclusive right to call the results Java and collects its value from that, that is a model that the open-source community would be totally happy with. Wed be completely down with that.

Ive been interested in this shift, particularly in terms of government procurements where there seems to be a subtle move from calling for open-source support to open-standards support. Have you noticed this? Whats your take on the whole issue of open standards versus open source?

I would say this: If it doesnt have an open-source reference implementation, the term "standard" is an abuse of the language.

Thats still a very strong position by todays standards. But it wont be in three to five years. If it doesnt have an open-source implementation, how do you know what the standard means? Theres a technical level to this, and theres a political level. The technical level is that standards always under-specify things. You never learn everything you need to know from reading a standards document. There are always assumptions and stuff that slip in, and you need to go to a reference implementation to compare your behavior with that to be sure that youre conformant with reality as opposed to the theory of the standard. So for that technical reason, if it doesnt have an open-source reference implementation, where are you? Youre stuck. Youre at the mercy of the vendor again. It might as well not be a standard at all.

So I would say the attempt by some—in particular Microsoft—to drive a wedge between open source and open standards, its a con game.

But its working. Ive seen it in RFPs.

Its a con game. Yeah, well, I think thats something youre going to see open-source advocates like myself addressing more forcefully in the future.

Next page: Open source vs. open standards and all the mixes in between.

Open source vs

. open standards"> Another thing is this whole issue of commercial development versus open source. I listen to Marc Fleury from JBoss [LLC] talk about professional open source. How do you view that?

Well, its not versus. Theyre two different axes. Theres commercial development versus noncommercial development. And theres proprietary development versus open-source development. Commercial versus noncommercial is about whether youre trying to make money. Proprietary versus nonproprietary is whether you have an open-source or a closed-source license. These are separate axes. And all four categories exist. There is open source for profit, theres open-source nonprofit, theres closed source for profit, theres closed-source nonprofit. All four of these categories exist, and trying to smash those four axes into one, the way Microsoft would like to do, really misrepresents the situation. Theres not open source versus commercial; its open source versus proprietary. Commercial is a different axis.

So you have no problems with the open-source guys who are out to make money?

Absolutely not. Absolutely not. And furthermore, I will state with confidence that I am representative of my community on that.

Well, Jason Matusows [manager of Microsofts Shared Source Initiative] whole thing is that there are elements of "proprietary-ness" in pretty much all open-source projects.

And, frankly, I think thats pretty much a dishonest argument. That is just game-playing with semantics. He knows perfectly well what it is people mean when they talk about proprietary versus open source. Its the issue of who has control, the customer or the vendor.

I really think thats dishonest, and every time he does that in public when Im around, Im going to take a two-by-four to it. Because there are honest arguments Microsoft can make. Theyve got the honest argument that the proprietary model is the only way that you sustain enough capital input to produce software at the scale that they want to do it. I happen to think that argument is wrong, but its an honest argument. Its not an argument that tries to flimflam people by confusing the debate. But this business about "All software is proprietary," thats just flimflam. Thats an attempt to confuse the terms of the debate.

Do you expect Microsoft to open up?



No, it would be like a battleship trying to turn around in the Suez Canal. Their whole culture is against it. I dont think theyll ever do it until so late in the game that it wont save them.

Next page: Other overarching issues in the open-source world.


-source hot buttons"> What are some other overarching issues in the open-source community?

Well, I guess the most important thing Id like you to take away is that theres still a persistent belief in some quarters that somehow being pro-open source makes you some sort of fist-pumping, long-haired Communard. And as a matter of history, I want to tell you that that impression exists primarily because of the character of some of our early advocates. But that was never representative of the community at large. Most of us are quite happy to be working with markets. Were quite happy to be working with people who make profits. And were quite happy to be working with companies like IBM and Sun. Because we know that a market economy is the only way that you sustain a high enough average level of wealth that we can afford to be artists.

One thing that you said that struck me was that you believed closed-source development leads to "crappy code." Why do you think that?

You really havent heard this story before? Well, lets start with some basics. Lets take a direct, historical analogy. You know what the difference between alchemy and chemistry is? It used to be that people who studied the properties of chemicals and materials were called alchemists. And they were all about secrecy. They were all about mysticism, and they were all about concealed black art.

The occult school of alchemy didnt turn into the science of chemistry until alchemists abandoned the practice of secrecy and instead started sharing results with each other and checking each others experiments. And that was a very early stage in the development of modern science and engineering. It happened about 400 years ago. And the thing that weve discovered over the last 400 years, as weve pursued experimental science and developed engineering from an art into a craft into a repeatable discipline, is that human beings doing complex, creative work, doing design work, make mistakes.

Next page: The importance of peer review.

The peer review process

There is no way to mechanically check the results of creative work. If you could do that, it wouldnt be creative work; it would be something you could do with a machine. So the only way to check complex, creative work for correctness is by the critical judgment of peer experts. This is why in science you can form a hypothesis about the sex life of hamsters or something … and you can come up with an incredibly elegant experimental design and a beautiful theory and you can test that theory—construct an experiment, test that theory, come up with results that either confirm or disconfirm your theory. But that in itself is not enough to get your experiment accepted as part of the core of scientific knowledge. Before that happens it has to undergo peer review. Other scientists, independent of your research group, need to check your results, confirm them and ferret out any hidden assumptions youve made that might invalidate the results youre presenting. And this is not just a process that goes on in theoretical science.

If youre a civil engineer and youre constructing a suspension bridge or a skyscraper, you are not going to get to string wire or pour concrete before peer engineers who are not associated with your design group skeptically review that design for flaws that might kill people. Youre going to be required to do that. If the local government doesnt require it, your insurance company is going to require it. And the reason thats the case is weve discovered when youre doing large, complex engineering projects, peer review is a critically important way to mitigate risk. And what my friends and I in the open-source community are doing is saying, "Hey, wait a second, that applies to software, too."

In engineering, whether its bridge building, aeronautical engineering or anything else, you get quality out of a peer review process thats transparent from top to bottom—where the assumptions, the working methods and the results are all subject to peer review at every stage of the process. Well, by gosh, the same thing works for software. We know in general, from our experience in building things like bridges and airplanes, we know that secrecy is the enemy of quality. Concealment is the enemy of good results. And if you look at it from that point of view, it becomes clear that open source is not an exceptional phenomenon. Its not some weird new idea that came out of nowhere. Its just good science. Its just engineering.

The aberrant thing, the weird thing, is closed source.

Next page: The Internet is an example of how open-souce development can scale.


-source proof of concept"> What about the process of alpha testing and beta testing in the so-called closed-source environment? Would that not entail a peer review?

Ah! We have lots of different debugging methods, some of which approximate sort of small-scale peer review. We have formal methods, we have structured walk-through, we have blah, blah, blah, blah, blah. We have lots of methodologies. The problem that were facing as an industry right now—and the fundamental reason that youre seeing more and more open-source development—is because each of these methods is appropriate and effective only within a given band of complexity, or a given region of lines of code. Formal methods, for example, are great stuff. They are wonderful. The problem is they only work on toy programs. Proofs of program correctness? They only work at very small project sizes. Similarly, for each debugging method that we have available theres a characteristic project scale … under which its not worth it to use that method because its too expensive, and over which the method doesnt work because the process overhead kills you.

What were increasingly finding is that open-source development and decentralized peer review is the only debugging method that scales up to todays project sizes and has any hope of addressing tomorrows project sizes.

Thats part of what I was getting at when I said we wont see open-source projects going proprietary … because the proprietary development method just doesnt work when your software gets past a certain size.

Well, what can you point at in the open-source world that scales to this degree versus proprietary software?

The Internet! The World Wide Web. That is the largest system of cooperating software programs in the world. Theres nothing that even approaches it, and its all erected on open-source technology and open-source standards, and thats not an accident. Because only peer review, only openness can sustain a system that large and that complex. If you want other analogies, its like free markets of ecospheres. Above a certain complexity scale, you dont get sustainable results from centralization and secrecy. No, you have to decentralize the system. You have to let the brains migrate out to the periphery, and you have to have constant communication.

Editors note: The headline on this article was edited since its initial posting. The storys original headline belonged to an accompanying news article.

Rocket Fuel