The Pragmatic Open Source Contributor(diurnal.st)
diurnal.st
The Pragmatic Open Source Contributor
https://diurnal.st/2025/03/02/the-pragmatic-open-source-contributor.html
18 comments
This is a great blog! Great points about just running your own fork if needed and testing your own patch in your own system for a while. I would be very happy as a maintainer if someone put in that much effort for a fix.
I don't contribute anymore because it's almost always a thankless endeavor further humiliated by very rude and irrationally demanding users.
If I don't do something, half the users get upset. If I do it, the other half get upset.
That combined with so many other developers who seem to have dogmatic god complexes and think they know everything while simultaneously having the emotional maturity of an eight year old... it was just too much for me to handle.
If I don't do something, half the users get upset. If I do it, the other half get upset.
That combined with so many other developers who seem to have dogmatic god complexes and think they know everything while simultaneously having the emotional maturity of an eight year old... it was just too much for me to handle.
I'm sorry this happens. You can cope by having a few "evangelist" users you communicate with to balance the negativity. There's a bias for comment on code that's not perfect. When everything's perfect, no one has anything to say. Open source bring with it an open quorum.
Github in particular has no way of stopping drive-by comments and issues, right?
You do not have to use Github.
Disable Github issues and use a mailing list instead.
A mailing list doesn't stop drive-by comments and shenanigans. It just raises the barrier to entry.
Sorry to hear that, can you point to an example?
libgd, the graphics backend of php. It's an ancient pile of shit yet the "maintainers" refuse An help, contributions and improvement as good as they can. The most popular example is emoji support on their text rendering. Questions on SO, bug reports to libgd and php go back at least 10 years, yet no interest by the devs to either fix it or accept any help in doing so.
A couple years ago I started investigating and it starts with the fact that their utf8 decoder accepts no more than 3 bytes per character, thanks to an ifdef. There's code to handle 4, so you change the ifdef and then it doesn't compile anymore because code rot. Fixing that you see the correct code points going into freetype but then something else I forgot about breaks. Then I saw there were already a couple patches on the mailing list and checking their github just now I see at least one PR with a bunch of back and forth and another couple issues with mostly no reaction or at best a few lame excuses.
If you could donate negative money to a project this would be a prime candidate. Sure, move fast and break things is bad, but this is the opposite of that, and not good either.
A couple years ago I started investigating and it starts with the fact that their utf8 decoder accepts no more than 3 bytes per character, thanks to an ifdef. There's code to handle 4, so you change the ifdef and then it doesn't compile anymore because code rot. Fixing that you see the correct code points going into freetype but then something else I forgot about breaks. Then I saw there were already a couple patches on the mailing list and checking their github just now I see at least one PR with a bunch of back and forth and another couple issues with mostly no reaction or at best a few lame excuses.
If you could donate negative money to a project this would be a prime candidate. Sure, move fast and break things is bad, but this is the opposite of that, and not good either.
You're a prime example of user that makes maintainers quit.
LOL what is he supposed to do instead?
And if the maintainers are dragging their feet because they hate emoji(my guess, it's common enough), what else do they expect than to be constantly nagged by users.
And if the maintainers are dragging their feet because they hate emoji(my guess, it's common enough), what else do they expect than to be constantly nagged by users.
github.com
/s
To add something constructive, think of how deamanding people can be in ordinary everday life.
Now think of how demanding they can be when something doesn't quite work how they want.
I've been on both sides of the fence being a demanding user myself and prolific contributor. I could write entire volumes on the cesspool that can be opensource contributing; obviously there's lots of good that comes with it too, good communities, good people.
But open source is an ecosystem like any other really, there are cesspools of obnoxiousness, toxic behavior, and also havens of really insightful and friendly people.
/s
To add something constructive, think of how deamanding people can be in ordinary everday life.
Now think of how demanding they can be when something doesn't quite work how they want.
I've been on both sides of the fence being a demanding user myself and prolific contributor. I could write entire volumes on the cesspool that can be opensource contributing; obviously there's lots of good that comes with it too, good communities, good people.
But open source is an ecosystem like any other really, there are cesspools of obnoxiousness, toxic behavior, and also havens of really insightful and friendly people.
It doesn't have to be thankless - some projects award bounties or contract their contributors (see https://algora.io). Similarly OP could compensate the maintainers for their help updating the software.
If you want to increase the liklyhood of your contribution being merged, do:
* Provide unit-tests
* Good types
* No breaking changes
And if you want breaking changes or grand new features to be merged, you have to show activity in the issue tracker or fix open bugs first, to show the maintainer that you are willing to deal with the fallout or support requests that follow after a PR gets merged. This is not to be rude. This is seeing a PR through the eyes of a maintainer.
* Provide unit-tests
* Good types
* No breaking changes
And if you want breaking changes or grand new features to be merged, you have to show activity in the issue tracker or fix open bugs first, to show the maintainer that you are willing to deal with the fallout or support requests that follow after a PR gets merged. This is not to be rude. This is seeing a PR through the eyes of a maintainer.
Remember that you make your contribution because you or your company get something out of it. Don't expect any enthusiasm or kudos from the project's side. If these come, consider them a bonus. The contribution process will be slow. If you need the changes you are proposing, you will have to live with a fork or workarounds in your code for a while.
Explain all the above to your company. Expect them to be completely clueless on how open source works, even if they are developers themselves.
Personal anecdote on this: I had a team lead who insisted we directly submit a patch because "people would be thankful that we fix their code". And actually expected that they would have merged our fix before the end of our sprint.