Subject: Re: Exploring the limits of free software: Cygnus, and GPL
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Wed, 26 May 1999 13:53:38 +0900 (JST)

>>>>> "Ian" == Ian Lance Taylor <ian@airs.com> writes:

    Ian> I'll note that I don't think the free software community has
    Ian> yet shown itself to be very good at creating new standards,
    Ian> in the sense of clearly documented interfaces which other
    Ian> people can write code to.  Free software standards, such as
    Ian> they are, tend to be defined by an implementation rather than
    Ian> a specification.

No free software people writing RFCs?

Linux's FSSTND and the more general FHS?

The Debian and RedHat package managers?  Do a "ls | wc" on the
contrib/ directory at ftp.redhat.com.  Even really bad programmers can 
write to that interface!  %-P

What's CGI?

Did you see Cox's comment about adding the whole IrDA interface at the
Linux 2.2-pre4 (or so) stage?  It went something like "you may be
wondering why I approved addition of an entire subsystem during an
alleged `feature freeze'.  Well, the impact of this contribution on
_all_ of the other code was three lines, two of which were `#ifdef
IRDA' and `#endif'".  If that's not "in the sense of clearly
documented interfaces which other people can write code to," what is?
Sure, it doesn't make the port of the IrDA code to *BSD easier, but is
that really a show-stopper?

Why do our standards have to be mutually exclusive with proprietary
ones (POSIX, Postscript)?  Little contribution to Postscript, I
suppose, but surely the folks at Cygnus and many free software
contributors with relevant day jobs have made important contributions
to POSIX.

Perl (the language, cf. Wall interview in recent Linux J), Python?
Perl is a classic example of "implementation-defined" but a lot of its
evolution has been according to classic patterns of standard setting.
Note that in open source, it's likely that this kind of endogenous
standard-setting will be very effective, although impossible to
disentangle from implementation evolution.  Unless there are severe
technical differences (like those that still plague Emacs and XEmacs),
how would you ever know the difference?  Python is clearly a
"designed" language.

A lot of the heated discussion on XEmacs-beta occurs when somebody
proposes regularizing syntax for some set of operations; ie,
"designing" rather than "documenting the implementation".  People who
do that well, once, are forever listened to thereafter.  (Not
necessarily with "all due respect," of course, this is the 'Net.)  One
problem that we face is that we try to track the FSF's internal Lisp
interfaces, which change in ways that (from our point of view) are
random and lacking design coherence.  Not that they do, of course,
from the point of view of GNU developers.  This would be an example in
your favor; this incoherence of _viewpoint_ is precisely a failure to
agree on a common standard, not the result of incompetence in either
group of developers.

But I don't see how to disentangle the failure of the open source
process to produce a unified standard Emacs from legal issues (the
unassigned Sun copyright problem) and personality issues.  And maybe
the technical issues really still are open.  In any case, were all
those issues to be resolved, the fork would probably be healed, and
once again you would be unable to distinguish the standards process
from the evolution of implementation.

I'm missing your point, I'm sure.  Please expand.[1]  But mine is simply
that what free software currently is mostly good at (unkindly called
"taillight chasing") means that free software is unlikely to have
standard specification as a fundamental design process; rather, free
software developers are more likely to have effect on externally
maintained standards than to write them themselves.  Those standards
that they do write are likely to be "little standards" written for a
given implementation's internal purposes.  But implementations with
better "little standards" do better in the marketplace of ideas, I
should think.  Data?  Anecdotes?


Footnotes: 
[1]  Maybe it has something to do with the way an (eg) XEmacs
developer makes what he thinks is an improvement to coherence in the
Lisp interface and simultaneously documents it in Texinfo, without
going through some formal standards process?  I don't have a problem
with that as long as it's documented and the patch is reviewed.

Of course its a good idea to sit down every once in a while and step
back and do a global review.  But that's what happened with Linux 2.0
and again with 2.2, right?

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."