chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] inventory of community skills


From: Peter Keller
Subject: Re: [Chicken-users] inventory of community skills
Date: Sat, 3 Feb 2007 02:27:55 -0600
User-agent: Mutt/1.4.2.1i

On Fri, Feb 02, 2007 at 09:32:35PM -0800, Brandon J. Van Every wrote:
> An ideal, theoretical open source business model, would spread the 
> impacts of development evenly over the entire community.  So that nobody 
> has much work to do.  Then people can rationalize, "Ok, if I contribute 
> a few evenings a month to the open source labor, we'll all have this 
> great Chicken system," that for the most part enables everyone to get 
> Real And Fun Things Done [TM].

Being a professional systems programmer has taught me that you can fix
things in basically only three ways A) In 5 minutes and the fix is "the
correct fix" that stands the test of time, B) in 5 minutes and the fix
is a "hack" which is incredibly fragile and *will* be revisited, or C)
in 5 months.

It all comes down to how well you've mapped the thought/assumption pattern
of the person who originally wrote the code into your head and the raw
complexity of the task at hand. If you wrote the code or have looked at
it every day for 5 years, you can almost always do option A. However, just
because 5 or 6 people can do option A that everyone can immediately. This
"quanta of effectiveness" is a real barrier because it is very difficult
to catagorize how much work a task needs and how much mental context a
person needs in order to be able to do the task.

The learning curve for a project the size of chicken I'd figure to be
about three years (learning for a few hours a night) before you can
make (with Felix's blessing) significant alterations. About two years
to find/fix odd internal bugs. About one year to learn & clean internal
APIs and refactor. About 2 months to learn entry level Chicken and write
decent C interfaces and publish an egg "following the rules".

> I think the way most open source communities are actually organized, is 
> a few key people are ideologically driven.  Something bugs them very 
> much about software, so they hack and hack and hack and hack to try to 
> fix it.  Their software products are somewhat beneficial to others, so 
> communities arise around them.  People glom onto a project if they think 
> they can solve their own ideological issues without much additional work 
> over what others have already done.  This is why I joined the Chicken 
> project originally, for instance.  I didn't anticipate that I'd be 
> banging on things for so long.  I have strong ideology about "builds not 
> sucking," having been burned by so many of them.

When I come back to chicken, and I probably will in several years when
I've finished some other projects I'm doing, I'll probably have a long
fight with Felix about how the backend should generate full assembly (as
opposed to C) so that scheme debugging symbols in a debugging format we
design can be placed into the executables and a proper debugger built.
Who knows if it'll even happen, but that's the itch I want to scratch.

> Similarly, there's a type called the 
> "Plant" that is great at chucking out new things, but gets bored with 
> them fairly quickly. 

Yeah, that'd be me.... :)

> A third is to find a way to amplify ideology.  That's implicit in an 
> inventory of community skills.  The presumption is that 5 OpenGL guys 
> are more powerful than 1 OpenGL guy.

I'd say pick the ONE thing that Chicken--or even Scheme itself, seriously
lacks that noone wants to touch with a ten foot pole. You could ask this
entire list what it is and after a while a consensus would form. Take
that ONE thing everyone thought was impossible and design and implement
a solution with 3 people (and no more, unless it is *painfully clear*
helpers could be added)--be it an application, a library, a compiler
feature, whatever.

Then people will be drawn to it since it would be innovative.

In addition, there is a fourth person out of your analogy, the users of
Chicken who write applications and couldn't care less how Chicken was
implemented--only that there is a vast and rich library with which to
build their applications. Ultimately, it is them we all worship since
they drive the reason for maintaining and evolution. Often they are one
in the same in the beginning of a project, but the goal is to make the
application writer base far larger than the developer base. In effect,
this page http://chicken.wiki.br/Software should have dozens if not
hundreds of links on it. Meaningful and powerful tools built from Chicken
is why everyday people would want to use and learn it.

In a sense, if you want to make money with Chicken, then write the kinds
of applications people will use and pay support for.

Later,
-pete









reply via email to

[Prev in Thread] Current Thread [Next in Thread]