4 ms·

In a way, I appreciate the attempt to encourage people to contribute to open source, but in another way, initiatives like this feel a lot like a cargo cult to m

In a way, I appreciate the attempt to encourage people to contribute to open source, but in another way, initiatives like this feel a lot like a cargo cult to me. I mean that in a very specific sense: Traditionally, contributors to free software and open source, especially the more prolific ones, are often good programmers. This has made its way into the collective consciousness in a way that affects hiring, e.g. by considering open source contributions as a positive signal. People who want to be software developers hear or read about this and want to replicate it, so they are looking for somewhere to contribute. Hence initiatives like in TFA, and GSoC etc. What they ignore or just don't see is that those traditional contributors to open source largely self-selected by having some issue that they wanted to solve and then just fixing it. They come to the projects with their own issues, which may overlap with issues of others out of coincidence. The difference in motivation and internal drive is significant. Of course it's still nice when people genuinely want to contribute to make the world a better place, but I'm skeptical about the support burden that these non-traditional contributors often put on project maintainers, because they tend to need more guidance on average and have less intrinsic understanding of the problem space and relevant use cases. Some projects grow structures to support it and manage just fine, but some don't and I think that also needs to be accepted.

WilliamEdward 7y ago
Whether someone wants to fix code because they use and have a problem with it, or they just wanted to knock out a random 'good first bug', it's not really up to you. Personally i think github shouldn't have this feature for a number of unrelated reasons, but don't start excluding one-off noob contributors. Open source is open for a reason.
- atq2119 7y ago
  I'm not excluding them. If they do just knock out a random 'good first bug', then that's actually great and welcome. But there seems to be a pattern of people who heard that contributing to open source is good for their CV, this ends up being their only motivation, and they expect hand-holding from project maintainers or for their patches to be accepted without scrutiny (or, if they are receptive to feedback, their patches are just really low quality and require a lot of review iterations). It's those last points that can be a problem, because it can cause their contribution to become net-negative.
  - AndrewThrowaway 7y ago
    I kinda understand the point. However at what point one can call himself a "good prolific programmer" which has no time for "hand-holding", can judge if contribution is sincere attempt by some thirteen year old who wants to learn or just being done for CV. One can argue that every kid with their "low quality patch" is net-negative as their teacher/project maintainer would be better spending time writing actual "good" code. At what point one just starts sounding like elitist thinking that open source should just be left for exclusive prolific programmers?
    - oefrha 7y ago
      > ... can judge if contribution is sincere attempt by some thirteen year old who wants to learn or just being done for CV. To me it’s no different. Whether they’re thirteen or thirty, I’m not obligated to donate time to help them grow. In fact I’d say “student drivers” deserve less of my time — I’m not a free tutor unless I explicitly agreed to such. That said, I deal with one-off contributors with respect and handhold out of kindness when necessary (assuming they’re not rude). But I don’t feel like explicitly setting the expectation that I will handhold, especially on trivial patches that’ll take me less time on my own.
    - atq2119 7y ago
      I agree with you and think you're well-intentioned. One thing I'd point out is that if you're a project maintainer, who would you rather mentor: - the inexperienced person who uses the software themselves, has an issue with it, and wants to fix it, or - the inexperienced person who wants to boost their CV and picked a bug off a "starter task" list. Assuming they are otherwise equal, I'd certainly prefer the first one, because chances are much higher that they'll stick around. Motivations matter. Now if a patch just appears out of nowhere, obviously I don't apply a litmus test where I try to divine what the person's motivation is. However, this logic has turned me off initiatives like GSoC. GSoC is great when there's a student who's already working on a project anyway, and it enables them to up their contributions during summer as an alternative to working a more boring job. However, my impression of GSoC with randoms who specifically scan GSoC for a project to work on has been disappointing.
- RomanBob 7y ago
  >but don't start excluding one-off noob contributors. Open source is open for a reason. The idea isn't that excluding noobs is good. But that noobs are coming in not because they want to contribute, but because they want to pad their resume. In doing so, they have diluted the pool in a way that they will not even be padding their resume.
