[Gnu-arch-users] me vs. the hypothetical guy from India

[Thomas Lord]

Ludovic:

> As far as GNU Arch development is concerned, suppose the community
> eventually gets to gather $500.  Now tell me, why would the
> community, as a rational employer, spend $500 employing Tom Lord
> less than half-time (you'd probably have to have a second job) while
> there is certainly somewhere a good hacker that could work full-time
> with that wage?   [Besides the fact that your the original author of
> the considered software, of course.  ;-)]

A four part response:


* First, "the community" doesn't act as an employer in this
  circumstance.  

  One way to funnel pooled funds to a maintainer is to give money,
  earmarked, to a third party organization who acts as an employer
  (e.g., the FSF).  When that happens, the third party organization,
  not the community, is the employer.  The contributors from the
  community are customers of or donors to the organization, depending
  on the type of organization in question.  I'm using "employer"
  slightly loosely, here -- for example, some people have created
  organizations for pooling community sponsorship for projects and then
  they hire the sponsored hacker as an independent contractor rather
  than a direct employee (there are different "flavors" of
  employment).  That still doesn't make the community an employer.  In
  some cases, people creating these funneling organizations have
  experimented with coordinated contracts with both the hacker and the
  funders that give funders some of the rights and responsibilities of
  conventional employers -- so the boundary is fluid -- but those
  experiments seem to have largely failed so far (which most people
  attribute to their high, indirect transaction costs -- it's a pain
  to jump through those hoops to fund something; there's usually a
  cheaper, better, faster way).

  The other way to funnel pooled funds to a maintainer is via busking
  -- handouts to an environmentally desirable beggar, essentially.
  Once again, the giving community receives no recognized rights or
  responsibilities of an employer.


* Second, let's consider the rational self-interest of the community.

  "Open" communities (of which the FOSS folk are an example)
  historically display a remarkable inability to behave in rationally
  self-interested ways as even an informal, pretend employer.

  To put it simply, it's a "too many cooks spoil the broth"
  phenomenon.  Demands are driven by the issue-of-the-day and are
  often driven by sentiment, and sentiment often swayed by corrupt
  marketing.  There is no long-term planning.  There is at best
  shallow evaluation of results obtained.  As we've seen with Arch, it
  all too easily becomes a "mob rule" situation (where, furthermore,
  the mob is not quite aware of from whom they are taking their cues
  and why those cues take the form they do).

  Andy's idea may have some charms, though I would reiterate my
  concerns about the dangers of trying to do business from afar with
  an email address given minimal vetting.  One charm is that he is
  aiming for a small and manageable scale, given his means.  A small
  number of Andy's adds up to the $600 he proposed.  It is easy for
  that small number of people to coordinate about planning and intent.
  Aside from the remote management problem, he and his small group
  would be far more able to coordinate themselves internally -- to
  plan and measure results with care.  They would be buying, in
  essence, future releases of Arch from a source they like better
  than, say, Canonical.  Taking Andy as a prototype of software
  consumers everywhere, I find his instinct exemplary: to pool funds
  to purchase R&D for future releases -- the pooling offsetting the
  inherent risks of uncertainty of R&D success.   (Call his idea
  a very tiny start on an R&D "mutual fund".)

  What's sad about Andy's idea is that he is just an individual -- a
  "grunt" in some sense.  He must set his sites very low.  He is not
  joined by corporate spenders who could, with respect and engagement
  for his goals, enlarge the pool.  His may be a fine example of a
  good idea but his chances of going far with it, and the risks
  intrinsic to his going it largely alone, are somewhat pathetic in my
  view.

  Corporate interests *do* sometimes pool funds to aims such as Andy's
  (the handful of consortium-style NPOs we have).  Alas, they have yet
  to do this without tainting the approach with the overall trend to
  collecting unpaid labor that I've been describing -- they are
  unjustly low-balling their investments in the projects they claim to
  care about.   And, as usual, the sponsors are under-informed about 
  the engineering consequences of the systems they back.


* Third: Me vs. the Guy From India

  I will not compete for Andy's $600 because, even if it is a positive
  development, it fails to make progress on the corrections I believe
  are needed within the FOSS community.   For example, it would then
  still be my $600 budget vs. the essentially hostile budget for baz.

  I will also not compete for Andy's $600 because it is not enough to
  help me with my current bind.  My corrected budget projections (some
  small gifts, some skipped meals, etc.) has my family running out of
  cash in about 8 days from today.  I'm currently contemplating
  ethical and practical issues like which infrastructure bills to pay
  and which to blow off to extend those 8 days -- though blowing any
  off would extend the window-of-opportunity for recovery by only
  several days while enlarging the problem.  Unskilled jobs around here
  are quite competitive and, anyway, thanks to untreated arthritis I
  have trouble walking any significant distance or even standing for
  much time, never-mind having "an ability to lift 40 pounds".  I am
  reduced, essentially, to hoping for a fiscal "miracle" -- and soon.

  Nevertheless, and the example of baz notwithstanding, maintainership
  and R&D are not naturally zero-sum games, which I'll address under
  the final heading:


* Fourth: My Advantage as Maintainer

  Baz is a poor example of what is possible when divergent interests
  want to contribute to a single piece of software.

  *Of course* the author of a moderately complex system has an
  advantage in taking it to higher levels.  A continuing coherence in
  the decisions that add up to further development of an already
  successful design are simply a very good bet.  Breaking that
  coherence tends to dead-end systems -- as even Canonical admits they
  have done with baz.  This does not mean that the proper role of a
  designer is to micromanage or to exclude unexpected developments.
  It does suggest that when new designers are added, care ought to be
  taken to smoothly integrate their work with those whose mental state
  about the original design is the most comprehensive.

  There would be no reason to *not* create geographically distributed
  co-maintainers for a system such as Arch -- provided only that they
  shared a genuine spirit of community and an ability to create
  an infrastructure and political structure that would facilitate 
  their cooperation in meaningful ways.

  When I had the opportunity to shift from busking to some very kind
  angel investment in a possible Arch startup (I hope my former
  partner doesn't feel himself too badly screwed in the outcome but
  realize he probably does), had that busking revenue shifted to a
  qualified co-maintainer (especially in a region where the amount
  would have meant much more) --- that could have been a great
  opportunity.

  So, I reject your either/or premise.   Given the choice between
  me and a good maintainer from a poorer region -- the community
  should try to choose both.

-t