3 ms·

While there's sometimes maintainer-prima-donna egos the contend with there's also this: Any patch sent in also needs to be maintained into the future, and most

While there's sometimes maintainer-prima-donna egos the contend with there's also this: Any patch sent in also needs to be maintained into the future, and most of the time it's the maintainers that need to do that, not the people contributing the patch. Therefore any feature-patches (as opposed to simple bugfixes) are quite often refused, even if they add useful functionality, because the maintainers conclude they will not be able to maintain the functionality into the future (because no one on the maintaining team has experience in a certain field, for example). The quality bar for a 'drive by patch' which is contributed without the promise of future support is ridiculously high and it has to be. Other peoples' code is always harder to maintain than your own so it has to make up for that in quality.

WesolyKubeczek 11mo ago
Not any patch. Sometimes there are patches that are not explicitly fixing defects, but for example they surface a boolean setting that some upstream library started to expose. That setting is exactly like a dozen other settings already there. It's made using the same coding style and has all requisite things other settings have. Will you be still making a fuss over it?
- josephg 11mo ago
  Maybe, it depends! Maybe the developer intends to some day change the internal implementation, such that that particular boolean flag wouldn't make sense any more. Or they're considering taking out the option entirely, and thus simplifying the codebase by making it so it only works one way. Maybe the developer just doesn't care about your use case. If I have a project that works fine for what I do with it, why should I also care about some other use case you have for my work? I'm not your employee. Your product doesn't put a roof over my head. I don't want a job where I do free work, for a bunch of companies who all make money off my work. That's a bad deal. Its a bad deal even if my code gets better as a result. I have 150 projects on github. I don't want to be punished if any of those projects become popular. We can't go around punishing projects like ffmpeg or ruby on rails for the crime of being useful.
  - WesolyKubeczek 11mo ago
    I don't know. The pattern I have seen is that if you want to contribute a fix into a project, you are expected to "engage with the community", wear their badge, invest into the whole thing. I don't want to be in your community, I want to fix a bug in a thing I'm using and go on with my life. Given the usual dynamics of online communities which are getting somehow increasingly more prone to dramas, toxicity, tribalism, and polarization, I just as increasingly want to have no part in them most of the time. I think many projects would be better for having a lane for drive-by contributors who could work on fixing bugs that prevent their day-to-day from working without expectations of becoming full-time engaged. The project could set an expectation that "we will rewrite your patch as we see fit so we could integrate and maintain it, if we need/want to". I wouldn't care as long as the problem is taken care of in some way.
    - fukka42 11mo ago
      Being allowed to contribute to open source is a privilege, not a right. You could also just pay for it.
      - okayjustonemore 11mo ago
        “Pay my way or take the highway” is as close to the closed-source ethos as you can possibly get. Collaboration is not feasible if the barrier of entry is too high and those involved make no effort to foster a collaborative environment.
        maybewhenthesun 11mo ago
        Yes, because with a closed source you can also just download the source and add your own patches and maintain your own fork... /s Most open source projects have way more patches contributed than the core developers can handle, so they tend to only accept those from the friendliest contributors or with the highest code/documentation quality.
      - WesolyKubeczek 11mo ago

WesolyKubeczek 11mo ago

Not any patch. Sometimes there are patches that are not explicitly fixing defects, but for example they surface a boolean setting that some upstream library started to expose. That setting is exactly like a dozen other settings already there. It's made using the same coding style and has all requisite things other settings have. Will you be still making a fuss over it?

josephg 11mo ago
Maybe, it depends! Maybe the developer intends to some day change the internal implementation, such that that particular boolean flag wouldn't make sense any more. Or they're considering taking out the option entirely, and thus simplifying the codebase by making it so it only works one way. Maybe the developer just doesn't care about your use case. If I have a project that works fine for what I do with it, why should I also care about some other use case you have for my work? I'm not your employee. Your product doesn't put a roof over my head. I don't want a job where I do free work, for a bunch of companies who all make money off my work. That's a bad deal. Its a bad deal even if my code gets better as a result. I have 150 projects on github. I don't want to be punished if any of those projects become popular. We can't go around punishing projects like ffmpeg or ruby on rails for the crime of being useful.
- WesolyKubeczek 11mo ago
  I don't know. The pattern I have seen is that if you want to contribute a fix into a project, you are expected to "engage with the community", wear their badge, invest into the whole thing. I don't want to be in your community, I want to fix a bug in a thing I'm using and go on with my life. Given the usual dynamics of online communities which are getting somehow increasingly more prone to dramas, toxicity, tribalism, and polarization, I just as increasingly want to have no part in them most of the time. I think many projects would be better for having a lane for drive-by contributors who could work on fixing bugs that prevent their day-to-day from working without expectations of becoming full-time engaged. The project could set an expectation that "we will rewrite your patch as we see fit so we could integrate and maintain it, if we need/want to". I wouldn't care as long as the problem is taken care of in some way.
  - fukka42 11mo ago
    Being allowed to contribute to open source is a privilege, not a right. You could also just pay for it.
    - okayjustonemore 11mo ago
      “Pay my way or take the highway” is as close to the closed-source ethos as you can possibly get. Collaboration is not feasible if the barrier of entry is too high and those involved make no effort to foster a collaborative environment.
      - maybewhenthesun 11mo ago
        Yes, because with a closed source you can also just download the source and add your own patches and maintain your own fork... /s Most open source projects have way more patches contributed than the core developers can handle, so they tend to only accept those from the friendliest contributors or with the highest code/documentation quality.
    - WesolyKubeczek 11mo ago