[BowBun]

> Having a project maintainer then call those patches boring or otherwise disregard them? That's childish

So what? Along the same lines, it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one.

With those PRs written, _anyone_ on the internet can apply them and use them in their software. I agree with GP, you aren't owed anything, and that extends to any form of social behaviors online. And let's not forget that even the most 'perfect' maintainer still deals with shit on a regular basis from the masses of people demanding features as if they got paid to write the free software people are using.

This expectation of being served high-quality open-source software for free, and then outrage when it isn't, is absolutely ridiculous and will make people not want to maintain software.

[kllrnohj]

> it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them.

It is when they setup an open source project that has that appearance and is framed as being such a project.

It is entirely the maintainer's responsibility to establish the type of open source project it is. If it was just a toy hobby project and that's all it was meant to be then it should have been framed as such (such as by being in a personal repo for starters). This project promoted itself for production usage, requested feedback & patches on its project page, and had a github setup that gave an appearance of being, for lack of a better word, professional. That's entirely the fault of the maintainer. They set all that up. They established the expectations of the project.

None of that at all forgives the name calling & mud slinging they were subject to, of course. Two wrongs don't make a right. But the maintainer was still also "in the wrong" here. They needed to hand off the project much sooner than they did when they realized they were not at all prepared or ready to handle what they promoted the project as being.

[khazhoux]

> It is entirely the maintainer's responsibility to establish the type of open source project it is.

On what basis does a developer assume this responsibility? You are saying that by uploading a library that works well, and whose presentation (docs, etc) are high quality ("professional") that the owner now has the responsibility to publicly state whether this is a personal project or not, and they must state their SLA and process with respect to accepting patches? No such thing.

> That's entirely the fault of the maintainer. They set all that up. They established the expectations of the project.

If the maintainer says "I shall provide X amount of service" but then does not, that's on the maintainer.

But if a user likes a library and starts depending on it without checking if the library is "properly maintained", that's on the user. How can it be otherwise?

[kllrnohj]

> You are saying that by uploading a library that works well, and whose presentation (docs, etc) are high quality ("professional") that the owner now has the responsibility to publicly state whether this is a personal project or not, and they must state their SLA and process with respect to accepting patches?

No, I'm not. I'm saying if you setup an open source project framed as a project that is production ready & open to patches with a guise of being run by an organization and intentions of having a community, then it is reasonable to expect that you actually do that. You don't accidentally make a github organization, after all. There are community norms around what you can expect when working with such projects. Particularly when then both the github page and the webpage speak of being welcome to contributions ( https://github.com/actix/examples#contribute ) and building a community.

This was not just a high-quality library tossed out into the wild that got adoption. This is a library complete with these pages https://actix.rs/community/ & https://actix.rs/code/

The author did a hell of a lot more than just "uploading a library" here. As such, the developer assumes these responsibilities because it's what they said.

You are always responsible for what you broadcast.

[Touche]

Read the license, it frames the project exactly.

[kllrnohj]

The license only frames the projects legal responsibilities. It is entirely unrelated in every way to how the project is run on a day to day basis.

Alternatively if we're going to just go strictly by the license then the maintainer deserved all the flames & flak he got. After all, it wasn't against the license, therefore he cannot complain about it. Just like that idea is unreasonable, so too is trying to hide behind the license in this case.

[bpt3]

> The license only frames the projects legal responsibilities. It is entirely unrelated in every way to how the project is run on a day to day basis.

You completely missed the point. At the end of the day, the legal obligations are the only ones, and both the Apache and MIT licenses very clearly state that the creator of the software has no obligations to any user.

Therefore, any other supposed obligations only exist in the mind of the person who has created them, and do not exist in reality.

> Alternatively if we're going to just go strictly by the license then the maintainer deserved all the flames & flak he got. After all, it wasn't against the license, therefore he cannot complain about it. Just like that idea is unreasonable, so too is trying to hide behind the license in this case.

Sorry, this doesn't make sense, because you're comparing an explicit statement of liability in the license to the social norm of not being a massive jerk.

[kllrnohj]

> Sorry, this doesn't make sense, because you're comparing an explicit statement of liability in the license to the social norm of not being a massive jerk.

Of course it doesn't make sense, that was my point! In the same way it doesn't make any sense to do what you're doing, which is comparing the explicit statement of liability in the license to the social norm of how open source projects are framed & run.

