Subject: Re: improving project maintainership
From: "Stephen J. Turnbull" <stephen@xemacs.org>
Date: 09 Feb 2002 16:20:32 +0900

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

    rms> Stephen Turnbull wrote:

    sjt>     [1] In fact, I have seen a GNU project use its dominant
    sjt> position in a given application to obstruct cooperation among
    sjt> third parties.

    rms> Your own description of the events shows that is unfair.
    rms> Here it is:

    sjt>     Richard Stallman made it plain that GNU Emacs would not
    sjt> conform to any common specification for remote file access
    sjt> until the (vaporware) lsh was available, as conforming would
    sjt> encourage use of the non-free (but immediately available and
    sjt> robust) ssh.

    rms> What it shows is that someone asked us to cooperate with a
    rms> plan that would encourage use of ssh, and we refused.  If we
    rms> "used our position"--I am not sure that expression fits the
    rms> events--it was to avoid being recruited to give aid and
    rms> comfort to use of ssh.

Right.

I recognize that from your point of view it's an "if you're not part
of the solution, you're part of the problem" issue.  However, the
effect was not merely to defend true GNUsers from the slippery slope
of SSH.  There was collateral damage.

It did obstruct cooperation.  Taking your words about the "moral
obligation" to promote free software literally, I have to conclude
that the obstruction of cooperation among people who have goals
differing from yours is at least a "happy accident" from your point of
view.  So I do not consider my phrasing unfair, especially in the
context of providing what was clearly meant as an extreme example of
GNU's attitude toward cooperation.

Ironically enough, GNU's attitude toward cooperation is that it is
purely economic, a matter of cost reduction.  Amending GNU priorities
is not considered.

If GNU believed in cooperation, then it would consider cooperating in
a generally positive effort, even though it involved a temporary
setback for one particular area.  You[1] could easily have said,

    Look here, SSH is not free, and GNU really doesn't want to promote
    that.  On the other hand, lsh isn't ready for prime time.  We
    really need a free secure shell.  If you'll promise to promote the
    early use of lsh, at least for non-critical applications, and to
    try to recruit developers and testers for it, GNU Emacs will
    acquiesce in the accidental promotion of SSH.  Then we can all
    move forward on the specification of remote file naming syntax.

Had that been on offer, Steve Baur (a cypherpunk himself, and thus a
considerable resource) would have jumped at it.  And Steve keeps his
promises.  Kai Grossjohann I consider reliable.  Mike Sperber tends to
be a little forgetful of things that don't directly promote his own
work, but he wouldn't actively promote SSH to the exclusion of lsh.
And you probably have gotten a deal where lsh was the default secure
shell in XEmacs, as long as there was easy customization to use others.

I think the odds are pretty good (say, even) that a deal like that
would have hastened the availability of a 100% free secure shell by as
much as a year, at the admitted high "cost" of improving the security
and privacy of all Emacs users in the interim.

I see win-win written all over that deal.  But it wasn't offered, and
deals like that are never offered by GNU.

This creates division in the community, division which I believe is
unnecessary, division which I believe can best be resolved in the
interest of free software by GNU amending its priorities slightly.

    rms> When a non-free program (such as ssh) becomes popular among
    rms> GNU/Linux users, it is an active threat to our community.

Where is that threat today?  Dunno about the commercial Linuces, but
in Debian GNU/Linux, NetBSD, OpenBSD, and I would guess FreeBSD, it's
_hard_ to use real SSH anymore.  OpenSSH is installed by default, real
SSH requires fiddling with the licensing filters that Deb and NetBSD
provide in their packaging systems.  All the sshds that I know what
they run run OpenSSH.

And where is lsh?  My guess is that if there had been a common
standard, and TRAMP had become a standard part of GNU Emacs and XEmacs
three or four years ago, lsh would have gotten lots of exposure in the
community, and would have recruited many, many Emacs hackers to its
development.

    rms> That is a much more serious problem than variations in remote
    rms> file syntax.

If it were a threat of indefinite acquiescence in non-free software,
I'd agree.  But that seems unlikely.

    rms> People who prefer power and convenience to freedom will
    rms> probably not stop promoting their views.  We in the GNU
    rms> Project will continue promoting the view that software
    rms> morally should be free, and non-free software is unacceptable
    rms> to use.  And we will act accordingly.

