The #8 Reason that Sun is Setting: Fumbling Jini

Originally posted in May 2009...

Just an aside...

Before I go any further, let me just admit up front that I have a specific software bias in my perspective. Most bean-counter analysts will rightly say that the primary reason for Sun to be setting is that we didn't keep our stock price up and that we could have through a variety of financial measures, most notably more lay-offs. But in my opinion, the ability to keep the stock price up is directly related to how a company exploits all its market advantages over time, and I believe that the primary failures for Sun are in the areas of exploiting its software assets, not in a lack of aggressive job cuts.

Building to the "Next Big Thing"

When I joined Sun in January of 1997, Java technology had already transformed Sun from a technical workstation and server company into a software powerhouse. The 1997 JavaONE conference was the largest software developer conference ever held at the time. And Sun was charting an aggressive course for the technology, introducing Java Beans, JDBC, Abstract Windowing Toolkit (AWT), PersonalJava, EmbeddedJava, JavaCard, Enterprise Java Beans, Java Naming and Directory Interfaces, and on and on. And we quietly introduced something called Remote Method Invocation, or RMI. Interestingly, RMI, (along with another interface called Java Native Interface, or JNI), was one of the two aspects of Java 1.1 that Microsoft found so threatening that they refused to implement them in their Java 1.1.4 runtime, causing Sun to sue Microsoft over breach of contract.

