jump to navigation

Hudson/Jenkins – some more context and thoughts January 12, 2011

Posted by Sacha in CloudBees, English, IT.
Tags: , , ,

Andrew Bayer just posted a blog post on Hudson-labs.org with a proposal for renaming the Hudson project to “Jenkins”. Since Kohsuke Kawaguchi, founder of and lead contributor to the Hudson project, is part of CloudBees, and I’ve helped Andrew and Kohsuke bounce ideas, I wanted to share some more context and thoughts.

Each and every Open Source project has its own DNA, its own philosophy that gets established over time. Born in 2004, Hudson has had plenty of time to find its cruising altitude. Yet, after Kohsuke left ORCL, ORCL decided they didn’t necessarily liked the way the project was handled and asked for some changes to take place.

Let me clarify a key point upfront: was ORCL’s proposal stupid? No, not at all. Each and every project has a different DNA and I could very well see some FOSS projects for which such proposal would have made sense. Yet, the real question was not so much whether ORCL’s proposal could make sense for “some” project, the question was whether their proposal was making sense for Hudson specifically, a project with a well established DNA. And here the answer is a clear no.

So, why didn’t the community simply reject this proposal and move on? Anybody can request changes to any project, which doesn’t mean they’ll get accepted, right? Well, the difference here is that Hudson has an “asymmetry” in its community: one of its community members, ORCL, claims they “own” the brand and every contributor has to sign a contributor agreement granting them a copyright license. This “asymmetry” is frequent in many projects (JBoss, Glassfish, etc.) Yet, what is less frequent is when the “owner” of such asymmetry contributes very very little IP to the project (but receives a lot of free IP from the contributors through the CLA).

And so, the fear was that the Hudson project would be at the mercy of any random decision ORCL could take in the future.  And while I trust the person at ORCL with whom I’ve been interacting to not make any stupid or damaging decisions, at the end of the day this is not an agreement with a specific individual, this is an agreement with ORCL: people come and go.

So, what was the right decision? Was it be better for the community to keep investing its time and energy in the existing brand, and take the risk that it could fire back at some point in the future or was it better to “sanitize” the situation upfront and invest those efforts in building a new brand, hence removing the asymmetry that currently exists in the community?

What about ORCL now? They essentially have two choices. They can either keep working on their own project under the good old Hudson brand, or they can participate as an equal player in the newly branded community. Personally, I’d really like to see ORCL join forces with the rest of the community, as CloudBees will. I truly hope ORCL will join us, if not now, once the dust will have settled.

Last but not least, let me clarify one important thing: CloudBees has no intention whatsoever to replace ORCL as the new asymmetry in the Hudson/Jenkins community: CloudBees has no intention to own the trademark on the new brand, to own the IP of the project or anything else. Yet, what CloudBees has every intention to do is to further invest time and energy in contributing to Jenkins.





IBM joining OpenJDK – repeat after me “pragmatic”, “pragmatic”, “pragmatic” October 12, 2010

Posted by Sacha in English, IT.
Tags: , , , , ,

Things have started to move quickly in Java-land. Yesterday, IBM announced they would partner with ORCL on Java and participate in the OpenJDK project. They also said that in doing so they would shift their Apache Harmony resources towards OpenJDK.

Note: I can insure you that the “pragmatic” word is going to be used and abused in the next few weeks when talking about Java…


From a market standpoint, ORCL played hard-balls and won.

One of the only possibilities for a Java fork to be successful was for IBM to co-lead it. With this announcement, the “pragmatic” view wins. I imagine IBM was able to negotiate and obtain from ORCL a proprietary license on the OpenJDK codebase. I also hope they were able to negotiate substantial *and specific* changes in how the JCP will work in the future.

For IBM, no drama, no legal fees, no long lawsuit, just business as usual. For ORCL, a first victory in how they intend to treat the Java community. Oh, and for the other players (VMW, RHT, SAP, HP, etc.) it probably means they will have to shut-up and follow IBM “leadership” (with one possible caveat explained below).


This is really a blast against the Java community. The JSPA dictates that companies leading a JSR have to provide a license to anybody requesting it. That is the very foundation of the JCP: to create a market place where all competitors are on an equal-playing-field. Yet, in that case, SUN refused to grant such a license, providing an interpretation of the JSPA that would make laugh a 5 years old kid. Everybody else thought this interpretation was vastly nuts. Fast-forward a few months and this becomes ORCL’s interpretation.

This probably also means the Apache Harmony project just died (Yes, resources allocation and life and death of a project are indeed topics that should be discussed on a DEV mailing-list… don’t hide behind your finger.)

How can the Java community trust a leader which doesn’t stand by its own constitution?

Anything good?

So, “pragmatically”, this news announces the end of a long-standing deadlock in the Java community: we can all hope the JCP will be rejuvenated on top of the JSPA and Harmony dead bodies, that new SE JSRs will be initiated, that ORCL will start investing more resources in new JSRs, etc. That’s the best case scenario.

Yet, I have a hard time seeing how a new “JCP” can work if any JSR lead can, at any point in time, refuse to grant a license on that JSR to a competitor… What if ORCL was to refuse to grant RHT of VMW a Java EE license?

What’s next?

