Where GitHub (Possibly) Went Wrong
While on my delayed train this morning I was listening to episode 80 of the excellent Stack Overflow podcast. In this episode Jeff Atwood was complaining to Joel Spolsky about his problems with GitHub.
GitHub is a social coding site, along the same lines as Sourceforge or Google Code, but focused entirely on the distributed version control system Git. Where GitHub differs from the other project hosting sites, and where I think Jeff’s confusion comes from is that with GitHub the primary structure on their site is that of the developer, not of the project. They treat every developer as a rock star, who is bigger than the projects that they work on.
GitHub makes it incredibly easy to take a codebase, make your own changes and to publish them to world. What GitHub fails to do is to encourage people to collaborate together to push one code base forward. What I’m not suggestion is that branching is a bad idea. Branching code is a useful coding technique which can be used to separate in-development features from other changes until the code has stabilised again. What GitHub focuses on is the changes that an individual developer makes, not the changes required for a particular feature.
When a developer creates a copy of some code of GitHub they get a wiki and an issue tracker as well. This further confuses matters because not only do you have trouble knowing which git tree is the correct one to pull from, but you also don’t know where to report bugs or go to for documentation.
Google Code seems to be in a better position for combining distributed version control with project management. They have an excellent wiki and issue tracker, and give each project a straightforward and simple homepage. You can also use Mercurial, which is similar to git, as your version control system. All that they need to do is allow developers to publish their own changes, but in a markedly separate section to the core code of the project.
I can see how GitHub is nice for developers, but in any mildly successful open source project the number of users vastly outweighs the number of developers. It seems crazy to me to make your primary web presence suited only for the minority of people who are involved with the project.
Comments
Actually, Google Code does offer support for non-project members to publish changes using Mercurial:
http://googlecode.blogspot.com/2009/10/mercurial-server-side-clone-support-for.html
That lets any other user make their own server-side clone and push their own changes up to the server.
Augie Fackler
27 Jan 2010
Chris Wansstrath from Github actually directly addressed this issue in a podcast I listened to: http://thechangelog.com/post/352878673/episode-0-1-0-chris-wanstrath-from-github
They recognize that not being able to determine where the "real" master branch is can become a problem. The good news is that they're convinced there's a good technical solution to help make the social solution easier. By looking just at unique commits, he said (and I'm paraphrasing and misquoting of course) that for a vast majority of projects there is actually a clear "main" branch of development where most changes get pulled in. Identifying that branch prominently is something they're working on.
There's nothing wrong with making developers "rock stars" as long as that doesn't impact usability for non-developers. In fact, I'd argue that making things project-centric is the *problem* not the solution. I know I'm much, much more likely to contribute minor changes back to a project if it's on github just because it's so easy to do and because I don't have to ask any permission.
It'll be exciting to see if they can address the "which fork do I use" problem.
Wes Winham
03 Feb 2010
I think a possible solution would be to have issues apply to every fork of a project.
Matthew Schinckel
15 Apr 2010
To compound the forking problem at GitHub... some idiots who are new to the site, yours truly included, decide to click the "Fork" button just to see what it does, and without as much as an "Are you sure?", and boom! a brand new forked project gets created. I found out how to delete mine, but I'm not sure how many others would bother.
AT
22 May 2010
I don't see anything wrong on this, actually, I much more prefer this viral approach.
I've been around open source since the SourceForge days, and what I can see with GitHub now is that it enables for, at least, a lot more experimentation.
With SourceForge you usually had a crappy project website, close to no documentation, no easy issue tracker, and some hidden indication on how to acquire the latest trunk. Even if the project looked interesting and they actually *had* code, you were just turned down to spend more than 1 minute there.
With GitHub, you have so many things easy accessible (wiki, issues, repository history), and is so easy to fork and pull a branch, that you actually feel motivated to at least experiment. Then maybe you liked, spent some time on your fork and pushed a change or two. The original author can get see your changes and merge right away if he likes.
No blabbering on the project mailing list. No having to put a ticket up, no having to deal with "please attach a better diff if you wanna see your code merged". It's right to what matters: the code the person wrote, instead of "opensource bureaucracy" like most nerds like to do - specially when the project is more popular.
I can't say it went wrong anywhere regarding this. In fact, I think it was right on the nail.
Henrique
06 Jul 2010
What Github needs to do is make the default fork behavior be to inherit the Issue Tracker, and Wiki, the Issue Tracker can create a automatic label identifying the fork. Then if the forking user wishes to they can create an independent Issue Tracker or Wiki, as some Fork may be the root of a new project or become that latter.
Glen Fletcher
27 Jun 2014