Re: help us design nonprofit org funding mechanisms

[glen e. p. ropella]

Tony Bigbee writes:
 > Ok, here goes a swarm of clay pigeons  :P

You say that like we're a bunch of skeet shooters waiting to 
kill any idea thrown up in front of us!  Surely, we're not that bad,
eh? [grin]

 > It seems that there are interrelated problems, such as the structure and
 > goals of the nonprofit organization (NP henceforth) and the funding
 > sources for achieving those goals.  While the overall reasons for moving
 > to an NP may have been put forth in the last month or two, I still am
 > unclear about the overall goals for the Swarm platform (other than
 > probable exhaustion of funds in the fall and a need to rethink funding
 > and thus organizational structure).  Perhaps there can be parallel
 > discussions about what Swarm should be and what are the overall goals
 > and strategic vision of Swarm?  It seems that there is a lot of
 > enthusiasm for a multiagent toolkit with a wide variety of features
 > (which have been discussed at length here), but I raise Java as an
 > example of an important issue.  Is one goal widest possible
 > usage/development using this toolkit (I'm not promoting Java and know
 > that there are significant problems with moving partially or completely
 > to it, I just use this as example)?

OK.  There's no restriction on conversation, here.  And I agree that
there may be some uncertainty about some things.  But, surely it's
obvious (from the funding aspect, at least) that a home for Swarm
needs to be found.  One of the things we outlined at SwarmFest (were
you there?) was that SFI does not really intend to be a software
development house.  However, they are wholeheartedly in favor of a)
using Swarm for research that lives at sfi and b) helping any spinoff
(including for-profit, not-for-profit, and educational and industrial
r&d).

So, we need to establish a plan to get the software maintenance/
development out of sfi.  This means that it must go somewhere, either
to another educational institution, a commercial enterprise, or a
non-profit organization.  Of those three options (all of which can
still be debated -- like the sim package and objective C, we're pretty
dynamic [grin]), the NP organization seems the best bet.  If you'd
like, we can go into the reasons for that.

All of this lies on *top* of the overall goals of Swarm because Swarm
can have *no* goals if it doesn't exist. [grin]  So, while the goals
of Swarm is a valid and pressing issue, it should be a different 
thread, I think.

 > I like the idea of a membership buy in, with the amount proportional to
 > "size" (individual, corporation, etc.)  What seems to be a really
 > important consideration and is found in option 2: *services* rendered
 > are proportional to contribution.  Then you ask what are the services?
 > This leads back to the question:  what are the mission and initial goals
 > of the organization?

This is relevant.  The services to be *provided* by the NP is a home
and hub for Swarm development.  Period.  We're not trying to be an FSF
or anything like that (whew!).  And we're not even trying to place
user services as the .org's responsibility.  We're trying to allow the
user services like help installing, help using the esoteric parts of
the libraries, modelling help, etc. to grow without bound in any
direction it wants.  So, while the .org will most likely do alot of
that (and probably most of that at first), it won't be one of it's
core responsibilities.

The core responsibility I see as belonging to this .org is the quality
control inherent in having a decision making body for the development
of the package.  There is fallout from this decision making body in
that it can't make decisions without being technically informed about
exactly what Swarm is and how it operates.  So, the fallout consists
of being intimately involved in the user community and the source code
and all it's peripherals.  But, those aspects aren't the core.

Am I rambling, here?

Now, where the LOEs come in is that, hopefully, the .org will be 
able to efficiently coordinate the performance of those tasks with 
the main package development and the user community.  This coordination
may involve hiring more people to complete a large task or
sub-contracting with freelance programmers or other companies to get
the actual work done.  Or, it could even involve simply being a type
of go-between the LOE sponsors and freelance programmers where an 
actual contract would bind the sponsor to the programmers with no 
mention of the .org.  How this will work is dependent on how you guys
(the users) want the .org to work.

 > Maybe there are studies out that review the histories of NPs, especially
 > small ones that deal with software development; they could be valuable
 > in the planning of the organization.

If there are, I'd like to know where to go to find them.  I've
looked in some indices and books and web resources; but, I find
mostly social and political programs.  One thing I've noticed, though,
is that the majority opinion seems to be to design your .org as you
see fit and then worry about making it work.  The advice I've seen
specifically recommends against modelling your .org after somebody
else's.  But, that doesn't mean we shouldn't look at others and 
see how well and what they're doing.

But, keep in mind that we only have about 5 months left.  So, we
may not actually have time to do a full scale study of what's been
done to date.

Whew!  I hope my wordiness doesn't bore everyone so much that they
don't want to help address this issue.

glen