Development of Creative Commons licenses

[Terry Hancock <hancock AT anansispaceworks.com>]

Greg London wrote:
>  Other projects require massive overhead as you add people. Try
>  writing a novel like Lord Of The Rings with a team of 1000 people
>  while keeping the characters consistent, have a plot that develops
>  over three books, keep a consistent tone and voice, and have the
>  three stages of story development, and pull it all off so readers
>  like it because of its quality, not because it's FLOSS. It's hard
>  because all these things about a novel require massive communication
>  and is HARD to communicate. Authors don't know neccesarily know how
>  to objectively describe their voice or tone so that other writers
>  simple "get" it.

Of course, just to make your life complicated, the LotR was pretty
much written in Tolkien's "spare time" -- his day job was teaching
linguistics at university.   The movie version, of course, was done by
many people (still working full-time at it), and of course, it drew
extensively on the work of a vast fan-base (some of the more important
contributors were drawn out of that fan base -- where do you think
you get "Elvish language scholars").

So it doesn't fit firmly in either of your two solutions. I would suggest
that few projects are perfectly served by either strategy alone.

But nevertheless, I'm pretty sure I see what you mean, and I'm
starting to think I agree with your point.

>  So, projects that are chunkable, projects that keep overhead low as
>  you add more people, can be accomplished by having a lot of people
>  make small contributions. i.e. bazaar:

>  And projects that don't chunk easily, projects that have overhead
>  skyrocket as you add more and more people, will natually tend to have
>  few people working together to keep overhead down, and having them
>  work full time on the project as the job.

Intriguingly, the choice of strategy also changes the product.  You
see this all the time with free software versus proprietary software:

A proprietary solution usually winds up being one huge monolithic
application, while the free project becomes a myriad of small tailored
solutions interacting through well-defined (and usually very simple)
interfaces.

Even in the cases where a large framework is constructed (e.g. Gimp),
the path to success is creating effective interfaces for plugins and
extensions. Nine-tenths of Gimp's edge over Photoshop is in the plugins
and filters.

OTOH, when a free project takes over a proprietary project, the first
thing that inevitably happens is "de-construction" of the project into
separable elements which are easier to work on separately.

I'm not sure what 'the moral' is at this point, though.  ;-)

Cheers,
Terry

--
Terry Hancock (hancock AT AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com