[dbcfd]

> 1. YOU are responsible for your dependencies.

They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back.

Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code.

Sadly, that led to some comments by people frustrated with the project, since they had likely invested considerable time at least using, if not more. But this was a situation that is entirely avoidable if Nikolay would have stopped promoting Actix as for production use.

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

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

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

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

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

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

[lostmyoldone]

It's his project. If he wants to act in a way you call "childish" - not that I agree with the characterization - neither I, you, or anyone else has much of anything to complain about.

If he says it's production ready, I have to assume he thinks it is. If you don't think so, you don't use it.

Open source projects dependent on a single person goes away all the time. If you aren't prepared to maintain it yourself for your use, don't use it.

Honesty is something we should expect, as well as some amount of mutual respect.

It's abundantly clear that anyone expecting him to dance to their tune was clearly lacking in respect. If you do a patch that isn't accepted you haven't lost anything, and have no grounds to complain, unless possibly if you had a prior agreement between you about you making that particular patch.

Many maintainers are absolutely inhumanly awesome, but that doesn't give us the right to expect anything at all from those who is "only" giving us tons of more or less awesome code!

[mynegation]

You cannot change other people, you can only change how _you_ react to other people and the world around you.

If Actix is that important to so many people, eventually there will be a person and/or organization that will step up, fork the projects, apply the patches, set the principles and code of conduct (or not), keep as much "unsafe" code as they deem necessary and try to rally the community around it.

The open source creators and maintainers gave you something and asked for nothing. They are people with their weaknesses, faults, insecurities, and other passions and commitments, like we all are. Get the best of what they are willing to give, give them the best you are willing to give and they are willing to accept, and move on.

[aprdm]

Where does it say he has to accept patches ? Couldn't they simply fork it instead of acting like entitled kids ?

[NewsAware]

Well, from my perspective it seems common practice in most open source projects which are hosted on GH that maintainers at least consider PRs and typically only reject if the PR is flawed, incomplete or somehow adds feature creep.

Of course any maintainer is free to handle it differently, but if going against usual expectations, it would be benefitial for all involved to note reluctance to PRs prominently to the Readme.

[virtue3]

It takes time to validate a PR, to test it, to verify it. He is not being paid for his time, he does not owe -anyone- his time.

If you don't like the way a project is being run, fork it and own it yourself.

I know that's harsh, and not idealistic, but it's the way people should really think about this. People take FOSS for granted, CONSTANTLY. And maintainers even more so.

[mratsim]

The PR contributor was not paid either to investigate the bug, reproduce it, write a patch and test it.

However instead of raising a "don't work, please fix" bug s/he took the time to do all that.

Anyone that went to such length deserve basic courtesy, whether the code is accepted or refused.

Refusing a patch because it is "boring" is not respecting the time people dedicated to your project.

I would understand refusing because the patch makes an unwanted compromise on performance and the maintainer considers performance regressions as bug.

[cerberusss]

These are merely your expectations, and this will probably disappoint you in the future.

I have replied to logged issues with the question: "I don't work on this, unless you have set aside a budget that pays my hourly rate".

[jhall1468]

And when maintainers respond to a significant amount of work involved in a PR for a bug with a note that they aren't interested because it's "boring" then they can be critiqued for being a jerk, because they decided to be a jerk.

If the maintainer had said, "Hey, I don't have the time to review/test/verify this PR so I'm closing it for now," the backlash probably wouldn't have been quite so severe.

[iudqnolq]

I thought basic etiquette was issue to discuss before PR?

Starting with a PR seems to me like saying "you have nothing to tell me about how your code works, I know exactly how your code should be changed and if my changes conflict with what you're working on you should throw your code out because mine is better".

Is that wrong?

[jlokier]

I agree that should be the basic etiquette.

Perhaps it needs to be said more clearly on project pages and codes of conduct and participation.

(Of course, it is not reasonable to demand that an already-overworked maintainer-for-free find extra hours to have the pre-PR discussion either. It needs to be exploratory and respect the maintainers' timescales. Luckily, if you don't get the response you wanted, you can fork and hire someone else or do it yourself, and keep your fixes in the queue for others to review eventually, if they want, at whatever timescale suits them.)

Unfortunately, there seem to be quite a lot of people who would, rather than discussing ideas respectfully, instead prefer to bully and shame the maintainer.

Such as, for example, calling out perceived issues in the code publically (sometimes incorrectly), and making out how unskilled the maintainer must be, in order to put pressure on the maintainer to sacrifice their personal life and do what the bully wants.

[iudqnolq]

> Of course, it is not reasonable to demand that an already-overworked maintainer-for-free find extra hours to have the pre-PR discussion either. It needs to be exploratory and respect the maintainers' timescales

I absolutely didn't mean to imply that. I also think that a pre-PR discussion can be useful because if the maintainer doesn't have time to say they want a PR that's a decent hint they won't have time to handle the PR.

[jlokier]

Sorry if you thought I thought you were implying pressure. Not at all.

I thought your comment was helpful and supportive.

I just wanted to clarify, for readers, that expecting anything at any stage from a maintainer can be expecting too much sometimes. It is time and work for them after all, and usually it's in their limited personal time, for free.

Sometimes, they have already exhausted all the time they could put into the project; even a brief "thanks" email is too much when you have too many for whatever available time and energy you have. People don't always realise that, when they say "the maintainer should just [...]". A lot of people wanting [...] adds up.

[aprdm]

For what its worth I agree with you

[aprdm]

I worked with a person who happens to have one of the most popular OSS Packages of my industry.

He has a kid and works 8hs a day like all of us... some merge requests are two years old, he doesn't have time for all the feedback / suggestions he receives and just keeps coding in his very limited time because is what he is passionate about... people keep using it.

[aspaceman]

This isn’t true at all. Many projects even say “we won’t accept PRs” in their README.

When the code is being used internally at Microsoft, it makes even more sense they wouldn’t take PRs.

[mroche]

There's been a request going for several years now to disable Pull Requests on GitHub[0]. They allow project maintainers to disable Issues, they should also be allowed to disable PRs rather than use automation to close any opened PR. Other SCM products (e.g. GitLab) offer the ability to make PRs available only to project members, or disable them completely.

[0] https://github.com/dear-github/dear-github/issues/84

[NewsAware]

Which is exactly what I suggested - avoid strife over mismatched expectations with a one liner. I would take your first paragraph to actually strengthen my assumption that Kinder treatment of PRs is the norm and that's why the many projects you mention add that line.

[AlchemistCamp]

I'm not sure the practice is that common when the maintainer works for one of the largest 5 software companies in the world and that company is using the code.

[jakear]

Did the patches obviously maintain the exact same behavior? If so, why should the author care about them? If not, it’s not the author’s responsibility to ensure they’re correct patches, but it is the author’s responsibility to ensure their package is correct. If it was correct already (not sure about this, but it seems it was very popular and used in production, so I imagine it worked well), they have no responsibility to vet incoming patches that do nothing besides change internal workings for the sake of changing internal workings.

I don’t write Rust, I write TS. If I produced a package that was had a clean and correct TS interface, but internally was filled with dirty dirty `any`s, I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s.

[the_af]

> I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s.

Out of curiosity, isn't a focus on that kind of things precisely the goal of Rust? I understand your point, but this was software built for Rust, which has this kind of thing (safety, the right types, etc) as a primary goal.

From https://www.rust-lang.org/:

> "A language empowering everyone to build reliable and efficient software."

and

> "Why Rust? Reliability: Rust’s rich type system and ownership model guarantee memory-safety and thread-safety — and enable you to eliminate many classes of bugs at compile-time."

So I can understand why someone bypassing this kind of things and then (for whatever, possibly understandable reasons) rejecting PRs to patch them because they are "boring" can be perceived as seriously mismatched with Rust's community. If someone finds this kind of thing "boring", is Rust really for them?

Note: I'm not saying he has any obligation to do anything. I'm just saying his attitude may seem mismatched with the community and goals of his chosen language, which is no small problem.

[solidasparagus]

> If someone finds this kind of thing "boring", is Rust really for them?

Are you kidding? Rust is a tool, not an ideology. You don't have to share in the beliefs of the tools designers to use a tool...

[the_af]

Agreed on all counts: Rust is a tool and you don't have to agree with the tool designers. It's just bizarre to ignore precisely the aspect of the tool that singles it out, the reason it was created to begin with, the one thing this tool is very opinionated about.

You can also write all your Haskell programs with all functions with type IO. You can use a hammer to paint portraits.

Just expect eyebrows to be raised.

[cosarara]

> is Rust really for them?

Maybe he likes rust because of other things. He had a very successful project with rust, it seems weird to think that rust was not the tool for him.

[the_af]

