I'm seeing a lot of GitHub sponsors and issues chatter lately, I'd like to surface a view point neither good or bad, about what eats some of our time as maintainers - just to add more data/context to the discussion.

(1/n)

Disclaimer: this is influenced by the fact I work on client/server libraries a lot. Whether it be something that connects to SQL, Redis, or logs to them, etc....there's a connection involved.

This category of open source: something that connects to something else is problematic.

You can slice divisions a hundreds ways, but the 2 main categories I see are:

1. Issues with the library, it's doing something wrong.
2. Issues with your environment.

Number 2 may be something the user does or doesn't think is the libraries fault, but the seek help regardless.

This can manifest from badly configured: firewalls, connection strings, thread pools, overall CPU (or any resource really) contention, the server just isn't running, network blips, service restarts, not the version of server they thought it was...it's a long, long list.

Importantly: these very often have little or nothing to do with the library, and fixing them is done with changes completely outside the maintainer's control (in your environment). But, they're super high in maintainer cost in the from time and sanity.

These issues, even when solved:
1. Are likely to be a one-time solution, just for that user.
2. Require a lot of context and back and forth (read: time).
3. Don't help any other user, or improve the world for anyone else.

Sometimes we get lucky on 3 with a better error, though.

These are, in short, support requests. They are asking for free debugging time, for something that isn't your problem. Maintainers do this out of good will.

I have ZERO problems requiring some form of compensation for that. It's an extremely lopsided drain of maintainer...fuel?

We can't integration test every environment. Integration tests for client libraries are very expensive to setup, maintain, and the *actual* production configurations have millions of permutations out there: it's just not anywhere remotely close to reasonable to do completely.

Actual library bugs? Yeah, absolutely. We can test those. Those should never require sponsorship, etc.

But users don't know the difference. A bug is something viewed as behaving unexpectedly - most users don't know it's their environment, at least when filing the issue.

For instance (this is super common):
users think a blip on something in the cloud is probably the library's fault, as if everything has 100% up time, never gets patched or failed over, etc.

This is simply not true, but as we abstract more and more, user are aware less and less.

I'm not blaming users here - I'm just illustrating a common issue and hopefully signaling the virtues of knowing a little bit about what you're building on, the characteristics of it, etc.

The less devs know about their environments, the less they know where to go to seek help.

And so, they got a connection error. It's from the library, let's try that library's maintainers first. Maybe it's intentional, maybe it's the first google result, whatever the reason: it's common.

You're a helpdesk, for someone else's network problems. It happens. A LOT.

Actual library bugs, something we can discuss in the context of a common way (not specific to someone's environment, though that context can *help*), are comparatively far easier, in my opinion. They're far less time, less iteration, and those fixes or improvements scale.

I've been burned out in ebbs and flows on open source, and it's mostly due to those environment-specific issues. I thankfully have rarely hit egregious user behavior, though we've seen entitlement to that support often (and it's very demotivating, I often step away for the day).

For me, and I can't speak for anyone else, I am personally driven by the desire to make a positive impact on the world. Spending a lot of time to fix one person's issue that's unlikely to help anyone else later isn't that...it's the opposite. I'm here for impacts that scale.