Essay RFC delayed.

[Jacques Chester]

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(Arrives Early)
e) a 'slow' project has a high pr(Arrives Late)

Seeing as a deadline is just a point of reference, what
matters is the probability of being 'finished' before
or after a given date. By this measure, we can take two
similar projects, Cathedral and Bazaar, and measure their
effectiveness at 'meeting deadlines'.

And besides, who says *I* set *my* cutoff on the deadlines
anyway? If, in measuring a late commercial project, would
I use data that ended on the deadline, or would I use data
showing the whole thing from beginning to end?

[..]
>Back to the OSP.  When the OSP splits of a sub-project, it
>can do it because it is beholden to nobody, and it can create
>its objectives on the fly.  Hackers decide what they want to
>work on, so they can recast the objectives so that they can
>work efficiently on meeting them.

*What* is being produced is a seperate issue from
*how* it is produced. This essay examines some mechanics
of the *how*.

Besides, the GNOME project was not so ad hoc; while it
holds some of the anarchy of any Bazaar, it still had a
fair degree of planning and common goals, yes?

>Scaleability
[..]
>Brooks can't change his scale because he can't change the
>original objective.  OS is infinitely scaleable because we
>didn't set the scale at the beginning.  Or, to cast it in
>Adam Smith terms, when we add more workers, we simply add
>more land.  No problem, more rice, as long as the weather
>holds.

And we move the Long Run, where the LODR does not at
all apply.

>Summary
>
>OS projects differ from commercial projects because they lack
>a hard objective, one that includes time and deliverables.
>As this assumption is critical to Brooks' law, it doesn't
>necessarily apply to OS projects.  We can break Brooks law
>two ways - by ignoring the time limit and by changing the
>objective.

I don't think this is a way to break Brook's Law at all;
it is merely moving outside the law's area of applicability.
Essentially, to break Newton's laws of physics, go to close
to the speed of light where they do not work. To break Brook's
Law/the LODR, go to the Long Run.

>Also, the only critical factor of production is programmers,
>so the law of diminishing returns also fails to hold.  There
>is no fixed plot of land limiting the production of rice.

There are four factors in economics: Land, Labour, Capital and
Enterprise.

Land and Capital are very important to this essay, because
depending how you view it:

a) programming is turning ideas into instructions for a computers

and either

b) ideas are natural, pre-existing and taken posession of/discovered 
(Land), or
c) ideas are human-created (Capital).

Then;

if ideas are Land, are they fixed in an OSP? Is any factor fixed?
And so on. All of this is an important source of caveats for the
essay.

Thanks again;

JC.