tdons 7y ago
https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law
jka 7y ago
It's analogous to the way that software companies train junior engineers: it takes time to define the tasks, set up infrastructure and tests to make development easy, review and provide feedback on contributions, and to encourage learning and further skill development. While open source communities have been around for a while, we're entering an era where the size of the community is scaling up significantly (thanks to GitHub and improved connectivity worldwide), and this is exposing some of the entrenched issues around the maintainer burden you mention, gatekeeping, and project maturity. There's a huge opportunity here to create an improved learning, accreditation and contribution ecosystem; one project I'd heard about recently in the UK is 'Code Grades'[0], which aims to provide a learning ladder for developers - whether they intend to code professionally or as a hobby. There's always going to be a requirement to define tasks and review contributions - the trick will be to spread the load and make consensus-gathering more straightforward, while also preventing accidental & malicious bad actors (reputation and accreditation can probably help get some of the way there). [0] - https://codegrades.com https://codegrades.com

WilliamEdward 7y ago

Whether someone wants to fix code because they use and have a problem with it, or they just wanted to knock out a random 'good first bug', it's not really up to you. Personally i think github shouldn't have this feature for a number of unrelated reasons, but don't start excluding one-off noob contributors. Open source is open for a reason.

atq2119 7y ago
I'm not excluding them. If they do just knock out a random 'good first bug', then that's actually great and welcome. But there seems to be a pattern of people who heard that contributing to open source is good for their CV, this ends up being their only motivation, and they expect hand-holding from project maintainers or for their patches to be accepted without scrutiny (or, if they are receptive to feedback, their patches are just really low quality and require a lot of review iterations). It's those last points that can be a problem, because it can cause their contribution to become net-negative.
- AndrewThrowaway 7y ago
  I kinda understand the point. However at what point one can call himself a "good prolific programmer" which has no time for "hand-holding", can judge if contribution is sincere attempt by some thirteen year old who wants to learn or just being done for CV. One can argue that every kid with their "low quality patch" is net-negative as their teacher/project maintainer would be better spending time writing actual "good" code. At what point one just starts sounding like elitist thinking that open source should just be left for exclusive prolific programmers?
  - oefrha 7y ago
    > ... can judge if contribution is sincere attempt by some thirteen year old who wants to learn or just being done for CV. To me it’s no different. Whether they’re thirteen or thirty, I’m not obligated to donate time to help them grow. In fact I’d say “student drivers” deserve less of my time — I’m not a free tutor unless I explicitly agreed to such. That said, I deal with one-off contributors with respect and handhold out of kindness when necessary (assuming they’re not rude). But I don’t feel like explicitly setting the expectation that I will handhold, especially on trivial patches that’ll take me less time on my own.
  - atq2119 7y ago
    I agree with you and think you're well-intentioned. One thing I'd point out is that if you're a project maintainer, who would you rather mentor: - the inexperienced person who uses the software themselves, has an issue with it, and wants to fix it, or - the inexperienced person who wants to boost their CV and picked a bug off a "starter task" list. Assuming they are otherwise equal, I'd certainly prefer the first one, because chances are much higher that they'll stick around. Motivations matter. Now if a patch just appears out of nowhere, obviously I don't apply a litmus test where I try to divine what the person's motivation is. However, this logic has turned me off initiatives like GSoC. GSoC is great when there's a student who's already working on a project anyway, and it enables them to up their contributions during summer as an alternative to working a more boring job. However, my impression of GSoC with randoms who specifically scan GSoC for a project to work on has been disappointing.
RomanBob 7y ago
>but don't start excluding one-off noob contributors. Open source is open for a reason. The idea isn't that excluding noobs is good. But that noobs are coming in not because they want to contribute, but because they want to pad their resume. In doing so, they have diluted the pool in a way that they will not even be padding their resume.

tdons 7y ago

https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law

jka 7y ago

It's analogous to the way that software companies train junior engineers: it takes time to define the tasks, set up infrastructure and tests to make development easy, review and provide feedback on contributions, and to encourage learning and further skill development. While open source communities have been around for a while, we're entering an era where the size of the community is scaling up significantly (thanks to GitHub and improved connectivity worldwide), and this is exposing some of the entrenched issues around the maintainer burden you mention, gatekeeping, and project maturity. There's a huge opportunity here to create an improved learning, accreditation and contribution ecosystem; one project I'd heard about recently in the UK is 'Code Grades'[0], which aims to provide a learning ladder for developers - whether they intend to code professionally or as a hobby. There's always going to be a requirement to define tasks and review contributions - the trick will be to spread the load and make consensus-gathering more straightforward, while also preventing accidental & malicious bad actors (reputation and accreditation can probably help get some of the way there). [0] - https://codegrades.com https://codegrades.com