It takes money–a whole lot of money–to make open source work, but it takes recognition and appreciation to make an open source developer happy.

As it turns out, maintaining good open source code is difficult. Just ask James Coglan, who disgorged a litany of reasons why releasing code can take forever. Oh, and without much hope of empathy in return. Or ask Isaac Schlueter, CEO of npm, who agonized over the burden of maintaining code for entitled downstream users who “don’t love me.”

As people, we want to be recognized for the good work we do. Open source, however, often tends to maximize negative feedback loops, contributing to developer burnout, as Schlueter highlighted.

Under pressure

Schlueter, commenting on developer burnout, was quick to highlight that “the most commonly cited aggravators in open source work have nothing to do with licensing.”

For some, like Go developer Ben Johnson, the problem is one of compensation: “The number of people offering to pay for BoltDB support vs people complaining about my lack of free support is SHOCKINGLY low.” Ultimately, open source comes with an expectation that the software is free, he goes on, and this simply isn’t tenable.

SEE: How Mark Shuttleworth became the first African in space and launched a software revolution (PDF download)

Schlueter isn’t convinced. For him, open source burnout is not about cash, as most open source maintainers make enough to keep the lights on. Even so, wrote developer William Gross, “What we need is a new industry norm, that project leaders will always be compensated for their time.” The software can be free, in other words, but all the time that goes into maintaining it should not be.

Is this really about money, though? Schlueter, again, thinks otherwise. Cash may be an issue for some, but “I’ve watched many people get super burned out while making very good money, where their open source happened during work hours.”

I’m just a poor boy, I need no sympathy

The issue, Schlueter called out, is entitlement: “The issue is irrational obligation; in other words, a self-destructive vulnerability to entitlement.” He digs in deeper:

The issue isn’t that users of my open source software aren’t paying for it, or aren’t contributing, or are for-profit companies. It’s that they don’t love me. Unrequited (or insufficiently requited) love + over-expenditure of effort – boundaries = burnout.

Coglan says much the same, acknowledging that “people are mostly pretty nice and don’t rage at me about their issues getting delayed” when he’s been working constantly to fix an issue. But not everyone is so pleasant, he lamented, and this burden of supporting other developers without empathy is taxing. Gross adds to this sentiment, stating: “We also need to bury the idea that any developer who submits an issue or pull request is automatically entitled to the attention of a maintainer.”

So what’s the solution?

Can anybody find me somebody to love?

The ” dew drops in the desert” that Schlueter longs for are simple words of thanks. However, because even the expectation of thanks can lead to frustration when it doesn’t come, he has inoculated himself by using the highly permissive ISC license that basically says, “Do whatever you want with this software.” That way, when someone proactively does reach out with thanks or positive affirmation, it’s an unlooked-for gift. In this way, licensing can matter.

SEE: Mastering Git (TechRepublic Academy)

Some developers think licensing can be used as a hammer to compel contributions back, whether cash or code. Maybe. But that’s not really the point, at least, it’s not what Schlueter and other developers seem most to want. No, what they want is to be treated with respect. This is harder in an open source context, in some ways, and differs from a corporation where your “thanks” is a paycheck and the occasional pat on the back.

In an open source context, the paycheck is generally related to one’s open source code, but not a direct reimbursement. As such, appreciation carries more weight. As such, next time you want to whine about how slow a maintainer is to accept your code contributions, perhaps you should start by offering a little empathy and appreciation. You’ll find it pays significant dividends.