You missed the point that everything we're talking about is just social norms. The license is irrelevant here, for all sides. There is no legal issue being disputed.

[bpt3]

No, everything is not just social norms, because there is no agreed upon norm or standard "framing" for open source projects (as indicated by all the disagreements here and elsewhere on this topic), leaving the actual license as the only concrete, agreed upon description of obligations and expectations between the creator/maintainer and users.

[aidenn0]

> You completely missed the point. At the end of the day, the legal obligations are the only ones, and both the Apache and MIT licenses very clearly state that the creator of the software has no obligations to any user.

There's a word for people who only fulfill their legal obligations: Assholes.

[bpt3]

> There's a word for people who only fulfill their legal obligations: Assholes.

There's also a word for people who expect others to meet their expectations without contributing anything on their end: Assholes.

If you explicitly state up front what you're willing to do to support a project, and I come along demand you go above and beyond your stated limitations, who is being unreasonable here?

[ori_b]

> There's a word for people who only fulfill their legal obligations: Assholes.

There's also a word for people who stake their professional reputation on the work of random assholes on the internet.

[rakoo]

The license is to a project's readme what patent claims are to the rest of the patent document: when there is a conflict, it's the one thing both sides can agree on.

However professional and well-presentend the project is, at the end of the day maintainers are doing this primarily because they like it. If they don't like doing something related to the project then no one can blame them for that.

[slavik81]

Every open source project has a warranty disclaimer. It really doesn't tell you anything about how serious the project is.

[tadfisher]

Open-source means freedom to fork, nothing more. But that's ancillary to the rest of your comment.

[dunnock]

Your statement is false. They called for contributors many times, last time in August https://github.com/fafhrd91/actix-web/issues/1019 .. This was public and open message and is not the first time.

Though while people are ready to open issues and complain, sometimes even supply patches and make big noise if they do not pass code review, there were nobody who could join to share responsibility in making decisions about the project.

[kllrnohj]

> Your statement is false. They called for contributors many times, last time in August https://github.com/fafhrd91/actix-web/issues/1019 .. This was public and open message and is not the first time.

That thread is full of people trying to sign up and help. Either they all lied or nobody was accepted.

[logophobia]

It was advertised as a production-ready web-framework, and it was very popular. When do people get to complain? "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.". Web-frameworks are cornerstones for security, and if you write one, advertise one, you need to care about security. Features, code-style, ad-hoc PRs, bug-fixes: little responsibility there, but security is something that can hurt a lot of people if done wrong. The use-after-free bug this was about could've been exploited in the right circumstances.

If I build a playground for free and it gets popular in my neighbourhood, and then collapses on some poor kid, I'm still responsible, even if I did it for free.

The way it was handled was definitely NOT productive though, the guy didn't deserve the flames.

[cmsj]

> if you write one, advertise one, you need to care about security

The word "need" there is wrong. You could (and perhaps should) take the opinion that one should care about security, but there is no obligation (legal, financial, or moral) that requires an open source maintainer to care about anything. If you want those obligations, get a contract and pay some money.

What's happened here, and you seem to have fallen into this trap too, is that people believe software abstractions also automatically abstract responsibility. It's certainly not a new mistake.

What this incident seems to show (and I'm not a Rust community person, I've just been reading a lot of the threads/archives about this) is not that the framework maintainer was terrible, but instead, that what he was offering was not what people assumed it to be - some people assumed the project would behave in certain ways, and have invested their time (and presumably money) in building on top of that project, only to discover that the project does not behave how they want and now they feel burned.

I believe that being an unpaid open source maintainer (which I am, and have been, in various small ways, for a couple of decades) means having a best-effort responsibility to your community, but never at the expense of yourself. That is, however, just my belief, and nobody is obligated in any way to share it.

The ancestor post about owning dependencies, while a little more aggressive than I might have written it, is basically right. You don't abstract responsibility for code just because it came neatly packaged - if you don't have a support contract for it, you are responsible for it. That's just basic logic really.

Having said all that, I do think that deleting the repos was a poor reaction - I believe (again, just me) that a maintainer should step aside gracefully when they are no longer the best person to lead a project. If there are people to hand it off to, do that. If not, archive it and indicate that it is unmaintained.

[PhaseLockk]

> You could (and perhaps should) take the opinion that one should care about security, but there is no obligation (legal, financial, or moral) that requires an open source maintainer to care about anything.

I was taught that part of being an engineer taking a moral responsibility for the safety of your creations. I know that the field has changed quite a bit, and that people in open source come from many different backgrounds. But I think it's reasonable to hold as an ideal that there is a moral responsibility to at least make sure people using your stuff understand what they are getting into. And that such a moral responsibility would require more than disclaiming liability.

[walleeee]

I don't think these are contradictory positions. It's a bit like defensive programming in social space: one can take significant responsibility for one's own work while remaining aware that others with no legal/etc compulsion to likely will not.

[sigstoat]

> I was taught that part of being an engineer taking a moral responsibility for the safety of your creations.

almost certainly in the framework of being employed or contracted to do engineering work. go back and ask your teachers what they felt they owe people asking them to design things unpaid, in their free time.

[slavik81]

> go back and ask your teachers what they felt they owe people asking them to design things unpaid, in their free time

As an engineer, your first duty is to protect the public, then your client, then your employer. You have that duty to the public regardless of whether you're being paid by a client or not, because it comes from practicing engineering, not from remuneration.

[zymhan]

If I build something in real life, like a playground, and ask people to come use it, but then through my own negligence it falls apart and becomes a hazard, it is my fault for having created this situation in the first place.

Idk why this keeps getting tied back to paid/unpaid. I can think of many a situation where someone gets paid, and also doesn't care at all to help.

[sigstoat]

> Idk why this keeps getting tied back to paid/unpaid

i was responding to a comment about engineering ethics. engineering is a profession. engineering ethics is taught to student engineers in the context of a job, where you're getting paid. taking the (literal classroom) lessons out of context distorts them.

if you go back to your engineering ethics professors and say "gee, but what if i do this work for fun and just stick it up on a web page on the internet", they're going to look at you like you're insane, and then not know what to say.

> If I build something in real life

the last thing this thread needs is more analogies.

[xscott]

> if you write one, advertise one, you need to care about security

No, you don't. The author doesn't owe you a single thing unless you have a warranty saying otherwise. Most licenses explicitly say something like:

   THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
   IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
   WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE

If you don't like the terms, don't accept the code. I don't see how that could be more clear.

[temac]

Half (more probably 99% actually) of our critical infrastructure software use that wording (or an equivalent one), regardless of it is free software or proprietary software.

Yet most are maintained responsibly, if they are used for serious stuff and/or advertise in a way that suggest that kind of usage can be considered.

[zzzcpan]

Everything you ever used in production is "production-ready". The bar is super low, there is no deception here.

The security thing is particularly interesting here. If you care about security even a little bit, you absolutely cannot rely on a random third party to provide timely updates or at all, especially for free. A lot of software doesn't even provide basic security necessities to the point, where OS packages may have to include such patches themselves, effectively always being forks, never using vanilla upstream code. But this is only if you care about security a bit. If you just install from language package managers into prod, you obviously do not care about security even a little bit.

[ambrice]

So, your advice is that if you care about security even a little bit, you should write all your software from scratch yourself?

[Ntrails]

You should accept that you are responsible for all the code you run in production, whoever happened to write it. Whether you feel you are more likely to write bug free code than anyone else is your call.

[rakoo]

I think it means you should look more closely into the contract you have with the maintainers. Either you rely on trust, like you would do if you used OpenSSL or NaCl because the creators and maintainers are known to go beyond the required minimum, or you get an official contract.

[kbenson]

This. There is no free lunch. Either you pay for quality or assurance, or you risk you might get something rotten that wasn't obvious at first glance and you can't do anything about it. That's the difference, when you pay, you might also get something rotten, but you can do something about it. Your options are of course only constrained by what you pay.

The problem, as I see it, is that a whole generation of programmers have grown oblivious to this implicit relationship, and when that relationship is actually exercised in some way, they default to what they understand, which is paid services and products, which results in both sides feeling like they got a raw deal.

[ambrice]

Again, in my experience there is very little correlation between how much you pay for something and how rotten it is. And I find the opposite, when you get open source software and it's rotten, you can do something about it. You can patch it locally, even if the maintainer won't accept your patches. If you have a proprietary product written badly, paying money for a support contract will not magically make it a more secure product or guarantee that they will be able to fix your issues.

[TuringNYC]

I think his advice is to purchase a licensed product with a paid support package if you need an SLA.

[ambrice]

In my experience licensed products with paid support packages aren't any more secure, they just let you pass the buck when things go wrong.

[TuringNYC]

To some extent, they also come with warranties and insurance policies that could potentially be collected upon if there are damages.

But yes, a lot of it is a legal CYA, which is important.

[rumanator]

> "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.".

This is a good opportunity for you to read up on the license you explicitly agreed to in order to use said software in order for you to discover that that's precisely what you agree to when you use said software.

You don't owe the maintainer anything, nor does the maintainer owe you anything at all. The project maintainers donated their work to be used freely as is, and that's the full extent of what you are entitled to.

[dodobirdlord]

That is why the Apache license has a responsibility disclaimer, that to the extent allowable under law the work is offered with no warranty and no guarantees, not even of correctness or usability for any particularly purpose. Words still mean things, even after we get so used to copying and pasting licenses that we forget that they mean something. If you expect a project maintainer to take responsibility, ask them to use a license where they take responsibility.

[kbenson]

> If I build a playground for free and it gets popular in my neighbourhood, and then collapses on some poor kid, I'm still responsible, even if I did it for free.

This is less building the playground and more providing architectural plans to build the playground with common building materials. If some part is unsound, people might also be upset, but they weren't forced to build using your plans and could have reviewed the plans themselves. Where the blame lies is much more ambiguous than how you present it, IMO.

[Turing_Machine]

Holding people legally responsible for bugs in their FOSS code would be a good way to ensure that no FOSS code got written. Ever.

[rckoepke]

Legally, absolutely agree with you. GP's playground analogy was a particularly bad choice in that context.

Socially though - I don't see an issue with holding major projects socially responsible for egregious failure to fix security flaws. Public criticism is part of the open source model, it's the "many eyes" defense in action. Social pressure would be appropriate if Ubuntu just said "ahh, so, a worm is stealing every user's keystrokes. There's a fix for it but we won't merge it because we'd rather spend our time working on PulseAudio and systemd. If users want to use a forked version that will stop the keylogger, they are free to do so, but we make no guarantees our future changes won't break those forks."

[AstralStorm]

They actually do exactly that. The only goal of Ubuntu is to provide usability. They will care about security to an extent it does not interfere with that goal.

Such as maintainers being overloaded fixing visible issues.

You want a security oriented distribution, you picked the wrong one.

[logophobia]

I didn't mean legal responsibility here (perhaps the example was somewhat poorly chosen), but surely there's some level of responsibility here? Bugs happen, security issues happen, facts of life, but actively rejecting security patches is another level of irresponsibility.

[bpt3]

> ...surely there's some level of responsibility here?

No, there isn't.

> ...actively rejecting security patches is another level of irresponsibility.

No, it's not, because the project owner has literally no responsibility to you or anyone else in the context of this project.

If you care, you need to fork and patch the project. If you're feeling generous, you can share that fork and maybe others will use it.

[rckoepke]

> it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them.

I mean, I'd say that it is a maintainer's responsibility to do some of these things. If they can't, they should allow another interested&qualified person to be the maintainer instead. I understand that it's their right to abdicate these responsibilities. It's not illegal or anything. They can choose to be irresponsible, yes. But personally, I think that maintaining the repo is the maintainer's responsibility. And I think the responsible way to do that involves "following best-practices, responding to feedback/PRs, or responding in any coherent way to anything asked of them."

I'm NOT saying a maintainer should have to add features to satiate the masses. I'm merely saying that a "maintainer" has some small duty to "maintain" a product, and also acknowledging that they have a legal right to abdicate that responsibility.

I'm not sure anyone should be immune from social criticism. They can always make someone else the maintainer and avoid any future work/limelight/criticism.

I won't touch the childish vs. adult debate as it pertains to abdicating one's responsibilities.

I am also NOT saying that people should "expect to be be served high-quality open-source software for free, and then outrage when it isn't." But it seems like it's a maintainer's responsibility to allow (and maybe even facilitate) competent, motivated individuals to contribute to their open-source project.

I also don't know exactly what the reddit brigading involved, this is the first time I've heard of this story. Harassment obviously is not okay and, not coincidentally, is illegal.

[cycloptic]

Not everyone who uploads an open source project to some random cloud hosting service (i.e. Github) is qualified or wants to be a maintainer. Remember that being a maintainer is equivalent to project management. A lot of people publishing open source code don't seem to care about this and just want to write interesting programs. And that's fine. I personally have sent patches to lots of people who just never responded and their activity trailed off. Doesn't bother me in the slightest, that's what the "fork" button is for.

