Oracle Maintains “Proprietary” Tools Strategy

I was talking to Ludovic Leforestier from Oracle’s analyst relations program earlier this week and he complained some of my blog entries aren’t clear enough, because I tend to be quite linky, and don’t always provide all the context myself.

He referred to this entry in particular. On re-reading it is perhaps a bit too linky for comprehension, although if you read the Tim Anderson blog it seems fairly clear to me.

So I will spell it out, given I now have some more context. I talked to Cote about an open source panel at Oracle OpenWorld. It was made very clear that the Oracle JDeveloper team and associated code base is being maintained separately, and will continue to be maintained separately, from the Oracle Eclipse team.

Oracle wants Eclipse developers to deploy to Oracle runtimes, but it wants to maintain its own end to end tool stack as well, for reasons of optimisation between components, and slickness of experience. Which is fair enough. Oracle has its own economic and technical decisions to make around open source.

But next time you see Oracle on stage “endorsing” an open source toolset such  as Netbeans or Eclipse take a deep breath and go take a look at JDeveloper. You can see where the firm’s attentions (and possibly affections) lie. It is a good toolset. 

I was lucky enough to meet Steven G. Harris, Oracle vice president of the Platform Group, yesterday. He seems like a really good guy, and confirmed that Oracle is to maintain a dual strategy with respect to IDEs. But Oracle is contributing significant intellectual property to Eclipse, in the shape of projects such as Persistence, BPEL Modeling and Java Server Faces. Its making contributions and should be treated accordingly. That means reasonably. Its certainly not as if the firm is just strip-mining…

Oracle has a good relationship with Eclipse (indeed, Steven is another of the Milinkovich/Skerret OTI/smalltalk mafia…), it is contributing code and doing the right thing.

So this post is really a clarification of position. 

Where I think Oracle’s strategy has some potential limitations is in the operational management and application lifecycle space. Forcing third party tools vendors to support Oracle tooling is pushing a rock uphill, whereas supporting Eclipse is rolling a snowball downhill.

It will be interesting to keep watching this, and I will be encouraging Oracle to do more with Eclipse. Credit where its due though.

disclaimers: Eclipse is a client, Oracle is not, but paid my travel and expenses to Oracle OpenWorld.