Subject: Re: funding indirect services (tangent)
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Fri, 4 Aug 2000 14:21:06 +0900 (JST)

>>>>> "Frank" == Frank Hecker <frank@collab.net> writes:

    >> The point is that BeOpen.com has greatly influenced the
    >> development of XEmacs by voting with dollars, rather than
    >> convincing the review board that it is good for XEmacs.  _IMO_
    >> this is good for XEmacs development--- we get to experiment
    >> with a GTK+ XEmacs without redirecting the whole project---but
    >> since the obvious target for those dollars is current volunteer
    >> developers, it is debatable.

    Frank> I'm sorry, I'm confused by what you're saying here; could
    Frank> you clarify exactly what here is debatable?

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.

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.

    Frank> Are you referring to the fact that offering payment for
    Frank> development will cause at least some volunteer developers
    Frank> to do less development as part of the community, because
    Frank> they'll be doing projects not approved (in some sense) by
    Frank> the community?  And that in such a case the FSB funding
    Frank> development might be seen as not contributing to the
    Frank> community but as helping to weaken it?

Precisely.

    Frank> I agree that such an outcome is indeed possible. I also
    Frank> believe that the community is not defenseless in such a
    Frank> situation; for example, its members' values might lead them
    Frank> to decline working on paid projects that are perceived to
    Frank> be "unauthorized".

A community need not be defenseless, as you point out.  But it may not
even want to defend!

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.

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.

An interesting aspect of the GTK+ case is that several of the regular
beta testers also ran the GTK+ branch through its paces, with no
effect that I could see (from list traffic and patch activity) on
their contribution to the mainline.

Some FS communities may be more robust to such sidelines than others.

    Frank> In that case offering payment for development would not
    Frank> necessarily cause a reduction in volunteer development, it
    Frank> might instead attract new developers who were not (for
    Frank> whatever reason) willing to work as volunteers within the
    Frank> community as traditionally constituted.

As far as I can tell this was not exactly the case with the GTK+
XEmacs project.  In a similar effect, it elicited more effort than
otherwise would have been possible from the contractor and from
several beta testers.  It may have resulted in the contractor taking a
sabbatical from mainline development.  I would guess that the testers
were carried by enthusiasm for a project that nobody was really
against; it was just considered a very bad risk for near-term
integration into the main line.  (I wrote "may have" because like most
developers sometimes Bill is very active, and other times not.  Noone
can be sure that he would have worked intensively on XEmacs-related
tasks if he had not taken the BeOpen contract.)

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.

    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.


-- 
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 straight lines for?  "XEmacs rules."