
Zed Shaw: Launchpad vs. Github/SysAdmin vs. Coder - thesethings
http://sheddingbikes.com/posts/1299555462.html
======
tedreed
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
> 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://drnicwilliams.com/2009/11/04/hacking-someones-gem-with-github-
and-gemcutter/)

[http://groups.google.com/group/gemcutter/browse_thread/threa...](http://groups.google.com/group/gemcutter/browse_thread/thread/80fd383032105250)

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

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

~~~
kunley
Even worse nightmare is pretending that the code is more stable just by
labeling it as "package vX.Y.Z" and hiding the actual meat behind such
"profesionally" looking cortain.

And yes, I'm an admin for 15 years.

My experience is when software is bad, it's just bad. No packaging system will
help it. If I have a suspicion it's bad, I want to see quickly just how bad it
is and check if I can repair it in half of an hour or drop entirely. Github
helps with such decision greatly.

~~~
bradleyland
I'm not making the argument that giving a package a static label makes it
better, I'm arguing that it makes it more consistently identifiable. When
you're trying to figure out what's breaking your system, consistency is the
key to isolation.

------
kunley
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
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
> 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
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. :-)

------
praptak
_"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
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
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.

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

~~~
zedshaw
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
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

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

------
bretthopper
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
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
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
Maybe I misunderstand how MacPorts works, but I vaguely recall seeing it pull
source code directly from projects.

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

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

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

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

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

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

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

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

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

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

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

~~~
binspace
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!

------
click170
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
You know, I think the cornerstone of Lame-Trolling is pretending like you
failed every reading comprehension class in grade school.

