From: wierda@ltb.ltb.bso.nl (Gerben Wierda)
Newsgroups: comp.unix.questions
Subject: Open. (was Re: more OSF/1 vs SVR4 (text))
Date: 16 Apr 92 08:22:42 GMT
Organization: BSO/LT, Baarn, The Netherlands


The ``open'' issue.

There are several definitions of open:

	1. binary compatibility
	2. source code compatibility
	3. connectivity
	4. availability of applications

1. This is the old "is it IBM-compatible" thing from the PC world. This is
compatibility on a hardware level.
2. This is what most unix-based/oriented standards are about like POSIX. Note
however that for instance POSIX only defines a small part of what is really
important for usable applications.
3. Networking issues. Can I run TCP/IP, Novell, NFS, etc.
4. Availability. Can I run Wordperfect, Lotus 1-2-3, AutoCAD....

There are more definitions. there are as many definitions as speakers on this
issue.

Everybody claims to be open. Even DEC nowadays advertises with 'open systems'.
DEC is a good example. They used to use 4/3 to claim openness, nowadays they
are shifting to 2 (Open VMS is POSIX compliant).

The point that is hardly mentioned, however, is that 'open' is of limited use.
First, vendors will try to be unique, wjatever standards. We are still far
from the PC world where only price/performance of the hardware counts. In the
Unix world we are still fighting over the software. The battle CP/M - DOS was
fought (and won by DOS) long ago. Open is the opposite of a monopoly. Open
stands for the availability of independent second sources. 

Vendors normally don't like being open. Open means more competition and less
lock-in of clients, hence lower prices. Users like open for the same reason.

Pitfalls.

I am not going to repeat am article I wrote for a magazine a while ago, but
note this: An application that runs on a POSIX-compliant machine is not by
definition a POSIX-application. If I write an app on a POSIX-VMS I can use all
the VMS specific things I like (and I will possibly need to do that to get it
working anyway). So if I look at POSIX-only applications (which are fairly
useless since POSIX is fairly limited) I can choose a lot of `open' systems to
compileand run it on. If I write an application using The NeWS Toolkit on a
Sun, I'm as open as using NeXTSTEP on a NeXT. Funny thing last happened: I got
the Adobe ref manual from SUN when I got Open Windows 3.0. It describes Display
PostScript (DPS), but not SUN's enhancements that turned PostScript into the
thing they used for TNT.

The perfect 'open' machine is a perfect clone of whatever dominates the
market. It will not contain any surprises. Not for bad, but also not for good.

Using any non-standard `goodies' that come with your open system and that are
not part of its standards-foundation will immediately make any advantage of
using your `open' system almost nil.

A word on NeXT.

	I think NeXT is one of the vendors who has really understood this.
They have the most intelligent statements on openness. They have a hard time
marketing their ideas, since the public normally does not think farther than
the word 'open'. 

Their idea is:  

1. use standards when necessary (TCP/IP, Novell, Ethertalk, NFS, ANSI-C, C++,
	BSD 4.3, DOS file format, Macintosh file format, PostScript) or have
	them available from 3rd party (X, DOS)
2. make a better solution where standards don't work out (Objective-C,
	NeXTSTEP)

	And they are flexible too. They adhere to standards they think that
have become important. They also make mistakes, like the Magneto-Optical drive
in the first machines.

A word on SUN:

	I like Sun hardware. I don't like their software that much. And I
definitely hate what they are doing now. (No compiler in Solaris 2.0 for
instance).

A word on GNU.

	If you want open: use GNU (when it is available).

-- 
wierda@ltb.bso.nl (Gerben Wierda) || I speak for myself and not for my employer.
(+31) 2154 84415/(+31) 35 833539  || Support the League for Programming Freedom!
	"If you don't know where you are going, any road will take you there."
	Lewis Carroll, "Alice in Wonderland".
Newsgroups: comp.unix.questions