Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

So much this. I'm glad he put this out there. I'll start linking to it too.

There seems to be a common misconception about open source. When I release software as open source, it does not mean I work for you for free, need to provide you with anything, even need to be nice to you. I may. Or I may not.

When I release software under an open source license, then we have a very specific deal. You are entitled to do certain things with the software, for example use it free of charge, or change it, or redistribute it, and I'm entitled to certain things in return, for example you keep attribution, you publish changes that you made under the same license, etc. Nothing more, nothing less. I could be an individual that hacked something in their free time, or I'm a multi-national mega-corp. Does not matter. It just means we have a deal.

It's nice if a community emerges, and if I feel like it, I may participate in it. And accept pull requests or help with troubleshooting or implement new features. But I don't have to and I don't have to feel any obligation whatsoever. Anybody who thinks otherwise has misunderstood the concept or is maliciously misusing it.

That's it.

This is misunderstood not just by users, but even by creators themselves. They feel pressure, they feel bad if they don't respond in time, or implement new requested features, or accept pull requests. They shouldn't. Open source just means I published it once with a very specific deal. I may continue to do so if it makes sense to me, but I can also just stop doing so. I implement features when I have a reason for it, for example I like to have them in the software so I can use them myself, or maybe because I'm a corp that sees a business need. But implementing them for free just because somebody asked for it, that's just asking for trouble. If you do that regularly, and not mostly because you think it's fun, but because you want to "support the community" or whatnot, you are taking steps towards burnout, and ultimately are not just hurting yourself but even the larger community, because you are fostering the expectation that that's what open source devs should do. No, they shouldn't. That's not what open source is about.

It's about a specific deal. Nothing more, nothing less.



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!


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?


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


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


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.


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


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.


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.


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


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


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


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


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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: