One Cooperative or Many?

66 views
Skip to first unread message

kahunamoore

unread,
Dec 13, 2014, 4:47:58 AM12/13/14
to coops...@googlegroups.com
One topic of considerable debate has been on whether to have a single cooperative or should each project be it's own cooperative with one global cooperative in which all the projects/members are a part of.

The simplicity of having a single cooperative is attractive but the reality is that members and/or projects may have different expectations or needs so they might need more autonomy from the larger community. This would allow them more self-direction but this would seem to discourage sharing between projects, etc.

This also leaves open the question of membership dues and how are they apportioned among the projects. Does each individual project cooperative join the larger cooperative in some way? Which way does the money flow? Who collects the dues? Are there multiple agreements involved?

Thoughts/comments?

Alan

Alan Moore

unread,
Mar 4, 2015, 2:46:00 AM3/4/15
to coops...@googlegroups.com
Wouldn't there be different sizes of Coops? One project may need 10 people and another 1-3, is how I imagine it. If one large coop, what is the one project everyone is contributing towards? A brainchild project? :)

I keep coming back to the need to simplify the entire concept and keep things really really simple. The more I have looked at bylaws and other organizational infrastructure the slower everything will move. With automation all that can be improved but initially the friction seems high to me and adds to the cognitive overload trying to on-board people.

It depends somewhat on your main goal. If your goals tend towards creating a constellation of small cooperatives operating more or less independently with little to no coordination with each other or the larger Co-op Source cooperative. In this case each cooperative chooses the degree to which they create agreements amongst each other, create bylaws, incorporate as LLCs, is played out in the small.

However, if your goals include providing a way to solve the free-rider problem for open source then you want to add as little friction as possible to what already exists in open source, adding just enough to make hacking co-op source a sustainably and profitable living for as many members as possible. The membership concept is very simple and can be viewed as a proxy for donations in open source, only up front and required. One cooperative, many projects funded by membership income. Join, vote, build.

Aside: additional goals could include providing benefits to society at large such as reducing wasteful duplication of effort that is rampant in software today and has been for years. By collaborating remotely we aren't commuting to jobs in the city and other tangential affects of distributed software engineering. Giving back to open source should also be a priority, IMHO.

More importantly distributed collaboration has network effects that allow a more perfect "market' for talent in software projects, similar to what happens in open source communities already but would extend this into more corporate and enterprise talent markets. Hiring based on locally available talent is very suboptimal. You don't even need to care about others' personal hygiene in staffing decisions :-)
 

I think that everyone should strive to make their coop larger over time with respect to number of people involved. We can motivate and incentivize coops to grow.

Each problem lends itself to a correspondingly sized solution. Once a project reaches it's critical mass of involved parties (can change over time) any further growth strategy should be to ensuring the work product of the project is re-used in as many other projects as possible (libraries) or expanding markets. This could even be used as a metric for fund allocation to encourage sharing code. As the lines between languages, frameworks, protocols, platforms begins to blur this becomes more and more important.

Sharing should be a goal only to the extent that it makes sense, fork everything else. Forking should be planned for and included as part of the strategy/policy to maximize the collective efficiency, robustness, quality of products and services and not something to be feared.

More cogitating to do on these topics. Where am I off here? Too unrealistic? Too many competing interests? Fatal assumptions?

Alan

Alan Moore

unread,
Mar 4, 2015, 12:16:17 PM3/4/15
to coops...@googlegroups.com
One more comment on this topic... I tried to argue both sides but I don't think I have enough thought to the "many" case. I'll look at doing that shortly.

My guess is that we need a combination of the two... It just gets hard to explain to people at first.

Alan
-- 
"Whatever you can do, or dream you can do, begin it. Boldness has genius, power, and magic in it. Begin it now." - Goethe
--
You received this message because you are subscribed to the Google Groups "Co-op Source" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coopsource+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
Message has been deleted
Message has been deleted
0 new messages