Re: RFC soon on essay "Does Free Software Production in a Bazaarobey the Law of Diminishing Returns?"
On Tue, Aug 17, 1999 at 03:00:10PM -0400, John Cowan wrote: > > Some of us have other goals. My principal goal in writing GNU Emacs, > > GCC and various other programs was to produce a complete free > > operating system, so that we could have the freedom to form a > > community. > > A complete free operating system *of sufficiently high quality* > (not the highest possible quality, but better than Windows, anyway). > Otherwise, any old hack would have done the job. I think that Richard's point is that Freedom is more important than features. Writing high quality software is fine and well and that is nothing new. The fact that Free Software authors recieve a philosophical satisfaction for their efforts is the prime mover for why this has all occured. People can try to make out that it really has more to do with business issues but they are just trying to cast a new reality in terms of the old system. There was a time that the GNU/Linux system was not of "sufficiently high quality" to do much of anything useful. If that had been the deciding factor we would have never made it to this point. -- ___ Ean SchuesslerFreak Novare International Inc. Freak Central --- Some or all of the above signature may be a joke
Re: RFC soon on essay "Does Free Software Production in a Bazaarobey the Law of Diminishing Returns?"
Richard Stallman wrote: > Some of us have other goals. My principal goal in writing GNU Emacs, > GCC and various other programs was to produce a complete free > operating system, so that we could have the freedom to form a > community. A complete free operating system *of sufficiently high quality* (not the highest possible quality, but better than Windows, anyway). Otherwise, any old hack would have done the job. -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau, Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies. -- Coleridge / Politzer
Re: RFC soon on essay "Does Free Software Production in a Bazaarobey the Law of Diminishing Returns?"
I'd opt for this one. Except the magic pixie dust is the pursuit of the Right Thing(tm). Unlike blundering corporations that write up mission statements and run around worried sick about profits, developers only have one goal - write the best software you can. Some of us have other goals. My principal goal in writing GNU Emacs, GCC and various other programs was to produce a complete free operating system, so that we could have the freedom to form a community. Many of the other people who have worked on the GNU Project have shared these goals. Without this idealism, our community would not be where it is today.
Re: RFC soon on essay "Does Free Software Production in a Bazaarobeythe Law of Diminishing Returns?"
On Tue, 17 Aug 1999, Jacques Chester wrote: > The issue of quadratic paths of communications. It's one of the > suggested causes of Brook's Law. Mathematically, N^2-N is only the number of *two-ended* communication paths. I could see several situations in which what would matter would be the number of possible *subsets* of the number of developers, which would be a much scarier 2^N. One extremely important effect we're not considering is the collaborative amplification of creativity: when people work on a project together instead of breaking it into pieces and taking one piece each, they share ideas that would otherwise never be implemented. As someone else who's name I don't remember said, "If I give you my idea and you give me your idea, we each have two ideas, and together we have four." This could turn out to be an even more significant contributor to bazaar-style development than the scaleability issue. > 'Always' is a dangerous word. 'So far' might be a safer bet > for now. So far the favoured solution is the Bazaar being a What I meant was that adding more people will never slow down development. (My interesting observation about Brooks's Law was specifically that for sufficiently high values of N, the developers will produce *nothing at all*.) The new people might turn out to be totally useless, but the additional cost per new person is so small that the free-rider problem is negligible. If one out of a hundred people on the project's mailing list actually contributes anything to the project, the mailing list is doing its job. The only cases in which this becomes a problem are those in which the free riders actively interfere with development by, for example, starting flame wars on the mailing list, spamming the newsgroup, wasting bandwidth on the FTP site, etc. In that case, the core development group (once it realizes it can't restore order) will typically adapt to the situation by moving to a new mailing list, for example. > >3. It's so easy for a bazaar project to divide up the labor involved > in a > >project that the largest bazaars tend to break up into smaller > >task-oriented teams. (For example, instead of porting Linux to the > >PowerPC chip by having Linus say "OK, all you kernel hackers out > there, I > >want you all to buy a PowerPC and start porting the kernel", the Linux > >developers handed the task off to a team that had PowerPC experience.) > > Well, there you go. If I got ESR right, the labour-division > thing is handled by independent action and the parallel > handling of vertical problems. I didn't know ESR said that. I was thinking that in a group that's not being forced (by a phalanx of whip-cracking PHBs) to build an entire project from the ground up, it would be natural to build it in pieces that communicate with well-defined APIs. The *interpersonal* communication paths only exist within each subgroup. So if N developers break into M subgroups, they go from N^2 two-ended paths to N^2/M paths. The communication between groups is handled by the APIs in their respective projects, as well as some higher-level coordination through Freshmeat-style shared resources. > Forking is important and healthy, in my view. Indeed, > if nanotechnology delivers on its promises, forking offers > a glimpse of how future society will work. Don't like > your government's laws? Space colonies are cheap. Fork > off from your current one to a new one. Or, as Heinlein said, "The best thing about space travel is that it made it possible to go elsewhere."
Re: RFC soon on essay "Does Free Software Production in a Bazaarobey the Law of Diminishing Returns?"
Jacques Chester wrote: > Forking is important and healthy, in my view. The trouble with forking is that it divides attention, which is the true scarce resource. The World Wide Web Consortium, for example, is fiddling around with its structure now, experimenting with subdividing and re-merging, but the fact is that it can only do so much with the available minds. (The fact that other minds aren't available is a separate problem). -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau, Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies. -- Coleridge / Politzer
Re: Essay RFC delayed.
Jacques Chester wrote: > [...] Brook's Law [...] BTW, it's Brooks's law (not Brook's law or Brooks' law); the current draft consistently gets this wrong. > >Projects > > > >So what are projects, and what are their factors? Brooks > >example can be characterised as a project with two factors, > >being programmers and managers. If we hold managers constant, > >and increase programmers, LODR tells us that productivity > >will increase less each time another programmer is added. Actually, Brooks's law says that productivity will *decrease* after a certain point, not just increase less. With the n**2 communications costs, eventually you reach a point where adding resources is bad not just relatively but absolutely. -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau, Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies. -- Coleridge / Politzer
Re: RFC soon on essay "Does Free Software Production in a Bazaar obey the Law of Diminishing Returns?"
>X-Eric-Conspiracy: There is no conspiracy *Coughs politely* >Jacques Chester <[EMAIL PROTECTED]>: >> Fifthly, the possible conclusions so far are: >> * That ESR is completely correct, that Free Software *does* break the >> LODR and that it represents a new economic phenomenon in production >> * That ESR is completely wrong, that Free Software *does* obey the >> LODR, it just happens to be far more 'scaleable' than the traditional >> "Cathedral" >> * That ESR, unaware of the economic framework in which this can be >> viewed, does not realise that Brook's Law is the same as the LODR; >> and has therefore failed to distinguish between production in the >> Short Run (where the LODR applies) and the Long Run (where it does >> not). > >My take on the situation differs from any of these three :-). I was wondering how you'd view an outsider's slant of your specialty. Those possible conclusions were, of course, *possible*. The caveat still stands that they may be wholly incorrect (for several reasons). >I'm not familiar enough with the technical literature on LODR to form >a firm judgement on whether Brooks's Law is equivalent to LODR. My >gut reaction is one of skepticism. I'm afraid that, having delivered a sermon on quantitatively testing your qualitative assertions, my own attempt to draw approximation between Brook's Law and the LODR is itself qualititative. Hypocrisy of the highest level, and great fodder for the Caveats appendix. >I also want to point out that I do not assert anywhere in my writings >that open-source development is immune to LODR -- for the very good reason >that I would coinsider any such claim patently ridiculous! So would I, and so would any economist. That's why, if a relationship between Brook's Law and the LODR is established, the subject ought to be investigated. Even if the answer is deadly dull, it's worth checking anyway :) >I'll put the case more positively. I strongly suspect the following things: > >1. Bazaar-mode development *is* susceptible to LODR effects, but (in your > own words) "happens to be far more 'scaleable' than the traditional > cathedral". This, in fact, is almost exactly how I would have phrased > my own answer if the question had come up before. The preliminary Total Programmers vs Average Total Output seems to concur with the "highly scalable" conclusion. To the naked eye, it seems to be a slight curve upwards, and this curve itself seems to match the beginnings of a stock-standard LODR curve. But the gotcha is simple to pick. We cannot say at all that it *is* the beginning of an LODR graph, because for all we know it could be any of an infinite set of graphs with that beginning. It is just that we *expect* to see what we are seeing. And that's all I can say. Despite the selection of GNOME as a data source, I am afraid that my conclusions will be tentative, at best. While some elementary guesses might be hazarded, the data set is just too small to make any concrete statements. Alas, GNOME is one of the largest community-based OSS projects that uses CVS. I would have liked to have used GNU or Linux data, but such data is not available in the high resolution of a CVS logfile. >2. Brooks's Law is not precisely *equivalent* to LODR, but is rather a special > case of it involving *particular* nonlinear scaling phenomena. Accordingly, > one may assert that the bazaar mode repeals Brooks's Law without making > any commitment about the applicability of the LODR in general. And, conscious of the theory of knowledge, I too would suspect that Brook's Law is a special case. In an earlier draft, I said so. For simplicity, however, such a reference is removed from the main body of the essay and into the Caveats section. This is for efficiency of reason. Logic, of course, is the act of creating perfect structures from imperfect ones, which implies a certain degree of fitting fuzzy cubes into velcro circles. It doesn't always work cleanly, and stuff sticks where it shouldn't. For convenience, and in a conscious decision, we choose to carve off the edges so that the basics fit. With the essay, I seek to create an equivalency between the LODR and Brook's Law. While I do think Brook's Law is one special instance of the LODR, I also think it inherits enough of the core function to be "approaching equivalence". No, it is not the same. But, for the purposes of the main body of the essay, it will be. Why? Because this allows us to bring to bear some of the economic analysis that we use when dealing with the LODR. I am only a student of the most elementary and fundamental economic theories, but even I have a toolkit that seems to fit the problem at hand. This issue will most certainly be addressed in the Caveats. Indeed, the Caveats might be more numerous than any other part of the essay. Thanks again; JC.
Re: Essay RFC delayed.
Hello all; I'd like to note in passing that my poor overworked father is on the list of CC:'s bouncing around. As I take it, he's not hot on economics or programming. But he's an old radio hacker from wayback. If it'd been computing, he'd have been a Real Programmer. Dad, these are a bunch of fairly smart persons who are the experts in this area. Their collective focus is computers and programming, of course, but they are often quick to learn anything new. If it were radios, they'd be ranging from the uni. certificate types you supervise down there, through to old-hands like yourself. Enough diversions. Back to it. >Some quick comments below. [..] >Law of Diminishing Returns [..] >His law of diminishing returns says that if we hold one >factor constant (in the example, land), and we increase the >other factor (by adding more worker), then we can increase >output, but the marginal increase for each new worker >goes down. It's easier to view this from a differentiation viewpoint: the Average Total Output is the f(x) graph, and Marginal Output is its first derivative. >But, it is important to realise that if we increase >both factors, the law of diminishing returns does not >limit increases in output. More on that later. Aha. *You*, sir, have been introduced to this. Yes, the LODR only applies in what is called the "Short Run"; where all factors bar one are *fixed*. Where multiple factors can be changed, we turn to the Long Run, where different rules apply. To (as a famous witticist once pioneered) quote myself: >* That ESR, unaware of the economic framework in which this can be > viewed, does not realise that Brook's Law is the same as the LODR; > and has therefore failed to distinguish between production in the > Short Run (where the LODR applies) and the Long Run (where it does > not). Of course, this assumes that Brook's Law and the LODR are effectively equivalent (or, similarly but not identically: that Brook's Law is a special case of the LODR). >Projects > >So what are projects, and what are their factors? Brooks >example can be characterised as a project with two factors, >being programmers and managers. If we hold managers constant, >and increase programmers, LODR tells us that productivity >will increase less each time another programmer is added. To place that in economic terminology (which will be rife in the essay, may I add!), you are setting the Enterprise factor as fixed and the Labour factor as variable. >Brooks says something different. If a project is late, >then adding more programmers or managers will make it >later. This is different to how Adam Smith described it, >in that Brooks is bringing in the time factor. As >described in your draft, complexity argument can be used >to infer that diminishing returns occur rather than benefits >in time. Yes and no. Firstly, by saying "adding more programmers *or* managers" (emphasis mine), you have shifted from the Short Run to the Long Run. If Enterprise and Labour are my two factors, and I can change both, I am no longer in a Short Run situation and the LODR *does not apply*. Secondly, time is accounted for in static economics (the kind I am using) and dynamic economics (the kind they teach on the day they say "Forget what you have just spent many months learning. It is wrong.") in different ways. Productivity is productivity. It is the average amount outputted. We must, as a point of necessity, arbitrarily create a cut-off in time when output is tallied up. We can also render productivity in terms of output units per time unit, say LOC/day. By this means, Brook's Law still has the same implication: adding programmers to a late project leads to falling LOC/day across the lifespan of the project, as it *took longer to complete the same work*. The link is subtle and difficult, but it exists. >So what is happening here is that the process is time-bounded, >just like the growing of rice is time-bounded for the original >process. Now, we could shoehorn the time into LODR by calling >time a factor of production, but I suspect that this is unnecessary. In static economics, time is ignored or subsumed in the way I just described. For the GNOME project, the arbitrary cut-off is the day the CVS data was extracted. >OS projects > >How do Open Source projects differ from the above? >In two very important ways. Firstly, OSPs have no >time-bound. That is, there is no deadline whereby >the next version of GNOME has to be delivered, "or >it's your head!" This basically says that Brooks >law doesn't apply, unless there is a deadline. I don't think this is entirely accurate. If we render deadlines as being "a point of time reference", we can say that: a) projects arriving *before* this point are 'early' b) projects arriving *after* this point are 'late' further, c) that (ignoring arriving exactly on the deadline) the probability pr(Arriving Early) + pr(Arriving Late) = 1 therefore: d) a 'fast' project has a high pr
Re: Essay RFC delayed.
Oh, and btw: As wild as this sounds, I am starting to get ground into the dirt by the programming involved in getting this project to Just Work, dammit. If anyone can help me, email me, quick! :) JC.
Re: RFC soon on essay "Does Free Software Production in a Bazaarobey the Law of Diminishing Returns?"
> >On Sun, 15 Aug 1999, Eric S. Raymond wrote: > >> 2. Brooks's Law is not precisely *equivalent* to LODR, but is rather a special >>case of it involving *particular* nonlinear scaling phenomena. Accordingly, >>one may assert that the bazaar mode repeals Brooks's Law without making >>any commitment about the applicability of the LODR in general. > >One interesting implication of Brooks's Law is that as N (the number of >developers) gets sufficiently large, the cost of management and >coordination (which is a function of N^2) ends up exceeding the >productivity of the developers (which is a function of N) and nobody >produces anything. I suppose the developers spend all their time sitting >in meetings trying to explain Brooks's Law to their boss. The issue of quadratic paths of communications. It's one of the suggested causes of Brook's Law. >If we look at the real-world experience of bazaar-style projects, this >doesn't happen. Adding more developers, or even more end users, * always* >benefits the project--if nothing else, they'll find bugs faster. This >suggests three possibilities: 'Always' is a dangerous word. 'So far' might be a safer bet for now. So far the favoured solution is the Bazaar being a highly scalable means of production. This means it has limits; but where one goes after creating entire operating systems is beyond me. >1. Bazaar-style projects really are immune to Brooks's Law, because >someone sprinkled pixie dust over them or something. I seriously doubt this. Seems akin to saying that "Friends" gets higher ratings for happy peppy reasons; which is patently rubbish. "Friends" gets high ratings because it has highly attractive people behaving like children. >2. Bazaar-style development is so scaleable that we've never even >approached the kind of 'critical mass' that it would take for the cost of >management to exceed the productivity of development. Internet >technologies make the bazaar scale even better. We'd need millions of >developers to start to notice the management overhead that Brooks >predicted. I don't know about *millions*. But this seems to be the best bet at the moment. It may well be that true Bazaar projects will never reach this point: pressures of organisational overhead will cause fragmentation into smaller projects. Rather than everything being subsumed by the GNU project as a single hierarchy, for example, a typical linux distro is the result of endless autonomous units. The pressure to subdivide spontaneously creates a structure that seems not unlike a mandelbrot fractal. >3. It's so easy for a bazaar project to divide up the labor involved in a >project that the largest bazaars tend to break up into smaller >task-oriented teams. (For example, instead of porting Linux to the >PowerPC chip by having Linus say "OK, all you kernel hackers out there, I >want you all to buy a PowerPC and start porting the kernel", the Linux >developers handed the task off to a team that had PowerPC experience.) Well, there you go. If I got ESR right, the labour-division thing is handled by independent action and the parallel handling of vertical problems. > So >a large bazaar never reaches critical mass; it recognizes, in an >adaptive-system way, that it's trying to do too much, and breaks up. One >disadvantage of this process is that if the pre-breakup stresses in the >group are aligned the wrong way, it may lead to forking. Forking is important and healthy, in my view. Indeed, if nanotechnology delivers on its promises, forking offers a glimpse of how future society will work. Don't like your government's laws? Space colonies are cheap. Fork off from your current one to a new one. Enough dreaming. JC.