You also say "legal right" but it's incredibly vague what this is supposed to mean. Nobody cares about this stuff unless the project reaches a certain level of popularity. So once you get over 1000 github stars, should github force you to sign a contract saying you'll respond to emails in a timely manner or they take away your stars? I don't think I need to explain why that doesn't make any sense.

[rckoepke]

No, no, no - none of this is about legality. Just sometimes people bring it up as a framework for determining responsibilities, so I addressed it ahead of time. I don't think (legal requirements) == (responsibilities). The sets may have some overlap but clearly they are not identical.

Instead, I am just saying that if I upload a "cool tool" to github, and I notice that it has become super popular, and I don't have time/interest/inclination to maintain it --- I would personally feel a RESPONSIBILITY, and probably social obligation (not a legal obligation) to either put a note saying "this is not actively maintained, please find an up-to-date fork. user/cooltool seems to have community support but I can't personally endorse it." or simply make some other people additional/replacement maintainers for the project which I'm not interested in maintaining anymore.

[cycloptic]

Maybe you do, I'm sure people would appreciate that, but it's not necessary. The nature of these things is that the users are already "following the herd" to a degree. So if the maintainer becomes inactive and a fork picks up the interest, they will just move to that. No ceremony required.

[stjohnswarts]

It's not their responsibility. If you want to use the software then use it, if you don't want to use their software then walk away. They don't owe you anything outside of what they are willing to pay with their personal time. No one forces you to use the software. It's open source and YOU are free to take the code and run with it if you don't like it.

[bpt3]

Notice how every single line in your comment starts with "I".

You alone decided that maintainers have all these obligations (which I would consider reasonable things to do for the record), but the maintainer of this library doesn't agree, and the license doesn't require it, so you're just setting yourself up for disappointment here.

[rckoepke]

It seems much of the disagreement may stem from lack of consensus around the semantics of:

'responsibility'

'requirement' 'obligation' 'should' 'can'

I believe responsibilities are personal/societal. They're part of a value system. However, I think I could collate a breadth of sources from landmark open source discussions which show that there are existing major themes for what a maintainer has a responsibility to do (that the open source community has a somewhat predefined value system existing wrt to topic).

I accept that it's not a consensus.

I just don't think we should conflate obligations, requirements, and responsibilities. That leads to vehement disagreements.

[bpt3]

> I believe responsibilities are personal/societal. They're part of a value system. However, I think I could collate a breadth of sources from landmark open source discussions which show that there are existing major themes for what a maintainer has a responsibility to do (that the open source community has a somewhat predefined value system existing wrt to topic).

I agree with all of this, but I also feel that you need to be mentally prepared for any maintainer to fail to meet these moral responsibilities unless you want to be disappointed and should act accordingly (not saying you don't already do this in practice).

> I accept that it's not a consensus. I just don't think we should conflate obligations, requirements, and responsibilities. That leads to vehement disagreements.

I agree 100%.

[pdimitar]

You are correct in general. I'll just add the nuance that when an open-source project gets beyond a certain popularity and usage threshold I'd expect the project's governance to take a stance that's more responsive to PRs.

That doesn't include any money incentives and that is likely the problem here.

Maybe `actix-web`'s author should apply for GitHub sponsorship. Maybe small sums of money every month will motivate him to take PRs more seriously.

[ljm]

This is quite an unusual topic but I find myself in agreement. But that's mostly because I don't agree with the general expectation that everything has to be a 'community', that the maintainer now has stewardship over. And the community is almost impossible to please as it grows larger and makes greater demands.

At one point it would have been code that anyone was free to use, before it becomes distorted as some bizarre social endeavour, and then people who've never used the software find themselves part of this 'community' and start to weigh in to add social pressure.

Use the software or don't; if the patches are rejected, fork it and go that way. If the maintainer won't merge the patches, because he has his own vision, you are perfectly welcome to branch out and follow your own. Or just use something else.

Having a maintainer adhere to a set of standards that only start to apply once 'the community' get involved and take control, is super unfair to the maintainer.

[zzzeek]

if a maintainer is a jerk to their contributors, that is of course their right, but...they are being childish.

[lanstin]

Seriously, you can just fork the source repo and do what ever you want with them, and pull from your repo.