4 ms·

"As an open source author and maintainer, I think you're looking at this from the wrong way around. Good contributions are not the norm, they're the exception,

"As an open source author and maintainer, I think you're looking at this from the wrong way around. Good contributions are not the norm, they're the exception, " I've contributed to hundreds of projects, and maintained a ton, so i feel this pain, so please take what i say in that vein :) The question i usually ask when i see this is: "What is the thing you did that you think should have caused people's behavior to change?" Assuming you want this to be different, what actions are you taking that should have changed this? If they didn't, what did you learn and try? I'm not suggesting you will get to some perfect place where all contributions are great, but if you really want to improve them overall, you have to be doing things to improve the behaviors you see, seeing whether they work, and iterating, until you get the behavior you want out of most contributors.

andkon 5y ago
Wowwww this is lovely! Have you written anywhere about what you've done on the projects you've maintained along these lines? I think we'd all benefit from hearing more about what you can do in a project to make contributors more capable and helpful. After all, it seems like their incentives should align? Like, why wouldn't they want to make a contribution that actually helps? Making that easier to actually do seems like time well spent for everyone.
- DannyBee 5y ago
  I used to write it in a blog a long time ago, but that website died and i'm just too busy these days ;) Ironically, my experience overall as a manager (not just in open source) is that when you ask this question, a lot of the time you get the answer that nobody did anything, because of the latter thing you describe. IE nobody is acting malicious, but they expected people would want to do X on their own, so nobody tried anything specifically. In those cases, once you get people onto the path of specifically trying things, and seeing what happens, it's often a great improvement. Even without lots of other process/measurement. Beyond that, one of the things we do internally, that is a bit harder to do well externally due to social norms/etc, is ask people. In open source, it's trickier because if i contribute randomly to 200 projects, i don't want every single one of them spamming me directly to find out more about my experiences ;) But occasionally poking people on PR's that are taking a while, or went really well, etc, and seeing if the people they are willing to fill out a form anonymously or something, even if heavily biased, would at least give you some notions of what is going well or not for people. There is also a lot to be said for analytics on PRs, but again, open source is not very advanced at this right now, so i don't think it's near as viable yet as just asking some people
  - andkon 5y ago
    This is really helpful. I love the idea of reaching out on long-running and getting feedback directly - that seems a great qualitative way to get a sense of what's going on, and fits well with my own experience about how to talk to early-stage customers who seem to have some value from a product I've made, but which probably isn't quite meeting people's needs yet. Turns out that's often enough to figure out the biggest, most helpful changes. Thank you!
- lamontcg 5y ago
  A lot of the time making a contribution that actually helps means fixing something foundational rather than bolting on another quick bug fix. That takes work, sometimes quite a lot of it, and there's no trick around getting the work done any easier. A lot of contributions to open source are simply worth what you paid for them, which is nothing. Early in a project it is possible to find areas of the codebase where easy things haven't yet been done because there just haven't been enough programmer-hours done yet to burn through the simple stuff. Late in a mature project the easy things have mostly gotten done and finding more easy stuff becomes difficult, and as you pull apart simple looking issues they start to look hard.
  - nyanpasu64 5y ago
    I often encounter foundational or complex issues (incorrect memory management, deep complexity) when trying to diagnose crashes in open-source apps. And I get frustrated trying to understand deep complexity is frustrating, and maintainers (who haven't looked into the crashes so far, and in one case fixed an earlier crash based on me debugging it for them) don't take it kindly when I complain about the unmanageable complexity and poor stability of these apps. What should I do in this case? Take a break then keep trying? Slow down debugging and spend more time reading and taking notes? Abandon the project, and switch to using/contributing to codebases I find simpler/more cohesive and easier to understand?
Etheryte 5y ago
My personal and very subjective opinion is that it's not my hill to die on. The majority of most things is not good, books, music, business plans, you name it. Open source contributions are the same — and that's okay. Much like I don't have a problem with people who write books I personally don't like, I don't take issue with people whose contributions don't align with what I think is good. I try to focus my energy on the ones that I find good, or at least the ones that look like they might end up being good. To perhaps put the same idea another way, if someone wants to put in the effort for making a change, it's their choice to do so. It is also their choice whether they take the time to do it well. If they didn't want to put in the work, it doesn't bother me, it's their time.
- DannyBee 5y ago
  I think that's a fine viewpoint, and one i take with many projects, and try to be clear upfront - IE "this is a thing i'm not going to spend a lot of energy on. If you give me stuff that works well, i'll integrate it. If not, i won't". I would also agree you are going to get some amount of crap no matter what. But, i would say if you want this to be different, it's not entirely on other people. Even with the best of intent, you can't expect contributors or teams or processes to behave magically just because they should. You usually need to motivate/incentivize or train the behaviors you want, and iterate the processes and your approach until you are getting what you want.
- SomeCallMeTim 5y ago
  >The majority of most things is not good "90% of everything is crap." -- Sturgeon's law [0] The problem is that once someone has put in the time to create a PR, declining it is never going to feel good for the contributor. Yes, they can maintain their own fork with their changes. But to be told "this doesn't work for our project," no matter how politely, is often emotionally interpreted as a form of rejection. Which is what spawns the kind of rant above in the original link. [0] https://en.wikipedia.org/wiki/Sturgeon%27s_law https://en.wikipedia.org/wiki/Sturgeon%27s_law

andkon 5y ago

Wowwww this is lovely! Have you written anywhere about what you've done on the projects you've maintained along these lines? I think we'd all benefit from hearing more about what you can do in a project to make contributors more capable and helpful. After all, it seems like their incentives should align? Like, why wouldn't they want to make a contribution that actually helps? Making that easier to actually do seems like time well spent for everyone.

DannyBee 5y ago
I used to write it in a blog a long time ago, but that website died and i'm just too busy these days ;) Ironically, my experience overall as a manager (not just in open source) is that when you ask this question, a lot of the time you get the answer that nobody did anything, because of the latter thing you describe. IE nobody is acting malicious, but they expected people would want to do X on their own, so nobody tried anything specifically. In those cases, once you get people onto the path of specifically trying things, and seeing what happens, it's often a great improvement. Even without lots of other process/measurement. Beyond that, one of the things we do internally, that is a bit harder to do well externally due to social norms/etc, is ask people. In open source, it's trickier because if i contribute randomly to 200 projects, i don't want every single one of them spamming me directly to find out more about my experiences ;) But occasionally poking people on PR's that are taking a while, or went really well, etc, and seeing if the people they are willing to fill out a form anonymously or something, even if heavily biased, would at least give you some notions of what is going well or not for people. There is also a lot to be said for analytics on PRs, but again, open source is not very advanced at this right now, so i don't think it's near as viable yet as just asking some people
- andkon 5y ago
  This is really helpful. I love the idea of reaching out on long-running and getting feedback directly - that seems a great qualitative way to get a sense of what's going on, and fits well with my own experience about how to talk to early-stage customers who seem to have some value from a product I've made, but which probably isn't quite meeting people's needs yet. Turns out that's often enough to figure out the biggest, most helpful changes. Thank you!
