So another day, another debate at work. Life goes on as usual. This one has to do with dependencies that nearly do what you need.

Let's say you need to implement a bespoke feature but

• you don't want to reinvent the wheel
• your extensive research have shown that existing packages only do some of the things you need

What's the next course of action?

• do you pick the package that satisfies most of your requirements, fork it, adjust it to your needs and move on?
• do an MR, be patient hoping that the package is still maintained and that your fix will eventually be merged
• do you try to use the that package by hacking your way around the it, until it satisfies the requirements
• do you write everything from scratch

If you do fork it

• do you feel the need to publish it on package manager (npm, nuget etc) with a different name for the slight chance that someone else might have similar requirements?

Personally 5-6 years ago I would try to hack my way around a package trying to do what I want it to do, trusting the developer that maintains that package entirely.

But nowadays, depending on the complexity of the package, I rather fork it, add my feature/fix and move on. And most of the times I don't even consider whether the community will benefit from such bespoke (usually) features. So I don't bother publicly republishing the new package. Not to mention that who needs another variation of a package, its nearly pollution.

Now if I see a benefit, and If I can afford spare some time (usually on my free time), I'll actually bother with an MR, if it concerns a well maintained package. Because let's be realistic there are a lot of packages out there (especially in JavaScript) that even if they are maintained, they are usually maintained quite poorly (I am including myself in that list, of poorly maintained packages), so your MR will probably either be rejected or take a long time to be merged.