Wednesday, July 25, 2007

The dangers of depending on a vendor and the power of an open community

When recently commented that IBM has bought DataMirror and thusly Pointbase, I failed to mention some very amusing history around this, and how this illustrates a very important issue around the dangers of using third-party code.

Some of you may remember that the original Reference Implementation of Java EE that Sun shipped included a copy of Cloudscape. I remember using it at a previous job and really enjoying the simple yet powerful database that came with the RI.

Then IBM bought Informix, who had bought Cloudscape. Now, we're all friends here, but let's be honest, Sun and IBM are competitors. I wasn't involved in the decision, but I suspect that Sun was uncomfortable licensing some pretty key technology like this from IBM.

So Sun found Pointbase, a tiny little company with a nice little Java database, negotiated a license, and replaced all uses of Cloudscape with Pointbase. Sun also started shipping Pointbase in their tools products.

Some years later, Sun decided to invest in Apache Derby. For those of you who aren't keeping score, Apache Derby got it's start when IBM contributed of Cloudscape to open source.

Well, having a database that you can use free of charge, open source, and which you are actually investing engineering resources in, is clearly better than one you need to license. So Sun decided to replace its uses of Pointbase with Java DB (Sun's supported distribution of Apache Derby). In other words, we put the same database back in that we had pulled out years before. Sigh...

And now, if that weren't ironic enough, IBM has acquired DataMirror, which owns Pointbase. My my, this does sound familiar :) But this time, Sun was not caught off guard, and we are not in a position of yet again licensing a key component of our software solution from IBM.

And this leads me to the moral of the story. When you depend on software from a single company, you run the risk (actually, I think a pretty high risk) of that software ending up being owned by a competitor.

If what you are licensing is a key part of your product, you may find yourself over a barrel. The competitor may discover that they have their hands on some pretty nice puppet strings, and they may choose to start yanking them. Oh, did you want that Very Important Feature? Oooh, that's going to cost you... I'm not saying that IBM would ever do such a thing, nor Sun, of course! But it sure is an uncomfortable feeling to find yourself in this position.

Even if the company you are licensing from is never acquired, the existing company may recognize that it is deeply embedded in your product portfolio, and start asking for more money. Ask anyone who is invested in and committed to Oracle or Microsoft, and you'll likely hear an earful about ever-increasing license costs.

These rules still apply in the Web 2.0 world. If you're building a mashup solution that depends on technologies solely owned and controlled by a single company (even if they swear they Do No Evil), you are putting yourself at risk. This is especially true if you're placing your data under their control.

This issue is a very real concern for governments. A lot of governments don't like the feeling of licensing or otherwise depending upon key components of their solutions from companies that are situated in (and governed by the laws of) countries they are not fully comfortable with. This is one of the key reasons why so many governments are mandating the use of open source software.

But you have to be careful what kind of open source you are using. As an example, a lot of companies rely heavily on MySQL. MySQL is open source, but you must be a MySQL employee to commit to the code base, and you have to purchase a license from MySQL if you want to redistribute it. At some point somebody could acquire MySQL (note that Oracle acquired InnoDB, a key component of MySQL), and you may find yourself in the uncomfortable position of licensing your database engine (and if that's not key technology, I don't know what is) from your competitor. Alternately, MySQL may decide to start increasing license costs more and more over time, and you'll have no choice but to grumble as you pull out your wallet.

On the other hand, Apache is an independent non-profit organization that is not up for sale. Apache projects are required to have committers from at least three independent organizations before they can exit incubation, so no one company can exercise absolute control over an Apache project. Apache projects also go through a very strict inspection during incubation to make sure there are no legal encumbrances on the code.

Similarly, PostgreSQL is managed by a non-profit organization and has committers from many different companies and independent developers.

For these reasons, if at all possible, I would much rather base my product on Apache Derby or PostgreSQL than on a product owned by a single vendor like Microsoft, Oracle, DB2, or even MySQL, even though MySQL is an open source product.

So, think carefully when licensing key software from a third party, and take a good hard look at open source/open community alternatives, even if they aren't as perfect a fit. Sometimes it is the right choice to purchase a license, but you should walk into the deal with your eyes wide open to the potential consequences.

No comments: