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 _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
