7 ms·

Zed Shaw: Launchpad vs. Github/SysAdmin vs. Coder

179 points by thesethings 16y ago

bigiain 16y ago
The last paragraph is making me think... "Really I think you need a 3rd system that's radically different." 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?
- zedshaw 16y ago
  Well, I cooked up an idea: http://fmlr.me/ http://fmlr.me/ But, sort of got stuck at how to do the client. I've recently relearned GUI coding and will probably dust the idea off and try it again soon.
  - ilikepi 16y ago
    Hmm...It would be interesting if one could subscribe to a personalized feed of some sort. Currently I skim my github feed in Google Reader every couple days. The biggest problem with it is that I watch RVM, which is fairly high traffic. It would be neat if I could subscribe to, say, only tag pushes on the RVM repo.
  - extension 16y ago
    This is a superb concept. Would you subscribe to people or projects or both? Where would the user questions come from?
binspace 16y ago
> 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. 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.
- cdavid 16y ago
  Especially with organizations being free (for open source projects at least), I think this usage will increase for github. As for Zed main argument, I am not sure it is the whole story. I think the launchpad vision is great, but the delivery mostly a failure. The fundamental idea of being able to track downstream bugs in a project sounds really right to me, but launchpad UI is really a big mess: you need a lot of hoop to get the code. Sure, you can do lp:foo for project foo, but few people know bzr, and for a long time, there were numerous issues between different incompatible bzr versions (which have been fixed ever since I think). Forcing people to use bzr has been one cause of failure I think. I also wonder how much differences can be attributed to how the things came to life: launchpad wanted to do many things from the start, wherease github grew organically.
  - zedshaw 16y ago
    I don't think the launchpad UI is a mess, if you don't expect to be able to browse code in it. The code browsing is horrible. But, the PPA, branch tracking, bug tracking, and other stuff is great. I can tell you from personal experience though that github's bug tracking is stupid as all hell. Remember that whole blow-up over my book and people turning one damn bug into a massive flame war? That all happened because I couldn't figure out how to contact the project owner directly and figured the bug was the best way to do it. Little did I know that this would turn into a massive idiot festival with no way to turn the damn bug or emails off. So, I disagree, launchpad's UI is only broken if you're into code. Github's is broken if you're into projects. Too bad they both can't just make both use cases a nice experience.
    - aaronbrethorst 16y ago
      i think the odds of the github folks figuring out projects are far greater than the launchpad folks sorting out code (or proper whitespace and padding, for that matter). that said, i do think that launchpad has some excellent attributes, like a bug tracker that doesn't make me want to defenestrate its author.
    - cdavid 16y ago
jarin 16y ago
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.
- zedshaw 16y ago
  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.
  - jarin 16y ago
    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.
- technomancy 16y ago
  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.
  - zedshaw 16y ago
    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.
bretthopper 16y ago
It's not just Launchpad that's "SysAdmin" friendly. Sourceforge and Google Code are much closer to the Launchpad model than to Github's. I know Zed Shaw isn't saying one is better, but doesn't the popularity of Github compared these sites tell us something?
- Andys 16y ago
  All its telling me is that I want a whole OS based on the Github model. I like the feel of working on github, I'd like to take the RVM/rubygems/github theme and extend it past Ruby, to the whole OS and its package manager.
  - zedshaw 16y ago
    That was my idea too, and why I started working on a light fork of pkgsrc to try it. Sadly, nobody who has to maintain systems at scale will use a package manager that just pulls random repos and "makes and prays". I've been trying to find the middle ground since then but haven't come up with it yet.
    - jacques_chester 16y ago
      Maybe I misunderstand how MacPorts works, but I vaguely recall seeing it pull source code directly from projects.
      - zedshaw 16y ago
        MacPorts? I was using NetBSD pkgsrc, which does either source builds or packages from the same system. So, you can lock it at a particular source revision/release and make an official package like a .deb, or do a gentoo/MacPorts style source build.
        xiongchiamiov 16y ago
        As I understand it, Arch's pkgbuilds are similar. The nice thing is that they have the flexibility to do whatever you want, whether it be updating a svn repo, downloading a binary, curling a script, building from source, whatever.
