Sun, Oracle and the need for open source… [updated]

Times are changing it seems: Not that long ago we were wondering about whether or not IBM eventually would buy Sun Microsystems and, if so, what this could possibly mean to many of the pretty good Sun software products like the NetBeans IDE, the Glassfish Application Server or the mySQL database server. Oh well… and it seems that, just shortly after these negotiations have obviously come to an end, another player does appear on the scene with database / enterprise software giant Oracle finally acquiring Sun. And, yet, I think we will have to see whether or not this is better than the IBM option. Eventually, there are products and projects likely to benefit from this merger, like all the Sun hardware stuff and the (Open)Solaris operating system which will allow Oracle to enter a whole new market in which they by now still depend upon other companies (hardware manufacturers, operating system vendors, …), and there are products which eventually aren’t on grounds that safe (mySQL, Glassfish, maybe also NetBeans).

I will keep myself from speculating aloud which of these projects might be continued and which ones might be stopped sooner or later, but rather want to come up with another thought on this: Product strategy. I know quite some people who chose the BEA WebLogic Java EE server for various reasons (including not depending upon a global “software super power”) and were quite happy with this. Some time earlier however, BEA also was acquired by Oracle, and even though Oracle product managers decided to discontinue their own application server in favor of WebLogic, these customers by then still ended up being customer of a company they never wanted to work with. Same way, some of the BEA products simply were discontinued, like some of the Oracle ones, in favor of having migration paths offered to alternate products virtually replacing them. This also might not always be desirable as, even though having a migration path available is a good thing, eventually one doesn’t want to migrate as product decisions also might have happened out of technical preferences for the product initially chosen – from that point of view being forced to migrate to something you didn’t initially choose for sane reasons doesn’t seem all too compelling.

So, after all: How to get out of this mess? How to be capable of doing sane strategic product decisions without having to worry that, sooner or later, your product might be discontinued in favor of another one after some company, service provider, … has been acquired by someone else? For that, I see just one solution really practicable: Go for Open Source software, and not just for sofware being open source but also for software being open source and maintained, developed, driven forth by some kind of foundation or consortium rather than just being a former product released under an open source license but still developed and maintained mainly by one single vendor. Examples for these things include:

So, overally, what to learn from all this mess:

(1) Despite all dedication, keeping a little independence pays off from time to time: Using maven2 as build tool, so far we really did enjoy the clean, usable, straightforward tooling NetBeans offers for this tool, while at the same time making sure our source structures and projects aren’t tied to the IDE like, in example, they would be while using stock Eclipse projects. From that point of view, in worst case we even could go on doing development work with a tool as simple and straightforward as jedit comes the need. Likewise, keeping applications as compliant to Java EE standards (and as independent of a given Java EE implementation) as possible will, assuming worst case (which is not what you do as a technology enthusiast but definitely is what you gotta think about when you have to make strategic decisions) ease migration to another target platform. Both things aren’t on our list at the moment however, and hopefully they’ll never will. The Glassfish/NetBeans tool chain is way too convenient and powerful to be abandoned without a fight. 😉

(2) Generally, even though (in worst case) the Oracle/Sun merger might change things for people so far into using Sun-contributed open source projects, there still will be alternatives at hand, if they don’t want to go with the offerings Oracle by then will be providing to them. This is, of course, a good thing as it makes dealing with the uncertainty obviously caused by such a strategic (corporate) move a little easier. And, after all, being acquired by some “strong” company still might be the best to happen to Sun given the current business situation of the company in order to let at least part of its technology survive (I will contribute more time to using OpenSolaris from now on).

(3) Despite their brave moves in releasing a great set of technology under open source licenses, it overally seems Sun didn’t completely “do this right” in the end. I remember that, a while ago, another good Sun-based open source project, the JSF component collection labeled Project Woodstock, after a period of silence and uncertainty for its adopters ceased to exist, now “just” offering a migration path to IceFaces JSF library. For quite a while it seemed there was just an awful load of open source projects appearing on the scene, providing great technology yet leaving users unsure about the actual nature of its community: How many people are there actively developing it, how many of them are full-time Sun employees and how many are open source volunteers and/or employees of partnering companies, how many of them are enthusiasts and small-time developers? Who does make strategic decisions about project roadmap, new features, …? Who, overally, has to decide what to be done and what not to be done? This, in my opinion, is the worst to add to the momentary uncertainty about Glassfish, NetBeans, … despite the fact of these all being open source projects: Of course, being by its very nature open source projects, they don’t generally to depend upon a very company to survive, virtually anyone could to a fork and drive forth development on her/his own. But yet, at least to me it’s absolutely unclear what will remain of, say, Glassfish in case Oracle might decide to suddenly withdraw all Java EE developers in order to make better use of them in any of their existing Java EE related projects – will there be anyone left to keep up developing an “open source Glassfish” without Sun? From that point of view, there would have been a better way initially if Sun just had made, say, java.net an open source foundation similar to Apache, Eclipse, …, contributed all of its open source code to this foundation and aggressively invited third party corporate and freelance developers to contribute and participate. This, asides all other business implications (like matters of education and support offered for these technologies) at least would have made things easier by having these projects “safe”, their technical development and progress reliably outlined no matter what eventually would happen… Then again, maybe it’s not yet too late for… Apache NetBeans? Codehaus Glassfish? O’w2’penDS? What are your thoughts?

Anyway, after writing all this text, what are my personal conclusions of this? For now, I will keep sticking to “business-as-usual” of course, keep on promoting the use of NetBeans, Glassfish and related technologies. From my point of view, they’re way too valuable to be ignored and abandoned without too much ado. Especially relating to NetBeans, there’s quite a clear road ahead, with 6.7 development nearing its end, providing an impressive list of changes and other things noteworthy compared to its predecessors. Along with this, we’re also at the moment trying to, as seamlessly as possible, take the NetBeans Community Docs project to a new shape, structure and performance, hopefully making this a resource valuable to the NetBeans community as a whole. As for anything else… time will tell. Maybe “being prepared” never is a bad thing, being prepared both for keeping everyday business going and, given this might be necessary, participating in one fork or the other…

Update 2009-04-22: As there are quite some people (obviously) dealing with this issue, I have decided to collect some of these resources that seem worth reading to me here:

Leave a Reply

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