James Governor's Monkchips

Other implications of Oracle OSS deals: blue sky thinking

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Sometimes we give away too much. I kind of feel Stephen did just that with his superb take on the swirling Oracle buys everyone open source rumors. I need to feed my boy, Stephen! šŸ˜‰
In the spirit of teasing out all the implications with free analysis, I just wanted to call out a couple more scenarios to consider, and to put forward some blue sky possibilities.
How about: what Mr Fleury did next… .see below…
Stephen said:

Q: How so – aren’t they just another embedded database vendor?
A: While they’re not as high profile as a platform like MySQL – possibly because it’s not the traditional SQL based RDBMS – Berkeley DB’s a very interesting technology. As Sleepycat’s Rex Wang says in a comment to Mike Olson’s announcement post here:

We conservatively estimate that there are 200 million copies of Berkeley DB running out there. Berkeley DB is in every copy of Linux, every distro, whether it’s server, desktop or embedded. It’s also in every copy of BSD Unix, so OpenBSD, FreeBSD, NetBSD, etc. Every copy of OpenLDAP and sendmail uses us. Every copy of OpenOffice and StarOffice (Sun estimates 40 million are out there). 3 million Motorola cellphones. Many copies of Movable Type, Subversion and Apache HTTP server.
To my mind Derby just got all its birthdays at once. The “database in a jar” is still really truly open source, under Apache’s stewardship, and its a developer favourite, certainly in the Java world. well from an open perspective, Sleepycat is now going to be “under suspicion”.
Stephen said:
Q: How about Zend as a lever against competitors – are there opportunities to exploit there as well?
A: Potentially, although in a less direct fashion then say the pickup of JBoss might allow. IBM, for example, was quicker out of the gate in seeing the opportunity around PHP and partnering with Zend than was Oracle – but might Oracle pull the rug out by taking the next step?
I think we could see IBM go full bore behind Ruby On Rails if Oracle acquires Zend. If Big Blue wants to go simple, and start eating its incredibly complicated babies, then why not bypass PHP and drive full bore behind “convention over configuration”? By next year everyone will be saying how PHP is a nightmare to debug and manage anyway, in comparison with the elegance of RoR. If PHP is the new Java, and Oracle is buying in, then IBM could disrupt thing signiificantly. Why not make a really absurd offer for 37Signals and join the world of lightweight software as a service in earnest? What do you mean you don’t sell applications – those are productivity tools…
So what about JBOSS?
Stephen says:
Q: So you don’t believe that Oracle can, in effect, buy the respective JBoss (and associated communities where it employs devs), PHP and Berkeley DB communities?
A: No, I don’t. It’s not really a question of licensing (JBoss is LGPL, PHP is BSD, and Berkeley DB uses the OSI approved Sleepycat Public License) – or forking (Sleepycat, for example, owns their IP which why they are able to dual license their product), it’s more a question of community dynamics. The attractiveness of the above projects is predicated not solely on their technical merits – maybe not even primarily – but on their popularity. If any vendor thinks that it can uniformly impose its will on a large scale community of developers, they’re in for a surprise. Those developers, in most cases, have alternatives they can and will turn to – Geronimo in the case of JBoss, Ruby/Python/Perl in the case of PHP, and a variety of datastores with respect to Berkeley DB – should they begin to get the impression that they’re being pushed around.
To my mind the most interesting aspect of a JBoss acquisition is likely to be the Fleury effect.
Marc Fleury and Larry Ellison working together would be a sitcom I would pay very big money to see. Marc is a maverick. He makes Scott McNealy look like a company man.
Larry on the other hand is not exactly known for giving his managers a lot of independence. So if Marc leaves, who else does? Most of the team I suspect. Would that matter? Sure it would. These are very smart developers, more productive that your average corporate dev.
In drilling down into JBoss its also important to note the potential for broader collateral damage. JBoss is not just a JEE player anymore. It has devs across the JEMS portfolio. We’re talking different portlet structures, approaches to persistence, process modelling subsystems, business rules engines, message queueing. Portfolio rationalisation is going to get really ugly really fast.
What do I think might happen? Marc might go off to create a very well funded aspect oriented programming company, and takes many of the lead Jboss developers with him. Or this could work itself out, and Marc and Larry will become firm friends…


  1. I’d love to agree with you on the 37 Signals thing but where is the ‘enterprise’ in that?

  2. I think you’re a lot closer to what might happen than Stephen – whose analysis by the way sounds plausible but I think underplays the cultural angle. As a start, I’d suggest making sure the Sleepycat lot are housed anywhere except Redwood Shores and are managed by John Wookie – if that’s a role John could fill.

    The IBM angle is interesting. Frankenstein’s monster meets msall but perfectly formed baby…

  3. good point dennis, for sure, but I would argue for IBM to succeed and more importantly grow (to shareholders and Sam) in the long term without a broader set of consumer touchpoints. POWER chips in game machines is goodness, but IBM needs more of these examples since it left the PC market. as enterprises boundaries break down and the work-life balance becomes more porous i would argue the whole definition of enterprise is up for grabs. does dennis howlett have some enterprise requirements? does redmonk? absolutely. but that doesn’t mean we necessarily want to buy the IBM Software stack. is Google enterprise software? if it is, 37 Signals is.

Leave a Reply

Your email address will not be published. Required fields are marked *