jmillikin 16y ago
I really wish Launchpad had at least some 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. 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. Ideally, there would be a http://junk.launchpad.net/~jmillikin/ http://junk.launchpad.net/~jmillikin/ that I could just ``bzr push`` random stuff to and have it show up. † Zed suggests this is due to developer vanity, but actually I see no need to pollute the precious global namespace with half-baked code.
- zedshaw 16y ago
  Hmmmm, that's a damn good idea. /project is for projects, and the canonical true ruler of such. /~dude is for programmers and their forks, half-baked ideas, and random pushes. Yeah, that'd work.
  - pilif 16y ago
    That's about the model Gitorious uses (minus the integration into debian packaging and apt repositories). In Gitorious the project is the main resource. Developers can be working on a project and they get their own area where they can put forks of the project or other one-off stuff. You can even easily (for a definition of easy as "doable with some effort") host one yourself for internal projects as it's available under AGPL. It's still not as easy to use as github (due to the project hurdle and less refined UI) and the public service lacks what makes github especially good: the large community of users
  - wnewman 16y ago
    If anyone does something like this, I'd suggest supporting not just http://junk.launchpad.net/~jmillikin/ http://junk.launchpad.net/~jmillikin/ but also something like http://junk.launchpad.net/~~jmillikinpersonalwebsite.com/ http://junk.launchpad.net/~~jmillikinpersonalwebsite.com/ , embedding other domain names in URLs for your service (with a policy of only permitting people to set up such double-tilde URLs in your service when they control the corresponding domain). Then to the extent that your service ever enjoys a success disaster where newbies naturally discover that all the mnemonic usernames like newman and whn and wnewman are already taken, you have relieved the pressure by providing a mechanism to delegate the unique name problem to the existing domain name system.
jacques_chester 16y ago
Here's a thought-bubble about packaging and distributions. 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. Possible solutions: * Cross-application consistency checks. This seems to be the way Singularity is heading. * Smaller distributions -- or rather, standalone VM images that have a carefully curated mini-distro built around single applications.
- rbranson 16y ago
  The VM image idea might be most palatable under a kernel-threading scheme like Linux OpenVZ or Solaris Zones. They are very inexpensive and quite efficient.
  - jacques_chester 16y ago
    The key is not about CPU/RAM/IO efficiency, it's administrator time efficiency.
  - jacques_chester 16y ago
    The key is not about CPU/RAM/IO efficiency, it's administrator time efficiency. I mean, you're absolutely right; but at a certain level it's irrelevant.
