5 ms·

I've never seen an opensource leader make fun of an honest attempt at contribution. What I have seen is a lot of ignoring and rejecting attempts. Miguel de Ica

by tinco 14y ago

I've never seen an opensource leader make fun of an honest attempt at contribution. What I have seen is a lot of ignoring and rejecting attempts. Miguel de Icaza had a blog post on this I think. The problem with large opensource projects is that they have a lot to do, and simply don't have time to thoroughly follow up on all the small contributions that are ridden with naieve errors and plain formatting issues. Not to mention the big ones that come with architectural changes without explanations. I think it's unfair to call these charity workers jerks, just because they are trying to make light of a dire situation. Yes it can hurt if your contribution is coldly cast aside, and yes it would be much better if they warmly took you in and taught you in their ways, but if the OSS project leaders don't keep up the constant stream of contributions, improving the project all the time the project will die and all work will have been in vain. On a side note: which project will you be contributing to this christmas? It is charity time after all and a bunch of hem could use a commit or two from your hands :) just be sure to read their code-style documents ;)

cloverich 14y ago
> Yes it can hurt if your contribution is coldly cast aside, and yes it would be much better if they warmly took you in and taught you in their ways, but if the OSS project leaders don't keep up the constant stream of contributions, improving the project all the time the project will die and all work will have been in vain. Perhaps I'm being naive, but doesn't fostering relationships with contributors promote more contributions? Or is it considered far too rare that a (somewhat) mentored contributor will continue to contribute?
- TillE 14y ago
  That's certainly Gina Trapani's philosophy with ThinkUp, and it seems fairly successful. http://smarterware.org/7819/my-codeconf-talk-your-community-is-your-best-feature http://smarterware.org/7819/my-codeconf-talk-your-community-...
- benmccann 14y ago
  More contributors means more work for the project maintainers since it's more code they have to review, discuss, and commit. Very often the maintainers don't care about bug fixes or enhancements if it's not for something that's impacting their work.
  - mion 14y ago
    How can bug fixes and enhancements not impact their work?
    - jeremyjh 14y ago
      Any number of reasons. It could be a platform specific issue, a feature they don't use, something they don't consider a real problem.
- dbecker 14y ago
  Agreed that fostering relationships with contributors promotes more contributions. But, if someone's first contribution had naive mistakes, and it took more of your time than it saved, I can sympathize with a leader who doesn't try to get similar contributions.
- munificent 14y ago
  It's an investment. The first few patches from a new person will likely require so much hand-holding from the maintainers that it would have taken them less time to just write the patches themselves. As that new contributor learns the ropes, though, that cost goes does. Eventually they hit break-even where they are adding more value to the project than they cost. But that requires the person to stick around long enough to get there. There's a pretty high chance any new contributor will lose interest and go do something else. So whenever a maintainer gets a new patch from a new person, it's always an open question as to whether taking it in will ultimately be a win for the project. Unless you can predict the future, you can't tell if that investment will get amortize out and yield something useful.
  - grogenaut 14y ago
    I have 1 patch in the git kernel. I barely knew c when I did it but I did tons of research on what to call and how. Junio (maintainer) took my barely workable patch and told me what to fix. Let me do it, then pulled it in. Amazing experience in a very scary environment, eg non-minimal chance Linus tears into you.
gav 14y ago
I'm of the opinion that the best thing for large projects is new blood. If large OSS projects rotated people through triage and new contributor on-boarding, e.g. how to make a patch, how to get it approved, and so on, then in the long-run the number of contributors will grow.
- ajross 14y ago
  But how do you do that without occasionally handing over the maintainership of some important piece of infrastructure to someone who clearly can't handle it? The people at the top of the ladder right now are there because (and sure, there are exceptions) they are (1) very good at it, and (2) willing to do it. And they have employers who have made bets on those two facts. Those employers aren't really interested in someone else taking over when they have someone working now. I'm sensitive to this, really. I work in an embedded linux world where I end up submitting a bunch of patches to various projects as an "outsider" (often one who is still learning the project in question). And yeah, I get yelled at a lot. And it sucks. I'd love these people to be nicer too. But honestly I don't see a "process solution" like you propose. We just need to find nicer hard-working ubergeeks. I'm not holding my breath.
  - pfortuny 14y ago
    There is a very very simple but quite useful technique which should be easily automated: send an e-mail thanking the contributor for the pull request and telling him with courtesy that it may be left to oblivion due to lack of time. Honestly, for any OSS project leader this should be easy. All of us know the difference after sending a CV anywhere between: -1) destroying answer (do not send us your CV anymore) a) NO answer b) Automated answer without politeness intent c) Polite automated answer d) Personalized, human-written answer You cannot do d) always but you should certainly do c).
  - gav 14y ago
    I'm making two assumptions here: firstly that there is a hierarchy of contributors, where triage doesn't have to be handled by the guys right at the top; and secondly that the first few submissions by a new person aren't major--they are going to attempt something small first. If the latter isn't the case, the response should be "sorry, we appreciate your help, but try to get some minor bug fixes in before a major architectural change".
eps 14y ago
Try Miranda IM ;)
j_baker 14y ago
I think it's unfair to call the OSS project leaders "charity workers" and not the contributors. Either way, if OSS project leaders have so little free time, why wouldn't they spend more of it fostering developers into being more productive members of the project? This is what baffles me most about the situation. It's a lose-lose for everyone when a project leader acts like a jerk.
- tinco 14y ago
  I think it is unfair to call "contributors" charity workers when all they do is cause headaches for the oss project leaders. The project leader won't be a jerk to you if you make a nice well-tested, style-adhering commit that only addresses a single issue without breaking other code. Don't think for a second 'occasional contributors' combined efforts even come close to the contribution of even a single project leader.
