Subject: Re: funding indirect services (tangent)
From: Ben_Tilly@trepp.com
Date: Fri, 4 Aug 2000 09:21:50 -0400


Stephen Turnbull wrote:
> >>>>> "Frank" == Frank Hecker <frank@collab.net> writes:
[...]
> You stated it well.  To summarize, when a (business) patron offers
> money for a particular task which is not high on the community's
> agenda, there are two effects:
>
>     (1) Someone contributes time to the new task that otherwise would
>         _not_ be spent on libre software development
>     (2) Someone reallocates time from some libre project to the new task.
>
> That these effects are both possible, and in general will be mixed, is
> generally acceptable.  I think that (1) is significant enough that
> such patronage should be considered a good thing in general.

I have a fundamental disagreement with how you are thinking about this
problem, and my disagreement is that there is something which can be
pointed to as "the community".  There are many communities involved in
a libre project, and the definitions of those communities interact.
For instance the developers and users of free software often are not
very similar populations.  Perl is a good example, and despite some
impressive efforts there are sharp differences in clues between your
average Perl programmer and the average contributer to CPAN.

Another excellent example is Linux.  Would you care to compare the
average Linux user to the average contributer to the Linux kernel?
They are not only different in their clue level, they are different in
their interests.  For instance IP masquerading has been a very popular
feature among Linux users for quite a while.  But my understanding is
that it was unmaintained for a long time because no developer needed
it.  By contrast developers want to scale Linux up and down far past
the needs of the average home user.  They really are different (if
overlapping) communities with different goals for the Linux kernel.

At issue here is a far more subtle question.  The question is who gets
to make the design decisions and why.  The application of money is the
usual strategy of companies.  The application of programming effort is
likewise the strategy of hackers.  Should they seriously disagree,
then you get into thorny issues.

> This assessment that (1) is strong enough to outweigh (2) is what I
> called debatable.  I am fairly sure that (eg) Stallman believes that
> the balance goes strongly in the opposite direction; he would prefer
> indirect funding via donations to free software foundations (or even a
> general software tax), rather than businesses directly commissioning
> free software projects.  Thus the community would decide how to
> allocate _all_ available effort, even if the total amount were less.

I do not disagree with your assessment.  But I submit that the reason
for it is that RMS has some very strong and specific opinions on what
the design decisions should be.

[...]
> In XEmacs, for a number of reasons, the issue is not "unauthorized"
> projects, but whether the product will be integrated with the XEmacs
> mainline.  The Review Board refuses such patches "more in sorrow than
> in anger" when it is necessary.  Bill Perry was not the only regular
> XEmacs contributor to express interest in the GTK+ project.  I find it
> an interesting paradox that XEmacs should have such a stiff-necked
> attitude toward developer freedom to do _anything_ with the code.

Again note that the isssue is over design decisions.

> After all, it grew out of a fork occasioned by commercial demands for
> specific features and presumably organized very much on hierarchical
> lines.  But today anything goes, if that's what the individual
> developer wants to do.  He goes off on his own at the risk that the
> Review Board will judge that the architectural identity of the
> mainline is threatened, and will not integrate the patch.

And there you see the difference in design priorities.  The hackers
care more about the integrity of the code-base, the business cares
about the features that they think they can market to end-users.

(Both see both concerns, but prioritize them differently.)

[...]
> The important difference between attracting new developers and getting
> more effort from current developers is that the effect of the apparent
> "sabbatical" is ambiguous, and different people can interpret it
> differently.  In the XEmacs group, there was no public opposition to
> the proposal (as such, there were debates on its technical merit) nor
> censure of Bill Perry for taking the contract.  I think that
> represents the consensus of the XEmacs developers.  But some people in
> some other communities would interpret that "sabbatical" as an injury
> to their community.

For a more touchy example (flamebait ahead!) take the mislabelling of
Perl 5.6.0 as stable.  Why did it happen?  I don't know.  But it was
clearly (IMNSHO that is) mislabelled and the result has not been good.

A better-known somewhat similar conflict (with clearer motivations)
would be the premature labelling of Gnome as stable to meet an
external deadline.  There are still a lot of bad feelings about
that.

>     Frank> Now one could go on to debate whether attracting such
>     Frank> non-volunteer developers would be good or bad for the
>     Frank> community. On the plus side, such new developers could also
>     Frank> at a later time end up working on "authorized" projects, or
>     Frank> otherwise contributing in a manner seen as positive for the
>     Frank> community. On the minus side, such developers could be seen
>     Frank> as weakening the coherence of the community in terms of its
>     Frank> underlying values and goals.
>
> I'd like to see more discussion.  One subtle point:
>
> More free software is inherently a good thing.  (1) Maybe "the
> community" didn't want it, but somebody did---and those people may be
> attracted into the community by the newly produced free software.  (2)
> The effect of the GTK+ XEmacs would probably be more subtle, bringing
> the "l'ancien regime d'Emacs" and the "GTK raver crowd" together.  (3)
> More free software of a given kind will tend to crowd proprietary
> software out of that niche, or force it to be better than otherwise.

One not so subtle point.  You just walked into an area where people
tend to have some *very* strong opinions... :-(

Cheers,
Ben