From SUNW to JAVA: SUN comes to the rescue of under-50-year-old-housewives? Not quite. August 29, 2007
Posted by Sacha in JBoss.trackback
So that’s it, SUNW decided to start leveraging their Java brand: they have updated their NASDAQ ticker symbol from SUNW to JAVA. To be frank with you, I thought this move was a rather “shy” one (read: weak). I mean, SUNW has always tried hard to act as the clean “referee” that – unlike Microsoft – builds an healthy open standard-based ecosystem around Java. So now, what do they do? They damage this “Peace of the Braves” by using the “Java” brand as their ticker symbol. That’s probably the most optimal way to get all of the negatives without getting any of the positives. Really, who cares about SUNW’s ticker symbol? Snore…
So, why did SUNW do that? As hinted by Jonathan Schwartz:
the number of people who know Java swamps the number of people who know Sun
Hum, Jonathan, you might want to review the methodology that has been used for this survey. Specifically, who did you ask? Middleware developers, CIO and Gartner Analysts? Or did you ask the “under-50-years-old-housewives” group? Because if you asked the former groups, I bet you got a one-to-one match between Java and Sun. Now, if you asked the later category, I am pretty certain they didn’t know much about Java in the first place, except maybe if they are the proud owner of a Starbucks “frequent drinker” Card. But, do you really really care to educate that group of people at the cost of upsetting your ecosystem? If you really really want to leverage the Java brand, rename “Sun Microsystems” to “Java Microsystems”. You own that brand, so do something real that justifies breaking this subtle equilibrium you’ve built over the years, not a quick-and-dirty something under the carpet.
Ok, I am slightly making fun of Jonathan Schwartz’s decision here and I probably shouldn’t: he is a smart guy. As such, I cannot believe he was just bored and decided to make such a move simply to educate “the masses”. Au contraire. I think that by doing so, SUNW is sending a clear signal to the first group of people, the IT market, that says “the rules of the game are about to change”.
First of all, SUNW is making it clear that they intend to further leverage Java, and probably not only its brand. Jonathan Schwartz is clearly trying to re-focus a big chunk of SUNW’s value around its software business. Still, when you look at their results in the Java space, that’s not brilliant. Truth is that it is difficult to be the referee and to win the match at the same time. And that is probably what SUNW is currently realizing. They have had no success whatsoever with any of the (numerous!) Application Servers they released into the market up to now in spite of the fact that they’ve made significant investments in the software field (including the acquisition of SeeBeyond). Is it paying off? My bet is that it is not. And SUNW is trying to find ways to accelerate their software clock. However, they probably don’t think they can accelerate the time of their payout without changing the rules of the game. That includes the branding of Java, for sure. But that might also include the way they intend to release future versions of the Java Platform (both SE and ME).
When you actually look at the kind of license SUNW proposed to the Apache Foundation for the Harmony project and the imbroglio it created, it is embarrassing. They are not respecting the JCP rules they have themselves defined. They hide behind their finger by using cryptic legal arguments which merely adds to the embarrassment.
And SUNW is sufficiently versed into the JCP rules to understand that if they don’t abide by their own rules, the JCP EC will most probably use the ONLY real power it has: to vote down a spec. Which, in that case, means to vote down the next SE JSR. Given that SUNW doesn’t seem to care about that threat, my guess is that they might be prepared to pull Java out of the JCP. They might keep the JCP running for the non-strategic/non-platform specs, but not rely on it for Java itself. If they want to be the only implementation in town, what do they need a standard for? They could just go the MSFT way and implement-first (with the gentle help of the OpenJDK community, wink, wink) and publish the resulting APIs after. Much less costly, with the same ability to monetize its JVM with OEM (thanks to the GPL). A priori at least.
So let’s see what SUNW’s next moves will be. They’ve clearly put a dot on the map by breaking the long-standing Java equilibrium. We need to see where they’ll put their next dot so we can draw a line and see in which direction it goes.
Jonathan, are you really ready to pull the plug and live with the consequences of that choice?
Onward,
Sacha
Sacha's Weblog 
i DO subscribe to the view that ponytail boy was just bored and decided to change the brand just for the fun of it. Next I hear he wants to list on the NYSE!
I do not want to believe in the “JAVA is now only SUN so let’s kill the JCP” view, it is too sad. Look everyone loves to bang on the JCP, IBM the first, but at the end of the day everyone (well, almost everyone 😉 certifies
Do you really really think that a CEO of a public company could be bored enough to move its trading from, let’s say, the NASDAQ to the NYSE?!? Nah, it cannot be possible 😉
If only the EC had the courage to vote down every single spec that ties in a proprietary TCK, RI or NDAs with a JSR, JCP could be a useful venue to work in, and actually be representative of an open process, open specs, and all the other fluffy feel good stuff that people assume the JCP stands for, but actually doesn’t quite do.
Fortunately, there is a simple way to fix that from within the JCP: vote the current EC out, and replace them with people who’ll take appropriate action against JSRs that try to wrap broken proprietary business models in the flag of community support.
Unfortunately, that’s not going to happen any time soon, for all sorts of reasons, and we’ll have to continue to live with the mess the JCP EC created, by favoring the interests of proprietary software vendors over the interests of the users, and letting them get away with nonsense like NDAs, proprietary RIs and TCKs.
Hello Dalibor,
I am not sure I agree with you on the proprietary TCK & RI. If the JCP releases good standards and good TCK&RI so I can i) prove that the standard can actually be implemented (RI) and ii) test my own implementation (TCK), then I am fine.
Most FOSS JSR implementations (if not all of the FOSS ones) actually never license the RI, just the TCK. And while it would sometimes be easier to be able to look at the TCK code (mostly to debug the TCK itself before raising a challenge before the spec lead), that is more by comfort than really a must-have.
I don’t think FOSS should become a mandatory constraint for the RI&TCK. This industry contemplates many different business models: the JCP should respect this and allow for these various business models to co-exist.
Imposing the TCK&RI to be FOSS software goes against that respect for multiple business models IMO.
Cheers,
Sacha
I don’t think that having a mandate for FOSS RI and TCK limits business models of implementors at all.
For the handful, at most, specifications that have gone the route of making both the RI and the TCK open source, I don’t recall anyone complaining about that choice limiting their business model. Quite to the contrary, Doug Lea’s concurrency JSR was hailed as the supermodel JSR everywhere, afaik, and it was the first JSR I’ve seen to have both an open source TCK and an open source RI.
At best, an argument could be made that mandating FOSS RIs and TCKs limits the opportunity of the spec leads to make a business out of discriminatory access to specifications, RIs or TCKs, which is a business model that’s currently encouraged by the JCP EC by default for most JSRs.
All the regular schoolyard theater that happens in the JCP around discriminatory access to one thing or another (and there something fishy going on every year, year after year) is a direct consequence from allowing the creation and maintenance of supposedly community driven and maintained specifications to be perverted into a profitable line of business for a couple of members of the JCP establishment at the expense of the Java developer community, that gets to deal with the consequences, and pay for them, directly or indirectly.
Putting an end to that sort of business practice would actually be a great thing for Java developers everywhere. But I don’t expect vendors on the JCP EC to empower their consumers by giving them non-discriminatory access to RIs, TCKs, and specifications without being dragged kicking and screaming to do it. And I certainly don’t expect the current EC to do the dragging part. 😉
… but I’d expect the current EC to ponder about screaming. 😉
I hear a lot of “industry insiders” crabbing about the JCP, but as a user, it’s generated more innovation and opportunity than any community process I’ve ever seen. Everyone on earth belongs, and just like any family, it has squabblers. But overall, it’s fantastically productive. And unlike Linux, at least it’s not a dictatorship.
Dalibor,
In fact, I am referring to none of the cases you’ve outlined above 😉 – but almost.
Mandating FOSS RIs and TCKs would limit the opportunity of the spec leads to keep a competitive advantage for their own implementation – usually a super-set of the RI. More specifically, if my business model is to sell proprietary software then I might be fine to lead a spec but might not want to make all of the IP of my RI available to any competitor out there, which is fair enough. The JCP is about standards, not implementations. If you want an implementation, go and code it yourself. In FOSS 🙂 Again, that is because most of the time, the product of the spec leads is an extension of their RI.
Companies that are NOT JSR leads but want to implement a JSR are not mandated to do it in FOSS, obviously. Providing the same possibility/option to the Spec Leads seems fair to me.
Also, if, as you hinted, the Java Developer community really thought it was suffering that much, it would be trivial for “it” to do what you are suggesting and to get rid of the current ECs (all it takes is to become JCP member and vote – all of this is free).
I cannot feel that wind of revolution yet 😉
Sarah,
I agree with you, the Java phenomenon is impressive. While we can certainly criticize many things and could improve many others, the list of languages/platforms that have generated so much value for an entire ecosystem, and this during more than 10 years must be pretty short and Java must be sitting right at the top of that list.
If Java had not been in the hands of SUNW (but instead in the hands of any of the big software guys out there), I am not sure I would be here to write the same thing today. That’s why I am currently concerned that SUNW might be have decided to go in the wrong direction with Java.
We are spoiled… 😉
Cheers,
Sacha
Even in that case, an open source RI does not prevent a spec lead from publishing their ultra proprietary, mega cool super-set implementation based on the RI, as long as the JSR is reasonably well designed and does not mandate that the functionality is provided through concrete classes.
I’d optimistically assume that current JSR spec leads have learned their lessons of API design over the past years. They’ve had a lot of practice, if nothing else …
Voting the current EC out would not be a revolution, it would be just a simple reform for the JCP to start serving the C in that acronym, rather then only the proprietary vendor subset at the expense of the rest of us. When the time comes, the vendors will jump on that bandwagon, like that did with open source Java, and we’ll all be winners, as usual. 😉
… I’d just prefer us to all be winners without having to spend too much time fighting the future. 😉
Dalibor,
I don’t see how. The RI has to be *fully functional* (it is not just a set of API). For most specs, that represents quite a bit of work!
Cheers,
sacha
Nevertheless, many spec leads seems to manage just fine these days to make the RIs open source even without explicit pressure: IBM’s 291, Sun’s 277, JEE, JSE, JME, etc.
So I’m not buying the argument that the spec lead is worse off with an open source RI, as I haven’t seen any spec lead with an open source RI come out and complain about it. So it doesn’t seem to be that limiting, as afaik Sun and IBM are happily licensing their code to whoever cares about licensing it under non-free terms. I don’t think they are all switching over to open source RIs for their JSRs out of the pure kindness of their hearts alone. 😉
Sacha, you’re just another Red Hat employee (or have you been fired yet?) bitching that the world wont give everything to you on a silver platter for you to make millions. I’m thrilled Sun’s finally standing behind Java, and promoting it with all their worth. I’m impressed they continue to put up with all this crap rather than dropping you like the whingeing bag of work you are. Java is free, long live Java. It must really piss you off that Glassfish is starting to steal your thunder.
Sacha,
Can you elaborate on what Sun’s “cryptic legal arguments” are?
I’m not looking for any detail – just curious what the gist of their argument is.
Andy
Hi Sacha. I’ll stay away from the Ticker symbol and the TCK issue… but I feel I need to do a quick follow-up on a (localized) point in this entry. You write:
>>
They have had no success whatsoever with any of the (numerous!) Application Servers they released into the market up to now in spite of the fact that they’ve made significant investments in the software field (including the acquisition of SeeBeyond). Is it paying off? My bet is that it is not
>>
From what I can see, GlassFish is doing _very_ well, and others, like Forrester (see http://blogs.sun.com/theaquarium/entry/what_a_difference_18_months) ) seem to agree. – eduard/o
Dalibor, I think JBoss showed a few years ago with the EC JDO vote, that we’re not scared to make waves and question the viability of certain JSRs. I can’t believe I’m giving him credit, but Geir Magnusson, Apache’s EC rep, has also made a pretty good stink in the Harmony debacle. So, although the EC may seem dead from the outside, there are definately a few members who don’t mind making waves.
Andy,
No, sorry, I cannot, per JCP-EC rules.
Cheers,
Sacha
John,
Thanks for your kind words. As you might not have understood, JBoss/Red Hat is not directly concerned by the field of use restriction of Java SE as we are using (and participating in) the OpenJDK project with SUNW, we are not using Harmony. However, we do think that the Harmony project should be properly treated, as a principle of equal-treatment.
Cheers,
Sacha
There has never ever been equal treatment in the JCP.
The current JSR system discriminates against people who don’t sign NDAs, for example. Yet the JCP EC never saw it fit to stand up against that discrimination and abolish it in the past five(5) years I’ve been following it, and to establish equal access to all of the Java community to JSRs under development (i.e. as long as commenting on them makes any sense at all).
That’s been something the GNU Classpath community has demanded at least since 2002, btw., but the JCP EC didn’t find time yet to fix that particular equal-treatment issue. I mean, the JCP EC never found the time in the past five years to invite the Classpath community to a JCP meeting and listen to their list of issues with the JSPA either. I assume they must be really busy doing whatever the JCP EC is doing behind closed doors. 😉
Bill, yes, I agree. But that’s not enough, in my opinion.
The issues the vendors are squabbling about today are issues they should have fought about 2004, when we first started working on scaling JCP’s steep walls and certifying Kaffe as a 1.5 implementation. The EC comfortably slept through the whole open source Java phenomenon for five years, and never bothered to figure out why those odd Kaffe, gcj and Classpath people are deliberately staying outside the JCP, and what their problems with the system are.
Today, that ‘omg, making an open source Java 1.5 implementation is not as easy as advertised by the JCP, shock, horror’ battle is no longer relevant. We’ve been there, we’ve done that, and we found a better way to win it over the past three years.
The relevant battle today is to turn the JCP into something where no longer a single vendor, or a cartel of vendors & their friends can have the ultimate advantage over others. The only way to get everyone to disarm at the same time, is to make clear, simple rules that grant everyone equal rights, rather than exclusive rights to those running the system. That leads naturally to open source RIs, TCKs, no NDAs, etc. That’s what the EC should get on, but from discussions with Sacha & Geir, I know that’s illusionary with the current EC.
So, alternatively, we should just gradually vote ourselves an EC that will do it, and put the interests of the community back into the JCP. We shouldn’t wait until the vendors run Java and the JCP into the ground, and we shouldn’t pay to watch another round of Unix vendor wars.
This is the most surprising move from Jonathan I have seen over years. First was the $100 per employee package for the entire sun software stack, that may have paid off partly. This was an attempt that basically leaked out any money to be made in software construction.
If Jonathan wants to bring the software face of Sun in the forefront, then he may as well redirect his sales staff, service engineers from a Hardware persona to a Software one. This in my honest opinion is the toughest job to do.
I will not be surprised if they change the name of “Sun Microsystems” to “Java Microsystems” with a motto of “We do Java Virtualization”.
It may be better to motivate the employees and bring out the innovation in them that has been lying hidden due to market fears. SUN is a brand, a synonym with a great technological company (Sutherland, Joy, Gosling, etc). Now this attempt to re-image yourself as Java is a bad one, IMHO.
Hello Eduardo,
I agree with you, you are doing great 😉
Cheers,
Sacha