Curt Sampson writes:
> On Tue, 26 Dec 1995, <netbsd@vu.com> wrote:
> 
> > if the various *BSD factions would rather be "right" than cooperate,
> > *BSD is history.  Linux will consume the programmer-oriented OS market,
> > Windoze gets the luser share, and Sun/Dec/...  keep the workstations,
> > at least for now.  *BSD becomes a footnote in technological commentary
> > describing the effect of schizmogenesis amongst software developers.
> 
> What rubbish. Why everybody thinks that there has to be some sort
> of `competition' in the free OS `market' where only one OS `wins,'
> and why three BSDs are considered `fragmented' when they differ
> less than any three Linux distributions out there, I don't know.

There are significant differences between the three versions for
commercial developers.  For example, that's why we have a BSD/OS Motif
implementation, a planned (in progress) FreeBSD Motif implementation
and we do not have a NetBSD Motif implementation in plan.  We have a
Linux a.out and a Linux ELF Motif implementation and they work on
pretty much all Linux distributions, so long as the installation
procedure covers the distribution - this is an "incremental problem"
that can be covered by improved documentation and is solved by
Technical Support in the interim period, so it is quite different
from a binary difference.  The *binaries* are the same across all Linux 
distributions and kernel versions from about 1.0.8 to 1.3.30-something.  
We will eventually be able to stop the Linux a.out product generation 
when old stocks of CD's in University bookstores and other places are 
depleted.  At the current rate, by the time that we exhaust the Linux 
a.out product cycle, we'll probably have to add a fourth BSD derivative 
binary format ;-)

The significant problem(s) for us, are that every new binary format
requires significant OS-specific testing.  We avoid this in our X
Server by making the chipset modules OS-neutral.  That way we can
compile once and test once on any OS and know that the fix will work
on all OS's.  We make the OS-specific part a dynamic linker that also
handles certain OS-specific core functions, and we have to test that
extensively whenever we change it, but it is relatively limited in
function compared with the chipset support, so it is easier to test.
This solution is not available for any kind of development product,
because that must be delivered with OS-specific libraries suitable
for the linker, and because a complete OS-neutral API is still one of
the Holy Grails of computing - it is not something that we're likely
to solve in the near future.  Stuff like Motif has to be compiled 
on each OS, in each supported binary format on each OS, and it has to 
be tested on each OS, Support have to be trained for the OS specific
variations in the compilation environment, install procedures, OS
specific documentation has to be prepared, etc.  If there is 
insufficient order volume to justify that work, we do not port.  That's 
why we do not have a NetBSD port planned - if we see the volume to 
justify the work, then we will do it.  Yes, that does mean that we still 
see more demand for Linux a.out format than we see for NetBSD.  We can't 
help that, it's just the pattern of demand... 

So, claiming that there are fewer differences between the variants of
the BSD OS's than between Linux distributions, is fallacious for at 
least one class of user.  I know that some of the BSD users count 
success as being the availability of commercial applications... and by 
that measure we get significantly less return for our effort on the BSD
OS's than we do on Linux.  That translates directly into which products 
we port, for each OS.  And that translates into at least one measure
of success for the BSD variants and the major obstacle to their
initial and continuing support by commercial developers.

If you want the BSD versions to be better regarded by commercial
developers, then binary format compatibility is useful... but the
true measure will be when a single binary and library format is useful 
so that the commercial developer does not have to care which OS is in 
use.  The same sets of library features and bugs and kernel functions 
and bugs must be present in each.  That translates directly into 
reduced porting costs, testing costs, support costs, etc.  This will 
only works if there is a commitment from the core team members to 
maintain compatibility and to correct defects that appear in one OS and 
not in the other.

Otherwise you end up with the situation common in the commercial UNIX
environments on Intel.  For example, you buy UnixWare because of the 
SCO compatibility, run a SCO application and observe a problem.  You
report the problem to the commercial vendor, who asks which rev of
SCO UNIX is being run... and when they hear that it is not SCO UNIX,
you are told to replicate the problem on SCO UNIX and call back when
you can do so.  I'm sure that neither NetBSD, FreeBSD or BSDI will
want to yield the high ground of compatibility, which is why I'm also
fairly certain that is hopelessly utopian to expect a single,
mutually agreed executable format and library format and kernel
function set, will be agreed in the BSD camps.  I have every
confidence that OpenBSD or some other derivative will decide for
sound technical reasons, that no other format is correct and they
will create the definitive, correct execution format... and then
decry the lack of commercial products and that the users will demand
that all commercial applications available for other BSD
implementations must be immediately available for the new format and
at no extra cost over the Linux version of the product...

The other big problem for commercial developers is the extraordinary
rate of software piracy on free OS's.  Many users seem to think that
because the OS is free, even commercial developers are somehow able
to avoid paying for phones, office space, etc... or perhaps they
assume that the banks will take copies of the free OS in exchange? :-)
Whatever, through a quirk of our software, we've been able to detect
significant piracy (beta versions of our product email a bug report
when the Server crashes).  There is a considerably higher rate of
dishonesty amongst users of free OS's than of the commercial OS's.
This was a concern for us, and we know of several companies that are
refusing to port software, for fear of the lost income from pirated
copies.  When there is a relatively small market, and a high
perceived loss of revenue from piracy, it is the exception, rather
than the rule, to find a company porting and supporting commercial
software.  Increase the market, by reducing the binary format testing
complexity, and you decrease the relative importance of those fears...

It would also help if the NetBSD core was a less abrasive group to
work with.  Jordan and the other members of the FreeBSD core with
whom I've had dealings, have been unfailing in their willingness to
help identify and solve problems with FreeBSD commercial
implementations.

NetBSD is not uniquely singled out for us to not-port products.  We do 
not have Motif 2.0 implementations for Solaris/x86 or SCO or Interactive 
or UnixWare, for example; if there were significant demand, we'd do those 
ports.  There are similar reasons for not-porting OpenGL, XVideo, etc
to various platforms.  The basis for selecting what we port, is
derived from basic sales of the Server and the customer expressions
of interest in other products.

Note that we do find NetBSD of sufficent interest that we monitor the
news groups and mailing lists...  We just need to see the orders to
justify more product porting effort ;-)

Cheers, JeremyC.
-- 
Jeremy Chatfield  +1(303)298-7478  FAX:+1(303)298-1406  email:jdc@xinside.com
        Commercial X Products - for more information please try:
        X Inside Inc, 1801 Broadway, 17th Floor, Denver, CO 80202
http://www.xinside.com/        majordomo@xinside.com          ftp.xinside.com