Skip to Content.
Sympa Menu

cc-licenses - Re: [cc-licenses] Founders as a module? was Re: Getting to Version 3.0

cc-licenses AT lists.ibiblio.org

Subject: Development of Creative Commons licenses

List archive

Chronological Thread  
  • From: Terry Hancock <hancock AT anansispaceworks.com>
  • To: Discussion on the Creative Commons license drafts <cc-licenses AT lists.ibiblio.org>
  • Subject: Re: [cc-licenses] Founders as a module? was Re: Getting to Version 3.0
  • Date: Sat, 27 May 2006 19:12:58 +0000

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






Archive powered by MHonArc 2.6.24.

Top of Page