It's definitely annoying when you are trying to find the "canonical" fork of a project on Github, but it's not THAT hard to just look under the project name and click on the "forked from xyz/project" link (projects rarely go more than a couple of forks deep), or in the worst case click on the network tab and look at the tree.
Edit: If it's a Ruby Gem, you can also look up the gem on rubygems.org and click the Homepage link.
See? That's the same as me telling you that to find the code on Launchpad you just... A packager doesn't want to navigate the bizarre tree of forks and junk, they just want official releases. A programmer could care less though.
Then, because projects live under a person, if they want to transfer ownership, the whole damn project basically goes dead and you have to track it down again. Again, if I'm a sysadmin that sucks since I have to keep up on their internal politics. If I'm a programmer I go, meh, and just pull the new stuff.
Haha, I guess I'm proving your point since I'm a programmer and I'm having a problem seeing why navigating forks is such a bad thing.
Plus, I usually just let Moonshine/Puppet take care of the sysadmin part for me and trust that it will grab all of the right packages. The people who write the Puppet recipes would probably feel very differently though.
Looking at the "forked from" field doesn't tell you whether a) it's a random forker who wanted to make a few changes, in which case you want the original, or b) the original project changed hands or was abandoned and the forked version is canonical, in which case you want the fork.
That's not the only problem.
Even with the network tree, you're still screwed, because Github's network graphs are incomplete. Take this brief conversation from ruby-talk last year:
http://www.ruby-forum.com/topic/203100
I challenge you to deduce the result of that discussion from the information available here:
https://github.com/rightscale/right_aws/network
Right now, without delving into the code, I still can't tell which one is supposed to be canonical, if they've diverged irreparably, or if it just doesn't matter which I pick.
Anyone who's paying attention will update the readme in the stale fork to make it really obvious. People don't sometimes because they're lazy, but this is an application of the more general "people suck" rule, and not very specific to Github.
Oh, in the README? Duh. I totally didn't think of that awesome way to communicate to all the package management build systems out there that the repository has moved. I'll get right on building the Turing Oracle so I can solve that "README File English As Redirect" problem.
Right, because package management build systems have obsoleted the need to package managers to be actual people that keep track of the packages that they manage...
Which is "the project"? The answer is all of them AND none of them. That's the nature of GitHub. Zed's point is that for a sysadmin, all this obscurity is unacceptable. Having a canonical source for a package is important. That source should obscure away who the actors are making the package happen. If Pieter wants to hand the project off to Andre, who in turn hands it off to Nathan, that's great, but the sysadmin doesn't really want to track that for every package he/she installs on their server.
That is why launchpad is better for sysadmins. Not because it is better in any general sense. Just because it meets a different set of needs. These are not criticisms of GitHub, these are statements of the reality.
The closest thing GitHub has to a "project" abstraction is the organization:
One could, conceivably, create an organization to manage a project's code, but that doesn't address all of the other package ecosystems that Launchpad executes more deftly.
Edit: If it's a Ruby Gem, you can also look up the gem on rubygems.org and click the Homepage link.