Git Hacking: A Social Layer for GitHub
readwriteweb.com
readwriteweb.com
Why would I want to contribute to someone's project that I don't even use? What would inspire me to all of the sudden want to hack on git's internals and then not dive into the source? On one hand, yeah, finding some menial bug or documentation fix I can work on to start contributing to a project is great, but at the higher levels just presenting tasks from issue trackers for me to smash, I don't think is a great idea.
Look at the ActiveRecord/AREL rewrite, sure @tenderlove was just squashing bugs in the Lighthouse tracker but only because, as he says, "AT&T Interactive started paying me to work on Rails" (http://engineering.attinteractive.com/2010/10/arel-two-point...) If you don't dive in real deep you can't really make things better and that takes a lot of time. You end up investing a lot in the project and the people around the project. So I don't see where GitHub doesn't support this. How does your product makes any of this any easier/better/more full of awesome?
An example from my experience: before I started working on Rubygems' testing infrastructure, I wanted to contribute to Rails, but didn't know where to start. The Lighthouse tracker is a bit intimidating without anyone to point you in the right direction. If there was a place I could go and find small "get your feet wet" tasks to then get to a point where I can rewrite major components, then I would have started contributing much earlier in my career. The way I got into doing things for Rubygems was via a friend: I got a direct request to help with a new project for Rubygems. I didn't know what needed to be done so I never helped out previously.
Githacking wants to be what that friend was for me: a way to contribute with no friction on either the maintainer's side or the contributer's side and a clear starting place for getting involved in a new project.
Taking that a step further: a major part of the platform will be feature requests from companies that depend on the project, not unlike the bounties large open source projects put out from time to time on a bug or feature. Companies request a feature from a project, it gets implemented, the contributer gets paid the bounty.
It pulls data from repositories and issue trackers to make it easy to find projects with tasks you can do based on your preferences and confidence level.
Under the possibly totally incorrect assumption that that article is based on marketing copy from you, I will offer a key suggestion I learned on product differentiation once: you need to say things that your competitors aren't just going to claim applies to their products as well.
Example: "our shoes are comfortable" is going to be a really difficult campaign because every single company in that space is going to be claiming that. In this case, saying "social layer for GitHub" is incredibly confusing (even if it is theoretically accurate, as another responder just pointed out), as GitHub bills itself as "a social network for programming projects".
To bring it to this case, when I looked at the readwriteweb article, the general idea of "find people to work on your projects" seems to be exactly what people are already using GitHub for, so my response was "wait, wtf" rather than "oh, that's an interesting take".
In particular, I got here: "the ability to find and promote repositories, showcase developers' skills and repositories, as well as reward those who contribute", and I thought "this article could have been written a few years ago about the launch of GitHub: what are they actually doing here that GitHub isn't".
Hopefully we'll get the message across clearer the next time around, thanks for the notes. I'll keep them in mind when we get more attention in future.