The Pragmatic Open Source Contributor
diurnal.st
diurnal.st
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.
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.
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.
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.
/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.
* 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.