Open Source Weblog

Let’s start with Buytaert’s article (by way of Matt Asay) in which he discusses the importance of enabling different Drupal distributions to collaborate, rather than compete with each other.

“Even if we collaborate and all Drupal distributions are built on the exact same Drupal core, there will still be incompatibilities in terms of documentation, support and vision. After all, most Drupal distributions will want to provide specialized documentation and support. Being able to create this kind of value is the very reason why distributions exist,” he writes.

Compare this with what Oracle is doing with Red Hat.

“These incompatibilities can create an incentive to compete. Just look at what is happening with Debian and Ubuntu. Ubuntu began as a fork of Debian with the aim of drawing from Debian's code regularly in order to allow for frequent releases. So Debian diverged and Ubuntu was created. Now, they are driven more and more apart by these incompatibilities, and as a result, Debian risks being superseded,” he writes.

“The same is happening with Mambo and Joomla, with NetBSD and FreeBSD, already happened with Unices and Linux, and might happen with Red Hat and Oracle.”

The way in which Drupal can prevent this happening, he adds is to ensure that distributions have a shared incentive to collaborate and prevent a fork. “So here is a simple rule: don't create a distribution because you can. Create a distribution because you want to provide users a service. If you don't want to collaborate or if you can't commit to providing a service around your distribution, you are likely to do more harm than good,” he adds.

Does that sound like Oracle? It remains to be seen. In the meantime Gartner – which recommending that users take a look at Oracle Enterprise Linux – also raises the spectre of Oracle’s security patches creating a fork.

“Oracle’s intention to provide ythe open source community with patches could still potentially result in forks. For example, Red Hat might fail to endorse and patch and create its own workaround,” writes George Weiss.

Why would Red Hat do this? Because it – and not Oracle – is responsible for maintaining the quality of Red Hat Enterprise Linux, and it is responsible for deciding whether a patch in one part of the code base will break something in another.

“Oracle has stated they will make changes to the code independently of Red Hat. These changes will not be tested during Red Hat's hardware testing and certification process, and may cause unexpected behavior,” it noted last week.

Talking of quality, the first reviews of Oracle Enterprise Linux are in, and they’re not exactly glowing.

“We didn't seem to have an applications menu, at least one that worked. Every time we opened it we were greeted with a tiny grey block in place of the usual application listings. However, we trudged on and happily used the terminal to launch our programs. Not the best of starts to this Unbreakable Linux then...” writes Linux Format.

Ultramookie had similar problems: “When I click the Applications menu, there is nothing available. When I try to add an application to a panel, there are no applications available,” he writes, concluding: “Any el4 packages out there for RHEL4 which are built against the RHEL4 kernel will not work with Oracle’s Enterprise Linux. Oracle Enterprise Linux is a fork.”

Digg this