My boundaries as an open source developer

> I fail to see why it matters that your PR isn't accepted.

Making their code useful to other people is a strong motivator for many altruistic open source developers.

The purpose of getting PRs accepted upstream is so that your changes are useful in concert with other people's changes, especially their later changes.

Your private change is of little use to others when it's only in your private fork, which hardly anyone knows about, and if they do know, your change is incompatible with later work and maintenance by other people anyway.

If you don't care whether anyone else uses your work, especially in future, that's fine. But if you want it to be more useful to others, getting it merged upstream makes a huge difference to that.

(Merging upstream or just submitting PRs that don't get merged also helps personal visibility and reputation, which is undoubtedly a motivator for many. That's a burden on upstream maintainers when someone is pushing low quality work and doesn't care to ensure it's useful to the project.)

> When it comes to low quality pull requests, tell the author how to improve them. Ideally, I should be able to merge PRs without any changes necessary on my part. This will both lower the amount of work I have to do, as well as educate the author so they will be more productive in the future.

I agree that this probably the ideal thing to do in the long run but, especially as a less social person, often it feels much easier to just do the minor fixes required myself. Training people to be good contributors is a good thing to do, but it is also something that can be very draining.

I found working in the Linux space did have that problem in pre-COVID times. Especially the lack of solid relationships, due to never meeting people and getting to know anyone personally.

I spent too much time working on things for free (not just open source, but also voluntary work, and a couple of tech R&D ventures that ate my savings) and as a result I couldn't afford to attend any of the in-person conferences in far off countries, where the real action seemed to migrate to. That was a strategic error on my part!

LKML also become stressful for me after a decade of reading, just due to the energy to skim the mails each morning due to sheer volume. So I fell off, which was a shame because I had a very solid understanding of the entire kernel at one time.

"It's hard to maintain a project as a single-maintainer. Nobody puts in more than a cursory effort to contribute."

"Yeah, but what if other people contributed?"

It's a huge chicken-or-egg problem.

At this point, unless you have a big name behind you (being a major corporation like Google or Facebook, or OSS celebrity like Torvalds), the chances of any particular project growing beyond single-maintainer are really slim.

I've seen several people, on my own projects and others, talk about not trusting single-maintainer projects to last as a reason to not get involved. It's infuriating, because it's a self-fulfilling prophecy.

And there are no guarantees the major OSS names will perpetuate their projects any better than an independent, no-name, single-maintainer. If anything, I've seen companies like Google drop projects much faster than I've ever done in any of mine.

People see the name and assume there is already support behind the project. Yet often the projects start as a single-maintainer thing that the company then puts a marketing machine behind.

I had a project years ago that was my first promising open source project. It was growing, it had a small handful of minor-but-meaningful contributors. People saw my name on 95% of the commits (I was working on it full-time) and called it single-maintainer. A year after I released, a major corp announced they were releasing a competitor. They hadn't released it yet, just announced. Overnight, I saw interest in my project dry up. It took another year for that other corp to actually releases, during which time they had fewer actual contributors than I had. When they did release, it took another year before they reached feature parity with me, but by that point it didn't matter. They had started telling people they were the first such project ever. Randos online started accusing me of copying the other project. I couldn't keep up with development and marketing on my own, especially after the digital agency I was working on it at went belly up.

I knew most of the people on the team at the major corp. We were in a very niche industry and we all knew each other. I think it was that "ours is the first" bit that really got my goat. They not only knew me and knew about my project, they even admitted they had been using my project for testing compatibility of another project they develop.

Thus I now hate Mozilla with a passion.

> That way, everyone knows what to expect, and if they do decide to use it in production, they do it at their own risk.

This is the default position for most open source licences, hobby projects or not.

I agree it is useful for hobby projects to be labelled as such, however.