tedreed 16y ago
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. I also know plenty of other sysadmins who use github but find no value at all in Launchpad. 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. 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. shrug
- zedshaw 16y ago
  > 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. Yeah, I think "BOOM!" is right. If you can't see the flaw in stuff like this: http://drnicwilliams.com/2009/11/04/hacking-someones-gem-with-github-and-gemcutter/ http://drnicwilliams.com/2009/11/04/hacking-someones-gem-wit... http://groups.google.com/group/gemcutter/browse_thread/thread/80fd383032105250 http://groups.google.com/group/gemcutter/browse_thread/threa... Then you got no business being a sysadmin and working this way.
  - tedreed 16y ago
    I see a number of things discussed in those links. Could you clarify which you're referring to?
    - Macha 16y ago
      From my reading of it (disclaimer: I've only done a tiny amount with ruby) A package uses rubygem to install a-blah 1. This causes packages using require 'blah' that are not connected to rubygems to break if the a-blah installation overwrote an existing version of blah 1.1 (which you installed alongside said packages)
      - 16y ago
tjogin 16y ago
Launchpad is kind of poorly designed, looks a bit messy. I think that matters too.
click170 16y ago
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.
- zedshaw 16y ago
  You know, I think the cornerstone of Lame-Trolling is pretending like you failed every reading comprehension class in grade school.
rtaycher 16y ago
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.
Locke1689 16y ago
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.
praptak 16y ago
"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 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. And small projects are just big project that haven't grown yet :)
- Confusion 16y ago
  As a programmer using the code others publish on Github, I'm definitely interested in those, the more so when I want to contribute. Many project are sorely lacking a way to report and discuss (possible) bugs (bug tracker, mailing list, hell, an email address would be fine) and to figure out what version of the code contains what (release history/changelog and version numbers). However small, I find projects without those much harder to use and improve.
  - praptak 16y ago
    Yes - the administrative stuff is important when contributing. Bug tracker + versioning might save you effort in cases when the bug you found is already being worked on or maybe even has a fix waiting for release.
davidw 16y ago
Good open source projects are projects, which are made up of code and people. I've never cared for the idea that a project belongs to one person on github.
- jwhite 16y ago
  Agreed. I've seen projects that have their own username to host the project repository (or repositories), rather than using the author's username. Quicklisp does this, for instance.
- mpk 16y ago
  Well, github can do that too. You can set up an organization that isn't tied to any particular account and manage repos from there. Projects start out as one person messing with code. Of course the project belongs to one person at that point. As more people join in you can re-structure the project into an organization with multiple owners. Check out the announcement from June 2010 https://github.com/blog/674-introducing-organizations https://github.com/blog/674-introducing-organizations
  - electrum 16y ago
    The problem is that GitHub has no way to point the original project to the official project. The new organization project will still say "forked from" the original person's project.
kunley 16y ago
There's also one issue not mentioned in this article: 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. 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.
- uxp 16y ago
  When I visit a GitHub page of a new project that I find interesting, I would like to hack on or use as an end-user I don't even have to click on the clipboard icon to get the URL. I just take the URL straight from my browser and put it into my terminal to obtain a local copy over https, or by changing https to git and adding .git at the end: git clone https://github.com/USER/PROJECTNAME git clone git://github.com/USER/PROJECTNAME.git Can you tell me off the top of your head how to checkout the source for $RANDOMPROJECT on sourceforge? What's the common URL to browse the sourcecode? One of my buggest complaints about sourceforge is that there is no easy way to grab an actual URL of a package for a project to download without manually editing it if you wanted to cURL or Wget it to a remote server you are shelled into. After enough years I've learned to download packages from sourceforge using this URL form: curl -O http://MIRRORNAME.dl.sourceforge.net/project/PROJECTNAME/SOMERANDOMFOLDER/PROJECTNAME-PROJECTVERSION/PROJECTNAME-PROJECTVERSION.tar.gz My hats off to the guys at GitHub. They took usability to the next level.
  - kunley 16y ago
    > Can you tell me off the top of your head how to checkout the source for $RANDOMPROJECT on sourceforge? I can't. That was the point, I'm always lost there..
jdub 16y ago
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. Zed Shaw is trying to divine the failures of Launchpad backwards. When you know the story behind it, it becomes brutally obvious. :-)
mstevens 16y ago
The problems I personally find with launchpad are: a) It's slow. Pages seem to take an age to load. b) I can never find anything. My problems with github: a) Fork queues never seem to work. Support will occasionally respond to complaints and fix a specific one, but never the general problem.
deleted 16y ago
[deleted]

179 points by thesethings 16y ago

The last paragraph is making me think... "Really I think you need a 3rd system that's radically different." 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?

zedshaw 16y ago
Well, I cooked up an idea: http://fmlr.me/ http://fmlr.me/ But, sort of got stuck at how to do the client. I've recently relearned GUI coding and will probably dust the idea off and try it again soon.
- ilikepi 16y ago
  Hmm...It would be interesting if one could subscribe to a personalized feed of some sort. Currently I skim my github feed in Google Reader every couple days. The biggest problem with it is that I watch RVM, which is fairly high traffic. It would be neat if I could subscribe to, say, only tag pushes on the RVM repo.
- extension 16y ago
  This is a superb concept. Would you subscribe to people or projects or both? Where would the user questions come from?

binspace 16y ago

> 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. 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.

cdavid 16y ago
Especially with organizations being free (for open source projects at least), I think this usage will increase for github. As for Zed main argument, I am not sure it is the whole story. I think the launchpad vision is great, but the delivery mostly a failure. The fundamental idea of being able to track downstream bugs in a project sounds really right to me, but launchpad UI is really a big mess: you need a lot of hoop to get the code. Sure, you can do lp:foo for project foo, but few people know bzr, and for a long time, there were numerous issues between different incompatible bzr versions (which have been fixed ever since I think). Forcing people to use bzr has been one cause of failure I think. I also wonder how much differences can be attributed to how the things came to life: launchpad wanted to do many things from the start, wherease github grew organically.
- zedshaw 16y ago
  I don't think the launchpad UI is a mess, if you don't expect to be able to browse code in it. The code browsing is horrible. But, the PPA, branch tracking, bug tracking, and other stuff is great. I can tell you from personal experience though that github's bug tracking is stupid as all hell. Remember that whole blow-up over my book and people turning one damn bug into a massive flame war? That all happened because I couldn't figure out how to contact the project owner directly and figured the bug was the best way to do it. Little did I know that this would turn into a massive idiot festival with no way to turn the damn bug or emails off. So, I disagree, launchpad's UI is only broken if you're into code. Github's is broken if you're into projects. Too bad they both can't just make both use cases a nice experience.
  - aaronbrethorst 16y ago
    i think the odds of the github folks figuring out projects are far greater than the launchpad folks sorting out code (or proper whitespace and padding, for that matter). that said, i do think that launchpad has some excellent attributes, like a bug tracker that doesn't make me want to defenestrate its author.
  - cdavid 16y ago

