GitHub and "canonical" vs "original"

governance.md

so re this:

https://www.pandastrike.com/posts/20150610-thought-experiment-github-community-view

@bkeepers's response was this:

I think it’s fundamentally a question of governance, which GitHub has been agnostic on thus far. @gilesgoatboy

— Brandon Keepers (@bkeepers) 10 March 2016

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

I disagree. I think GitHub's made some very specific assumptions about governance:

1. Governance exists
2. The people who use the project are in communication with the person who originated the project
3. The originator has any opinion at all about what the project does next
4. If you create code which other people adopt and modify, you have an obligation to settle any disagreements they have amongst themselves, and an obligation to pay attention to them in the first place
5. If your repo is more widely-used and current than the originator's repo, but GitHub users can't discover your repo and always end up at the originator's repo, that's not a user interface problem, it's a problem with the governance of the originator's repo and (somehow) with yours as well.

Number 5 doesn't describe me, and I take the assumptions in number 4 with a big grain of salt.

But, if my thought experiment revealed any kind of problem with GitHub, I think that problem would be that GitHub calls this agnosticism in the first place. (If I understand correctly, @bkeepers works for GitHub.) This is not agnostic. This is a set of assumptions about social obligations, social roles, and therefore governance.

GitHub's awesome, but I think this is indeed a subtle problem in its design assumptions, and it's the kind of subtle problem which evolves into a glaringly obvious problem as a user base gets bigger. I'd need to be a time traveller in order to tell you definitively whether or not it will ever become a big problem. However, it was a tiny problem years ago, and it's a small problem now. I don't think that's a good sign.

I don't totally understand this, but I think I disagree with it:

a world where code can be distributed but communities can't

Distributed version control means that when I clone or fork a repository, I get a full copy of all the changes to the code. But I don't get a full copy of the community. Forking divides the community. This was a big concern with forks in 2008, and I still don't think we have a full grasp on the repercussions.

The Node.js/io.js fork is probably the best story of a fork resulting in better software overall.

This could be an example of why forking should be hard. It's hard to imagine a better scenario than the current state, where the entire community coalesced around one implementation. Would the community be better off if GitHub had automatically pointed people to io.js? I honestly don't know. I started to get a little terrified when *-iojs forks of node modules were popping up. Eventually I imagine we'd start to see something akin to web standards for node implementations, where each "vendor" implements the spec plus some extra sugar. I don't think I could make the argument that this is better.

In high-profile situations like Node.js/io.js, everybody knows about it anyway, so it's not a huge problem. It's only in the smaller communities where this seems to be a real problem, at least so far.

This is a really great point, and a pain point I have experienced personally.

I don't know the answer. I just know there are huge repercussions that need to be carefully considered.