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