Hudson/Jenkins – some more context and thoughts January 12, 2011Posted by Sacha in CloudBees, English, IT.
Tags: DEV-at-cloud, Hudson, Jenkins, ORCL
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.
add a comment
While 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.