In my case, I have found trying to contribute to open source to be a huge waste of time.
For example, I once found and patched a bug in paperclip, explained why it happened and sent a PR. It was ignored for 5 years and then they abandoned the project.
Or I once fixed Heroku issues by upgrading the ImageMagick version with a custom build pack. They featured it somewhere and suddenly I was getting entitled emails every day by random strangers who strongly felt that I should fix their Heroku deployment.
Then there's the issue of dependencies. My cool tool for analysing satellite photos won't be of much use to anyone who doesn't have API access to a satellite ground station. I.e. there's no benefit in making it open source.
And lastly, I've had the unpleasant experience of a company taking my open source project, adding copy protection and then selling it as theirs while simultaneously refusing to adhere to my license of either following GPL or paying for closed source use.
Nowadays, I only share source code for hobby projects with friends, but not publicly. Otherwise it's more work and less pleasant for me.
> In my case, I have found trying to contribute to open source to be a huge waste of time.
You mentioned the full extent of your attempt at contributing to open source consisted of a grand total of two meager pull requests.
I'm sorry to say but if throughout all those years you only managed to put together two patches then quite obviously you did close to zero contributions, both in absolute and in relative terms.
In fact, it seems you complain more about floss than actually contribute stuff.
I find that I general it's terribly easy to get your pull requests accepted to random FLOSS projects. Whether your PR is janitorial work, fixing bugs or adding features, you don't need much work to get your contribution in. So, quite frankly it sounds like you are grossly exaggerating and overstating not only the extents of your work but also the challenges you supposedly face.
> Then there's the issue of dependencies. My cool tool for analysing satellite photos won't be of much use to anyone who doesn't have API access to a satellite ground station.
In that case your so called cool tool to analyse satellite photos sounds very poorly designed. I mean, the whole FLOSS earth observation stack is designed literally from the ground up with extensive separation of concerns in mind (see GDAL and proj4 and orpheo toolbox for example) and apparently somehow you failed to learn the lesson that everyone doing professional, academic, and even amateur work knows by heart.
I'm happy to report that of course I sent in much more PRs and some even got accepted, but I highlighted one that didn't as an example of why it feels like a waste of time.
Similarly, I've had unpleasant experiences with entitled users more than once, I just picked the Heroku buildpack randomly.
As for the satellite tool, open tools will only take you so far. I do use GDAL, for example. But when you need to take photos on demand, you need very precise real-time trajectory and weather data, for which there is no free equivalent. Plus you actually need to send your photo request somewhere. And that's when you become dependent on an NDA-ed proprietary API.
There's good open source tools if you want to do offline analysis of static archive images. But not everyone has such relaxed requirements for refresh period and processing latency.
Consider using satellite photos to analyze traffic. You schedule photos with a proprietary API, use proprietary modules to download them, followed by proprietary file format converters. And then there's a block of image processing that I could open source, but that won't be helpful without the data acquisition and conversion pipeline. But actually it's a TensorFlow AI trained on proprietary data, so even releasing that is a legal nightmare. The whole project is commercially tainted from start to finish.
This is one of the most fascinating things about the internet. If someone were to read this incredibly extreme and atypical experience of sending in two(!) pull requests, they would think they'd be better off getting punched in the face than to send in a fix they made.
Opensource is enormous at this point. One data point(or even 30!) is no longer particularly relevant. Instead think of it like any endeavor in life. You are taking a leap of faith. Sometimes you'll have a great experience that may even blossom into greater things you never expected. Sometimes you'll be let down despite your best efforts and intentions.
I'm a bit surprised that you thought I only tried sending two pull requests. Those were just examples. I'm pretty sure I submitted 50+ by now, and a few were even accepted, but overall my conclusion is that it wasn't worth my time.
are you the only person on this planet with access to a satelite ground station?
niche projects that can only be used by a small group of people still benefit from open collaboration that FOSS enables.
also, i might patch your code to work without that ground station on publicly available satellite image data.
that last example is clearly a copyright violation. you should have legal means to go after them. i realize that is not trivial and may cost you a lot of effort, and while i would love to say there is help available i can't right now point you to one.
is there an organization that helps any FOSS project (not just their own) with license violations?
I'm the person who signed the NDA that I will not disclose the secret proprietary API for that ground station, so while others might substitute their own API, I would have to deliver things as a broken non-compilable project, which is sure to raise questions.
And yes, I did eventually succeed in resolving the copyright violation. But it was still a lot of work for me which I could have avoided entirely by keeping my source code secret.
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.
Notably the first. You fixed a bug, you contributed, you did your part but it was ignored. Did you learn anything from that? Beyond "Open Source is a waste of time" I guess?
It's easy to look at things negatively, but there's often positives to be found if you simply look for them. Not to say you're wrong, just, trying to offer some perspective.
For example, I once found and patched a bug in paperclip, explained why it happened and sent a PR. It was ignored for 5 years and then they abandoned the project.
Or I once fixed Heroku issues by upgrading the ImageMagick version with a custom build pack. They featured it somewhere and suddenly I was getting entitled emails every day by random strangers who strongly felt that I should fix their Heroku deployment.
Then there's the issue of dependencies. My cool tool for analysing satellite photos won't be of much use to anyone who doesn't have API access to a satellite ground station. I.e. there's no benefit in making it open source.
And lastly, I've had the unpleasant experience of a company taking my open source project, adding copy protection and then selling it as theirs while simultaneously refusing to adhere to my license of either following GPL or paying for closed source use.
Nowadays, I only share source code for hobby projects with friends, but not publicly. Otherwise it's more work and less pleasant for me.