jarin 16y ago

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.

zedshaw 16y ago
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.
- jarin 16y ago
  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.
technomancy 16y ago
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.
- zedshaw 16y ago
  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.

bretthopper 16y ago

It's not just Launchpad that's "SysAdmin" friendly. Sourceforge and Google Code are much closer to the Launchpad model than to Github's. I know Zed Shaw isn't saying one is better, but doesn't the popularity of Github compared these sites tell us something?

Andys 16y ago
All its telling me is that I want a whole OS based on the Github model. I like the feel of working on github, I'd like to take the RVM/rubygems/github theme and extend it past Ruby, to the whole OS and its package manager.
- zedshaw 16y ago
  That was my idea too, and why I started working on a light fork of pkgsrc to try it. Sadly, nobody who has to maintain systems at scale will use a package manager that just pulls random repos and "makes and prays". I've been trying to find the middle ground since then but haven't come up with it yet.
  - jacques_chester 16y ago
    Maybe I misunderstand how MacPorts works, but I vaguely recall seeing it pull source code directly from projects.
    - zedshaw 16y ago
      MacPorts? I was using NetBSD pkgsrc, which does either source builds or packages from the same system. So, you can lock it at a particular source revision/release and make an official package like a .deb, or do a gentoo/MacPorts style source build.
      - xiongchiamiov 16y ago
        As I understand it, Arch's pkgbuilds are similar. The nice thing is that they have the flexibility to do whatever you want, whether it be updating a svn repo, downloading a binary, curling a script, building from source, whatever.

jmillikin 16y ago

I really wish Launchpad had at least some 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. 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. Ideally, there would be a http://junk.launchpad.net/~jmillikin/ http://junk.launchpad.net/~jmillikin/ that I could just ``bzr push`` random stuff to and have it show up. † Zed suggests this is due to developer vanity, but actually I see no need to pollute the precious global namespace with half-baked code.

zedshaw 16y ago
Hmmmm, that's a damn good idea. /project is for projects, and the canonical true ruler of such. /~dude is for programmers and their forks, half-baked ideas, and random pushes. Yeah, that'd work.
- pilif 16y ago
  That's about the model Gitorious uses (minus the integration into debian packaging and apt repositories). In Gitorious the project is the main resource. Developers can be working on a project and they get their own area where they can put forks of the project or other one-off stuff. You can even easily (for a definition of easy as "doable with some effort") host one yourself for internal projects as it's available under AGPL. It's still not as easy to use as github (due to the project hurdle and less refined UI) and the public service lacks what makes github especially good: the large community of users
- wnewman 16y ago
  If anyone does something like this, I'd suggest supporting not just http://junk.launchpad.net/~jmillikin/ http://junk.launchpad.net/~jmillikin/ but also something like http://junk.launchpad.net/~~jmillikinpersonalwebsite.com/ http://junk.launchpad.net/~~jmillikinpersonalwebsite.com/ , embedding other domain names in URLs for your service (with a policy of only permitting people to set up such double-tilde URLs in your service when they control the corresponding domain). Then to the extent that your service ever enjoys a success disaster where newbies naturally discover that all the mnemonic usernames like newman and whn and wnewman are already taken, you have relieved the pressure by providing a mechanism to delegate the unique name problem to the existing domain name system.

jacques_chester 16y ago

Here's a thought-bubble about packaging and distributions. 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. Possible solutions: * Cross-application consistency checks. This seems to be the way Singularity is heading. * Smaller distributions -- or rather, standalone VM images that have a carefully curated mini-distro built around single applications.

rbranson 16y ago
The VM image idea might be most palatable under a kernel-threading scheme like Linux OpenVZ or Solaris Zones. They are very inexpensive and quite efficient.
- jacques_chester 16y ago
  The key is not about CPU/RAM/IO efficiency, it's administrator time efficiency.
- jacques_chester 16y ago
  The key is not about CPU/RAM/IO efficiency, it's administrator time efficiency. I mean, you're absolutely right; but at a certain level it's irrelevant.

tedreed 16y ago

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. I also know plenty of other sysadmins who use github but find no value at all in Launchpad. 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. 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. shrug

