4 ms·

> I’ve submitted a handful of pull requests and I’ve already run into the classic “Your patch works and provides a feature some people might like, but I don’t l

> I’ve submitted a handful of pull requests and I’ve already run into the classic “Your patch works and provides a feature some people might like, but I don’t like it, go away Same. I think it is potentially easier to get a well defined change into Linux itself rather than a randomly chosen but largish open source project these days. I don’t really try to contribute to other projects anymore, not because I don’t want to, but because if you’re coding for fun anyway it’s usually better to work on a project you control rather than dealing with the frustration. I think a huge percentage of open source would be more accurately advertised as “open source but closed contributions”, and being upfront and realistic about this is important. People who are already working for free deserve to have a realistic understanding of whether they will get to merge that simple bug fix they need to unfork the library, or if it’s more realistic that they need to start talking on a mailing list for 5 years and work out how to join a steering committee first.

throwaway2037 2y ago
> open source but closed contributions +9000 I have seen this so many times. It used to bother me a lot, until I stopped trying to boil the ocean and fix a bug in a project that I do not control.
pasc1878 2y ago
One issue here is that the main author has very limited resources. Thus can only support a small amount of code. Your Pull Request makes the project larger and it needs to be maintained - so making the load on the original author larger. If it fixes a bug then it helps the original author and so can be accepted. So it is not closed contributions but rather it has a defined scope and we are not going let the project suffer from scope creep. One example of this is a project written on Linux - it does run on macOS but not fully correctly. The original author just says I don't have access to a Mac so cannot support it. They are not being a bad person here just stating a fact. The answer here is that there is now a fork that does support macOS, hopefully correctly but I would not be surprised if there are bugs due too differences in the OS - the major ones have been made but I'll bet that a full code review has not been done over every line of code.
- photonthug 2y ago
  I understand these issues and project maintainers don’t owe random people a merge. But they do owe random people a little clarity about what should be expected as a potential contributor. It’s not that much to ask. Realistically as programmers we should probably solve these problems with data and not waste anyone’s time. If your supposedly open project has never merged a pr by a non-member or a person without a looong history of hanging out on the projects social periphery, then non-members should be warned when they submit a PR that this is the case. Saves 2 weeks of fake requests for tests/documentation/justifications when the real issue is a steering committee that prefers insiders-only. And again, that’s fine, it’s just the missing transparency that’s the real problem. And yeah, even clearly needed bug fixes can still be in this category, it doesn’t take a major feature that’s going to be a maintenance burden. 3 weeks (or years) of discussion arguing the bug is not a bug, followed by the users saying it’s a bug, and then maintainers asking for changes/docs/tests and then when that’s all in place, maintainers pivot to suggesting it needs to be an extension/plugin or whatever. In some ecosystems this kind of thing is more common than elsewhere.. but if you’ve never seen this count yourself lucky. Naming projects is tempting here but in the end it’s unpaid work that’s a passion project for an army of volunteers. But the volunteers are still just dumb monkeys that really enjoy dumb hierarchies, so what can you do..
  - massysett 2y ago
    > I understand these issues and project maintainers don’t owe random people a merge. But they do owe random people a little clarity about what should be expected as a potential contributor. Absolutely not, no. A potential contributor can start by assessing the project. This can begin by politely asking the maintainer whether a particular patch will be accepted. Or, the contributor can examine the project history. If the potential contributor receives no response, or sees no indication of a robust history of merging patches, then assume no patches will be merged. The code is there for the taking. The contributor is free to fork it and modify at will. Rich Hickey said this best: "As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation." https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...

throwaway2037 2y ago

> open source but closed contributions +9000 I have seen this so many times. It used to bother me a lot, until I stopped trying to boil the ocean and fix a bug in a project that I do not control.

pasc1878 2y ago

One issue here is that the main author has very limited resources. Thus can only support a small amount of code. Your Pull Request makes the project larger and it needs to be maintained - so making the load on the original author larger. If it fixes a bug then it helps the original author and so can be accepted. So it is not closed contributions but rather it has a defined scope and we are not going let the project suffer from scope creep. One example of this is a project written on Linux - it does run on macOS but not fully correctly. The original author just says I don't have access to a Mac so cannot support it. They are not being a bad person here just stating a fact. The answer here is that there is now a fork that does support macOS, hopefully correctly but I would not be surprised if there are bugs due too differences in the OS - the major ones have been made but I'll bet that a full code review has not been done over every line of code.

photonthug 2y ago
I understand these issues and project maintainers don’t owe random people a merge. But they do owe random people a little clarity about what should be expected as a potential contributor. It’s not that much to ask. Realistically as programmers we should probably solve these problems with data and not waste anyone’s time. If your supposedly open project has never merged a pr by a non-member or a person without a looong history of hanging out on the projects social periphery, then non-members should be warned when they submit a PR that this is the case. Saves 2 weeks of fake requests for tests/documentation/justifications when the real issue is a steering committee that prefers insiders-only. And again, that’s fine, it’s just the missing transparency that’s the real problem. And yeah, even clearly needed bug fixes can still be in this category, it doesn’t take a major feature that’s going to be a maintenance burden. 3 weeks (or years) of discussion arguing the bug is not a bug, followed by the users saying it’s a bug, and then maintainers asking for changes/docs/tests and then when that’s all in place, maintainers pivot to suggesting it needs to be an extension/plugin or whatever. In some ecosystems this kind of thing is more common than elsewhere.. but if you’ve never seen this count yourself lucky. Naming projects is tempting here but in the end it’s unpaid work that’s a passion project for an army of volunteers. But the volunteers are still just dumb monkeys that really enjoy dumb hierarchies, so what can you do..
- massysett 2y ago
  > I understand these issues and project maintainers don’t owe random people a merge. But they do owe random people a little clarity about what should be expected as a potential contributor. Absolutely not, no. A potential contributor can start by assessing the project. This can begin by politely asking the maintainer whether a particular patch will be accepted. Or, the contributor can examine the project history. If the potential contributor receives no response, or sees no indication of a robust history of merging patches, then assume no patches will be merged. The code is there for the taking. The contributor is free to fork it and modify at will. Rich Hickey said this best: "As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation." https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...