Hacker News Reader

Comment by supportlocal4h | Hacker News Reader

There are a lot of facets to open source contributions. One big facet is the whole itch-scratching thing. If you know longer itch, stop scratching. That's ok. Maybe when you stop scratching, it will start to itch again for you or for someone else. If nobody steps up, it just means it doesn't itch enough.

Abandonware is not such a bad thing. It served its purpose for a season, then the world moved on. Nobody's out there trying to breath life into the Apollo program. Or into Mosaic. And that's ok. It doesn't diminish how awesome they were at the time.

View on HN

The hard part of OSS management is dealing with change requests. Something comes in and now it's on the maintainer to ensure that the new fix doesn't break anything existing, or the new feature doesn't collide with anything else that comes down the pipe later. It's not work that can be done by volunteers, it's something that can only be done by long-term maintainers.

When I worked on an OSS project I hated getting PRs. They usually wouldn't work for one reason or another and I would have to explain why they were problematic. It took a lot of time out of my day—I would rather people just submit bug reports and feature requests.

Also it hurts all around to tell a hopeful contributor that their code isn't good enough.

Yes, with hours of effort you can make your review relentlessly positive and constructive, but then it still hurts and they probably don't have the ability to fix it.

You'll have to fix it for them, which is often harder than writing it from scratch.

Thanks for writing this; it matches an undescribed feeling that I've experienced for a few codebases.

What I'd add in response is that this "change request load" is much easier to manage for small, well-maintained projects with fewer quirks.

And if the entire project architecture can fit within your mental buffer space at one time, then it's much easier and faster to parry those incoming change requests and pull requests into clear, effective feedback and code.

This applies well for things like a java package where the itchy generally have the skills to scratch. I think of these things as having numerous benefits, namely saves your company/team time; most of the time, in this case I think boo-hoo if the person working tirelessly for no compensation stops doing that... Pay them or do it yourself. (I am currently doing-it-myself with an abandoned java package my team relies on.)

However, this logic fails for situations where the itchy often aren't capable of scratching. For example, a wordpress plugin. In this case, I think it's a grey area. Maybe users should have to pay since they can't write it themselves. But that attitude would still fail for situations where a library is widely used and security patches would be for the "greater good".

In such a case, maybe Wordpress themselves should extend some engineering capacity for maintaining popular OSS plugins for their ecosystem.

There's also libraries that are simple enough that they just work fine without constant updates. I have numerous libraries that I use that haven't had commits pushed for 2+ years. This is the other aspect: burnout is so rampant because it feels like it never stops and you can come up for air.

Burnout is made worse when you take on too many complex interactions and dependencies.

OSS works best when it’s a small project that does a single thing and does it well, but doesn’t rely on too many upstream projects for its functionality.

As soon as the project tries to do too much, it virtually needs a committee to coordinate it all. If it relies on too many upstream dependencies, then the maintainer will be hammered with complaints that “this doesn’t work with version 1.45 of foolib… fix it!”.

But a project that just lives in its own little world, doing its own little job? It’s something you can just maintain and improve at your leisure.

The irony is we demand constant updates, pushes, recent commits, and maintenance, yet we use OSes with libraries and tools that were written decades ago and see little to no updates at times. Some of us go happily along using a decade old version of zlibc, for example. But when it comes to that latest NPM dependency -- if it doesn't have a commit within the last six months, psh! must be abandonware.

That sounds good in theory but it doesn't compose.

Maybe only a few people are using your library directly, but most use it as part of some larger library. That library has a continuity problem now.

Reply on news.ycombinator.com