Our friend Jonathan Schwartz has a blog (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 of it.

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.

Jonathan's blog entry on this subject confuses the issue of what an open system is really about. He confuses the issue by referring to an 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.

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 was possible.

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.