How Sun's need to control the code cost them the company

The difference between Sun systems and everything else out there in the late 1980's (mostly Novell Netware or Microsoft LAN Manager networks) is that Sun networks “just worked”,  all the time. I remember visiting remote Sun offices in the UK, and just being able to log in wherever I was and have all my files and work environment automatically available via the Network File System (NFS) auto mounter and directory services available via Sun's Network Information Service (NIS/Yellow Pages). One morning I was outraged when Sun network operations informed me my home directory and work environment wouldn't be available until that afternoon due to a network outage. I was so spoiled, I didn't even realize such things were extremely rare outside the cozy world inside Sun.

I took a job on the Sun “hotline”, the most technical job available to engineers working for Sun in the UK. We were a hard drinking, hard partying bunch, who prided ourselves on the number of technical customer calls we could fix per day. I'm still friends with a few of the engineers I met there, they were a technical group with extraordinary skills. The UK hotline prepared me for the job that brought me to the US, working for Sun Corporate Technical Escalations (CTE) Group, whose job it was to prepare the front line code fixes sent to Sun customers reporting bugs in the software.

So why did Sun die ? Partly it was their custom designed hardware that couldn't keep up with the immense commodity power of Intel and the x86 clones. Even in the early 1990's there were warning signs when Sun canceled the replacement for their early foray into x86 hardware, the Sun386i. Rumor had it that the Sun 486i was canceled when early benchmarks showed it out performing the Sun-designed SPARC chips of the time, which upset the “all the wood behind one arrowhead” slogan that was Sun's credo around their own SPARC processor design.

But in the long run it was the software that ended up being unable to compete.

Linux systems from Red Hat and others ate Sun up from the inside out, by colonizing their customer base. Sun vs. the Linux world is a wonderful example of the weakness of proprietary licensing and trying to maintain control over software versus the GNU General Public License (GPL) and decentralized development model that Linux uses.

Sun was originally born from a combination of BSD-licensed and proprietary code. The BSD UNIX system was built on top of AT&T's original proprietary UNIX code. The first version of the SunOS operating system was licensed from this version of UNIX, and one of Sun's founding software engineers, Bill Joy, was one of the original creators of BSD UNIX. BSD-licensed code is available to be used freely by anyone without restrictions, and Sun took full advantage of this. Sun didn't give back any changes to the BSD parts of the code, but kept most of their changes proprietary. Occasionally they would release something to the “community” they came from. The Open Network Computing/Remote Procedure Call (ONC/RPC) code that was the underlying technology for NFS was one such thing. But most of the kernel changes and enhancements they made were kept hidden.

That's not to say they never gave anything back to the Open Source/Free Software community. On the contrary, Sun CEO Scott McNealy claimed repeatedly that “We're the largest contributor to open-source on the planet”. The problem was never the size of the contribution (which was indeed large by the end of Sun's life). The problem was that the contributions were always on their own terms. Sun was the poster child of a company trying to retain complete control over everything they released into Open Source.

Most of their released code was essentially just dumped over the proprietary wall. The idea that others may have had contributions they wanted to make to the code that had been opened was never even considered. Originally there were no Free Software projects run from within Sun; the attitude was always “how generous we are to show you our amazing code.” After Linux became popular, they tried to adopt a community-friendly attitude.

The Solaris operating system, the Java language and virtual machine, the OpenOffice office suite -- all of the really large software projects that Sun released -- had strings attached that stopped any real external community from forming around the code. Usually it was the demand that any code contributions be contributed directly to Sun for their own use in proprietary products that was the major failing of all the Sun “community” projects. Poor licensing choices, demands for ownership of all contributors work, ignoring contributors outside of Sun, all of these can be blamed for Sun's inability to maintain active coding communities around their Open Source code, but in the end it comes down to the desire to maintain control and ownership of the code at all costs. People are smart enough to understand when they're being taken advantage of, especially programmers.

This desire for control cost them dearly. When my own Free Software project, Samba, was first released, SunOS and Sun Solaris were the major platforms people wanted to run our code on. Once Linux got networking code added to the kernel, people started to move Samba servers over from Solaris to Linux. The control of your own destiny and the freedom that people got from Linux was the main advantage, even though the Linux kernel didn't work as well as Solaris did at the time. Other Free Software projects tell similar stories about the Solaris to Linux migration.

Real Free Software projects like Linux completely give up centralized control and ownership, in favor of a decentralized model that means contributors keep ownership and see direct benefits to participation, with no one party being able to take advantage over others.

Linux the operating system project completely confused Sun, even the Sun engineers, who you would have thought at least understood what Linux was trying to do. The best example of this is the wonderful email exchange between Linux kernel hacker David Miller, who at the time was one of the Linux Sparc maintainers, and Bryan Cantrill, a Solaris engineer. It's worth quoting:

David Miller wrote (at the end of a long email explaining how Sparc Linux used cache optimizations to beat Solaris on performance):

“One final note. When you have to deal with SunSOFT to report a bug, how "important" do you have (ie. Fortune 500?) to be and how big of a customer do you have to be (multi million dollar purchases?) to get direct access to Sun's Engineers at Sun Quentin?  With Linux, all you have to do is send me or one of the other SparcLinux hackers an email and we will attend to your bug in due time.  We have too much pride in our system to ignore you and not fix the bug.”

To which Bryan Cantrill replied with this amazing retort:

“Have you ever kissed a girl?”

Talk about missing the point and underestimating the competition. You can read the entire exchange.

Of course that's not the only reason for Sun's failure. By the end of Sun's life in the early 2000's the management was bad. No, that's not true. The management was very bad. But it was caught in an untenable situation trying to compete with Free Software.

What could Sun have done ? Was there any path that could have left them successful in a world of widespread Linux and Free Software ? It's not clear. Sun is the classic case of Clayton Christensen's book “The Innovator's Dilemma”. The disruptive force of Linux left them unable to compete, with their high priced product that didn't have enough advantages over the community developed project to get people to pay for it. Oracle did them a kindness, and has picked up some very talented engineers. The interesting thing to observe now will be if Oracle (who is already a Linux vendor) takes the valuable parts of Solaris and adds them to Linux, or tries to resurrect Sun's failed Solaris business model and throws more money onto the fire.

I'm betting Larry Ellison is too smart to do that, and at last Sun has some good management. R.I.P. Sun Microsystems, I'll miss you.