RMI is actually a relatively innocuous technology that allows the Java software components (called "objects") in one Java environment (called a "virtual machine", or VM) to talk to Java objects running in another VM. This type of process enables something called "distributed computing", a concept that had been around for years in various forms (some of the more common ones were Common Object Request Broker Architecture, or CORBA, and Microsoft's own Component Object Model Plus, or COM+). Distributed computing enabled software systems to become distributed around a network and still cooperate in solving a given compute task. RMI introduced a Java-specific way to accomplish this and it turns out that by having the same type of objects on both sides of a distributed computing model, the whole process became much simpler and more powerful (CORBA and COM+ allowed objects of different types, like Visual Basic and COBOL, to talk to one another and required a complex set of request brokers and foreknowledge of the application in order to work). What was needed was some form of dynamic finding service where Java objects could register themselves and, using Java-specific capabilities like Reflection and Introspection, determine how to interact with one another at run-time.

Jini Jumps out of the Wrong Bottle

In 1998, Sun introduced something we called Jini. According to and interview with Bill Joy in Wired Magazine, "The Net made it possible. Java made it doable. Jini might just make it happen". What was "it"? It was the idea that the Network really could become the Computer, making Sun's long quoted catch phrase a reality. It was the idea that if every computing device in a network could run Java and RMI, then creating networks of applications that could easily describe themselves, broadcast their capabilities to the network and join up with other devices to create distributed compute networks would be greatly simplified. And by doing it all in Java, it could be programmatic and automated. Jini was the architecture that made the value of Java running everywhere leveragable. And don't forget that Bill Joy was Sun's resident genius and a strong proponent of both the idea of Jini and its development.

So what happened? How could a technology that was the brain child of Sun's resident genius and part of what Microsoft considered to be such a threat end up as a barely noticed project run by Apache? One obvious answer is that, like so many Sun products and technologies, it was a solution looking for a problem. Another obvious answer is that it was a technology that was simply ahead of its time. The real problem was that the engineers had built this technology using the latest Java platform (a beta of what would become Java 2 Standard Edition version 1.2) 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 (the minimum requirements for J2SE 1.2). 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 which was built on it. And to further complicate things, once this misalignment was identified, no consensus formed on how to solve it - should we abandon Jini in devices? Should we re-target Jini at servers and desktops? Should we re-architect Jini so it would work in a smaller memory footprint and processing power? (no small technical feat, I assure you). In the end, we did a little of everything and ended up confusing ourselves and everyone else about what Jini, the heir apparent to Java, was supposed to be.

Jini's Lasting Legacy

None of this was in-and-of itself devastating for Sun. Misalignment between engineering and marketing is commonplace throughout the technology industry. But Jini was no ordinary technology - it was being positioned as the "future of Java", the logical extension to the incredible network of Java-enabled devices that Sun and its partners had created. It was over-hyped for sure, but we didn't seem to realize or care that a vast amount of our reputation as a software innovator was getting wrapped up in Jini and that developers were starting to ponder if Sun was really up to continuing to lead them into new and wonderful markets or down some poorly thought out road to nowhere. In short, we were losing our software mojo.

Jini should have been first-and-foremost about distributed computing. This means big enterprise servers running networked, Internet-scale applications that could dynamically configure themselves and recover from unexpected outages. But ultimately, Sun never really delivered any commercial value with Jini. And we went on to market other "cool" four-lettered "J" technologies like JXTA and Jiro that also never caught on in the market. And worse still, we left the door so wide open on distributed computing that Microsoft and others were able to walk through it with "Web Services" and the associated complexity along with it (Jini could have solved all the problems currently encountered and would have locked alternative languages like Microsoft's C# out of the distributed computing market, to Sun's advantage).

Jini still has a loyal following and there have been some commercial successes based on Jini. But the promise of Jini when it was announced was that Sun would continue to innovate and drive the technology in new and unique directions, enabling things that had not been dreamed of before. Instead, Jini marked the beginning of an era in Java development characterized more by the Java Community Process and the JSRs and Executive Committees that spew forth from there. In short, the failure of Jini marked the end of Sun's vision leadership in software technologies.

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

Originally posted in April of 2009...

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 #10 Reason Sun is Setting: We Failed to Understand the x86 Market

Originally posted in April of 2009...

It often gets mentioned by the press and certain analysts that Sun didn't get into the x86 market soon enough, or strong enough, or didn't drop SPARC when it should have, or some other such criticism. I believe Sun entered the x86 server market when it had to (our first foray into the server market was the oft-lamented LX50 server back in 2002) and has done a decent job (with the help of Andy Bechtolsheim) at differentiating our offerings while maintaining a competitive price (although margins are another matter altogether).

The problem is we didn't 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. We've been improving over the years, but we still have a channel strategy that leverages our traditional partners and programs and does not effectively take our volume products to volume customers.

Our other mistake was to allow our strategy for proliferating Solaris on x86 to overshadow our need to drive volume for our x86 business. Although Sun has been offering Linux on our x86 systems since 2003 and has recently entered into OEM agreements with both Microsoft and VMWare, our focus as a company has been exclusively on Solaris. It is the only OS we pre-install on our hardware. The key to gaining momentum in the channel is to provide the environments that customers want, which for x86 is still predominantly Linux and Windows. We needed to focus on Solaris, but in the area of ISV recruitment and creating solutions that uniquely leverage Solaris and add value to customers, thereby creating demand. By failing to promote other OS offerings and solutions within the channel, we became a niche player in their mind and ultimately became an after thought in their sales to end users. Volume drives the channel, the channel drives volume and volume is the only way to make money in the x86 market.

We've been getting smarter about this lately and over time we would have eventually gotten this right. And we've made progress on the Solaris side, so overall this was not going to bankrupt the company. But it has stunted one of the key growth markets for us and helped to keep us in the "expensive, proprietary system" box that our competitors painted for us, so it has contributed to our lackluster stock performance. For this and other reasons, it is my #10 Reason for Sun to be Setting.

The End of an Icon - revisited

Sun is now history and it's a new day at the combined "Sun-Oracle". Thankfully, I have a position in the new organization and look forward to contributing to the combined company for at least the foreseeable future. My heart goes out to all those who were not so lucky.

Back in April of 2009, when the proposed acquisition was first announced, I had this to say:

"Having worked for the Corporate Development group at Sun for the past 3 1/2 years, I've had to be very careful about what I posted on a public blog. I felt it was better to be safe than sorry, so I've left it to the many other prolific bloggers at Sun to tell our story.

But with the recent announcement that Sun will become part of Oracle, I feel able for the first time to talk about how we got here. Not about the Oracle acquisition itself, but rather how we as a company came to the point where seeking an acquirer was the best way forward. Granted, 2009 is one of the most challenging years in decades and many companies are struggling, but when I joined Sun in 1997, we had the technology world by the tail and were poised to become as influential and lucrative as our more famous rivals (Microsoft, IBM, Intel, HP and even Oracle). So as excited as I am about becoming part of Oracle (there were many far worse options in my opinion), it still feels a little anti-climatic.

So as a sort of "post mortem" on the company, I'd like to examine where I think Sun really missed its opportunities. Some things are only obvious in hind sight, but many of these things are things I've spent my career at Sun advocating and attempting to drive forward. Maybe this is a bit of sour grapes on my part, but mostly this is just an attempt to say externally some of what I've been saying internally at Sun for most of my tenure, now that our future as a Corporation is moving out of our hands.

I will call this my "Top 10 Reasons Sun is Setting". In typical Top 10 fashion, I will start with the #10 Reason Sun is Setting and work my way up to the #1 reason. I know there is a lot of opinion on this topic out there, so feel free to comment as you see fit. I think we may all find this cathartic."

In the course of outlining these "top 10 reasons", I responded to several comments that had been made on what I posted. It was some of those responses to comments that contained what might have been considered "forward looking statements" and I was advised by Sun management to delete my responses to comments. Not wanting to put myself or the company at risk, I voluntarily removed all of my "top 10" posts, promising myself to re-post them once the acquisition closed (not knowing that would be 9 long months later).

What I didn't anticipate was that the deletion of my posts would garner more attention than my posts themselves. So with the added attention, I decided that when I did repost reasons #8 through #10, I would do so on my private blog so as not to garner more attention than is warranted.

So I will now repost those original 3 reasons here and continue to add the other 7 reasons as time allows. As before, please feel free to comment and I will respond freely now that the acquisition is closed and I can do so without fear of overstepping my bounds.