lamontcg 5y ago
A lot of the time making a contribution that actually helps means fixing something foundational rather than bolting on another quick bug fix. That takes work, sometimes quite a lot of it, and there's no trick around getting the work done any easier. A lot of contributions to open source are simply worth what you paid for them, which is nothing. Early in a project it is possible to find areas of the codebase where easy things haven't yet been done because there just haven't been enough programmer-hours done yet to burn through the simple stuff. Late in a mature project the easy things have mostly gotten done and finding more easy stuff becomes difficult, and as you pull apart simple looking issues they start to look hard.
- nyanpasu64 5y ago
  I often encounter foundational or complex issues (incorrect memory management, deep complexity) when trying to diagnose crashes in open-source apps. And I get frustrated trying to understand deep complexity is frustrating, and maintainers (who haven't looked into the crashes so far, and in one case fixed an earlier crash based on me debugging it for them) don't take it kindly when I complain about the unmanageable complexity and poor stability of these apps. What should I do in this case? Take a break then keep trying? Slow down debugging and spend more time reading and taking notes? Abandon the project, and switch to using/contributing to codebases I find simpler/more cohesive and easier to understand?

Etheryte 5y ago

My personal and very subjective opinion is that it's not my hill to die on. The majority of most things is not good, books, music, business plans, you name it. Open source contributions are the same — and that's okay. Much like I don't have a problem with people who write books I personally don't like, I don't take issue with people whose contributions don't align with what I think is good. I try to focus my energy on the ones that I find good, or at least the ones that look like they might end up being good. To perhaps put the same idea another way, if someone wants to put in the effort for making a change, it's their choice to do so. It is also their choice whether they take the time to do it well. If they didn't want to put in the work, it doesn't bother me, it's their time.

DannyBee 5y ago
I think that's a fine viewpoint, and one i take with many projects, and try to be clear upfront - IE "this is a thing i'm not going to spend a lot of energy on. If you give me stuff that works well, i'll integrate it. If not, i won't". I would also agree you are going to get some amount of crap no matter what. But, i would say if you want this to be different, it's not entirely on other people. Even with the best of intent, you can't expect contributors or teams or processes to behave magically just because they should. You usually need to motivate/incentivize or train the behaviors you want, and iterate the processes and your approach until you are getting what you want.
SomeCallMeTim 5y ago
>The majority of most things is not good "90% of everything is crap." -- Sturgeon's law [0] The problem is that once someone has put in the time to create a PR, declining it is never going to feel good for the contributor. Yes, they can maintain their own fork with their changes. But to be told "this doesn't work for our project," no matter how politely, is often emotionally interpreted as a form of rejection. Which is what spawns the kind of rant above in the original link. [0] https://en.wikipedia.org/wiki/Sturgeon%27s_law https://en.wikipedia.org/wiki/Sturgeon%27s_law