Comment by photonthug

Comment by photonthug 2 months ago

> 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.

pasc1878 2 months 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.

Reply View 4 replies

photonthug 2 months 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..

Reply View | 3 replies
- massysett 2 months 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/1563cddea1002958f96e7ba95...
  
  Reply View | 2 replies
  
  photonthug 2 months ago
  
  I agree with most of this on a personal level. On the other hand, since your community owes nobody anything, including even publishing how they want to differentiate insiders vs outsiders, then it is absurd to be annoyed by all the overtures that you’re refusing to say that you don’t want.
  To put it in simpler terms.. here is a person who wants everyone to fuck off, but refuses to even explain that’s what he wants? How are we supposed to know? If no one is entitled to an explanation, then don’t be surprised if everyone is confused.
  
  Reply View | 1 reply
  
  massysett 2 months ago
  
  To an extent I agree with you: that’s why I pulled all my code off GitHub. The website is (was?) called “social coding,” so I realized the conflict in putting stuff on there and then saying “don’t bother me, but this stuff is here if you want it.” I don’t think it’s wrong to post on GitHub and say “leave me alone,” but I just don’t see how it benefits me personally.
  
  Reply View | 0 replies

throwaway2037 2 months 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.

Reply View 0 replies