- TheZenPsycho 14y ago
  The Mythical Man Month. When it comes to software, uniformly accepting and mentoring newcomers into a project does not bring uniformly good return- and in many or most cases, will result in NEGATIVE return, that is, a bad developer can cause progress to move backward, making more work for the other developers- both in working around the badness, and in time spent educating the newbie.

by tinco 14y ago

cloverich 14y ago

> Yes it can hurt if your contribution is coldly cast aside, and yes it would be much better if they warmly took you in and taught you in their ways, but if the OSS project leaders don't keep up the constant stream of contributions, improving the project all the time the project will die and all work will have been in vain. Perhaps I'm being naive, but doesn't fostering relationships with contributors promote more contributions? Or is it considered far too rare that a (somewhat) mentored contributor will continue to contribute?

TillE 14y ago
That's certainly Gina Trapani's philosophy with ThinkUp, and it seems fairly successful. http://smarterware.org/7819/my-codeconf-talk-your-community-is-your-best-feature http://smarterware.org/7819/my-codeconf-talk-your-community-...
benmccann 14y ago
More contributors means more work for the project maintainers since it's more code they have to review, discuss, and commit. Very often the maintainers don't care about bug fixes or enhancements if it's not for something that's impacting their work.
- mion 14y ago
  How can bug fixes and enhancements not impact their work?
  - jeremyjh 14y ago
    Any number of reasons. It could be a platform specific issue, a feature they don't use, something they don't consider a real problem.
dbecker 14y ago
Agreed that fostering relationships with contributors promotes more contributions. But, if someone's first contribution had naive mistakes, and it took more of your time than it saved, I can sympathize with a leader who doesn't try to get similar contributions.
munificent 14y ago
It's an investment. The first few patches from a new person will likely require so much hand-holding from the maintainers that it would have taken them less time to just write the patches themselves. As that new contributor learns the ropes, though, that cost goes does. Eventually they hit break-even where they are adding more value to the project than they cost. But that requires the person to stick around long enough to get there. There's a pretty high chance any new contributor will lose interest and go do something else. So whenever a maintainer gets a new patch from a new person, it's always an open question as to whether taking it in will ultimately be a win for the project. Unless you can predict the future, you can't tell if that investment will get amortize out and yield something useful.
- grogenaut 14y ago
  I have 1 patch in the git kernel. I barely knew c when I did it but I did tons of research on what to call and how. Junio (maintainer) took my barely workable patch and told me what to fix. Let me do it, then pulled it in. Amazing experience in a very scary environment, eg non-minimal chance Linus tears into you.

gav 14y ago

I'm of the opinion that the best thing for large projects is new blood. If large OSS projects rotated people through triage and new contributor on-boarding, e.g. how to make a patch, how to get it approved, and so on, then in the long-run the number of contributors will grow.

ajross 14y ago
But how do you do that without occasionally handing over the maintainership of some important piece of infrastructure to someone who clearly can't handle it? The people at the top of the ladder right now are there because (and sure, there are exceptions) they are (1) very good at it, and (2) willing to do it. And they have employers who have made bets on those two facts. Those employers aren't really interested in someone else taking over when they have someone working now. I'm sensitive to this, really. I work in an embedded linux world where I end up submitting a bunch of patches to various projects as an "outsider" (often one who is still learning the project in question). And yeah, I get yelled at a lot. And it sucks. I'd love these people to be nicer too. But honestly I don't see a "process solution" like you propose. We just need to find nicer hard-working ubergeeks. I'm not holding my breath.
- pfortuny 14y ago
  There is a very very simple but quite useful technique which should be easily automated: send an e-mail thanking the contributor for the pull request and telling him with courtesy that it may be left to oblivion due to lack of time. Honestly, for any OSS project leader this should be easy. All of us know the difference after sending a CV anywhere between: -1) destroying answer (do not send us your CV anymore) a) NO answer b) Automated answer without politeness intent c) Polite automated answer d) Personalized, human-written answer You cannot do d) always but you should certainly do c).
- gav 14y ago
  I'm making two assumptions here: firstly that there is a hierarchy of contributors, where triage doesn't have to be handled by the guys right at the top; and secondly that the first few submissions by a new person aren't major--they are going to attempt something small first. If the latter isn't the case, the response should be "sorry, we appreciate your help, but try to get some minor bug fixes in before a major architectural change".

eps 14y ago

Try Miranda IM ;)

j_baker 14y ago

I think it's unfair to call the OSS project leaders "charity workers" and not the contributors. Either way, if OSS project leaders have so little free time, why wouldn't they spend more of it fostering developers into being more productive members of the project? This is what baffles me most about the situation. It's a lose-lose for everyone when a project leader acts like a jerk.

tinco 14y ago
I think it is unfair to call "contributors" charity workers when all they do is cause headaches for the oss project leaders. The project leader won't be a jerk to you if you make a nice well-tested, style-adhering commit that only addresses a single issue without breaking other code. Don't think for a second 'occasional contributors' combined efforts even come close to the contribution of even a single project leader.
TheZenPsycho 14y ago
The Mythical Man Month. When it comes to software, uniformly accepting and mentoring newcomers into a project does not bring uniformly good return- and in many or most cases, will result in NEGATIVE return, that is, a bad developer can cause progress to move backward, making more work for the other developers- both in working around the badness, and in time spent educating the newbie.