• E-mail this page
• |  Print this page
• | 
• | 
• | 

Open Sources, Open Notebook: Why Oracle Should Worry

Will open source databases make incursions into Oracle? Not likely. That's the view that extends far outside the circular towers of the Oracle campus. Consider, then, the experience of Jason Weiss, software architect at national florist supplier FTD. He thinks Oracle should be worried. Actually, he said, "terrified."

FTD supplies flowers and other goods to 200 wholesale flower distributors, and those distributors want to see what orders are flowing into FTD, what flowers they should stock, and what their cash flow looks like on any given day. They rely on FTD's central Oracle database and financial systems to provide them with that information.

Because of the heavy reporting requirement, FTD ran into performance problems this past Valentine's Day, and Weiss decided to off-load the reporting to a secondary database system, removing stress on his transaction system. He had six weeks to do so before the build-up started for Mother's Day, FTD's biggest holiday of the year.

His choice for a reporting system was EnterpriseDB, a commercial system based on open source PostgreSQL. EnterpriseDB understands Oracle's PL/SQL, stored procedures, and triggers, so FTD's Oracle applications migrated relatively easily to EnterpriseDB. The new system was running within the six-week time frame Weiss had allotted before the Mother's Day traffic hit. Weiss and associates got an ovation from the FTD executive committee when he reported on IT's Mother's Day performance.

There were several reasons for the change, but one was price. Weiss said another Oracle license would cost $125,000 vs. $20,000 for EnterpriseDB. "We're an Oracle shop," says Weiss, "but it's going to be very hard to make a financial case for another Oracle database system."

Weiss is will adopt EnterpriseDB for his next database application and says he can see using it in production for his next two projects. The experience of moving off Oracle to a PostgreSQL product was an eye-opener. "Oracle should be terrified," he says.

Indeed, it can be argued that Oracle's acquisition spree is a bid to escape the likely consequences of improved open source databases. By making application logic the focus of the company, Oracle moves up the food chain to a product that's harder to match through open source code. Still, FTD is a solitary voice in the huge Oracle customer base.

Too Many Linux Distros? Ha!
Are there too many Linux distributions? This recurring discussion sometimes confuses key patterns of behavior with Linux. It asserts that each Linux distribution is a fork of Linux, which makes Linux just like Unix, going off in multiple directions. Ah, Linux is different than Unix.

It's hard to explain the self-sustaining creativity, discipline, and self-governance of open source projects. If the rules governing the community are not laid down in tablets of stone, then I guess some people assume there must be no rules in play and upheaval is imminent. Somehow, for Linux, chaos is always just around the corner, but it never actually arrives.

Linux has not forked and probably won't fork for two key reasons.

One is that there is unity among Linux distributions about adopting a common kernel. That's the work that Linus Torvalds and the kernel contributors, such as Andrew Morton, lead. Red Hat, SUSE, Ubuntu, and all the Linux distros heed it. These distributors know they go their own way at their own risk. So the many distributions have a shared core of operations. With Linux's modular design, software packages around the kernel may vary and do, but the kernel behaves the same across applications.

A second reason has more to do with the rate of innovation and adoption of key, successful open source projects. It's hard to duplicate all the effort going into Linux to create a competing fork. Even starting with today's code, freely available, a competing project would soon be left behind by all the group activity of the main project.

Those who fork also need to convince the larger community that there is an overriding need to create a fork. If they don't command this moral high ground, they will not gain widespread adoption and support, and the effort they're pouring into their fork will go for naught. When it comes to Linux, woe to the pretender who says he commands the ground above Torvalds.

I know of one open source project that forked with justification, the Gnu C compiler, and achieved widespread adoption in the developer community. The pain engendered by that fork is one of the hidden reasons there's still tension between the originator of the Gnu compiler and other free software, Richard Stallman, and the larger, more pragmatic practitioners of open source development. The Free Software Foundation eventually adopted the fork and distributed it because its rapid advance had won wide acceptance among software developers.

I know of a second project that forked, the JBoss Application Server, with former JBoss developers producing Apache Geronimo with a different design and enjoying limited adoption. But Geronimo still eats a lot of JBoss dust. There are probably more forks, but I know of only two projects -- out of hundreds of thousands -- that can be described as having forked with the fork still alive. Show me a Linux fork and I'll show you a project busily writing, not code, but its own epitaph.

« China Weighs In On Its IT Security Challenges | Main | Forget Harry Potter: Books We'd Really Like To See »