zedshaw 16y ago
> 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. Yeah, I think "BOOM!" is right. If you can't see the flaw in stuff like this: http://drnicwilliams.com/2009/11/04/hacking-someones-gem-with-github-and-gemcutter/ http://drnicwilliams.com/2009/11/04/hacking-someones-gem-wit... http://groups.google.com/group/gemcutter/browse_thread/thread/80fd383032105250 http://groups.google.com/group/gemcutter/browse_thread/threa... Then you got no business being a sysadmin and working this way.
- tedreed 16y ago
  I see a number of things discussed in those links. Could you clarify which you're referring to?
  - Macha 16y ago
    From my reading of it (disclaimer: I've only done a tiny amount with ruby) A package uses rubygem to install a-blah 1. This causes packages using require 'blah' that are not connected to rubygems to break if the a-blah installation overwrote an existing version of blah 1.1 (which you installed alongside said packages)
    - 16y ago

tjogin 16y ago

Launchpad is kind of poorly designed, looks a bit messy. I think that matters too.

click170 16y ago

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.

zedshaw 16y ago
You know, I think the cornerstone of Lame-Trolling is pretending like you failed every reading comprehension class in grade school.

rtaycher 16y ago

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.

Locke1689 16y ago

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.

praptak 16y ago

"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 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. And small projects are just big project that haven't grown yet :)

Confusion 16y ago
As a programmer using the code others publish on Github, I'm definitely interested in those, the more so when I want to contribute. Many project are sorely lacking a way to report and discuss (possible) bugs (bug tracker, mailing list, hell, an email address would be fine) and to figure out what version of the code contains what (release history/changelog and version numbers). However small, I find projects without those much harder to use and improve.
- praptak 16y ago
  Yes - the administrative stuff is important when contributing. Bug tracker + versioning might save you effort in cases when the bug you found is already being worked on or maybe even has a fix waiting for release.

davidw 16y ago

Good open source projects are projects, which are made up of code and people. I've never cared for the idea that a project belongs to one person on github.

jwhite 16y ago
Agreed. I've seen projects that have their own username to host the project repository (or repositories), rather than using the author's username. Quicklisp does this, for instance.
mpk 16y ago
Well, github can do that too. You can set up an organization that isn't tied to any particular account and manage repos from there. Projects start out as one person messing with code. Of course the project belongs to one person at that point. As more people join in you can re-structure the project into an organization with multiple owners. Check out the announcement from June 2010 https://github.com/blog/674-introducing-organizations https://github.com/blog/674-introducing-organizations
- electrum 16y ago
  The problem is that GitHub has no way to point the original project to the official project. The new organization project will still say "forked from" the original person's project.

kunley 16y ago

There's also one issue not mentioned in this article: 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. 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.

uxp 16y ago
When I visit a GitHub page of a new project that I find interesting, I would like to hack on or use as an end-user I don't even have to click on the clipboard icon to get the URL. I just take the URL straight from my browser and put it into my terminal to obtain a local copy over https, or by changing https to git and adding .git at the end: git clone https://github.com/USER/PROJECTNAME git clone git://github.com/USER/PROJECTNAME.git Can you tell me off the top of your head how to checkout the source for $RANDOMPROJECT on sourceforge? What's the common URL to browse the sourcecode? One of my buggest complaints about sourceforge is that there is no easy way to grab an actual URL of a package for a project to download without manually editing it if you wanted to cURL or Wget it to a remote server you are shelled into. After enough years I've learned to download packages from sourceforge using this URL form: curl -O http://MIRRORNAME.dl.sourceforge.net/project/PROJECTNAME/SOMERANDOMFOLDER/PROJECTNAME-PROJECTVERSION/PROJECTNAME-PROJECTVERSION.tar.gz My hats off to the guys at GitHub. They took usability to the next level.
- kunley 16y ago
  > Can you tell me off the top of your head how to checkout the source for $RANDOMPROJECT on sourceforge? I can't. That was the point, I'm always lost there..

jdub 16y ago

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. Zed Shaw is trying to divine the failures of Launchpad backwards. When you know the story behind it, it becomes brutally obvious. :-)

mstevens 16y ago

The problems I personally find with launchpad are: a) It's slow. Pages seem to take an age to load. b) I can never find anything. My problems with github: a) Fork queues never seem to work. Support will occasionally respond to complaints and fix a specific one, but never the general problem.

deleted 16y ago

[deleted]