Sun Employee Completes Partial List of Reasons for Sun's Failure

It seems that a Sun employee started documenting the top ten reasons for Sun dropping from a $200b company to one that was picked up for $7.4b. The list was pulled, and now it only exists in Google Cache (and some blogs :) )

Here's my favourite of the 3 he managed to get out:

The #9 Reason that Sun is Setting: Messing with the Java Brand

Much has been said and will be said about how Sun "blew it" with Java - mostly around the lack of contribution by the technology to Sun's bottom line. But this #9 reason for the Setting Sun is not so much about lack of Java revenue (that's actually a rather complicated story), but rather about the numerous attempts by well-meaning marketing folks at Sun to try exploit the value of the Java brand itself and how that ultimately reduced the very value they tried to exploit. To some degree, this is as much about the lack of value in the Sun brand (at least outside our loyal customer base) as it is about Java. After all, if we had sufficient value in the Sun brand there would be no need to try to leverage the Java brand in other areas. But I believe our attempts to leverage the hard-fought value of the Java brand ultimately back-fired, diminishing both the Sun brand and the Java brand.

In the earlier days of Java, the technology was managed by an independent "operating company" called JavaSoft, with its own marketing, sales, products and brand management. There were numerous discussions and debates within JavaSoft about the use of the Java brand and for the most part there was a strong focus on associating the brand with the promise of the technology - that old idea of "write once, run anywhere". There were several brand campaigns around Java - there was the concept of "Java Compatible" for licensees of the technology, "100% Pure Java" for application providers, "Java Powered" for devices, etc. - some of which were very successful, others were branding duds. But there was always a careful consideration of the term "Java" and how we would allow it to be used - both internally and externally.



Fast forward to around 2003 and Sun is struggling to regain its former dot-com glory. We're coming off the painful Netscape-AOL alliance (more on that later) and we're struggling to find a way to express our remarkably robust software assets through a brand. We'd abandoned the confused "iPlanet" brand (which suffered from under-promotion and a "who's your daddy" syndrome between Sun and AOL) and were struggling with the equally confusing and under-promoted "Sun ONE" brand. We were also in one of our many post-dot-com-bubble austerity programs, so heavy investment in any brand was not likely to get funded. I can only assume that the branding discussion (which I was not part of) went something like this:

What's the answer to our branding problem? Java! It's already one of the most recognizable brands in the world and we own it outright. Confused about what Sun ONE Application Server is? Call it the Java Application Server and problem solved! Well, wait - not quite. We can't really call it Java Application Server - that's already an industry standard term for Java EE implementations like IBM's Websphere and BEA's Weblogic and we don't want to further promote them. So let's call it Sun Java Application Server! Wait - hold on. That's likely to get confused with Sun's Java Application Server, which isn't very "brandy" and would be like saying "Sun's Operating System" for Solaris. Not good. Okay - how about Sun Java System Application Server! Yeah! That means it's not just an Application Server, but it is part of a system! Great! All our software is part of a "system"! Now we have a convention for all our software assets! The Sun Java System (fill in your product function here)!

This lead to a proliferation of product names like Sun Java System Access Manager, Sun Java System Identity Manager, Sun Java System Directory Proxy Server, Sun Java System Web Proxy Server and on and on. The problem was not only was this a messy and cumbersome branding campaign, it was diluting the Java brand both within it's own convoluted convention and the broader technology market. Did Sun Java System Web Proxy Server have any Java in it at all? Did it manage the proxies of a Java web server or any web server? And if Sun was not going to use the Java brand to describe Java technologies, why would anyone else? The net effect of this ill-fated campaign was to make Java more about Sun's weakening grasp on its core software portfolio and less about the benefits of modern object-oriented, network-centric computing. It was a double-declining depreciation of the core value of Java.And the two insults added to the injury were the ill-fated Sun Java Desktop System (which I had a hand in creating, but not in naming) and the changing of our stock symbol to JAVA. The former was no more about Java than is Mac OS X (which, like JDS, contains a Java SE runtime). The latter was a sad attempt to make Sun's stock more recognizable on Wall Street, as if that's what we created the Java brand for.Fortunately, the value of Java as a technology was not irreparably damaged and there is still enough value to in the brand to cause Larry Ellison to declare that Java is the the single most important software asset we have ever acquired. That's why I rank this is my #9 reason for the Setting Sun and not something much higher.

The other 2 posted were:

Reason No. 10: Failed to understand the x86 market. "We approached the market in the only way we knew how - as an extension of our high-end, low-volume, high-value approach to network computing. And not just in terms of product features and capabilities, but in terms of sales, partnerships, channel programs and supply chain management."

Reason No. 8: Fumbling Jini. "The real problem was that the engineers had built this technology using the latest Java platform...and had incorporated specific changes into J2SE 1.2 to support the Jini requirements. When launched, Jini could not run in anything smaller than a device with 64MB of memory and a Pentium-class processor.... Meanwhile, Marketing and PR were off describing uses of the technology that were all about small devices (cameras, printers, cell phones, etc.) that were completely unable to run RMI, nonetheless the Jini on which it was built.