Kissaki comments on Open source is a thankless job and I think we've lost the plot on how we treat maintainers

Open source is a thankless job and I think we've lost the plot on how we treat maintainers (github.com)

submitted 4 months ago by sanitation@lemmy.today to c/programming@programming.dev

78 comments fedilink hide all child comments

I saw an issue today on a fairly popular project (better-auth, see the link to the issue attached). No repro, no context, just a wall of caps and profanity ending in "fuck you". The maintainers ship this for free. People run production businesses on top of it, for free. And the thanks is someone raging into a text box because a minor bump cost them an afternoon.

I maintain and contribute to a few projects myself, so this hits a nerve a bit. Something people don't see from the outside: it's not enough to know how to build the thing. You also have to know how to defuse a thread where someone's insulting you and not fire back, even though most of us aren't paid for any of it, let alone the work of staying civil while being told to get fucked.

I'm not pretending breaking changes don't cause real pain (that's what the issue is about). But I keep coming back to a boundary question: if you're not paying for it, do you actually get to demand anything? (Obviously yes, but we still need some boundaries)

[–] Kissaki@programming.dev 3 points 4 months ago* (2 children)

What makes you think it's a lockfile issue? If they sighted a patch upgrade then updated the lockfiles but then noticed a breaking change, then lockfiles are irrelevant.

If it's actually like they claim, I understand the frustration. (Not that I know this project in particular or how it gets integrated.) Without clear versioning and/or changelogs/release notes managing upgrades is cumbersome, sometimes impossible.

In some cases I've had to ask for clarification in PRs because release notes were not clear, PR was not clear, and resolved ticket was also not clear on the thing or solution.

Apparently they had issues before, so maybe they could have expected "patch may not be patch-only".

permalink

fedilink

source

parent

hideshow 2 child comments

[–] kibiz0r@midwest.social 15 points 4 months ago (1 child)

It’s the combination of “breaking changes on minor releases” and “disregard for … production environments”.

Can you stop releasing breaking changes on minor releases? It's absolutely infuriating that you guys keep doing this over and over again with complete disregard for people downstream using this package in production environments.

By the time you’re deploying to production, you should already have your versions locked in, so semver does not factor into resolving dependencies for production deployments at all.

I can understand it being annoying for development processes. Like, if you have a dependabot-style tool that tests against new releases and submits PRs for them, that can definitely be a waste of time and attention if it fails frequently on patch-level updates.

But in between that “eager testing” step and a production rollout, there needs to be a moment where a human reviews the updates and signs off on updating the lockfile.

And at that moment, reading the changelog, it really doesn’t matter if it says “1.0.1: breaking changes!” or “2.0.0: breaking changes!”, because you need to be looking at the substance of the update.

The only way semver violations burn you in a prod env is if you’re YOLOing new versions out there, either by forgoing a lockfile or by merging lockfile updates without review.