Development of Creative Commons licenses

[drew Roberts <zotz AT 100jamz.com>]

On Saturday 27 May 2006 12:48 am, Greg London wrote:
> > On Thu, 2006-25-05 at 20:03 -0400, Greg London wrote:
> >> You can either get a small number of people to work
> >> a large number of hours to get N hours
> >>
> >> p * H = N
> >>
> >> or you can get a large number of people to work small
> >> numbers of hours to get N hours total.
> >>
> >> P * h = N
> >
> > Kind of like how one woman makes a baby in 9 months,
> > so 9 women can make a baby in one month? B-)
>
> Har.
>
> Or not.
>
> > This is the mythical man-month fallacy; communications
> > and organizational overhead between people takes a
> > significant toll in terms of effort after p = 1.
>
> no, you just assumed something about the formulas that wasn't correct:
> lowercase reflects fewer numbers than UPPERCASE,
> but no one said it had to be: lower = 1/UPPER.
>
> cathedral: people * HOURS = Total
> bazaar: PEOPLE * hours = Total
>
> where
>
> HOURS = PROJECT_HOURS + overhead
>
> and
>
> hours = project_hours + OvErHeAd

I think that the confusing bit might be that the equation seems to indicate 
that the N is the same in each case for the same job accomplished.  (Perhaps 
it would clear things up for those of us who can be dense at times to include 
something like this:

Project 1:  p * H = N

Project 2: P * h = N

*** Note: Project 1 and 2 have different goals (ends) in this example.

At first is seems like the goals could be the same as in paint room A blue. 
It 
also seems like N is equal in each case. (Say 16 - it is a big room.)
>
>
> And if there is any pattern to successful bazaar projects,
> the amount of OvErHeAd is small even as you add more people.
>
> Wikipedia allows me to contribute something about
> electrical engineering and your grandmother to
> add something about Knitting. There is no overhead
> between us. None. Zip. Nada. overhead remains constant
> as you add me and your grandmother to the wikipedia project.
> So, the mythical manmonth issue doesn't apply.
>
> This is the objective measure of "chunkability" of a project:
> Whether people can work without having to communicate
> with each other every freakin' day. Wikipedia contributions
> break into easy, small, chunks. And there is little or
> no overhead between contributers working on differnt chunks,
> which means OvErHeAd remains extremely low, regardless of
> how many people you add. Adding people to the wikipedia
> project does not make the project more late. It defies
> that "law" of the mythical man-month. because the mythical
> man-month is project centered, and if you can chunk something
> up, you basically have separate projects.
>
> The overhead in the linux project is somewhat higher
> because modules have to functionally interact with
> each other, applications have to run on top of
> operating systems, yada, yada, so people have to
> talk, stuff has to get worked out before an hours
> worth of project contribution goes to the project
> instead of the overhead.
>
> 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.

I don't think you will get much argument over the idea that projects which 
chunk better are easier to do in a distributed way and incur less overhead.
>
>
> 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:
>
> many people * (few project hours + small overhead hours) = bazaar TOTAL
>
> 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. i.e. cathedral:
>
> few people * (many project hours + small overhead hours) = cathedral TOTAL
>
See, I think that is clearer. N does not equal N in the examples.
>
> There is a single game:
> how to create content that takes N man-hours to build.
>
> There are two possible solutions:
>
> Gift economy or market economy.

Here is where I have yet to be convinced. I think things are all intertwined 
and the goal at least for me is the Free end product able to be used and 
re-used in Free ways. If these ideas of the different economies help people 
to understand and make sense of how some things work, all well and good. If 
they help guide us in structuring things in ways to get to the Free goals 
better, cool. But I don't think it is either / or in a lot of situations when 
it comes to the development side of things.

> All Rights Reserved or GNU-GPL.
> neither one has magical capabilities
> that change the amount of man hours needed.
>
> It's just that some projects chunk well
> and have little overhead so gift-economy
> and GNU-GPL or CC-SA make sense for them.
>
> And for projects that don't chunk,
> you're looking at All Rights Reserved,
> and maybe CC-NC, or CC-Sunset, and
> stuff like that.
>
>
> WHich is why I keep saying the LICENSE
> doesn't change the game or the solution
> to the projects. The LICENSE All Rights
> Reserved was CREATED to ENABLE one solution:
> Cathedral style creations. The LICENSES
> such as GNU-GPL and CC-SA were CREATED
> to ENABLE another solution: Bazaar style
> construction.

I am fairly certain that the GPL was not created for the reason you give and 
in fact, IIRC, the early development style for much of the GNU software was 
what ESR would term a cathedral style. (May or may not be what you would call 
a cathedral style.)

One license may fit one development style better than another or vice versa, 
but they do not necessarily go together in all cases.
>
> But neither license changes the game,
> changes the projects, they just enable
> solutions weren't possible before.

Perhaps one of the problems inherent from the beginning in putting a gift 
economy idea beside a bazaar image is that a bazaar is a big time market?

As in: "A bazaar is a market, often covered, typically found in areas of 
Muslim culture."

which shows up on this link: 
http://www.google.com/search?hl=en&q=define%3A+bazaar&btnG=Google+Search

all the best,

drew
-- 
http://www.ourmedia.org/node/145261
Record a song and you might win $1,000.00
http://www.ourmedia.org/user/17145