So Github is a good example of why the traditional open/closed dichotomy falls apart on the web.
The things that make Github really valuable are by definition closed. They own a well-known URL and have a ton of content behind it. I know where to go to find projects, I have a consistent workflow for acquiring or modifying those projects, and I have a reliable method for commenting on and contributing back to those projects. Even if Github were completely open and simple to customize and deploy (which are very different things), a fork would have very little of the value we associate with the original.
Not an open/closed issue, but illustrative of the concept: Google+ is a noticeably better written piece of software than Facebook, but no one uses it because that's not where they can see their sister's baby pictures.
This is very different from desktop applications, such as Office. Assuming file interoparability, I can use an alternative that I like better to improve my workflow without losing much value.
So what we really need is to move away from focusing on project source and toward open data. We should be pushing for better and richer APIs for third-party access to large datasets.
Except for the single URL, there's nothing in there which couldn't work using an open, federated Github implementation.
Take the example of the StatusNet server I used to run own my VPS. I would go to Identi.ca or any other site, and to follow a user I'd just have to click on "Subscribe", fill in my handle (easy to automate) and then I'd be redirected to my own server, where I could with one click confirm the subscription.
The messages from that user would get POSTed to my StatusNet server, which would display them in my feed as if it was a local user.
Doing the same with forking, pull requests and bug reports is perfectly feasible; there's nothing inherently "closed" about an easy, consistent interface and workflow.
I think "consistent" is the operative word there. On a desktop app, if I change something it changes the entire experience and only for me. On the other hand, if on my theoretical distributed github host I decide that I hate markdown and I want my comments to use textile instead, then not only do I not solve my own itch (I still have to deal with markdown on everyone else's repos) but I've created friction for everyone else who comes to my repo and wants to comment like they do everywhere else.
Multiply that by several thousand hosts and the friction involved in using, let alone contributing to a project goes up considerably. Having a world where every repo uses the same visual and interaction metaphors and supports the same features is a huge UX win, almost regardless of the quality of that interface.
We used to have something sort of federated for source management. Before Github basically won everyone had their own bugtracker and repo set up. It was not uncommon to spend an hour trying to figure out where they hid the pull URL, then installing whichever version control tool they were using, then fighting with whatever half functional import tool you needed to convert their repo to whatever version control your project had. Then spend another half hour creating yet another account and then fighting with whatever half functional plugin they had installed or trying to figure out the difference between "Critical" and "Severe" just to submit a bug.
We didn't have a federated system, we had a bunch of silos to which we would connect to. The advantage of a federated system is that you use your system to interact with others' data, so the experience is consistent to you†. The server to server protocols are domain specific (unlike HTML), so it's much harder to deviate from the standard without breaking the connections.
In the end what you're advocating for is governance, but I disagree that it must be enforced top-down; shared consensus works in irrigation systems in Nepal, and it works in online systems as well.
† Mostly, but then again, Github isn't perfect either. Some repos don't have READMEs, some don't accept pull requests (e.g., torvalds/linux), many depend on various build tools
The things that make Github really valuable are by definition closed. They own a well-known URL and have a ton of content behind it. I know where to go to find projects, I have a consistent workflow for acquiring or modifying those projects, and I have a reliable method for commenting on and contributing back to those projects. Even if Github were completely open and simple to customize and deploy (which are very different things), a fork would have very little of the value we associate with the original.
Not an open/closed issue, but illustrative of the concept: Google+ is a noticeably better written piece of software than Facebook, but no one uses it because that's not where they can see their sister's baby pictures.
This is very different from desktop applications, such as Office. Assuming file interoparability, I can use an alternative that I like better to improve my workflow without losing much value.
So what we really need is to move away from focusing on project source and toward open data. We should be pushing for better and richer APIs for third-party access to large datasets.