Open Ownership

[tute]

Moving discussion from osscommunity/starters#8 into this new project.

Aidan presented me with the idea of Open Ownership: when a contributor surpasses a given threshold of activity, they earn automatic commit rights. The active community members shape the community, as it happens in Wikimedia and StackOverflow. Also, it lowers the risk of stagnation for a project that loses interest, say, in a company, and would be effectively abandoned. @afeld, do you have more resources on this?

A Software solution would be ideal, as the whole point of Open Ownership is not to depend on people to gain commit rights. To get it started in a lean manner, though, we could add a section to project's READMEs that defines the criteria for gaining commit access. Something like (numbers need to be defined):

# Becoming a team member

You will get automatic commit access to the project when you:

* get accepted 5 patches in a month, and
* actively participate in 3 issues per week

Do you know of any community that works this way? What do you think?

[kfogel]

What's the argument in favor of this?

If a project is abandoned, someone can always clone (fork) it and revive it.

No fully automated analysis of someone's activity is going to be a good judge of whether they should be a committer on some particular copy of a project. Automated tools can assist other humans in making that judgement (see http://www.red-bean.com/kfogel/beautiful-teams/bt-chapter-21.html#contribulyzer for example), but having the entire decision process be automated suffers from two problems. One, the tools have no judgement (they can't distinguish between constructive bug tracker activity and trolling, for example), and two, automatic thresholds just motivate people to game the system -- e.g., submit what should be one patch in 5 parts, so they magically reach their 5-patch threshold.

I don't know of any community that works this way, and if I did, I'd worry for them :-).

I'm not sure what the purpose of Open Ownership is in the context of open source. The whole point of open source is that it makes ownership irrelevant in the first place, since anyone can copy the code. Instead, in open source what matters is who endorses which particular copy, and endorsement by its nature cannot be part of an open ownership structure.

[tute]

Karl, thank you for your input!

What's the argument in favor of this?

To be honest, I have no idea yet of the potential implications of this. If nothing else, it will be at least an interesting social experiment though, unlike https://github.com/illacceptanything/illacceptanything, I'd like to see it working in a "real" software project with "real" responsibilities.

If a project is abandoned, someone can always clone (fork) it and revive it.

That is technically true. And if you are lucky, or have popular communication channels, or have a good set of connections, in the midterm you can always rebuild the community. But for contributors with less reach there's always the risk of a scattered community, united before by this git hub, where people check latest version, publish issues and patches, and where it's not always easy to find what the next better fork is once upstream is abandoned.

No fully automated analysis of someone's activity is going to be a good judge of whether they should be a committer on some particular copy of a project. Automated tools can assist other humans in making that judgement [...].

Tools that assist rather than decide sound indeed more reliable (Contribulyzer looks very useful) provided there's someone to be assisted to take the decision. I agree that there's no concrete metric that can automatically tell who will be a good contributor or not. I also see the potential for gaming a simple system where there're not many humans involved.

The whole point of open source is that it makes ownership irrelevant in the first place, since anyone can copy the code.

Again, that is theoretically true, but there're practical implications when a project centralizes the community and contributions.

The concrete case that pushes me towards this idea is http://github.com/doorkeeper-gem/doorkeeper, an omniauth provider library. It was built by a company that was bought, and everyone lost interest on it. There were dozens of contributors, hundreds of people discovering bugs and security issues, and thousands of downloads from the package manager. And there were dozens of forks solving the same issue over and over again too, with similar patches being ignored waiting to be merged upstream. If the owners hadn't responded to requests for commit access, that project would have potentially died.

A friend had an analogous case, where he lost access to the open source project he maintained after leaving the company, company that isn't interested in keeping that project alive.

If these cases had had an implementation of "open ownership" as we are discussing, the community backbones wouldn't have depended solely on a company or relatively small set of people. Companies tend to have more reach than the individuals working on the project, so individuals don't have the possibility to tell many people that the project has been moved or renamed.

[kfogel]

Granting commit access liberally is often a good thing; it's not "open ownership" of the project per se, but rather more-open ownership of that particular copy of the project. But I think it's simply a strategy -- often a good one -- for managing a project in which there is no longer a single large investor.

I don't quite understand what it means for your friend to have "lost access to the open source project he maintained after leaving the company". If it's open source, then he didn't lose access, by definition. He may have chosen not to participate anymore, or chosen not to create a new fork of the project if the copy he used to work on was no longer being maintained or he no longer had commit access, or whatever. But if something is open source, that means that no one can ever "lose access" to it (unless they lose their Internet connection, or something, but that's something about the person not the project).

[tute]

I don't quite understand what it means for your friend to have "lost access to the open source project he maintained after leaving the company". If it's open source, then he didn't lose access, by definition.

Indeed he didn't lose access to the source, but to the community. Many contributors know the company behind of the project, but not himself as maintainer, and his new fork. Community is the main reason why we work in the open, but community is centralized somewhere, and that can't be moved over as easily as the source.

[max-mapper]

this is how we do it over in my corner of node land: http://openopensource.org/. and this is an example project that uses that method, it has 19 owners who get input on project level decisions