[cc-licenses] Founders as a module? was Re: Getting to Version 3.0
Terry Hancock
hancock at anansispaceworks.com
Sat May 27 15:12:58 EDT 2006
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
More information about the cc-licenses
mailing list