A github first

Like many github users, I often create forks for projects whenever I want to pull down their code, rather than cloning from the source directly.  This is pretty much the default way of working on github, as the site encourages collaboration through individualized repositories.  On my github page, this is what you’d see for my repositories:

It’s front and center, right on my home page.  Only two of those repositories were ones that I created completely fresh, and the rest are forks.

The other day, I posted a question on the StructureMap mailing list, but wound up getting a response in a github pull request!

This is because it’s just as easy to fork a user’s repository as it is the central repository.  Even the concept of a “central repository” isn’t ingrained in git (or github), there are only “blessed” repositories that the OSS project’s organizers agree upon.  For example, the “blessed” AutoMapper repository is just the AutoMapper repository in my github.

Pretty sweet, I can pull in this request locally, as well as any upstream StructureMap changes (as Git allows me to have as many remotes as I want), and see if it works for me.  If it does, I can then issue a pull request to the blessed StructureMap repository.  But if it doesn’t go through, no worries, I have my own StructureMap repository 🙂

</p>

Comparison to CodePlex

CodePlex is fantastic for a public-facing project hub, but it’s still not close to github on the OSS collaboration side.  Here’s an example, my homepage for the AutoMapper repository looks like this:

I have a wealth of information at my disposal here.  For new users, it’s a one-click operation to watch the project, fork it, create a pull request.  I can see how many folks follow the project or forked it.  All the information here is about the repository itself, rather than a project.  Github has a separate page for that, but by default, it’s about collaboration rather than documentation.

On CodePlex, I get a list of checkins:

The list of forks isn’t that much better.  CodePlex is definitely making strides, but you can definitely tell the difference between an OSS project hosting site built around DVCS versus one around centralized version control.  In github, its design is built around distributed collaboration, centered around individual commiters.  In CodePlex, its design is built around centralized projects.

Both definitely have their benefits, as it’s super-easy to get a URL to the CodePlex AutoMapper project page:  http://automapper.codeplex.com.  In fact, I kept the project on CodePlex because its support for project-centric activities I felt was better.  However, its support for collaboration-centric workflows still is pretty far away from github.  Unfortunately, CodePlex has to support both centralized (TFS) and distributed (Hg) source control systems, so I’m not sure how it’ll all shake out in the end…