On Wed, 2005-09-07 at 08:19 +0100, Andrew Suffield wrote: > On Tue, Sep 06, 2005 at 05:24:22PM -0700, Thomas Lord wrote: > > From an engineering perspective, I question why we need platform > > distribution companies *at that scale* *at all*. > > I question who said that we needed them. We get them because people > with money move in and 'invest' (which means speculatively purchasing > other people's effort) with the intent of making more money. And > people without money are willing to sell out to them.
Hence the labor issues that appear in free software: only a subset of the effort that goes into the software components needs to be purchased to control the rest. It's all about hearts and minds, baby. One small example from Arch illustrates how this plays out: the "tree allocator" code Baz added to Hackerlab. Months prior the code was discussed with me. I said I didn't want it added to Hackerlab because it was too specialized and too much code solving a relative non-problem. It's very limited range of applicability invited future bugs when it was misapplied or when people modified code without spotting how it was being used. It's performance characteristics are certainly nothing to write home about. I saw no good reason to commit to maintaining this code for so little and so dubious gain. Sure enough, then, it appeared in baz, in hackerlab, with dependencies on it in Arch itself. No attempt had been made to format it consistently with the rest of Hackerlab code. No attempt had been made to integrate it with the alloc_limits API that all of the rest of hackerlab uses as a layer over malloc. If it contained non-portable code I don't remember but certainly other patches from baz did. How many hours am I supposed to volunteer to fix that code -- either cleaning it up and making it fit the API conventions or eliminating it altogether? How many hours am I then supposed to send working on getting my repairs to it into Baz itself so that future patches to overlapping areas of the code don't conflict? (And isn't it ironic that I noticed this particular egregiousness while working on patching tla to be able to read baz archives whose format reflects a design process in which I was, again, early on asked for input, suggested improvements, and then ignored). And with patches arriving like that at the famously high rate of change in baz, and most of those patches of about the same quality -- I could easily have had more than a full-time job just cleaning up other people's code which implements yet more bogus design decisions. The whole time, of course, Canonical is hosting and running around to conferences, chanting the mantra "Tom is too slow at processing patches" without mentioning their role in making that so --- and the final kick in the teeth, treating their newly taken over project as a provisional hack to be discarded at the earliest possible opportunity. Of course they wouldn't make the effort to work cleanly: to them, the whole thing is just a throwaway project. This appears to be quite similar to the pattern that played out with GCC and its "friendly, experimental" fork, EGCS. The volunteer-managed FSF GCC progressed "too slowly" for businesses at the time and through a similar set of maneuvers, it was forked and then displaced. It was inconceivable to the commercial hackers I spoke with back then that what they were doing was wrong. They were sold on the idea that "progress" meant their businesses getting ahead as cheaply and as short-term-oriented as possible. The resulting dog-pile-on-the-code approach resulted, predictably, in a bloated monolith of a compiler and complete neglect of contemporaneous efforts to get compiler construction back on the track of producing simple, maintainable systems. Management oriented towards a slower growth path for those businesses and business units, marketing aimed at educating customers about why this was desirable -- those ideas were simply not on the table. One of the more amusing and clever alternatives I've heard of comes from Greenspun, who I'll paraphrase. After initial successes, he had a small company with plenty in the bank and a tight team of hackers. Worst case, they reasoned, they could use the banked money to go into the party equipment rental business for bread and butter while taking careful next-steps with the software. Brilliant! Alas, they made the usual mistakes of trusting outside investors and through a series of power plays, lost control of the now trashed company. > > Money corrupts. I don't accept that. Money is a very useful tool. Some markets function very well, promote economic growth, and create the famous "rising tide". Overthrowing the money-system is unlikely to be helpful. Stupidity and moral bankruptcy corrupt. Arrogant wielding of power corrupts. When stupid, morally bankrupt, arrogant people dominate a particular market they tend to attract and favor people like themselves. When the bulk of a given labor force is young, naive, inexperienced, and politically uncritical, a corrupt leadership can more or less lead them around by the noses -- that is how the Tragedy of the Commons is playing out in the free software and open source volunteer community. The funny thing is I don't have an image here of a bunch of Dr. Evils sitting around a conference room table saying "How can we best screw as many of these people as possible." Rather, it seems to be mostly the result of habits and uncritically inherited attitudes. Hence my, as one person put it, "moral whining". "The unexamined life is not worth living." -- S. -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/
