▲ | Aurornis 2 days ago | ||||||||||||||||||||||||||||||||||
> Why? If it is well-designed, useful, and has no obvious technical flaws, why shouldn't it be included in open source software In my experience, there is a subset of open source projects where contributions are theoretically accepted, but in practice the maintainer doesn’t actually want to accept anything from anyone else unless it’s something they’ve asked for. They view contributors as assistants who are willing to volunteer their time to handle tasks that have been delegated, but they prefer to keep it as their own project. That’s fine, of course, if that’s what they want from their project. It’s their project. Where it starts to get frustrating is if they throw a fit when someone forks their open source project, or when they start rejecting PRs from other people but then lightly rewriting the code and resubmitting it as their own work. Both of these have happened to me in recent years. In one case I spent a long time writing a new feature that the maintainer had created an issue for and marked as open for contributions. Yet no amount of responding to his PR reviews made him happy about the structure of my solution. Eventually I didn’t respond for 30 days because I was busy and he closed it as stale. Then a few months later I saw the release notes included the feature he claimed he didn’t want. I looked at the commit history and saw he had committed something strikingly similar to the exact PR I had been working on, with only minimal changes to function names and locations of code blocks. That’s life, of course, but at the same time it’s getting a little frustrating to read all of the writing holding open source maintainers up on a pedestal simply because they’re holding that position. Over the years many of the projects I use have had to fork off and take new leadership and names because the old maintainer was getting in the way of progress. Again, they are within their rights to do so, but that doesn’t mean we need to praise any and every move they make. | |||||||||||||||||||||||||||||||||||
▲ | zahlman 2 days ago | parent | next [-] | ||||||||||||||||||||||||||||||||||
> Where it starts to get frustrating is if they throw a fit when someone forks their open source project, or when they start rejecting PRs from other people but then lightly rewriting the code and resubmitting it as their own work. Agreed, that's horrible. I would absolutely give credit at least for the idea behind even heavily rewritten code. And the freedom to fork is one of the essential freedoms of FOSS. Many people in certain organizations (cough GNOME cough RedHat cough) don't seem to get this. Typically the same ones who overlook key parts of the OSI definition: > The license must not discriminate against any person or group of persons. > The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. | |||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||
▲ | StilesCrisis 2 days ago | parent | prev [-] | ||||||||||||||||||||||||||||||||||
I had a somewhat similar experience with libjpeg-turbo. Found a real bug, submitted a working PR, needed to argue my case that the bug was real despite providing examples, and eventually the maintainer paraphrased my PR into their own PR and landed their own fix. It's fine I suppose, but it was a weird experience. | |||||||||||||||||||||||||||||||||||
|