|
I disagree that these examples are a waste of time. In all cases you benefit from having created the code to address your own use case, but perhaps don't see further direct benefit from sharing your work. Submitting a PR allows others in the community to apply your patch (or incorporate into a forked version of the project) if the PR doesn't get merged or deleted. From a project maintainer's point of view, significant patches can be difficult to test & review, and merging a PR implies accepting the long term maintenance of those changes. I've left some promising PRs for much longer than I'd prefer to because of factors like time to review and the risk of merging code which may not have adequate tests. If an open PR attracts some community interest or discussion, that can give project contributors a helpful signal for prioritising. If a PR is featured somewhere, this can be an opportunity to raise your profile and perhaps introduce those inquiring users to something you can benefit from more directly. If I get direct emails about a PR or project I contribute to, I try to politely point those users to the right channel (eg raise a GitHub issue) and ideally a contributor guide so they can be empowered to contribute directly. This may not be a straightforward reflex to develop, but I think responding with "This is a volunteer effort -- here's how you can help with docs, testing, or code" is a better viewpoint than "Ugh, more entitled users". I've been pleasantly surprised to see this approach turn some agitators into useful contributors. If a project has very niche dependencies (like requiring API access to a satellite ground station), there can still be an audience and they may be even more motivated to collaborate on your open source project. I feel like this may have the best upside in terms of potential ratio of users to collaborators. I think your last example is the most challenging. If you are concerned about someone else benefiting by stealing or repackaging a project you have openly shared, it would be best to keep that effort private. Compliance with open source licenses (or the spirit of open collaboration) requires ethics that are not universal across developers, companies, and countries. This problem isn't unique to open source (commercial licenses also don't prevent piracy), but is a harder blow when you are personally affected. |