6 ms·

Contributing to Open Source projects

84 points by mqt 17y ago

jrockway 17y ago
Github solved this problem. Everyone knows how to contribute to a Github project. Click the fork button, commit your patch, send pull request.
- trevorturk 17y ago
  I was thinking the exact same thing...
- krainboltgreene 17y ago
  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.
  - apsurd 17y ago
    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.
    - jrockway 17y ago
      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...
  - jamesbritt 17y ago
    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.
    - jrockway 17y ago
      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.)
      - durin42 17y ago
        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.
  - jrockway 17y ago
    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.
  - techiferous 17y ago
    "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).
    - krainboltgreene 17y ago
      Yes, it was a typo.
- benatkin 17y ago
  It's made a huge difference. http://www.reddit.com/r/programming/comments/7svak/look_at_505_for_the_github_effect/ http://www.reddit.com/r/programming/comments/7svak/look_at_5... It hasn't solved the problem for everyone, though.
- treeform 17y ago
  I don't think Github solved it. Many open source projects don't use Github. Github has made great leeway in the right direction but its not the end.
  - jongraehl 17y ago
    leeway -> headway?
- davidw 17y ago
  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.
  - jrockway 17y ago
    And you should really be doing that in a publicly archived, visible place. The commit message.
    - davidw 17y ago
      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.
      - jrockway 17y ago
        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.
dgl 17y ago
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/ http://lwn.net/Articles/379109/ it seems Google have managed to fork libjingle, so even Google can't get this right.)
mhansen 17y ago
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
benatkin 17y ago
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-do-if-you-get-fired.html 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.

84 points by mqt 17y ago

Github solved this problem. Everyone knows how to contribute to a Github project. Click the fork button, commit your patch, send pull request.

trevorturk 17y ago
I was thinking the exact same thing...
krainboltgreene 17y ago
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.
- apsurd 17y ago
  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.
  - jrockway 17y ago
    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...
- jamesbritt 17y ago
  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.
  - jrockway 17y ago
    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.)
    - durin42 17y ago
      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.
- jrockway 17y ago
  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.
- techiferous 17y ago
  "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).
  - krainboltgreene 17y ago
    Yes, it was a typo.
benatkin 17y ago
It's made a huge difference. http://www.reddit.com/r/programming/comments/7svak/look_at_505_for_the_github_effect/ http://www.reddit.com/r/programming/comments/7svak/look_at_5... It hasn't solved the problem for everyone, though.
treeform 17y ago
I don't think Github solved it. Many open source projects don't use Github. Github has made great leeway in the right direction but its not the end.
- jongraehl 17y ago
  leeway -> headway?
davidw 17y ago
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.
- jrockway 17y ago
  And you should really be doing that in a publicly archived, visible place. The commit message.
  - davidw 17y ago
    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.
    - jrockway 17y ago
      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.

dgl 17y ago

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/ http://lwn.net/Articles/379109/ it seems Google have managed to fork libjingle, so even Google can't get this right.)

mhansen 17y ago

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

benatkin 17y ago

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-do-if-you-get-fired.html 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.