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

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

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

Do you have any examples of this?

The entire XLibre debacle seems like the most obvious example.

So because the maintainers of Xorg does not want patches that causes regressions Gnome makes people fork projects somehow?

I said

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

and you asked for examples. XLibre is a fork (of XOrg); people from GNOME and RedHat have spoken publicly to object to the fact that the fork exists (along with more generally expressing opinions that I find incompatible with my understanding of FOSS). The GitHub for the project has a wiki page (https://github.com/X11Libre/xserver/wiki/Are-We-XLibre-Yet%3...) tracking what Linux distributions do or will include the package; several prominent developers were found (https://github.com/X11Libre/xserver/issues/346) to have defaced this page by referring to the developers in very unkind ways. Among these was Jordan Petridis who is part of GNOME as well as XOrg and wrote extensively about the effort to remove the X11 GNOME session (both on a gnome.org blog and on social media), making many contentious claims about the XLibre developer in the process.

For more, I'd have to put in considerable time collating information, or else you'd have to follow sources that I have found are better not to mention in places like HN because doing so would attract too much drama. But I only make comments like these on the basis of what I can independently verify.

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.

sometimes people have a strong vision for the code they maintain. in those cases they'll usually more happily accept issues, rather than code. but GitHub doesn't let you turn off prs...

It's hard to know without looking at the datails, but in this case it would have been nice to add in the commit

> Thanks to @whoever for reporting the bug and providing a fix prototype.

(Probably prototype is not the correct word, but something like that.)

> (Probably prototype is not the correct word, but something like that.)

"... and suggesting a fix that inspired the actual change."