Enterprise Unix Roundup: Sun Should Loosen Up

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Last week, Simon Phipps, Chief Open Source Officer at Sun Microsystems, stated in an interview that much of the current animosity from the open source community toward Sun has its origins in the way Sun used to treat the community.

Phipps, being his usual straightforward self, phrased it as Sun “screwed up,” a quote guaranteed to make headlines, which it did.

In the interview, Phipps stated:

Open source developers have been much more sceptical [sic] of Sun, a lot of open source developers don’t remember the fact that Sun was pretty much the first open source start-up in 1982.

All they can remember is what happened in 2001/2002 when, to be quite frank with you, we screwed up. We alienated a large group of open source developers by the attitudes we had of the community back then.

No kidding. I remember sharing a cab in Manhattan at LinuxWorld in 2002 with several Sun folks and hearing the exchange they had about Red Hat and the open source development community. Needless to say, the statements were far from positive. The thrust of their point was that Red Hat claimed to be all good and open source, but the Linux vendor was actually more proprietary than most people thought, and Red Hat’s vendors complained mightily about it (or so these guys claimed).

Sun wasn’t the only one to espouse that point of view. Lots of people back then, including myself, had concerns about just how open Red Hat was with its homegrown technology. But Sun was really vocal about it, and it didn’t endear the company to the community at large.

I have had a few conversations with Phipps over the years, and he’s no corporate flack. He’s very smart about what makes open source work. But he has a predilection for obtaining the maximum business gain from an open source project, an attitude I know is not winning Sun any friends now, nor did it earlier in the century.

Phipps is absolutely right when he refers to the early 2000s as a time that colors people’s judgment about Sun and open source. What he seems to be missing, however,is that there are present-day concerns, too.

Sun has been a good open source citizen in the past and present, in terms of the sheer volume of lines of code it has released to the community. However, it has usually done so with strings attached. OpenOffice.org was initially opened under the dual Lesser General Public License (LGPL) v2 and the Sun Industry Standards and Source License (SISSL). From OpenOffice.org 3.0 onward, it will be just LGPL v3. OpenSolaris’ license is a bit more restrictive in the grand scheme of things, being under the Common Development and Distribution License (CDDL).

While all of these licenses are open (and the LGPL is Free, too), it’s how the projects are managed that tends to rankle. Sun consistently keeps the management duties held by Sun employees, and has often made decisions in the project that benefit Sun more than any other participant. (The recent decision to name the Project Indiana “distribution” OpenSolaris, thus superceeding any other OpenSolaris-based distro is one glaring example.)

I have no doubt as to Sun’s sincere desire to open things up. But at the end of the day, it’s alway been about what’s best for Sun.

But before I beat up Sun, let’s be honest: Is this really any different for any other open source vendor? Novell, Canonical and Red Hat are just as guilty of this practice of self-preservation as any other company. And why not? That’s what companies do.

No, I won’t pick on Sun’s motives. I think it’s the execution that’s off-kilter. The company must learn to let go a little bit and let the open source ecology proceed naturally. In the short term, Sun might lose a little bit of advantage in the market, but long term, it is has a better shot at success.

Brian Proffitt is managing editor of JupiterWeb’s Linux/Open Source channel, which includes Linux Today, LinuxPlanet, and AllLinuxDevices.

This article was first published on ServerWatch.com.