Comment by dmitriid

Yes; it’s definitely less convenient to write and maintain your own software compared to having someone else do it for you.

As a project maintainer I’ve made the mistake several times of being too permissive with pull requests. Someone comes along with a feature they’re excited to add to my project. I don’t need the feature myself. They exuberantly make a PR, and I eventually merge it. Before long it turns out there’s a bunch of bugs with that feature, and the original author is gone. Do I waste my time fixing their code, for a feature I never wanted and don’t use? Or do I ignore the bugs and let the smell of low quality work waft over my code base?

These days I default to refusing most feature requests, even if they have decent PRs. I write most software for fun, or to scratch an itch. I don’t do it because I want to manage a community. If you want to add features and build a community around a project I’ve written, great. I’m happy to link to your fork in my readme.

Forking is not a symptom of failure. Maintaining a fork is sometimes just the ticket price to control your destiny.

You can fork, fix the issue, and issue a pull request and/or start a discussion about the issue and potential fix. That is the core of open source - not demand that others fix the underlying issue for your problem.

So you're asking someone else to do that work for you. Look, the user has a few choices:

1) find a work-around (maybe unwind his or her own mess) 2) manage a fork 3) work with the existing process

I've worked around people doing all three of these options but what I've regularly found was that taking a look at unwinding your own mess is the right approach for the vast majority of cases.

If it is for his pressing need, he can maintain a fork. And it is not difficult to maintain a clojure fork given its release cadence.