Open Source business -
Read the following press releases issued this week and ask yourself,
do they have in common (hint --this won't be
BindView Corporation announced today "bv-Control'
for Windows 2000 priced at $795 [and that] bv-Control for
UNIX, which is available for the Sun Solaris and Red Hat Linux operating systems, is priced
Ipedo Inc. introduced the Ipedo Directory Cache
available now for Microsoft Windows NT and Windows 2000, Sun Solaris
Red Hat Linux, starting at
ProactiveNet Inc. today announced a new version of the
software. Agents are now available for Red
Linux and Windows 2000.
TeamQuest Corporation introduces its latest release of
software. The new release adds support for the
RedHat Linux operating system.
Apparently PR types think that Red Hat
Linux has become a separate and distinct operating system.
question is, are they right? And is it a problem?
What is an operating system in Linux? Or are there several? Or is
even such a thing? Is Linux really "an" operating system, as opposed to a codebase
software elements you can use to concoct anything you want (as long as
document it in detail)?
The question seems particularly relevant now that version 2.4 of the
kernel has been released by Linus Torvald et al. The kernel is a
small part of any effective Linux-based operating system; a common
does not make for a common operating system. In many cases, the kernel itself has
been heavily patched and tweaked. The inevitable result is interoperability
Sometimes all the patching is the natural result of developers
adapt Linux to architectures that it was never intended for. When SuSE
IBM or Red Hat (or whoever) announces that it has "adapted" Linux to
on a mainframe or a PDA or a toaster oven or whatever -- I chuckle to
These various devices have fundamentally different architectures, and
sorts of quite radical changes have to be made to Linux's codebase in
to generate a functioning system. It may be "Open Source" but should
results of such an effort even be considered Linux?
More troubling are commercial distributions that veer away from the
"standard" to the degree that code compiled on one distro doesn't work
another distributor's Linux. That's become an issue, particularly with
Hat 7.0. It's not really news to the more dedicated members of the
community that code compiled on 7.0 has tended to do really weird stuff
(like not run) when the resulting code is used on another version of
The result has been the one thing corporate systems people dread --
unpredictable, non-portable software.
It may be that this "fork," if it is a fork, is some sort of
aberration. As Linus Torvalds himself said, 7.0 had a "idiotic ... broken" development-quality, third-party compiler. This
of problem was inevitable. After all, 7.0 was released during the big
explosion when the resources of all commercial developers were severely
strained trying to meet the demands of their customer base and their
investors. Stuff happens. Red Hat has already announced that patches
fixes are available.
But there are lots of other niggling deviations from one version of
another, and the variations among distros have increased over time.
the release of the 2.4 kernel will spur Red Hat and other commercial
developers to make sure their products are truly compatible. However,
re-integration is not easy to accomplish. The history of software
development suggests that once a platform has begun to split away from
parents, it stays that way. The many and varied attempts of commercial
developers to re-connect their platforms over the years is instructive
Most enthusiasts will suggest that the problem really isn't
problem. After all, Torvalds has suggested that Linux code is
compromise between various contending visions and that some patching "for
specific uses" is part of the natural evolution of the code. That may
true. And it may also be true that Open source code allows would-be
adopt and re-compile code to their hearts content, theoretically
the impact of software incompatibilities.
But that's unlikely to reassure the beleaguered corporate IT manager
wants the software he bought to run on the platform he owns, and who
neither the time nor the expertise to be messing about with each and
software element in his system, or monitoring corporate listserves to
up the most recent patch to the software that he assumed was going to
when he bought it. If incompatibilities begin to become a serious
that manager is likely to either:
- "Standardize" on one distro -- in effect treating it like a
and distinct operating system, or
- Avoid Open Source software as inherently unreliable.
Neither is a good thing for the long-term prospects of Linux and
NewsForge editors read and respond to comments posted on our discussion page.