If you were trying to develop software cooperatively, how would you bring in new cooperators? Everyone who writes even a small patch gets copyright and voting power? Everyone gets copyright but voting requires a more substantial time investment? I'm not even sure if it makes sense or not to distinguish between someone who owns the copyright to the published work and someone who owns a share of the organization (and in turn a share of the capital, if there ever is any).

To be clear, this is about a small open source project that is trying to get people together to solve a problem they have collectively. This is not about a business that's trying to extract value from the software and convert it to capital.

Right now I see two potential models for this in a not-for-profit software co-op: members are those who pitch in a small amount of money which is used to pay for infrastructure and services (the way platform co-ops normally work), or members are contributors that have shown dedication to the project and money comes from donations (like most OSS). Maybe there are others?

@sam I would say either by invitation of the existing members or review of an application.

@sam Speaking from my experience with Mixxx, inviting new people into the group who have made substantial contributions and have shown sustained interest has worked fairly well.

@sam Of course, that goes along with actively encouraging new people to contribute and take on more tasks.

@be I'm getting more and more general interest (drive by PRs or chatter in the chat room by users, etc.), but no one who really wants to dive in and contribute in a substantial way, sadly. I'm also kind of hoping that bringing in a few of the smaller contributors could lead to a bigger sense of ownership and commitment for them and help them get more involved, but maybe that's not a good idea because if it doesn't work you end up with a disengaged voting community I keep going back and forth.

@sam In my experience, people do take on more responsibility when invited in. My advise is to err on the side on inviting people who show interest and competence.

@be Thanks, I'll keep that in mind. I've got a few drive by contributors I'm hopeful I can turn into more regular visitors, so I may reach out to some of them and see if they'd be interested in attending a meeting or something to try and get them more involved. Maybe with one or two other voices it will be easier to figure out what the best way to run this thing and make decisions is.

@sam I haven't started a new project from scratch before so my experience is from a bit different context, but I think your idea of directly reaching out to people is a good idea.

@sam I would avoid trying to formalize it very much so early, but do make your intentions to do so known.

@be Yah, I dunno that it needs to be formalized as in "bylaws" or anything like that, but I do think it would help to have a decision making process that's not just me making it up as I go along. I have very strong opinions about most of this stuff, so having others helps ensure those opinions aren't being self-reinforced in a void BDFL-style.

@sam Our rule in Mixxx is that you don't merge your own pull requests and all contributions are done through pull requests. This works pretty well to ensure there is consensus. Of course, that's difficult to do if the project is primarily driven by a single person.

@be Oh yah, I think most people use that rule regardless of whether you're a co-op or not; I know I do when I have enough contributors to do so :)

@sam Make it closed source or “throw tarballs over the wall and never accept contributions” open source, and use a traditional hiring process to bring in members?

@bhtooefr I think it would probably be harmful to the longevity of the project to restrict who can contribute to it at all, or who can use it that severely. Those parts we probably still want out in the open. Also, since this isn't a business (I didn't mention that before, sorry) I think the project would benefit from the wider community being members, not just a select few. There won't be money to pay anyone, like most OSS projects, we're just working together to try and solve a common problem.

@sam In that case, you’d need a much more complex system to get voting power.

Pure lines of code is such a poor metric, but maybe a “lines added, changed, or removed” metric could determine the percentage of voting share that a person gets? (I can already see massive problems with that, though. Someone could add a bunch of bullshit code to increase their voting share, or remove someone else’s code to block/reduce their vote.)

A “issues resolved” metric is another possibility, but it promotes creating and resolving bullshit issues to increase voting share.

Also, no matter what, I’d strongly consider a contributor license agreement, rather than maintaining full copyright with the contributor. Contributors who haven’t either assigned their copyright to the org or given an unlimited license to the org effectively have a liberum veto on changes of licensing terms, and that’s required massive rewrites for open source projects that have changed terms in the past…

@bhtooefr In general we wouldn't want there to be a percentage of voting share; most definitions of co-op include "one member, one vote" or something along those lines. We specifically want to avoid creating perverse incentives to add more lines or spend an unhealthy amount of time on the project. It's more about when you get equal voting share. Some co-ops have a waiting period, for example where you show a commitment first, then get voting power, or some you have to pay a fee, etc.

@sam coop is always measured by contribution so yes, either material (money, hardware, hosting) or non-material (time, effort) contribution. The question is always - what is the threshold (after which contribution is counted as substantial) and how to measure / evaluate non-material one to match the threshold.

@sam The threshold is usually - "comparable to others" that is for another person to become my partner in coop he needs to contribute at least not less than myself. If there are more of us - to average of others' contribution. Similar could be applied to non-material, conversion from one to another though is always problematic (because is subjective)

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!