Follow

Thinking about how to structure paying contributors to cooperative software: I think you'd start by having the co-op members (whatever that means, possibly contributors if you're analogous to a worker co-op, possibly donors if you're analogous to a consumer co-op) set a road map including a budget for each item on it and a rough order that they should be done in.

If you want to be paid by the co-op for your work, you implement one of the upcoming items on the roadmap. This way you're implementing the features your other cooperators agreed on, not necessarily the ones you personally need next: benefiting the group is prioritized. You can still implement something you need individually, but it will be on a volunteer basis just like commits to most OSS.

Bug fixes and security issues are always eligible for payment, the roadmap is for higher level features, enhancements, technical debt cleanup, etc.

This may lead to pressure on contributors to wait on submitting important changes until they show up on the roadmap. I think this might be fine however. Someone has still done the work and if everyone else hasn't prioritized that work yet it means that it doesn't need to be merged immediately anyways. We can wait and pay someone for their labor in a deferred fashion and they can have the feature for themselves until the group needs it or the budget allows for it.

Code review could also be a paid item to encourage people to actually do them, but I'm not sure how you avoid the pressure to do a lot of cursory reviews just to get paid for them. Maybe the amount paid goes up with the number of issues found (and agreed upon/fixed). This also pays more for reviewing large patches, which is probably good, but also makes people less likely to want to review contributions by experienced contributors who will have less things to point out.

@sam in the DAO/crypto space some groups have solved this by the group voting to accept/not accept a PR as fulfilling the requirements it says it does.
If the group doesn't want to review the PR / vote it as accept it, then either the group doesn't have the technical knowledge to validate the work (which is an issue) or there wasn't really support for the work in the first place.

@sam If the cooperators are invested in the success of the project they might contribute code and advocate for its review and approval (basically, to add it to the roadmap), if they're interested in collecting payment for a roadmap item then they don't have to do the politics part since they're following a roadmap - they know the work they're doing is needed / wanted / has already been decided on.

Sign in to participate in the conversation
social.coop

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