Contributing to Open Source projects(brad.livejournal.com)
brad.livejournal.com
Contributing to Open Source projects
http://brad.livejournal.com/2409049.html
22 comments
Github solved this problem. Everyone knows how to contribute to a Github project. Click the fork button, commit your patch, send pull request.
I wonder if you're being sarcastic? Had you said that to me two weeks ago I wouldn't know what the hell "fork", "commit", and "pull" had to do with contributing.
Git is hardly the end all be all.
Git is hardly the end all be all.
Huh? How much software do you write?
All I know is that I get a few patches a week from people I've never heard of, thanks to Github. I can even anticipate them in advance, since I can see who has forks of my project, and what they've committed.
For those of us that are able to learn about simple concepts, Github has been a godsend. It has never been easier to share code.
And no, I am not being sarcastic, nor was my original post.
All I know is that I get a few patches a week from people I've never heard of, thanks to Github. I can even anticipate them in advance, since I can see who has forks of my project, and what they've committed.
For those of us that are able to learn about simple concepts, Github has been a godsend. It has never been easier to share code.
And no, I am not being sarcastic, nor was my original post.
Even for people git-aware, there's a bit more involved.
Most people are probably happy to get patch submissions, but there's some work involved in accepting them.
Generally, project owners want to see a test accompany any change to demonstrate that a bug was fixed or that new behavior does what's claimed. There may also be coding standards to follow, and (ideally) some documentation for new code.
If you omit these things when you submit a patch or issue a a pull request you may still think you're doing the project owner a favor, on the premise that something is better than nothing, but reviewing your submissions and checking that it is correct, and possibly cleaning up your code and adding tests, may end up being more work than it's worth.
Git and github have removed some obstacles to contributing, but there are still assorted details one has to look after.
Most people are probably happy to get patch submissions, but there's some work involved in accepting them.
Generally, project owners want to see a test accompany any change to demonstrate that a bug was fixed or that new behavior does what's claimed. There may also be coding standards to follow, and (ideally) some documentation for new code.
If you omit these things when you submit a patch or issue a a pull request you may still think you're doing the project owner a favor, on the premise that something is better than nothing, but reviewing your submissions and checking that it is correct, and possibly cleaning up your code and adding tests, may end up being more work than it's worth.
Git and github have removed some obstacles to contributing, but there are still assorted details one has to look after.
Generally, project owners want to see a test accompany any change to demonstrate that a bug was fixed or that new behavior does what's claimed. There may also be coding standards to follow, and (ideally) some documentation for new code.
If the project owner really wants the patch, they will fix these details themselves. In my experience this is how project owners reject patches that they don't want; make the submitter do more work than he is willing to so that the patch silently dies.
Personally, I will usually ask a submitter for a test case and some docs... but if I don't hear from them (or hear, "works for me, no time"), I will just write them myself. Same for style issues; easier to just fix them myself, then I know that the style is exactly what I want.
Github, at the very least, eliminates any technical reason not to contribute. Social issues are largely the same; although back-and-forth is a lot easier when you both have access to a public repository. (Who likes attaching the 8th iteration of a patch to email? Not me.)
If the project owner really wants the patch, they will fix these details themselves. In my experience this is how project owners reject patches that they don't want; make the submitter do more work than he is willing to so that the patch silently dies.
Personally, I will usually ask a submitter for a test case and some docs... but if I don't hear from them (or hear, "works for me, no time"), I will just write them myself. Same for style issues; easier to just fix them myself, then I know that the style is exactly what I want.
Github, at the very least, eliminates any technical reason not to contribute. Social issues are largely the same; although back-and-forth is a lot easier when you both have access to a public repository. (Who likes attaching the 8th iteration of a patch to email? Not me.)
Seriously? I'd much rather get a potential repeated contributor who can follow my style than clean it up without asking him to do it. Double for tests: I frequently can't figure out exactly what the best regression test will be and the contributor needs to make it himself (though that may be a special case of my VCS work). Pull requests actively make commenting on a patch harder than a patchbomb in email. The fork queue (imnsho) is even worse, as I've had people just assume I'll see it and just take it from the fork queue page.
Feel free to write me off as a cranky old fart - I've been doing OSS long enough to remember Subversion as a wonderful thing on the horizon and the pure joy of its relative speed. This is all based on my mostly-poor experiences with GH preventing a community domain forming by causing nobody to talk outside of their commit messages, which is a huge loss.
Feel free to write me off as a cranky old fart - I've been doing OSS long enough to remember Subversion as a wonderful thing on the horizon and the pure joy of its relative speed. This is all based on my mostly-poor experiences with GH preventing a community domain forming by causing nobody to talk outside of their commit messages, which is a huge loss.
"Git is hardly the end all be all."
Not sure if that was a typo, but in case it wasn't: git is version control software, and github is a web app that allows you to host and manage git repositories (and open-source repo hosting is free).
Not sure if that was a typo, but in case it wasn't: git is version control software, and github is a web app that allows you to host and manage git repositories (and open-source repo hosting is free).
Yes, it was a typo.
what's nice about needing to learn what fork, commit, and pull are, is a nice barrier to entry for developers to contribute. This is counter-intuitive since as many people should get involved as possible. But this is more true for things like spotting bugs or user testing and much less for actually contributing code.
What's there to learn? You just click buttons in a web interface. Click fork, click "edit", click "save", click "send pull request". It's like Web 2.0 for free software...
No it hasn't. It helps, it's a nice tool, but it does not take the place of human communication, which is essential. You can't just send someone a 'pull request' without explaining why you want to do it, what it's for and so on.
And you should really be doing that in a publicly archived, visible place.
And you should really be doing that in a publicly archived, visible place.
And you should really be doing that in a publicly archived, visible place.
The commit message.
The commit message.
Which is why traffic has stopped on the linux kernel mailing list, despite being long time users of git? Nope. All serious open source projects have some sort of discussion area. Even github lets you comment on commits, but that's not quite as convenient to read for most people as a publicly visible mailing list/forum/whatever.
Git is a nice tool, but you can't take things to extremes. It is not a substitute for actual discussion. What happens when the patch is 'pretty good', but not quite right and both people are willing to work on it? It just gets discussed in commit messages? No, it goes to a mailing list, especially when it's a larger project with many interested parties. This is pretty elementary open source stuff:-/
Where you're completely correct is that git and github make it easier to contribute 'at the margins'. In the sense that what once may have simply lain idle on one's own hard drive is easier to simply throw at some project in the hopes that they can do something useful with it.
Git is a nice tool, but you can't take things to extremes. It is not a substitute for actual discussion. What happens when the patch is 'pretty good', but not quite right and both people are willing to work on it? It just gets discussed in commit messages? No, it goes to a mailing list, especially when it's a larger project with many interested parties. This is pretty elementary open source stuff:-/
Where you're completely correct is that git and github make it easier to contribute 'at the margins'. In the sense that what once may have simply lain idle on one's own hard drive is easier to simply throw at some project in the hopes that they can do something useful with it.
When your project's size warrants it, you can switch from pull requests to an off-site mailing list. But most projects never get there, and so pull requests are quite useful for the long tail.
I remember back in the sourceforge day, most projects died before they ever got a mailing list, CVS account, web page, wiki, bug tracker, ..., all setup. Now, reasonable defaults are provided for you, and you can focus on writing the code. Once your project has a bunch of contributers that are all working on time-consuming projects... then you can invest some time in moving away from the defaults. But if you project is like most and has 3 users, you won't have to waste your time.
I remember back in the sourceforge day, most projects died before they ever got a mailing list, CVS account, web page, wiki, bug tracker, ..., all setup. Now, reasonable defaults are provided for you, and you can focus on writing the code. Once your project has a bunch of contributers that are all working on time-consuming projects... then you can invest some time in moving away from the defaults. But if you project is like most and has 3 users, you won't have to waste your time.
github is without doubt an improvement over SF, and makes it easier to contribute to smaller projects.
> I remember back in the sourceforge day, most projects died before they ever got a mailing list, CVS account, web page, wiki, bug tracker, ..., all setup.
What happened a lot is that people thought they were going to do some great open source project, registered the project, then never did anything with it. This can happen anywhere, really, although it's probably less prominent on github, because a repository with nothing in it is pretty ridiculous.
Also, it's amazingly easy to set up a Google Group, even though they have some known issues.
Anyway, where I'm going with this is merely that putting it on github does not make open source magically 'work', and people need to pay attention to the human (communication, etc...) side of things too. Github is an improvement in many ways.
> I remember back in the sourceforge day, most projects died before they ever got a mailing list, CVS account, web page, wiki, bug tracker, ..., all setup.
What happened a lot is that people thought they were going to do some great open source project, registered the project, then never did anything with it. This can happen anywhere, really, although it's probably less prominent on github, because a repository with nothing in it is pretty ridiculous.
Also, it's amazingly easy to set up a Google Group, even though they have some known issues.
Anyway, where I'm going with this is merely that putting it on github does not make open source magically 'work', and people need to pay attention to the human (communication, etc...) side of things too. Github is an improvement in many ways.
I was thinking the exact same thing...
It's made a huge difference.
http://www.reddit.com/r/programming/comments/7svak/look_at_5...
It hasn't solved the problem for everyone, though.
http://www.reddit.com/r/programming/comments/7svak/look_at_5...
It hasn't solved the problem for everyone, though.
Node.js is a great example of how to do this right. They walk you through the exact steps needed to submit a patch.
http://nodejs.org/#contributing
http://nodejs.org/#contributing
One key difference which the post doesn't really touch on is that when it's a company everyone's interests are more closely aligned (or at least should be...).
On the other hand even if you find where to contribute to with open source you can't be as sure your patch will be taken.
(Although as mentioned on LWN: http://lwn.net/Articles/379109/ it seems Google have managed to fork libjingle, so even Google can't get this right.)
On the other hand even if you find where to contribute to with open source you can't be as sure your patch will be taken.
(Although as mentioned on LWN: http://lwn.net/Articles/379109/ it seems Google have managed to fork libjingle, so even Google can't get this right.)
I found Giles Bowkett's for-sale video, which covered contributing to open source along with many other things, helpful. Contributing to the open source community way easier than it sounds. Contributing to open source code, specifically, in a noticeable way, is probably harder, but not that much harder.
http://gilesbowkett.blogspot.com/2010/03/programmers-what-to...
It didn't even take a week after I watched it for me to start implementing his suggestions.
http://gilesbowkett.blogspot.com/2010/03/programmers-what-to...
It didn't even take a week after I watched it for me to start implementing his suggestions.