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

http://sheddingbikes.com/posts/1299555462.html

by thesethings • 15 years ago

179 64 15 years ago

bigiain• 15 years 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?

zedshaw10• 15 years ago

Well, I cooked up an idea:

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• 15 years 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• 15 years ago

This is a superb concept. Would you subscribe to people or projects or both? Where would the user questions come from?

binspace2• 15 years 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.

cdavid2• 15 years 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.

zedshaw10• 15 years 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.

zedshaw10• 15 years ago

That was a joke. You know, those things that make people laugh? In seriousness, it sort of doesn't matter if you're a programmer. Either way works so long as the first thing you get is code. If you're a sysadmin or packager though, that's annoying as hell. You want to just go to /project and not worry about the who's-who of forks.

binspace2• 15 years ago

Zed, I'm a robot, so I'm impervious to jokes, especially deadpan sarcastic ones without proper metadata :-)

And I agree with your serious statement. Yay, happy!

jarin2• 15 years 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.

zedshaw10• 15 years 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.

jarin2• 15 years 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• 15 years 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.

zedshaw10• 15 years 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.

regularfry• 15 years ago

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.

bretthopper• 15 years 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• 15 years 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.

zedshaw10• 15 years 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.

ollysb• 15 years ago

You wonder how much sysadmin effort would be saved if they didn't have to deal with shared libraries between packages. Is it a case of the sysadmin practices not keeping up with the current abundance of disk space/ram or is there still a case for the efficiencies of the shared library model?

jmillikin• 15 years 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/ 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.

zedshaw10• 15 years 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• 15 years 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• 15 years ago

If anyone does something like this, I'd suggest supporting not just http://junk.launchpad.net/~jmillikin/ but also something like 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_chester4• 15 years 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• 15 years 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_chester4• 15 years ago

The key is not about CPU/RAM/IO efficiency, it's administrator time efficiency.

jacques_chester4• 15 years 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.

tedreed4• 15 years 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

zedshaw10• 15 years 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-wit...

http://groups.google.com/group/gemcutter/browse_thread/threa...

Then you got no business being a sysadmin and working this way.

tedreed4• 15 years ago

I see a number of things discussed in those links. Could you clarify which you're referring to?

bradleyland3• 15 years ago

I definitely live more in the sysadmin camp than the programmer camp, so I can see exactly what you're saying without even reading the links.

A programmer is prepared to dive deep. The programmer writes tests that validate their assumptions at ever level. The programmer lives intimately with their project.

Contrast this to the sysadmin. The sysadmin lives wide. He/she has to support many developers and many applications. These days, it's popular to use virtualization to isolate applications in their own little world, but it's also horribly inefficient. I love virtualization because it lets me get the most out of my hardware, but as a responsible sysadmin, I group applications in ways that make sense, rather than firing up a bare bones container for every app. This means that I must maintain some sense of consistency and order in the environment. Imagine the sysadmin's frustration when every programmer they work with thinks it's ok to grab any randomly forked lib from Joe Blow's GitHub repo and expects the sysadmin to integrate it in to the environment. It's a change management nightmare.

Being a sysadmin is about fostering stability and consistency. The server must be up. Apps must be up. The sysadmin's job is to make sure those two conditions remain true, and the "fork and go" mentality makes it a nightmare.

tjogin• 15 years ago

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

click170• 15 years 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.

zedshaw10• 15 years ago

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

rtaycher• 15 years 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• 15 years 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.

praptak2• 15 years 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• 15 years 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.

praptak2• 15 years 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• 15 years 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• 15 years 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• 15 years 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

electrum• 15 years 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.

kunley3• 15 years 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• 15 years 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.

kunley3• 15 years 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• 15 years 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• 15 years 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.

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

Related Stories