This is a great idea, and I'm surprised no one thought of it sooner. Now, if only someone would create a "social layer for Facebook" my online life would be complete. Maybe there could be some way to recommend Facebook friends, get access to some kind of news feed of things my friends are doing... you know, stuff that would really make Facebook useful in a social environment rather than just a place to host my photos.
Yeah the word "social" is not accurate, thanks for pointing that out. Githacking is about connecting developers to projects and surfacing accessible tasks to get involved in OSS. ie: I'm a developer looking to get involved in git development. Git is a very complex piece of software, so I have 2 options: dive in head first and hope for the best or find someone to help me choose a task to work on. Githacking takes the second route but removes the 'someone' from the equation.
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.
OpenHatch does some things well: they have a place to store tasks that get people involved on a basic level, and they let you promote your projects. Githacking is built directly on GitHub, however, so we have tons of data about the projects without the maintainers having to keep it updated. We can tell if a project is active, what language it's written in, and what open issues are up without anyone touching the Githacking profile. Github's api is fantastic.
Ok, this specific feature description makes a lot of sense (pulling data from issue trackers to find projects with tasks you can do). From having read the readwriteweb article I was left with this feeling of "but that's exactly what GitHub does".
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".
Ah, yeah, I can see that. We're a group of 4 developers who started this project this past Friday so we're still hashing a lot of things out.
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.
I think contributing to open source is more about "fixing a broken window" than a service finding me projects it thinks I should work on or that have lots of broken windows. I have more than enough things that I should work on, and when I contribute to open source its always because the tools available didn't work for me. GitHub makes it pretty easy to find projects you're interested in and pretty easy to start contributing code to those projects, so I guess I don't get it.
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?
That's only part of the picture. What if you know what project you want to work on, but don't know what exactly needs doing?
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.
I like the bounty idea and it could be a way to monezite the app if you can get traction. Didn't mean to be harsh in my earlier comments I just hadn't gotten a good idea of what you guys were thinking of providing. Good luck!
14 comments
[ 4.1 ms ] story [ 40.0 ms ] threadIt 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.
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.