I don't disagree. But a tool can be successful in adoption and still not be correct from a technical point of view.

"Who cares about correctness or safety?" one could ask. Well, Rust's designers for one. It's why they created the language.

[Sharlin]

> If it was correct already (not sure about this, but it seems it was very popular and used in production, so I imagine it worked well)

Oh my. This was not about code aesthetics or some purely philosophical problem. It was about experimentally found undefined behavior that opened potential security vulnerabilities in the wild. The ”well it works fine so it must be correct” mentality is exactly what led us to this situation where the vast majority of critical net infrastructure code is full of vulnerabilities, the very problem that Rust attempts to alleviate in the first place. The problem with the existence of malevolent actors is that it matters little if your program works correctly in all common cases. Someone out there is going to be actively looking for the uncommon case and their goals may not align with yours.

[eropple]

> I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s.

Why would you possibly not? Increased correctness, no change in runtime behavior, and a resistance to code rot and mistakes on your next concrete change.

Passing up on such a PR would almost immediately disqualify a library from further use unless I could manage a fork.

[flatline]

> no change in runtime behavior

That's the problem: how does the maintainer guarantee this? And when flooded with multiple such PRs, the task rapidly becomes overwhelming. If you have a robust suite of unit tests and a CI system you have better guarantees but still about as much work to ensure the new functionality is properly tested. That's not to say the maintainer's attitude in this case was excusable, but it's his project and this style of maintenance is definitely not for the feint of heart.

[eropple]

In many cases, you're right. But here, specifically? If somebody goes through your code and annotates it with types, TypeScript is gonna scream if it doesn't build clean and is going to emit the same code it did in the first place. This is literally complaining that somebody might write helpful documentation for your system and that you'd refuse to merge it. It's a pathologically bad statement.

[virtue3]

> Passing up on such a PR would almost immediately disqualify a library from further use unless I could manage a fork.

It's a bit disingenuous that you can accuse someone of being absurd for not doing something, and then mentioning in the same breath that you "might not want to" as well.

I'm merely saying that for the sake of pointing out that maintaining a project is a PITA and we should all really accept that.

[eropple]

It's not disingenuous; I have a number of open source projects on my plate already. I probably can't take on more. But if somebody hands me, for one of my projects, a set of typings that compiles clean in TypeScript (and, seeing as how it's a compiler, that's a really trivial thing)? I'd be literally-not-figuratively out of my mind to not say "thank you" and take them. Failure for another maintainer to do so means that they are a business risk for me that I should not entertain.

[munificent]

> they had likely invested considerable time at least using, if not more.

I think your choice of the verb "invest" implies a highly flawed mindset about the incentive structure of open source.

A lot of open source consumers have a mindset that by using someone's open source project you're giving them something or doing them some kind of favor. "Hey, I'm investing in your project!" You aren't.

From a maintainer's perspective, simply using a project is likely either a zero or net negative. You are not investing your time, you are using their code. You may be asking questions which consume their time. You may be filing bugs which are on code paths they personally don't hit and fixing those uses up their time. For open source projects that pay for hosting things like their repo and issue tracker, you're consuming network resources.

We have a finite time on Earth, and supporting users is time the maintainer cannot spend with their friends and family, relaxing on a beach, taking a stroll, etc.

A consumer of an open source project may cancel out that drain by offering other things in return: popularity, kind words, the feeling that the maintainer has created something that benefits other humans. Filing issues can help a maintainer fix bugs and feel good about the improved quality of their code. Pull requests can add functionality they want.

But none of that is a given and often does not happen.

In my open source projects, I have certainly receive kind words, but also many angry words in bug reports. I've had demands to spend huge amounts of time making sweeping changes, pull requests that needed be basically be rewritten, the feeling that I'm letting people down by not replying to issues quickly enough, etc.

I believe the right mental model is that if you use someone's open source project, you are in their debt by default. They have used their labor to create an artifact that provides clear material value to you. They did work. You got personal value. They clearly owe you absolutely nothing and you reasonably owe them something approaching the material value you get from their code.

This doesn't mean you need to pay them, but it should inform how you interact with them. Filing issues and sending pull requests may pay off that debt, but even then it is not a given that every issue and PR is a net help to them. Maintaining an open source project can be gratifying, but it can also be hugely draining. It would be less so if consumers were more sensitive to that fact.

[biesnecker]

> 2. Open source participants are volunteers and owe you nothing.

The two rules work in concert.