Subject: Re: update server alternatives
From: "Stephen J. Turnbull" <stephen@xemacs.org>
Date: Tue, 29 Oct 2002 20:15:39 +0900

>>>>> "Tom" == Tom Lord <lord@emf.net> writes:

    Tom> Which is fine until you get to the details.  I think there is
    Tom> a disconnect there, because instead making that QA their
    Tom> contribution to the community (by striving to push it
    Tom> upstream and make it intrinsic in how free software is
    Tom> developed) they try to use it as differentiation.

I see no real need to "push what Red Hat does upstream."   We already
have that; it's called Debian GNU/Linux.  To the extent that it can be
done by the community, Debian does it and pretty well IMO.  I've been
Red Hat-free for 6 years (I think it is) now.

    Tom> They are trying to turn an FSB into a de facto proprietary
    Tom> company -- to exploit the weaknesses of the community to
    Tom> their advantage rather than trying to fix those weaknesses.

The Red Hat version of Bugzilla is freely distributed.  So Red Hat
gives you the checked-out product (as RPMs), and the work process that
generates it, _and_ they pay a fair amount of the salaries of the core
developers of certain crucial OSS projects.

You may think they should also be funding arch.  YMMV, as they say.
Red Hat took a look at OSS QA, and decided that they didn't need a
better CVS, or that there's always Bitkeeper if they do, or
something.  But they did need a better Bugzilla, so they built it.
That _is_ a contribution to OSS QA.  (And the main Bugzilla page says
that RH Bugzilla may be merged back to the mainline, but that's been
there for as long as I can remember.)

As for the biasing effect of salary, it's real, but overrated.
Rationale below.

Bottom line: who's contributing more to the availability of tools (in
a very broad sense, including the Linux platform itself) for
community-based engineering?  I sure don't know.

    Tom> Look, the business advantages of free software have to do
    Tom> with cost sharing, opportunistic development, customer
    Tom> autonomy, user-driven development -- in general, community
    Tom> based engineering.

Right.  And as the non-coding catherd-in-chief at a non-infrastructure
project, I say community-based engineering is vastly overrated in many
applications.  XEmacs (as a non-business) is moving toward a Red Hat-
like model of distributed maintenance really fast.  Right now it is
the main contribution of XEmacs (as a project) to the Emacs community.
Oh, there will be more big code contributions, but those are really
contributions of a couple of "heroes", and not anything "the XEmacs
model" or "current management" can take credit for.

Where community-based engineering is important, on the other hand,
such as in the kernel, or in web servers, where the people who _run_
the infrastructure are the people who _build_ the infrastructure, RH
is contributing salaries of core people.  At least, I assume the
relations between Stronghold and Apache are pretty good, anybody want
to say one way or the other?

    Tom> In my opinion, these guys aren't behaving in the manner they
    Tom> would if their jobs didn't depend on their RH-biased
    Tom> participation: there's a discordance of values at work, and
    Tom> it puts those particants in a schizophrenic [*] position.

Better they should be working for Microsoft, so they could be unbiased
among Linux distros?

*shrug*  I doubt these guys are biased toward Red Hat solely because
Red Hat pays their salaries.  I suspect it's more likely that Red Hat
pays a lot of attention to them so (1) Red Hat's versions of
everything more closely reflect their individual opinions more than
any other distro, let alone your proposals or mine, and (2) they've
already made their compromises with each other to get Red Hat's
version working smoothly, and of course they lobby to have those
compromises installed as community standards.

     > I think that Red Hat is going to want to control the
     > distribution channel in the same way for the same reason of
     > quality control as Federal Express.

    Tom> "_The_ delivery channel".  Belief in the essentialness of
    Tom> such a thing is the hegemonic bug in your world-view.
    Tom> Personally, I see no need for any such thing.  It's a concept
    Tom> borrowed from proprietary software.

The "the" in "the distribution channel" here is simply the standard
English syntax to create a back-reference to RHN.  It doesn't imply
a unique distribution channel for the whole industry, or even that
among various types of channels RHN should be one-of-a-kind.

I assure you, I am well-aware of the other channels of distribution.
Because every time RH or Mandrake released[1], xemacs.org became
unadministrable (ssh shells echo a character every 5 seconds or so)
for 48 hours until our sponsor stopped being monopolized as a RH
(resp. Mandrake) distribution channel.

So I know from personal experience that RH provides many distribution
channels.  There are real resources being used; I know, because my
project sometimes competes with RH distribution for them.  And I
expect RHN is worth the price, because our sponsor's admins take a lot
of s**t from their members because the 10MB/sec they are allocated by
their sponsor isn't enough to keep up with the demand (estimated at
80MB/sec for the last Mandrake release).  If you want now and want it
right, you'll pay.

Granted, I think it would be nice if they'd lower prices dramatically
and take a lot of pressure off the shared channels.  But it would be
awfully greedy of me to actually _ask_ for it.


Footnotes: 
[1]  Since the last release, they've installed throttles on the iso
download areas, so that should be a thing of the past.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py