The Wonderful World of Open
~ by Philip Peake
Our friend Jonathan Schwartz has a
(if you didn't know). In a recent entry he discusses "open"
as applied to computing and attempts to put his spin on what
the word open really means.
I think he misses the point. So let's take a look at what open systems
are all about, their history and meaning.
Do, please, note though that Open Systems and Open Source are not the same
thing. Open Source was alive and well at the time that Open Systems were
first defined, with Richard Stallman's GNU project and the USENET comp.source
group both providing an array of Open Source for those that wanted to make use
Virtually all of my professional life has been working with Unix.
From my first Version 7 copy running on a PDP11/34 to the present day
with Solaris running on Sparc and Linux running on a variety of systems.
(I will also hang my head in shame and admit to having run Microsoft
systems, from Dos to WinXP-SP2).
I have been involved, sometimes directly and sometimes peripherally with
the evolution of Unix and standardization efforts around it during that time,
and so can claim to have at least some knowledge of the subject.
entry on this subject confuses the issue of what an open system is really about.
He confuses the issue by referring to
article by David Kirkpatrick, writing for Fortune,
and claiming that this article suggests that
"open" is really defined by the degree to which
a vendor seeks interoperability with other vendors' products.
This isn't exactly how I read the article. David Kirkpatrick clearly
differentiates between the open and proprietary worlds, but he suggests that
what really matters is the completeness of the whole solution,
how well the components work together, and that better profits appear
to be associated with the proprietary model. He also suggests that this
is the direction that Linux is being dragged by Red Hat adding proprietary
software to its distribution.
Jonathan's view is that "open" is really in the eye of the beholder, and that it means
the ease of substituting one product for another. Well, that is one definition
of "open", but it is certainly not the definition of an Open System, and not one that
I have heard before. Jonathan appears to confuse
"open system", "open source", "open standards" and a few other "opens" too.
Open systems came into being following the balkanization of Unix caused by
the AT&T/Bell labs (System3/System5) and BSD camps. These Balkan states were then further fragmented
by the efforts of various Unix vendors to "improve" Unix by adding their own
proprietary extensions. Independent software vendors (ISVs) found that code written to
any given Unix variant was a real pain to port to another, and the incremental costs
associated with maintaining each port soon became prohibitive.
There were several attempts to define a common API and utility subset by different groups, but that
was a problem in itself -- there were several attempts. In addition, there were attempts
by various commercial interests to insert standards into those efforts which validated
their products and excluded competitors. It took a formal standards organization, IEEE,
to accept the task and to create the POSIX standard before any level of standardization
Now POSIX only addresses basic operating system functionality and APIs. But this was enough
to enable ISVs to create applications with many less differences across Unix systems. The idea
behind POSIX was never that this would completely define every possible thing to ensure
perfect compatibility between systems, only in the areas covered by the standard.
The standard was general enough that non-Unix systems were able to implement it, for example,
VMS from Digital (DEC).
This meant that applications targeted at the POSIX standard were now potentially
candidates not just for Unix systems, but for a range of systems, all
of which implemented the POSIX standard.
Because it was possible for non-Unix systems to implement POSIX, the generic term "Open Systems"
was coined. This was intended to cover systems which no longer has proprietary interfaces to
system services, but which implemented interfaces covered by an openly available standard. Programmers
could develop code independently of the OS, following only the openly available interface definitions.
As an interesting side note, POSIX was so successful and resolved so many of the
problems with vendor lock-in that the US government set procurement policies requiring
POSIX conformance for any new computing systems. When Microsoft came out with NT, which was designed
and built by the chief VMS architect from DEC, it too included a POSIX conformant subsystem.
However, this subsystem was virtually independent of, and isolated from, the normal Windows
environment other than being able to see the same filesystems and networking.
Only the most trivial applications from either environment could successfully execute in
the other environment.
Microsoft never produced any applications for this environment that I am aware of and never encouraged ISVs
to do so either. The POSIX subsystem apparently was purely a ploy to get around the US procurement policies.
By any reasonable interpretation of the spirit of POSIX, this did not make NT an Open System.
Now Jonathan is actually correct that by this definition Solaris is an open system. It is. It
is POSIX conformant. Beyond that, it actually implements a range of other published open standards,
such as X3J11 for the C language. Source code availability has nothing to do with a
system being an Open System or not.
Jonathan goes on to say:
Let's instead look at what it takes to move off Solaris, and onto, say, IBM's AIX.
How easy is the move? It's not particularly easy. There are features in Solaris, like the
Java Enterprise System Directory Service, N1 Grid Containers, dTrace or ZFS that don't show up
in AIX. Nor is there an industry agreed upon definition of Unix to enable a neutral test, or a
certification, of what you're using. There was, it was called POSIX, but then all the vendors
(Sun among them), went well beyond POSIX in delivering operating system distributions - we added
app servers and directory engines and web services infrastructure, innovations that saved
customers millions of dollars, and tons of effort. But using those features made it difficult
(but by no means impossible) for customers to substitute Unix vendors - and as IBM slows AIX
investment, Solaris is bound to leapfrog even further. So is AIX open? Does it promote choice?
Well, by that sword, is Solaris? Or moreover, Red Hat?
What we have here is a perfect description of why you should never use any
of those proprietary extensions that Sun has bundled into Solaris, unless you clearly understand
the trade-off in doing so.
Actually, most of what he lists isn't available to most Solaris users anyway, unless they upgrade
to Solaris 10, which makes the list just a little bit disingenuous, and also brings up the question
of why is Sun adding these non-standard technologies rather than turning them into open standards,
either via existing standards bodies, or via open source. This couldn't be to lock users into
Solaris could it?
Picking fault a bit more, the Java Enterprise System Directory Service (which would otherwise be
called an LDAP server, if Sun's marketing team hadn't become involved) really isn't a required part
of Solaris anyway. It will run happily without it. It also contains some specific extensions, so although
it is an LDAP V3 server, you find that for use with much of the rest of Sun's software stack, you can't
simply replace it with an LDAP V3 conformant LDAP server, because that software requires the specific
extensions to work fully, or even work at all.
It's this pretty-much deliberate lock-in that is the problem.
Although by the definition of Open System being equivalent to POSIX conformance,
Solaris makes it, by the spirit of Open Systems, Sun fails to make the grade.
Sun has a long and distinguished history of contributing to and promoting Open Systems,
Open Standards and Open Source. Not so very long ago, a Sun workstation was what a Linux system is today,
a reference platform for just about any free software/open source available. If it wouldn't compile on
a Sun workstation, it wouldn't compile. Sun worked on technologies intended to improve its competitiveness
in the market, but also took the time and effort to make certain that its protocols were well documented
and the subject of relevant standards, remote procedure calls and NFS being perhaps the most obvious,
and still widely used today.
Sun was an active participant in the POSIX standards process, not only because they saw it as key to
commercial success, but because they believed in the Open Systems philosophy.
Perhaps it's time to revitalize the Open Systems movement with something like POSIX II to include
all developments of the last 20 years. It seems to me that Sun has a lot they could
contribute to that effort.