[enraged_camel]

I will preface this by saying I have immense respect for anyone who open-sources their work. I think the web as we know it today would not exist without such kind and hard-working individuals.

In my opinion, I think most of these issues outlined in the article are caused by lack of communication combined with unclear expectations, to be honest.

The only thing I ask of open-source library authors/maintainers is this: be upfront and clear about the nature of your library, and your level of commitment.

Is it just a hobby app? Totally fine, just put in bold text "this is a hobby app, not recommended for production use". That way, everyone knows what to expect, and if they do decide to use it in production, they do it at their own risk.

Do you feel that it is feature-complete? Then just say so, and indicate you will not be doing any more work on it.

Do you want to work on bugs whenever you feel like it? Nothing wrong with that, it's your work, but again, please just put it somewhere in writing so that any developer or PM who comes across your library knows exactly what to expect.

You painstakingly supported a library for years, got burned out and want to quit? At least try to pass it to another maintainer.

IMO these are just some very, very basic things that open-source authors can do that would alleviate a LOT of the friction that occurs in this space between them and those who decide to rely on their work.

Be kind, be clear, be upfront. That's it!

[cycomanic]

So your solution to open source authors getting too many demands for doing things is to demand they should do more?

Seriously, this feels almost a bit like victim blaming. Why would an OSS maintainer need to write that something is a hobby project. It really doesn't matter, if as a company you want to rely on it, pay for it. Why should your expectations change because of what the maintainer says?

[wildmanx]

> I will preface this by saying I have immense respect for anyone who open-sources their work. I think the web as we know it today would not exist without such kind and hard-working individuals.

That itself is part of the problem.

I do also appreciate all the great FOSS ecosystems that I'm using. Who knows where we would be without them.

But open source software is not about some kind, selfless altruist who hacks away for free for the benefit of others. It's about publishing the source code with some attached rights and obligations for programs or libraries that have been developed to scratch an itch. Be it personal need, personal interest, learning opportunity or straight up business necessity. You publish to get a community involved to make your software better, be it through bug reports, recommendations for improvement, pull requests, etc. That ultimately benefits the author, and that's the whole point.

It's a misconception that open source software is (or should be) developed for the greater good, to be kind to one another. And by keeping to thank "kind hard working individuals" (which they often times are!), one perpetuates this misconception. It's great if kindness is a component in all of this. But it's not the central point and should not be expected to be. That's what causes threads like this one in the first place, where somebody has to complain about being exploited or getting annoyed with peoples expectations, or their own expectations with themselves, and then others opining about that.

> You painstakingly supported a library for years, got burned out and want to quit? At least try to pass it to another maintainer.

Are you serious? Above you just said that you have immense respect for open source authors. And now you say that somebody can't take it anymore and is burned out and THEN you STILL expect them to put MORE work in, despite being burned out, to pass things on? The source code is available, the license is clear, if there is anybody else who wants to maintain, they can just go and to it. Why do you keep demanding anything from the already-burned-out author that you respect immensely? Honestly, I find that deeply disrespectful.

[account42]

> Are you serious? Above you just said that you have immense respect for open source authors. And now you say that somebody can't take it anymore and is burned out and THEN you STILL expect them to put MORE work in, despite being burned out, to pass things on? The source code is available, the license is clear, if there is anybody else who wants to maintain, they can just go and to it. Why do you keep demanding anything from the already-burned-out author that you respect immensely? Honestly, I find that deeply disrespectful.

I just want to add to this: Finding and training a new good maintainer is a lot of work. If you just pass the project along with its reputation to whoever comes up then you might be doing more harm and it might be better to not do anything and have the new maintainer earn their own trust with their fork. So yeah, having open source developers to pass on the project when they want to quit is not a fair expectation.

[yawaramin]

The OP is an article doing literally exactly what you want. And he's going above and beyond what's required–he didn't even need to communicate all this redundantly. It's already all in the open source license–willingness to work, level of commitment, etc. Just read the license. It's included in every open source project.

[account42]

Exactly, here is the first sentence of the zlib license:

> This software is provided 'as-is', without any express or implied warranty.

Almost all open-source licenses will have conditions like this, MOST EVEN MAKE IT ALL CAPS. The default expectation of support from the author should be 0.0

[unmole]

You could figure out all of this by looking at the project's releases, mailing lists and the bug tracker. That's something you should do even if a author puts up a statement because it might no longer be accurate.

[chrisshroba]

I agree with you. There was a comment on here at some point that if you have a solution that starts “If everybody would just...”, then you don’t have a solution at all. Everybody will not just respect open source maintainers (well deserved) right to not be harassed, poked, and prodded.

I 1000% agree that open source contributors and maintainers don’t owe anyone anything, but if people still demand things, I’d recommend putting disclaimers like you’re recommending front and center, if at the very least so that maintainers can respond to the pushy people with a link to it.

[jjav]

> be upfront and clear about the nature of your library, and your level of commitment

The clear statement on this is in the license of the project. You need to read the license, which grants you certain rights to the software to see what you're being granted and what you're not getting.

In nearly every license, very specifically says that it's not supported and you're entirely on your own if you decide to use it.

If you need a higher level of assurance, you need to pay for support. Either from the author(s) if they are interested, or from third party companies who provide support for that library, if any exist.

[damethos]

I was about to reply something similar but your comment totally covered me.

NPM had some thoughts about providing package.json metadata in order for the customers to know the author intentions but I am not sure what happened to it.

I remember reading about it in this article: https://www.theregister.com/2020/10/28/nodejs_15_michael_daw...

> The [module] maintainers are struggling," he said. "They may have written a module, it was a hobby they did on a weekend, now they've got 20,000,000 downloads and the people who are using it > have expectations which are more than what > is appropriate for something that they're getting for free. We've worked on something that we call package support which is adding extra metadata to > the package JSON, which allows the maintainer to provide information about their intention in terms of support. So what kind of support is there? Is it best effort? Is there no support at all? Is there > a company? Is it part of a foundation?

- Michael Dawson

[wildmanx]

> We've worked on something that we call package support which is adding extra metadata to > the package JSON, which allows the maintainer to provide information about their intention in terms of support. So what kind of support is there? Is it best effort? Is there no support at all? Is there a company? Is it part of a foundation?

The default answer is: No. There is no support. And that's written in the license already.

Announcing anything beyond that is called an ad. It may be a useful ad, but it's still an ad.

(Assuming it's paid support. If it's support "for free" then that's part of the problem if it's social-pressures somebody to do this in their free time. You are externalizing your business support costs. And you really want to build your business empire on a teenager's hobby project? So, whoever is interested in this "intention" metadata should only really care about paid support, and then that's an ad.)

[heurisko]

> 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.

[tome]

Totally agreed. One of the easiest ways to deal with misaligned expectations is to clearly state your expectations.

[wildmanx]

While that's true, it's sad that the default expectation seems to be "you provide support for me and keep maintaining this thing, and once you can't anymore, you'll find somebody else who does, so that I can keep benefiting for free from all your work".

The default expectation should be that there is nothing promised beyond what's in the license. Anything beyond it needs to be clearly stated, but in the absence of any such statement, don't assume or expect anything.

Note that this expectation is clearly stated in most FOSS licenses. Usually right at the top, IN CAPITAL LETTERS. Having to write an extra blog article that basically says "I really mean what is in the license" is redundant, and it's sad the this has do be done and is even being argued about.