The only free electron that could change the situation is GOOG – and that electron is pretty excited given their lawsuit with ORCL.

Until now, nobody really leveraged that JSPA issue aggressively. Yet, GOOG could decide to sue ORCL for refusing to give the ASF an appropriate Java SE license (or help the ASF sue ORCL). I see this as the only remaining open item that could change the game. And if this doesn’t happen, ORCL will have won by KO.

Oh and obviously, it will be interesting to see what the JCP EC members will vote on the new JSRs for Java SE 7 and 8 (be ready to count the number of times the “pragmatic” word will be used in the comments section). My bet is that unless GOOG sues ORCL, the JCP EC will just “pragmatically” accept those new JSRs and send some flowers to the Apache Harmony project.


Unless GOOG initiates a lawsuit against ORCL over the JSPA, I think this is game-over. ORCL essentially tells the Java ecosystem that the good old JCP is dead, that they are willing to rejuvenate it but not at the expense of loosing control on the only FOSS JVM out there, that is the price to pay. While that might seem fair, the problem is that this is a unilateral decision done at the expense of a legal agreement signed by many.

Next time you shake Larry’s hand and he tells you “we have a deal”, don’t get too excited…

ORCL & Snow White remake: “Looking glass upon the wall, Who is fairest of us all?” November 1, 2007

Posted by Sacha in JBoss.
add a comment

Snow White LarryWhile watching this autumn’s middleware soap opera (i.e. BEA’s hunting season), I read a few articles about ORCL’s middleware business and was impressed by Larry’s ability to spin stories (given ORCL doesn’t disclose middleware-specific statistics/numbers).

Essentially, Larry keeps telling the market that he is #2 on the middleware market and is its fastest growing player.

Oracle’s middleware new license business grew 82% in the third quarter. That is in stark contrast with BEA, which grew 8% in their most recent quarter, so we are growing ten times, more than ten times faster than BEA.

Over the trailing 12 months, Oracle’s middleware business grew on average over 60%. Again, that is in contrast with BEA’s last year where they grew 12%, so that is five times over the last year, we are growing five times faster than BEA.

Oracle’s middleware business is now larger than BEA’s middleware business, or larger than BEA. It took us a long time, over five years, to catch and pass BEA, but we did it. We did it with a combination of innovation and acquisitions and years and years of determination and endurance and again, I am very proud of what the middleware team has achieved, both in development and marketing and in sales [Sacha: “but most of all I am proud of myself”].

Not only this, but more recently he explained why “his” growth type was definitively more genuine than others:

Microsoft, with their middleware, a lot of which is embedded in Windows, Microsoft being the number 1 player, IBM being the number 2 player, and Oracle being the number 3 player in middleware. We passed all the other niche players. We really separated ourselves from the niche players. BEA, we’re almost twice as large as BEA right now, BEA is shrinking in terms of new license sales. So, it’s come down to the same big three, but we’re growing dramatically faster than our competitors and our target really is to beat IBM because it’s very difficult to measure the size of Microsoft’s middleware business because so much of it is embedded in Windows.

Who is Larry’s Coué’s Method teacher? That guy must be good (and probably the same one that updates Larry on how great his Linux toy story is doing).

Anyway, truth be told, if there is one company generating MOST of its middleware revenue on embedded business, it is … ORCL. And not from some random OEM vendor, but from … ORCL itself. Just go ask people. Outside of their own embedded applications, ORCL’s monolithic AS is pretty much invisible from end-customers. So what’s going on? The most credible theory is that most of their revenue comes from (their own) embedded applications (ERP, DB, etc.) – where customers do not really care whether they deploy on one AS brand or the other; they care about the solution running on top, not about the details of the engine. When you buy a new car, you don’t necessarily care about which tires it will have by default. Same thing here => First explanation: INTERNAL CROSS-CHARGING. What’s more, in some cases, ORCL is giving away middleware licenses to DB/App customers and mark some of the cost down to the middleware rather than the database. But from a revenue recognition standpoint, both products get their share of revenue with an identical discount rate being applied.

Then, there are additional explanations:

  • GROWTH BY ACQUISITION. ORCL keeps buying middleware-related products/companies (Collaxa, Oblix, etc.). The revenue related to these acquired products directly feed into their middleware revenue and helps to hide what is the real organic growth of their core middleware offering.
  • CROSS-CHARGING OF NEWLY ACQUIRED APPLICATIONS. ORCL bought non-middleware-related product companies (Siebel, PeopleSoft, etc.) and those are now slowly transitioning most of their subsystems (management, etc.) to ORCL’s middleware offerings. Again, this is pretty much like a “forced-conversion” of their products, with no real choice on the underlying platform being used. This is accounting cross-charging, not organic growth.
  • GROWTH OF THEIR MAIN BUSINESSES. Given that their overall DB and Application business is growing, ORCL’s middleware business will mechanically grow as well, but again, it doesn’t say anything about the real organic growth of their business: this axis of growth is entirely dependent on their other “true” markets (DB, applications) and on cross-charging accounting.

Consequently, a lot – if not most – of ORCL middleware business is embedded and only growing artificially. Beyond that though, it is impossible to get actual metrics about its true organic growth.

Bottom line: BEA’s acquisition is probably ORCL’s only true way to acquire REAL end-customers.