This is somewhat of a follow on to my previous criticisms of centralising decentralised development where I was worried that services such as Github and Gitorious were introducing unnecessary centralised workflows and dependencies.

Since then the official Rails repo has moved to Github and I’ve been slowly adding various tid-bits, and having a bit more experience using Github I really like it, and much more so than Gitorious. I prefer the /user/project focus rather than Gitorious’s /project/fork focus, the activity timeline, and being able to ‘watch’ repos. Looking at the interface every day doesn’t give you a headache either.

…and none of this is to say that Gitorious doesn’t fill a need, or Gitorious isn’t good at what it does—we’ll be using a slightly hacked version to coordinate all the development at the upcoming RailsCamp 08 and I think it’ll fit the use case perfectly—it’s just that a superior design and experience does count for a lot, even with the most low-level of dev tools.

…and before you cry ‘hey there they-brigade, it’s open-source!’ I did get Gitorious up-and-running locally and spoke to a local hotshot IA/designer Phil Oye to ask if he’d care to do a redesign. To be honest neither of us cared enough, or felt enough pain, to spend the months… we’re much more excited by building end-user-focussed web apps.

I’m a big fan of design-driven-development, something which Github has done from the get-go… it’s just both fortunate and unfortunate that Github’s an actively supported but closed-source tool.

There’s truth in saying you’re not totally locked into these centralised development services, but only as far as the code itself is concerned. Pull requests, network relations and comments aren’t going anywhere regardless of how distributed git itself can be, and if your development process relies on using those collaboration tools then you’re quite strictly tied into that particular centralised system.

Once Github’s collaboration data (pull requests, comments, watchers, networks, etc) becomes available via their API it will at least create potential for portability and more truly distributed activities, possibly creating the opportunity to extract defacto standards in how these systems could communicate with one another.

Bug fixes, comments and activity appearing and being fixed in repositories across the internet in tandem… teams on different systems that suit them best collaborating… is there something to the idea?