And I suppose you will continue to misrepresent differing views as you
did just above.  Those who prefer power and convenience are using
VMware or double-booting, and they don't ever mention freedom, not
even to say they prefer the power to it.  Those who actually promote
views regarding power and convenience vis-a-vis freedom do not prefer
the former to the latter, as both words and deeds abundantly show.
They see the judicious application of the former as a means to the
latter.

I, among others, will continue promoting the view that power and
convenience are important tools in the service of promoting freedom,
even if "power and convenience" means _temporary_ acquiescence in use
of non-free tools.  And I'm in good company:  you personally
_deliberately_ use non-free software every time you promote software
freedom by sending a message over the Internet or making a phone call.

Let's try a compromise.

I've advocated the goal of maximizing the "volume" (in some sense) of
free software that is available, regardless of the use of non-free
software outside that sphere.  Given the dynamic nature of the field,
I propose that we compromise between my "economist" position, and the
GNU "refusenik" position.

* Toward a GNU GNU Manifesto *

    Can we agree to cooperate on promoting and developing an
    infrastructure that promises the fastest possible migration of
    each application from proprietary implementations to free
    implementions?  Regardless of the means used to do so at any given
    time?

(By "any given time" I mean that part of our social contract is that
should the most efficient development seem to require a proprietary
tool, we are obliged to devote more and more resources to developing a
free equivalent until we have a satisfactory replacement.)

I realize that on the face of it I'm hardly giving a thing on the
"economist" position.  Rapid migration presumably is nearly the same
as maximizing the volume of free software.  And of course FSB is not
compromising much; all the major FSBs are already devoting substantial
resources to exactly the goal of ensuring that the FS development
infrastructure is at least as good as that available from proprietary
vendors.

So GNU has to bend the most to cooperate in this way.  But I think an
argument can be made that the goal enunciated in the GNU Manifesto is
fait accompli, and that current GNU goals such as "conquer the
desktop" are too conservative in the light of that experience.
Hackers will try to conquer the desktop regardless of GNU policy.  And
we'll probably succeed as we[2] did with creating the "GNU System",
but in the light of that experience it's not a pioneering effort.

I propose that GNU adopt as its explicit goal for the next ten years,
not the creation of a wholly free system that meets specific user
needs, but the creation of a free development infrastructure,
technical and organizational, that _dynamically_ addresses the goal of
promoting freedom by concentrating on the issues of migrating
proprietary implementations (Word -> AbiWord) _and_ specifications
(MP3 -> OggVorbis), creating free networks for users (whatever it was
-> Gnutella), and dealing with the hard problems that ASP technology +
megabit bandwidth pose for our current social/legal strategies.

Consider it to be an analogue in the social sphere of the process of
bootstrapping the GNU toolchain using proprietary "native" tools.

Of course this is already going on; I propose making it the explicit
goal, and accepting that the means to this goal may involve temporary
use of non-free software.

I think that this would further vitalize GNU, and more important,
would give GNU a much more central role in coordinating FSB activity
to mutual benefit than it currently can hope for.

Funny, but what I just described is pretty much what Tom Lord
described (although his description was complementary in that he
focussed on sketching out the technology and organization).  Given
that Tom and I disagree on almost everything, maybe this is worthy of
consideration.

Tom and I do disagree on one point.

I think that GNU is the obvious candidate for such a role, and it can
do it by itself.  If you decide to.


Footnotes: 
[1]  Agreed, I didn't suggest it then, either.  But then, I've had
several years now to think about "how to cooperate with GNU".  At the
time I thought it would be possible on the usual give-and-take terms,
and I considered you irrational.  Now that I understand that your
axioms are different, I realize that every such deal will have to be a
special case with each point strongly supported, and the relation to
GNU's goals made excruciatingly explicit.

[2]  I'd like to explicitly acknowledge Richard as "first among
equals" here, and disclaim any important role for myself.  I wasn't
doing software then.  But "we" seems the right phrasing on FSB, as
fairly representative of the cooperating hacker society that made the
success of GNU possible.



-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.