Re: Means to an end WAS: Re: [ba-unrev-talk] On Tournaments
OK, I don't think I'm getting through on that tack so I'll try another. (02)
If an OHS conforms to the requirements of an OHS, then information
will be transferable between two OHSes without loss.
Does it then matter what is used to build an OHS if the information
can be seamlessly interchanged between individual instances?
On the assumption that the alliance-980.htm docs constitute requirements
then that leaves a couple of things to sort out.
1- Sources of investment.
2- Organisation. (04)
As regards (1) the question is who is going to build it and why?
Folks paid by industry get paid by industry, and industry carries
the risk on ROI.
Volunteer open sourcers are by definition in it for kudos, heroism,
and service spin-offs. You only get to wear the red underpants on the
outside if you can say you saved the world out of the goodness of
your heart. (05)
Assuming folks on the list regarding OHS development fall into the
latter category, then the investment is a matter of volunteer hours.
But the efficiency of a volunteer effort might turn on its organisation
There might be 4 volunteers who put in 4 hours a piece (heroically) per
week = 16 person hours per week.
Or there might be 400 hundred people who only put in an hour a week
(a lot less heroic) = 400 person hours per week. (06)
(Is it _necessarily_ the case that the organisation required for that
presuppose the existence of an OHS? No.) (07)
The whole point of Doug endorsing the GPL was that folks would be
able to forego immediate personal greed and collaborate on the core
tool. Selfish memes are out.
(And is it certain that memes behave like genes anyway?) (08)
Stage 1: find out who wants to play and how.
Someone with a server could set up a simple html form that people
could plug their names and possible roles into. (I don't have a server
that'll run FormMail before you ask.)
Stage 2: decide what subset of alliance-980.htm constitutes a first
(After Stage 1: we'll know who wants to be plugged into that.)
Stage 3: find an effective organisational method for the project that
scale to 400 people doing an hour a week. Much of that might turn on
how cleverly one could modularise the requirements.(?)
(Organisational methods gurus step forward now. If not we'll innovate.)
Stage 4: Set a deadline for first prototype. Fire it up. (09)
Herding cats is hard. So if you're sure you're irredeemably cat-like
don't listen to me.
Anyone out there wants to make one more bid at not being
a cat? (010)
----- Original Message -----
From: "Eric Armstrong" <email@example.com>
Sent: Thursday, June 20, 2002 12:57 AM
Subject: Re: Means to an end WAS: Re: [ba-unrev-talk] On Tournaments (012)
> Peter Jones wrote:
> > ----- Original Message -----
> > From: <firstname.lastname@example.org>
> > >
> > > ... Anecdotal
> > > evidence suggests that competition--in situations where the goals
> > > or rewards are tangible, immediate or play well on TV--
> > > accelerates the process of improving and creating tools that
> > > help reach those goals
> > But look at the redundancy of effort involved.
> > If 4 teams pursue the same goal and only 1 wins what happens
> > to the investment of the other three?
> There is a need to identify the variations of the effort that result,
> as well as the redundancy.
> Natural selection works by a randomly(?) generating variations,
> and then selecting those which succeed.
> With variation, no selection, and therefore no evolution. That
> statement could easily identified as as the "creed" that makes
> free societies and relatively open markets successful.
> With too much cooperation, there is too little variation, and
> no selection, which inherently limits evolution.
> With too little cooperation, admittedly, nothing gets built.
> But the marketplace has an interesting way of creating an
> exponentially-declining proportion of market share, over
> Market Leader: 50% of market
> #2: 30% of market
> #3: 10% of market
> all others: 10% of market
> At the outset, variation explodes. Think of all the fanciful
> ideas for flying machines that we laugh at now. But it wasn't
> clear at the time which was the *right* idea. The machines
> are humorous in retrospect, because now we know.
> After that initital explosion, successful implementations start
> to take off. There were 20 or 30 automobile manufacturers,
> once upon a time. Then it condensed to 3 (GM, Ford,
> someone else.)
> Internationalization produced a temporary increase in
> car companies back up to 15 or so, as we now have
> manufacturers from Japan, Germany, and Great Britain.
> But in the next 30 years or so, they will inevitably converge
> down to the "top 3". When that happens, we'll be back to
> seeing the fins change year after year (and not much else)
> like we did in the 50's, 60's, and 70's.
> Explosion of variations, at this point in time, is a good thing.
> What is needed is better collaboration tools and matching
> making services, so that people with compatible ideas can
> find each other and work across vast distances. Then useful
> cooperation among like-minded people will be balanced
> with the variations generated by people with different ideas.
> The true loss lies in the redundancy of very similar
> designs where, if IP issues could be worked out and
> remote collaboration were effective, a single design of much
> greater power could be produced.
> But, of course, it is exactly those problems which the system
> is trying to solve.
> With any luck, this effort will be the last one in which a new
> technology enjoys an explosion of variation, with an
> insufficiency of cooperation.