As a sysadmin, I have to say that I hate Launchpad. I always have click many levels deep to find the thing I want. The interface just sucks.<p>I also know plenty of other sysadmins who use github but find no value at all in Launchpad.<p>Also: FWIW, I never notice folks' names on github. The important thing for me is that the code is right there front and center. If I want to download it, I click the clipboard button and then go clone it. Boom.<p>Edited to add: I also think that if it's not immediately apparent which fork is the "canonical" one, it probably doesn't matter. Just grab whatever looks most popular. If you decide you'd rather have a different one, then grab that later. <i>shrug</i>
There's also one issue not mentioned in this article:<p>Lots (if not most) of the code has documentation so poor, that there's no way to determine what it's really worth other than looking at the code, examples, tests. Github does it right by enabling you to browse the code right away and make your opinion.<p>This is also the reason why Sourceforge and other *forges are doomed - and to a lesser extent google code too. They present complicated interface but all in all you end up downloading the tgz only to determine later that in most cases it wasn't what you're looking for. All that buzz because of the premise that said package is actually worth your attention. Well, usually it's not (but probably is for someone else). So it is right and sane to give an opportunity to decide it as quickly as possible, by showing the code tree as quickly as possible.
Launchpad was conceived from the perspective of an organisation optimising the process of working on and building Debian packages (Ubuntu/Canonical), designed the same way 90s three-tier systems were: database schema first, and built as a monolithic platform rather than iteratively as a user-facing product.<p>Zed Shaw is trying to divine the failures of Launchpad backwards. When you know the story behind it, it becomes brutally obvious. :-)
<i>"Programmers don't care about version numbers, release history, bug trackers, mailing lists, nothing. Especially if the project is relatively small. Just the code please.</i>"<p>I disagree. Experienced programmers definitely care about bug trackers and version numbers. Once you get bitten by version skew or lose a day trying to reproduce a bug against a wrong version, you start to care about such things.<p>And small projects are just big project that haven't grown yet :)
I really wish Launchpad had at least <i>some</i> support for the GitHub model. Sometimes I don't want to register a project for some half-hour code dump; I want to push it out, namespaced under my uid† to an easily locateable repository.<p>The +junk feature sort of does this, but it's a lot more awkward to use than GitHub because viewers have to jump through flaming hoops to get to the code.<p>Ideally, there would be a <a href="http://junk.launchpad.net/~jmillikin/" rel="nofollow">http://junk.launchpad.net/~jmillikin/</a> that I could just ``bzr push`` random stuff to and have it show up.<p>† Zed suggests this is due to developer vanity, but actually I see no need to pollute the precious global namespace with half-baked code.
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.<p><i>Edit: If it's a Ruby Gem, you can also look up the gem on rubygems.org and click the Homepage link.</i>
It's not just Launchpad that's "SysAdmin" friendly. Sourceforge and Google Code are much closer to the Launchpad model than to Github's.<p>I know Zed Shaw isn't saying one is better, but doesn't the popularity of Github compared these sites tell us something?
Good open source projects are <i>projects</i>, which are made up of code and people. I've never cared for the idea that a project belongs to one person on github.
The last paragraph is making me think...<p>"Really I think you need a 3rd system that's radically different."<p>I think he's right. I'm not sure what that 3rd system would look like. I wonder if a meta-service piggybacking on both Github and Launchpad would work?
The problems I personally find with launchpad are:<p>a) It's slow. Pages seem to take an age to load.<p>b) I can never find anything.<p>My problems with github:<p>a) Fork queues never seem to work. Support will occasionally respond to complaints and fix a specific one, but never the general problem.
Here's a thought-bubble about packaging and distributions.<p>In a single piece of software, the compiler can enforce some degree of consistency between different components. In a distribution this is done manually. That's why it scales poorly.<p>Possible solutions:<p>* Cross-application consistency checks. This seems to be the way Singularity is heading.<p>* Smaller distributions -- or rather, standalone VM images that have a carefully curated mini-distro built around single applications.
As a middle ground, how does Google Code work? The project lives under its own name and has specific, transferrable maintainers, but pulling source code is very easy and it's easy to see changes as they come and go. On the other hand, GCode isn't based only around DVCS, so the fork model doesn't work as well.
I thinks this is fairly wrong as its more of a project based (launchpad) vs code based(github) approach. Sys admins can write a decent amount of short scripts which don't mesh well with a project based approach, many programmers may prefer github for scaling down more and making the code easier to find but the more stability you want the more you might like a project like approach(until you want to make a quick contribution). I bet lots of larger teams might prefer to grab a library of launchpad.
> The second you made Github more "SysAdmin friendly" you'd piss off the Programmers. Their egos are too softly stroked by having their name first in the URL.<p>I don't think that's true. Having the name first is great for uniqueness of the fork, but has been a pain when finding the canonical version. I've seen plenty of projects that adopt the similarly named user account, which is great.
False dichotomy.
Also, github puts the author name before the project name for namespace reasons, not for egotistical ones. At least do your research before bashing them.