help us design nonprofit org funding mechanisms

[glen e. p. ropella]

Hey guys,

In the planning of the .org, we've kinda come to a sticky point.  As
usual, it's about funding. [grin] But, it's not really about money.
Here's the problem and I really want as much feedback as possible so
that we can develop an organization that serves its purpose and is as
palatable to the users as possible.  (Remember that decisions by
consensus usually take awhile, but, usually produce very optimal
solutions.  So, I'd like hashing about and final agreement on
something developed here on the list.)

Now, in the current model we're mulling over, we have 2 basic types of
funding mechanisms: a task-specific one and a general everything-else
one.  The task-specific fund would be contributed to by persons,
organizations, or groups of such, for the sole purpose of completing
their task.  An example of this might be the parallelization of the
Swarm kernel or the development of a specific library that one company
or industry needed and was willing to feed back to the public domain.
(This is very distinct to code a company wants developed and keep
proprietary.)  This type of funding doesn't really present a problem.

The one that presents a problem is the funding for general day-to-day
tasks like salaries for employees, documentation tasks, source code
control, bug collecting and fixing, release management, etc.  These
are all tasks that should be supported at a steady rate (even if
small).  The problem is "Where does this money come from?"

We have a couple of ideas in mind, right now.  These are just ideas
and can't be called "plans" as yet.  We need the users' input to
either decide on one of these ideas, a hybrid of them, or something
better.  They are:

1) Charge for "membership" in a type of entity that has influence over
the direction of the development of the package.  Here, members would
be paying for votes that would influence the development.  (I say
"influence" instead of "determine" because I don't know what level of
influence the members might have.  It could be total control or it
could be subject to decisions made by the board.)

2) Charge for "membership" in a type of entity that provides levels of
service to the members.  Here, a member will be paying for things like
the right to occupy the developers' time with requests for new
features and help-desk type questions.  (Again, I don't really know
what the services would be... these are just examples.)  The levels
could be based on levels of service, institution size and purpose, or
some other criteria.

3) Seek grants from various different institutions.  It's entirely
reasonable to think that this effort could continue under the auspices
of normal academic or corporate charity.

4) Don't have a general fund at all.  There are projects that seem 
to continue and thrive without a single source of this type.  All
it really requires are understanding and generous developers who work
on the task-specific budgets or for other companies who are willing to
do a little extra work in their spare time to help the basic package
hang together.


These four are very general directions and are not meant to be the
only ways to view these things.  I'm really fishing for ideas from
swarm-support for two reasons: 1) I want the mechanisms to be amenable
to the present user community and 2) none of us in the SFI Hive have
significant business acumen.  So, any and all opinions are not only
welcome but begged for. [grin] Some things to keep in mind are actual
work-a-day considerations.  One person has suggested that it's harder
to work for many bosses than it is for fewer bosses.  This applies to
the level of influence a committee might have over development *and*
the operations of the .org in the face of several contributors.  And
this kind of thing should be taken into consideration now, while
forming the organization.

Help!!!

glen