Thank you. Online discussion would be much more productive if everyone clearly laid out the principles on which their viewpoint was based.

Fundamentally, there are only a few ways honest people can disagree: Different principles, different information, different interpretation, or just plain misunderstanding. (Meta-meta: This is the principle that I believe and based this comment on.)

Much of what makes online (and offline) arguments so unproductive is confusion over where exactly people are disagreeing in the first place. There's no point in discussing whether someone did the right or wrong thing if you don't even agree on the principles by which that rightness or wrongness will be judged.

If I disagree with one of your principles, we need the discussion to be at that level, or more likely, we simply must agree to disagree. If I think there's another principle you aren't considering, we can debate its relevance. If you're missing key information, I can provide it. If you're misinterpreting something, I can offer my alternate interpretation and justification for why I think it's better. In any case, if I disagree, it's clear how to proceed because your line of reasoning is clear. We can engage in a productive discussion without talking past each other.

As it stands, I agree with you 100%, but more importantly, you have raised the bar for discussion on this contentious issue. Thank you again.

However, I was trying to process whether incentives are essentially part of your principles? i.e. if an incentive to do something against your principles is so strong that it wins out, doesn't that mean you've effectively abandoned (or changed) your principles along the way?

Not to say we shouldn't try to live up to the ideal you set forth. We should do our best. But there's not some category of honest people among whom you can avoid human nature.

If we agree on the facts and we agree on their implications, but we still disagree, it's likely because we weight things differently. Emotions are simply a large component for how we weight things.

This has significance, it's not just a restatement of "the problem" using different terminology. It's significant because the brain, like every other part of the body, evolved parsimoniously, and it does not have spare capacity lying around, so anything that "distracts" the emotional parts of the brain will diminish rational capacity. "Hangry" is not just a pun/quip about being hungry, it's empirically measurable, it affects outcomes.

Debating rational topics with your rational friends, whether at work, at school, or after hours over a beer, it's fun (emotion), can be frustrating (emotion) but does it ever not get heated (more emotion)?

The brain is an emotional organ. All the other organs are rational, they do what they do in entirely predictable and logical ways.

think of rationality of the brain like a signed vs unsigned char in most implementations of C, basically a byte: you could think of a byte as 0-255 or as -127 to +126. The brain is an emotional organ. Rationality is the best possible outcome, but it's not the default state; the brain doesn't function from 0 to 255 rationality, it functions from -127 to +128.

I say it this way because you talk about rationality "breaking down" as if it's some sort of default. I don't think of it that way. Rationality is something we hope to build up to and are lucky to achieve, but our default state is animal passion.

I'm not trying to convince you to change what you think, just using some restatements to open your thinking to the way psychiatry views the brain.

I'm sorry, can you please explain how you come to this conclusion based on what I wrote:

"however the part of it that has "rational debates" is not an intrinsic behavior. that part is based on cognitive skill which will perform to a greater or lesser extent based on current brain state."

I'm not really arguing with you, as your first point seemed to be some kind of "but what about...!" that didn't really negate what I was trying to say. However if you think I was saying something completely different, that would make more sense for whatever it is you're attempting to "argue".

I don't think that's a problem with the emotion itself, so much as which specific events trigger that emotion and how you chose to process them and react.

Having fear does not make you lash out at users. We all have fear, often about similar things. It's having fear associating with a person calling you out, and then failing to process that fear in a healthy way that caused you problems.

Very rational people still have lots and lots of emotions. They are not robots. They can just handle their emotions in a mature, mindful way.

In those times that I have not been able to respond politely or rationally, my lack of mindfulness as well as my own emotional reactiveness to certain stimuli (e.g. triggers) was at the core of it.

that is, if a request is not triggering strong emotion in me, I don't need to employ patience and mindfulness in order to have a reasonable and rational response. If a lot of requests are in fact triggering, this is what I would term "emotionalism", and I have to work much harder to have rational responses. Hence emotionalism is linked to irrationality especially for someone with fewer emotional maintenance skills.

emotion is not a "problem" any more than the urge to go to the bathroom is, however, both require proper training to be dealt with.

Even mature people often can't reason their way out of a conflict on their own. When people feel personally threatened, sometimes no amount of simple reasoning will bring them back to rational thinking. Most of the time, the solution is to be a genuine friend--for the long haul.

But as I understood you, point taken. The distillation of principles, information, and interpretation into an opinion does not actually occur as idealized in my breakdown. I wouldn't disagree with that.

Perhaps logic is just our way of explaining our otherwise unexplainable decision making systems.

Put in the time and focus, and one day it will just click.

models which humans will not actually be capable of understanding.

https://www.pnas.org/content/108/17/6889

;-)

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.

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.

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.

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?

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.

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.

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.

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.

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?

However, I read your earlier comment as meaning roughly "anyone who releases any software under an MIT/X11 license has zero obligations to anything regarding that software period" which is something I do disagree with.

If the creator does act as a "good steward", that's great, but you shouldn't plan on that being the case or be surprised when it isn't.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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

Such as maintainers being overloaded fixing visible issues.

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

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.

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.

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.

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.

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.

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

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

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.

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.

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!

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.

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.

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.

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.

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

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.

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?

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.

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.

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.

No problem at all.

> I thought your comment was helpful and supportive.

Thank you. I'm glad you saw it that way.

> A lot of people wanting [...] adds up.

It sounds as though you've had some tough experiences with this. I'm sorry to hear that.

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.

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

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

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

The two rules work in concert.

I don't think the anger is directed at there being security issues, the anger is directed at the fact that even when security vulnerabilities where found and patched, there was major pushback even getting those patches merged into the library. And regardless of how strongly you feel about 2), the community is extremely validated in saying "Hey this library in a language that professes security isn't secure and the maintainer doesn't seem to care". These statements aren't mutually exclusive

Yes, but that's not what they said. They were hateful and virtrolous, which is never appropriate. Fork it and fix the problems, create a new library which has the same API but is more sound, promote an alternative library in its place, offer to lend a hand in maintenance - these are the correct solutions.

Who's they? Most of PR commenters were courteous. The last few were rude, but so was the fafhrd91. https://gist.github.com/mafrasi2/debed733781db4aba2a52620b67...

> The last few were rude, but so was the fafhrd91

https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f...

I was there (as a user who closely followed development) during the nodejs > io.js split. While it worked out in the end, it felt like a bitter battle at first. Node survived by chance perhaps.

We have our async-std vs Tokio right now, I'd imagine having another split (at least in opinions and preference) on actix would still keep tension high.

It allowed for the chaffs to fall through making node a stronger project because it was clear that neither of the sides was going to "win" outright.

If the argument is that "maintainer is not doing his/her job of being a maintainer" and this argument is accepted by the users, then should the project be forked by someone who will do his or her job of being a maintainer, the users will flip their source repo pointer and move onto the fork effectively killing the original.

Does the fork care as much about TechEmpkwer benchmarks? What happens if it is slower because it forbids unsafe even where it makes sense?

There was a looming cliff in Async/await, which caused a split to some extent (some old libraries that no longer have maintainers, changes that make updates difficult). A fork with those changes looming would mean divergence when rewriting to support Async/await.

Maybe I'm being too cautious, but I doubt we'd have had a successful fork earlier. Let's see if it happens now ...

Those "bad apples" are part of the Rust community, and the Rust community needs to take responsibility for them the same way any community needs to take responsibility for their bad apples even if it's just to denounce their behaviour.

Good thing that those who submitted the patches and PRs were polite; they're not the ones who caused this maintainer to quit though I'd wager...

There is a prominent "Fork" and "Clone" button in every GitHub repo. If you're so fucking sick of the lack of support from the maintainer, fork it, fix the flaws that you've found, and assume some of the responsibility for the project.

This whole situation is a bunch of people getting angry because of what they view as a lack of accountability. That's preposterous - the nature of GitHub and open source makes it super easy for you to assume some of that accountability yourself. The fact that so many people chose to get upset rather than assuming accountability speaks volumes to me.

Pull requests welcome, jerks. </s>

Sure, but that DOES NOT mean you're immune to criticism, especially when it comes to security.

Your type of argument could otherwise be used for pretty much everything - even large corporations. It's not useful.

The problem wasn't the criticism, but the expectation that said criticism invokes a certain behavior of the maintainer.

You can criticize open source maintenance by creating a fork in which you outline your vision (e.g. "much less use of 'unsafe' in the web package") - and deal with the burden of being a maintainer.

Everything else is just trying to force people to do stuff for you, and that's rude.

> The problem wasn't the criticism, but the expectation that said criticism invokes a certain behavior of the maintainer.

Of course it implies that the maintainer should change. All criticism implies an expectation of change, at least when the opportunity to change is still available.

> Everything else is just trying to force people to do stuff for you, and that's rude.

Criticism isn't "force" or "attempted force". This is just criticism. If you think criticism is rude, that's fine. Hypocritical, but fine.

You can't rationally say the maintainer is within his rights for rejecting security patches and then argue that critics are wrong for criticizing these practices.

No, the attempt to make somebody do what you want by brigading is what's attempting to exert force and what's rude.

Hiding that behind "I'm just criticizing" (you didn't, but it's a popular refrain in such "debates") is more than only rude, it's also cowardice.

> You can't rationally say the maintainer is within his rights for rejecting security patches and then argue that critics are wrong for criticizing these practices.

The author of the package didn't force their code onto the users.

The authors of the criticism forced their criticism on him by throwing it his way in the form of bug reports etc. even when it was clear that there's no interest in it.

Unless the critics are engaging in threats, intimidation, and/or violence, we're talking about criticism and not force.

> Criticism isn't "force" or "attempted force". If you think criticism is rude, that's fine. Hypocritical, but fine.

No, the attempt to make somebody do what you want by brigading is what's attempting to exert force and what's rude.

> The author of the package didn't force their code onto the users.

No one is arguing this. Weird straw man.

> The authors of the criticism forced their criticism on him by throwing it his way in the form of bug reports etc. even when it was clear that there's no interest in it.

Wow. I really didn't anticipate the "bug reports == force" equivalence.

Re. "The author of the package didn't force their code onto the users," it's not really a straw man. People are arguing that the author has moral responsibility for their use of his code. That ignores the fact that they actively chose to use his code. The only way the author would be morally responsible for their use of his code is if he had forced them to use it somehow. So yes, people are basically arguing this.

No, if you pay for things, you have a contract and things are immediately different.

Even if I'm not paying them anything.

Find vulnerability. Already, awesome of you to have done. Issue patch request. That's 10x even better, you're a boon to the community. You submit it, it gets rejected, you find out why and it's the maintainer is just not feeling it or some other irrational reason. Fork, put in the readme why you forked, write a blog post without being a dick about it, done.

The article we're talking about is referring to the bloodbath of a Reddit pile-on. That's totally unacceptable behavior from an adult.

You should be able.to fix them yourself

That's the premise of OSS

if you don't want to pay for a cab or a driver, you should be able to drive

- full access to the source code

- full rights to modify it and use it as it was your own

There's no other guarantee.

So if someone writes some code that becomes highly popular, they have no obligation whatsoever to maintain it the way people want.

They don't even have to maintain it at all, if they don't want to!

It's out in the public, it's free, that's the end of the agreement on the creato's side.

If a writer gave away their writings for free, could people pretend that they write what people want them to write, the way they want?

Is it fair to judge the writer because the answer was "WONTFIX"?

But the reality is worse than that.

A lot of companies are literally making billions using OSS, but they are not paying for it, a lot of programmers are making a lot of money by assembling OSS for their clients, but they are not paying for it, hell most of them are not even contributing in _any_ way, what does entitle them to pretend the attention of the OSS maintainer or that the maintainer should act in a way or another, according to the "community" desires?

But our society does not just openly accept giving criticism. There are rules. Unwritten and extremely vague ones, no doubt, but still social rules. This is especially so when criticizing something a person is providing for free. In this incident, did the criticism cross the boundary and violate those rules? It seems so. Many people likely gave respectful criticism that followed the rules but they appear to have been drowned out by those who did not.

But software done for free by volunteers carries no obligation of a legal or even a moral kind, whatsoever. This is completely different from selling software or doing work for hire or donations. There a moral and often even legal obligation exists.

And you know what's a good form of criticism? An issue with an attached PR

if you accept that the open source projects are voluntary as an axiom then you in fact cannot criticize choices made by the volunteer.

here's an analogy: a homeless person asks for money. you don't give him money but buy him food. can the homeless person rightfully criticize you?

A homeless person asks for money. You don't give him money but give him some advice. Can the homeless person rightfully criticize you?

You can absolutely criticize choices made by volunteers. I don't think you need to think too deeply about this to imagine situations where few would object to criticizing a volunteer's behavior. An obvious one would be if an open source maintainer willfully included malware/etc. into their project - which, to many people, ignoring glaring security issues is vaguely equivalent.

I obviously don't think vitriol is warranted ever, but criticism obviously is from time-to-time.

you can criticize all you want as an exercise of your critical thinking faculties but the volunteer is not in anyway obligated to heed the criticism.

"it's my money/time and I'll spend it how I want, which includes burning it"

is the fundamental axiom. Given that that is the foundation what sense would it make to criticize that person for burning the money - it's right there in the premise that they're allowed to!

It's your analogy, you tell me.

> you can criticize all you want as an exercise of your critical thinking faculties but the volunteer is not in anyway obligated to heed the criticism.

Nobody said they were. Nobody's trying to punish the maintainer legally. That doesn't mean criticism won't be offered or warranted.

Here's another analogy: You have a right to be a jerk in real life. Nobody's going to physically or legally stop you, barring extreme circumstances. People will still criticize you for being a jerk, as is THEIR right.

>People will still criticize you for being a jerk, as is THEIR right.

completely specious. code in a github repo is not active participation in society. the fact that it's public does not mean it's been submitted for evaluation in any way. criticizing a thing that wasn't critically submitted is meaningless. it's like calling my practice sketches inferior to commissioned pieces - no shit that's the point!

the maintainer?

> completely specious. code in a github repo is not active participation in society. the fact that it's public does not mean it's been submitted for evaluation in any way. criticizing a think that wasn't critically submitted is meaningless. it's like calling my practice sketches inferior to commissioned pieces - no shit that's the point!

Uh, what? By packaging something as a crate, by listing it on crates.io, you're submitting it to be used. If you don't want it to be used or evaluated, at all, why in the world would you publish something as a crate on a public registry?

This is more like submitting your sketches to a public art gallery and then being upset when the public criticizes it.

that's not what happened. there weren't simply discussions of the viability or soundness or the crate. there were implicit/explicit demands for changes. so your analogy is wrong again - it would be like submitting public sketches and then facing demands that the sketches be improved. does that sound like something that i as the artist should be comfortable with? more importantly does that sound like something a reasonable person would do (make demands for alterations to sketches submitted to a public art gallery)?

Are you sure you have a firm grasp on what actually transpired here?

https://news.ycombinator.com/newsguidelines.html

By publishing something to be used by others in a public registry, you are opting in to receive criticism from the public.

Criticism is not the same thing as vitriol and I’m not endorsing the latter even one iota.

Is that not crystal clear to you?

Please review https://news.ycombinator.com/newsguidelines.html though, and stick to the rules from now on.

https://news.ycombinator.com/newsguidelines.html

there's something so aggravating about how you preside (note i didn't call it moderation) over these forums. what is the point of a voting system if you can unilaterally censor and censure? you know what the pretense to "objective" and "rational" discourse of this forum does? it inspires the kind of arrogance you see here on so many posts - absolutist positions on everything from tech to healthcare to history. the brand of yc and you and the rhetoric of the guidelines and you all function as an aegis.

> what is the point of a voting system if you can unilaterally censor and censure?

HN is a constitutional democracy. I can see why you'd find it annoying if you're assuming otherwise. We can't go by upvotes alone—if comments break the site guidelines, it doesn't matter how upvoted they are.

The voting system alone doesn't regulate itself—it leads to flamewars because indignant and unsubstantive comments frequently get upvoted. That's why there need to be countervailing mechanisms like flagging and moderation.

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

>man i'm glad there are identifying details about you in your profile so i can avoid working with you

is an attack. it's an expression of my personal exasperation. there's literally not a single ascription of any qualities to the other person. you can ctrl+f "you" or "your" in this subtree

https://news.ycombinator.com/item?id=22075698

and i in no place ascribe any qualities to anyone. my only other remark was pointing out the other person's belligerence which i still didn't make personal.

so either you can claim that there's something like a "zero tolerance" policy for antagonism or you can retract what you've accused me of.

this is my overarching point and has been for years on hn: it's evil to paint with a broad brush people that are actually antagonistic and those that don't feel they should toe the line in response to those people. your constitutional moderation is this brush.

It's basically the same as saying "I hate you". You hate them so much that you will go to great lengths to never work with them.

Maybe it's true—maybe you really do hate them—but stating as much is absolutely a personal attack IMO.

> it's an expression of my personal exasperation.

"Comments should get more thoughtful and substantive, not less, as a topic gets more divisive."

maybe a better analogy is if i play a pickup game of basketball and i get labeled a bad player for not trying my hardest. it's not that the criticism is misplaced it's that it doesn't make sense at all - i wasn't trying to be a good player! i was trying to have fun.

I don’t understand the desire to make this out to be a sort of dichotomy—both groups have the right to do what they did (the maintainer to reject patches and even allegedly lie about the security properties of his project and the critics to criticize even in bad taste) and both parties could have handled it better. TFA did a fine job for implicitly acknowledging this by simply referring to the situation as sad all around.

this is so weird to me. i have a really difficult time on hn often because i don't understand why people that claim to be intelligent can't distill out the fundamental/primary issues.

it's a free/proffered/donation/voluntary/no strings attached piece of code. that is the first thing that defines its use/understanding/existence/ontology whatever other words. everything else is contingent upon that. you can debate this point - you can say something about the social contract of open source software and your responsibility to the community if you yourself have benefited from other open source projects and etc but no one is debating this. everyone is debating aposteriori things.

if i put a mattress out on the street with a sign "no bed bugs" and you pick it up and it has bed bugs in can you be mad at me? can you take action against me?

i don't know what kind of framework i need to appeal to in order to underscore this issue so that people address it directly instead of things further down the line. i would really appreciate someone showing me how to either do this (put the focus on the thing i'm engaging with) or tell me why i'm wrong for focusing on that.

I feel the same way, but not about /u/weberc2's post.

> it's a free/proffered/donation/voluntary/no strings attached piece of code. that is the first thing that defines its use/understanding/existence/ontology whatever other words. everything else is contingent upon that.

This is another of your own axioms. These aren't universal. In particular, if a maintainer states or otherwise implies that his project is secure and suitable for production and then behaves otherwise, criticism is warranted. Even if he doesn't, criticism is still permissible.

> you can debate this point - you can say something about the social contract of open source software and your responsibility to the community if you yourself have benefited from other open source projects and etc but no one is debating this. everyone is debating aposteriori things.

No one is debating this because it's not necessary. The maintainer's explicit assertions about his project (its security, etc) override implicit "social contract" responsibilities.

> if i put a mattress out on the street with a sign "no bed bugs" and you pick it up and it has bed bugs in can you be mad at me? can you take action against me?

Not sure, but I can certainly criticize you.

> i don't know what kind of framework i need to appeal to in order to underscore this issue so that people address it directly instead of things further down the line. i would really appreciate someone showing me how to either do this (put the focus on the thing i'm engaging with) or tell me why i'm wrong for focusing on that.

In general your arguments are based on your own axioms. If your axioms aren't widely-shared, then you will run into these sorts of disagreements.

how is this my axiom? it's on github. no one has paid for a license (the license is completely permissive).

>In particular, if a maintainer states or otherwise implies that his project is secure and suitable for production and then behaves otherwise, criticism is warranted.

is that part of the TOS of github? is that part of the bylaws of the guild of software engineers? is that in the bible? where is this codified except in this thread around this issue where everyone is mad?

>Not sure, but I can certainly criticize you.

you can do whatever you want. you can stand on your head and recite the star spangled banner. i'm posing the question whether it's reasonable. is it reasonable to criticize me for putting that mattress there in that state?

>In general your arguments are based on your own axioms

again they're not mine in the least - i did not coin the phrase "don't look a gift horse in the mouth". that is much older than me and fairly universally understood/accepted.

The trouble is distinguishing the cases.

What actix developer did was, to pardon my French, inexcusable. Deeming security patch boring? Making your own `Cell`, implementing it badly and misusing it, because it's faster on some stupid benchmark site?

If we designed cars like that, they would have no breaks, no gears and no cabin.

Honestly, I think it's better Rust abandons `actix` asap. Before it gets any real traction.

I do not know how the Rust community manages performance comparison, but the .NET bubble was broken by that page and resulted in awesome results for the platform.

PS: just pointing out what the page achieved somewhere else. The discussion about the maintainer and what happened there is a different topic.

But from what I heard, to get where it is, actix developer took some really bizzare shortcuts. E.g. hardcoding parts of response. On top of general unsafe usage.

I think the benchmarks are flawed, since they don't account for such "optimizations".

In .NET case they changed the language in response to the needs of the Techempower benchmark (and the Unity3d engine) to allow safe and performing ops. .NET also has the unsafe keyword for low level ops and is surely also used. The advantage of .NET is that it was a team with a central manager who pushed all areas, http framework, base class library and language into the same direction. A community like Rust does not have that privilege.

The patch was "boring", not substantial to claim copyright.

https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f...

Adding to this, you might still transitively depend on the upstream through your other deps in ways you can’t change without either forking all your deps... or getting them to switch.

And what does “getting the ecosystem to switch” look like? It looks a lot like complaining about the upstream, such that others in the community understand what the problem is that your fork is solving.

If the community cares about security then should this happen:

> Sure, but once you’ve forked, now you have a fork only you use, but which you know is more secure than its upstream for reason X. That’s an unstable equilibrium—you want others to know of your fork, and to switch to it, so that other downstream projects can also be more secure.

The community would move onto your secure fork and the author of said fork would become a maintainer. As Dave Rand, the CTO of AboveNet used to say to newcomers who used to say 'X should be done!' -- "Thank you for volunteering - you are now in charge of X."

"Atrix-web should not use unsafe"

"Thank you for volunteering - you are now in charge of making atrix-web not using unsafe"

"Thank you for delegating responsibility of making atrix-web not use unsafe, to me. I accept responsibility for this piece, but you are still the leader of $PROJECT." <workworkwork> "Here is a PR that makes atrix-web less unsafe."

"I don't accept your PR."

Dave Rand's advice doesn't apply here, as several people picked up responsibility for making atrix-web less unsafe, put forth the work to do so, but were rejected. It's one thing for me as a user to feel entitled to everyone else doing what I think they should, while not putting in any effort, but IMO it's less clear cut when I'm putting my money when my mouth is, and submitting PRs.

Fork it, make it "atrix-web-safe", post about it on whatever rust announcement list/forum/group is and have people move to the "atrix-web-safe". That's leadership. The rest is moan-fest.

If you fork on GitHub, they take care of letting people know.

I've forked a few abandondedish projects, and other people seem to find the patches. The best example I can think of is stud, which the people behind Varnish adopted and renamed to hitch; they surveyed the landscape and took good patches from most of the forks.

I might not look for forks from a more active project, but it's definitely something I look for when I run into problems with software without a lot of recent updates.

Or you can pay the cost of bringing in changes from the upstream project. This happens a lot for commercial software. I remember having to maintain a “fork” of BEA’s WebLogic server for a year or two until they incorporated changes my employer needs.

It’s not so bad.

If you depend so much on that code, if the security of your software depends on someone else's free work, why don't you hire that person to fix the bugs?

Those are demands. The toy project one is relatively low cost, but "he should have given reasons" brings with its lots of effort to do right - and then you get to do it over and over again, because the masses can fling shit at you faster than you can reason about it.

critcism: the expression of disapproval of someone or something based on perceived faults or mistakes.

"he should have ..." is clearly an expression of disapproval.

Of course he didn't, in the legal sense of the term. And then people didn't have to stop criticizing him, in the legal sense of the term.

And obviously for the ethical / moral point of view, people have vastly different opinions, otherwise there would not be this debate.

You publish your code to Github, you're part of a community. You make it open and allow for contributions and see people are using it, you should be clear about your level of give-a-shit.

Hell no. It that were the case, I'd never publish anything.

> You make it open and allow for contributions and see people are using it, you should be clear about your level of give-a-shit.

It is YOUR responsibility to see that for yourself by watching how the project is actually maintained.

Why do so many people insist on being aloof and unhelpful in communicating to users of their software? What is so hard about offering a modicum of context for what people can expect of you as a maintainer? It's so ideologically rigid and unreasonable.

Maybe. The main issue I see with github is that it's impossible to disable pull requests there. We have that issue in the coreboot project, which uses github as a read-only mirror.

Maybe we should just shut that down to make clear that coreboot is not part of the "GitHub community".

"It’s extra nasty this time. Some people go far, far, far over the line."

When someone polite says this, I picture some of the nastier attacks on the internet - doxxing, death threats, and swatting.

The correct response would be to organize the community to create a fork that is more focused on correctness and security than on performance.

Whether it would be appropriate in this I case I don't know but I disagree that it is never the correct response.

I highly doubt that it would do anything to prevent that continued behavior. I cannot imagine a situation in which there is not a better and more appropriate solution to mitigating poor behavior that telling people "don't participate in this field". At best you will alienate them in such a manner that alternative approaches are less feasible and at worst you convert bad behavior from being passively to actively malicious. I'd be curious if you have a concrete example for when you think this approach has been beneficial in any context.

Note, I consider revoking credentials (e.g. disbarring an attorney or revoking a medical/engineering license) to be something entirely different as there is an active endorsement that needs to be terminated. Relevancy in this case would be to removing a package from a package/dependency listing service/manager.

Can I express that to people who think a volunteer project owes them anything & couldn't be arsed to implement the project's functionality themselves in the first place? Somehow I don't think that would be a constructive use f time.

I don’t want to come as negative toward Rust or developers using it, but there is a whole lot of using Rust’s ‘security’ focus/features to say the Actix developer needed to do things a certain way. He wrote he, he could do whatever the hell he wanted.

I can't agree. Not for all participants.

Let's take Linus. He's in charge of the Linux project, which thousands (millions?) of people contribute to every day. If Linus suddenly stopped merging any and all patches—but refused to officially step down—what do you think would happen? Oh, the project would more than survive—someone would fork it and that would become the de-facto new mainline kernel—but there'd probably be a couple weeks of chaos. Does Linus bear zero responsibility because he's a volunteer?

---

Every Saturday, I volunteer as an assistant teacher (they call us "facilitators") at a Girls Who Code club, a free weekly class to teach computer science to young girls. I don't get paid for it, but that's okay—the kids are adorable and teaching them is fun. The primary teacher is also a volunteer.

If we both decided to just not show up one week, and parents brought their children to the library and found an empty room, would that be okay?

Personally, I do think I owe something to those students, and to the primary teacher. I've made a commitment to show up every week and do what I can to help a group of children. My commitment is what matters, not whether it generates income.

Now, there's actually second GWC class for slightly older students which starts right after the first one. Sometimes I help teach that one, and sometimes I go home. I told the primary teacher I'll stay "when I can", which actually means "when I feel like it".

There's certainly a place for doing work without a commitment to continue, but your intentions need to be clear. Most large projects are not going to function without a commitment from someone somewhere in the chain.

One weekend in October, the primary teacher had plans to go traveling in Europe. She asked if I could cover both classes that week. I said I would, and I did.

I think what we are running into here is a matter where different groups have different expectations of what is owed and why it is owed, but due to the difficulty of talking about what is owed to others makes it hard for us to verbalize or sometimes even concretely conceptualize what we are talking about. There are also different extents one can owe something (legal being the most extreme, as you will be forced to by the courts with possible violence if you don't).

If a one of the parents tried to get a court to order you to teach the class on penalty of contempt of course, would you find that reasonable? This sounds quite extreme, but there are plenty of cases of owing someone something that the court does enforce in a similar manner. My guess is that you would find such an reaction unreasonable to an outrageous degree, but would find far less extreme enforcement measures (such as being disappointed) as being reasonable. I would even go a bit off topic and say that this level of being owed is proportional to the payment you receive. As a volunteer you likely get no money, but are still 'paid' in social recognition.

So you can owe something on the level of being disappointed, but not on the level of court order. So what level does a project maintainer owe others and why. And what do those others owe them in return?

Linux Foundation would appoint somebody else on his place and have him sign similar contract. It would be likely a person that is already employed in similar capacity - one of current paid maintainers. No fork would be needed. Linus Torwalds is not a volunteer at this point.

Linus Torwalds will leave linux one day. He wont stay there forever - most likely to retire, but possibly to do something else.

Also, Linux is particularly bad example, because most contributors are paid for their effort by someone.

Any big enough project will formalize relationships at one point or another - latest when they need to raise money or organize conference. These projects are too big to be run over the weekend, they do have to pay regular staff.

If Linus is truly a volunteer, then he owes me and the rest of us nothing beyond what he's done already. I haven't sent him any money and have no relationship or agreement with him; he owes me nothing. The chaos will resolve itself and the world will go on.

In this case there's nothing to prevent someone else from forming the code and moving forward with it, until they also tire of the abuse this poor fellow experienced.

I think that we could use some norms around this. Perhaps there could be an EXPECTATIONS.md in each project where we lay out exactly what to expect from the author, if anything. Maybe even specify a monetary incentive to take things further. And then the rest of us know exactly what to ask for if things aren't up to expectations. But no matter what, make sure to show appreciation to everybody who does what they do as a volunteer.

For Rust, my personal mantra was always that _usage is contribution_. Why? Because we have a high interest in adoption. It's literally one of our top-priority goals.

But not everyone taking part in these discussions is a user or someone I have some kind of relationship with. And a relationship goes both ways.

To take your example: if a kid showed up and was _constantly_ loud, didn't respect you or showed no interest in learning? What if _most_ of the kids were like this?

Would you still like to go every Saturday?

I do teach in similar settings (RailsGirls, RustBrige) and a crucial part of the experience for me is that many attendees have a progress that they are thankful for. The deal and the relationship works, even if it is just short.

My big frustration is that the debate is often "Maintainer vs. Users", but I don't believe that boundary is as hard as people make it to be. Still, user entitlement exists and is _very_ rampant and this is what people are up against, even if they put it less nuanced. (maintainer entitlement also exists, but that's a story for another day)

And to focus on a different part of the analogy for a moment—if somebody looks more closely at what I'm teaching students, and sees that I'm actually showing them how to use flamethrowers, yeah, they have a right to be upset. Again, it doesn't matter that I'm a volunteer, they've placed a significant degree of trust in me.

People should still audit their dependencies, just like people should observe my teaching. But it's also fair for them to have expectations.

It’s just “npm install” and YOLO for a lot of developers!

This is an understatement.

I work in regulated environments where a software error has consequences. Dependencies must be vetted. If we end up relying on a dependency with known vulnerabilities the auditors are going to want to know what we did to mitigate the risk of this out-come. You need to have an answer for that question.

I recommend packaging your upstream dependencies. That way you can patch vulnerabilities you find and ship those fixes today before those patches make it up stream. That's a risk mitigation strategy and often good enough to fend off auditors.

Many (all?) open source licenses provide the software without any warranty or guarantee of merchantability or fitness for use. None. At all.

1. Just because a thing exists, does not give you the absolute moral right to criticize it, especially in a way that is toxic for the person or persons that created it.

Criticism affects both the people criticized and the community/universe at large, and not always in positive, productive ways.

2. Just because a thing is free, does not grant the thing or its creator absolute immunity from criticism.

Things that exist have an impact on communities or the universe in general, and people are going to be affected. And not always in positive, productive ways.

1 and 2 can both be true, and I think they are both true.

There is a judgment call involved as to when criticism is unfounded, unproductive, a distraction, and/or outright toxic, just as there is a judgement call involved as to when a thing’s existence in its current form is a net negative.

You are not wrong about user entitlement being a problem, as noted by #1, and you are not wrong in a commercial sense about maintainers not owing any one person anything.

But as per #2, I do not believe that is an absolute blanket injunction to never have an opinion about their choices or about the net positive or negative effect of the existence of the thing they maintain in its current form.

Critiquing someone's actions and choices is a founding principle of open source software, politics, and in general most human culture. "I think it was wrong to delete the GitHub issue because my belief structure XYZ" is acceptable.

Critiquing someone personally based on their technical choices is not acceptable. Reddit allows it, and thus Reddit is unusable as a social platform for positive outcomes. "I think you are a bad person because you deleted a GitHub issue" is NOT OKAY.

That distinction appears to be what led the creator to quit today, because the GitHub issue they deleted (perhaps incorrectly) contained personal attacks that linked their technical choices to their quality of human self (definitely incorrectly). I personally would have chosen to XYZ and I think they'll do so in the future if that comes up in a GitHub issue again — but focusing on that is incorrect here.

The focus needs to be on those who wield personal attacks on others over technical choices, and on rewriting communities to prohibit and evict these participants in all cases where such can be done. Shun them, ban them, and prohibit them.

Here is an entire essay touching on the subject:

https://github.com/raganwald-deprecated/homoiconic/blob/mast...

And the HN discussion at the time:

https://news.ycombinator.com/item?id=589200

If it doesn't meet your standards, don't use it.

Alternatively, go fork yourself.

It would be nice to have cargo/rustc support 'allow_unsafe' per module and also for dependencies, so you know you have to review a dependency really well.

>Alternatively, go fork yourself.

I think this could be the new template for Open Source Author to include in their OS work description should they choose to.

Or you get drama like ffmpeg vs libav/avconv.

This is a nice idea, but in an era of one-button package managers it just doesn't work like that. You're trying to fight against New Jersey style. Which in the entire history of software has never been a winning approach.

The reality is that for 95%+ of active software developers, done is better than perfect. Yes there may be a small subset of developers working on super-critical defense systems or nuclear reactors. Who have the time, resources, know-how and organizational support to meticulously and carefully audit all of their dependencies.

But the vast majority of developers are not in these types of environment. The mantra of the entire tech industry is "move fast and break things". Try being a Silicon Valley startup engineer and trying to justify to your manager that you could standup functionality with one call to "npm install", but that's not sanitary and you need to audit the entire dependency tree. Now assume that the next round of VC funding for your cash-strapped startup is on the line. How well do you think that concern will go over?

The reality is that if something can be instantly installed in 30 seconds, then it will be. We can give as many "caveat emptors" as possible, but convenience trumps safety every single time.

The way to solve this is to enforce consistency on an ecosystem level. The best example of this is the Debian project. There's very firm guidelines about QA and safety before a package is allowed into stable. The Debian people are probably right about another thing too: language-level package managers should be considered harmful.

Many of these problems could be avoided if we strictly used apt-get instead of pip, crate, and npm. For one distro maintainers tend to have a lot more experience and competence at evaluating stability and safety. Two, since a system only has one distro package manager, but potentially many runtime environments, it prevents a race to the bottom. Harried developers will just gravitate towards the least strict runtime with the most low-quality packages.

This lesson is probably very tough for the Rust community to swallow. Crate is considered one of, if not the most, compelling features of Rust. If we acknowledge that it was a mistake, it really undercuts the argument for adopting Rust.

The underlying contradiction seems to be a theme in software development. People who haphazardly slap together inefficient and buggy software assume the safety-critical software I've worked on must be engineered to an impossibly high standard in formally-proven Ada. We don't use Ada or formal proofs, for the same reasons nobody else does. I can say we are a lot more careful than 99+% of other projects, but we still live in the same software ecosystem everyone else does. I can't audit every platform and library we use with a fine tooth comb. A few million dollars will buy you a lot of reviews and testing (internal/external/penetration testing), but it will never be the platonic ideal of well-written software.

And Debian is a funny example for you to bring up. It's hard to take the temperature of a crowd online, but the HN attitude towards Debian's slow-and-careful releases in any other type of thread is that they're old fogies that don't understand the needs of modern software. I don't think even Debian lives up to this thread's level of code scrutiny that everyone should be doing all the time.

Our package managers have in-house mirrors, only validated dependencies by legal are allowed on those mirrors.

Installing in 30 seconds is not allowed by design.

Imagine if the linux maintainers took this attitude.

This attitude severely undermines the credibility of opensource.

If users of opensource libraries can't have confidence that those libraries are written correctly, we might as well all go back to commercial software.

It is a simple cost/benefit analysis. Your risk of presuming that Linux today is sufficiently good for what you need to do is lower than it was 10 years ago, which is why Linux today is more popular than 10 years ago and a lot more popular than it was 20 years ago.

Equally, someone gets hit by a car while crossing the road. I don't owe them anything to go help them but society, morality and being decent are these unwritten rules that kind of do force you into owing something.

Yes, I agree, volunteers don't owe anything but there are some unwritten rules that when broken should be frowned upon and I'd probably go as far as saying should be held against them.

As a reader of this, you could be thinking, wow this sounds extreme but here is the easiest example I can give.

- Someone writes library

- Library comes insanely popular

- Author refuses to allow the community to take over original project

- Author wants to maintain status, ownership, etc

- Entire community now suffers because the author doesn't owe anyone anything

"Just fork the repo", is the most common response but let's be real, nearly nobody uses the forks and every other repo that uses this popular library is using the non-forked repo.

1. Someone writes a library

2. Library becomes insanely popular

3. Users receive value out of library

4. One day, users stop receiving value from library

Is the author not responsible for the value generated by this library? At what point does the author become required to continue providing value?

"Just fork it" is an excellent response to (4), anything else is what entitlement looks like.

But ignoring good practice: a unpaid maintainer owns nothing to anyone.

In most countries they actually have written laws which require you to help in such a situation though.

"I wasn't aware someone got hit. I thought it was an animal."

What the law says & what people do :P

P.S. Thanks for making Sourcehut.

It's almost like watching lottery winners having their lives ruined.

It just seems to me that there's a give-and-take to being the maintainer of a popular open source project. You get help on the project in the form of people contributing patches, right? Doesn't simple human curtesy and a modicum of wisdom suggest that you should explain your rationale in accepting or rejecting them, to manage expectations, so that it doesn't end up like this? I know, I know. I'm taking my crazy pills again. Sorry.

Sounds like a whole lotta give to me...

It seems like you're trying to make it seem like there is always a legitimate exchange, and so they owe you something. Some projects want help, others don't. In the latter case, it's just a gift from the author, and they don't owe you anything.

Any open source maintainer will tell you that many PRs, even well-intentioned ones, end up being a net negative. Often they don't further the maintainers aims, they need detailed review, take sometimes a lot of effort to manage the communication tactfully, etc.

Yes, many PRs are a win and it can be really gratifying seeing your project become bigger and better than you could have made on its own.

But also, many PRs are just a chore and a hassle.

At the very least, I'm not going to make it easy for people to contribute. I'll keep the git repo private, go without a ticketing system, and just post tarballs full of code on a self-hosted website (I guess like the NetHack team used to do before 3.6, but they had a ticketing system, and I wouldn't). Maybe I'll even use a non-free license just to reinforce my "you take what you can get" policy.

That doesn't mean I'm willing to accept your patch. As soon as I accept collaboration, I need to worry about copyright on the contributions, whether they follow my coding style, and whether I'm willing to accept additional complexity for features I don't care about.

- There exist open source licenses (with copyleft) that disallow making it closed source.

- There exist other reasons to publish the source code: for example allowing the user to study it.

Technically you could just post the .pyc bytecode as long as you didn't care about it working on anything but CPython and compatible implementations.

Consider CC0 instead.

As a veteran open source contributor, I totally understand that dealing with open source communities has a huge cost to go with the huge benefit. Even just vetting patches can be a pain when you care about security and architecture and don't want to spend time endlessly explaining your choices.

CC0 allows you to provide maximum benefit should you opt out of "social coding". People can go ahead and fork your stuff, or just use bits and pieces, without needing to deal with licensing or crediting headaches. (Significant consumers still have to track provenance, though.)

Certainly I would expect amyjess and anyone else reading to exercise due skepticism and perform their own research and I respect them enough to expect that they will "consider" my suggestion rather than "blindly" follow it.

PS: Why assume everyone is "ill-informed"? We're all learning together forever: you, me, amyjess, other readers...

People should decide if it's a big deal for them and if it is, fork the project to fix the issue or move to another library. I have had to do this many times myself, I kind of thought that's just how things worked with smaller projects. More than once I've found someone of a like mind has _already_ forked and made the change.

The level of entitlement in the discussion astonishes me. Someone has done a lot of work and offered it for free along with a license that lets people modify it and redistribute it and that is not enough. Instead of being grateful for it, people are demanding that the giver also make the changes that these people need and take on the burden of maintaining them.

To all those people: Why should he? Do it yourself or pay someone to do it. It need not be any more complicated than that.

That's correct. Here's Rich Hickey's take on it: https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...

Otherwise we get dozens of half broken forks all over the place. That's no fun for anyone.

This wasn't a drive by beg. This was a patch solving real demonstrable problems and at minimum there should have been a transition plan due to basic decency.

Doesn't work that way, I'm afraid. The maintainer already gave the community something, and doesn't owe them anything more.

Giving someone the mere ability to make a PR is already a gift far beyond what the original author owes.

And a lot of the internet has this wrong, including you.

Let me start by saying that Open Source is not a zero-sum game. I can make a library like your library and it doesn't have to be an adversarial relationship. I have users, you have a few less users.

But there are costs to having more. There is still only so much space in the ecosystem for so many actors. The more logging libraries we have the harder they are to find, the more drama there is over picking one...

The best analogy I have is a party. If I throw a party this weekend, and your birthday is next month, then I'm not hurting you. If I throw it the weekend of your birthday, knowing it's your birthday, I'm kinda being a dick. That's not cool, and you have every right to be upset.

Okay, but what does any of this have to do with Open Source projects, hinkley? I'm within my rights to throw a party. But my guests are within their rights to be upset if I throw a shitty party. They showed up. They could have been doing something else. But I insisted on taking up space and now I'm being ungracious about it. It's my party and I can treat people how I want is technically the truth, just like "I can do Open Source and ignore the concerns of my users" is technically the truth.

What I'm saying is that the people who show up don't have to like it. They're entitled to complain to people about it, especially if I don't apologize and say I'll do better next time, or get help.

It's my party, I can cry if I want to, but people are gonna talk.

[edit to add]

I think the problem is that we have a bunch of people who throw themselves into software at a young age because of or at the expense of social awkwardness, and we insist on treating things and other people as if they are machines instead of people who are also just trying to do the best they can. I'm fully aware that this observation cuts against my argument as well as supporting it, but we can't go on coddling people and organizations for ignoring the very real social aspects of our work. For being poor hosts.

And it's really hard, believe me I know. But people want to see that you're at least trying, or they will paint you the villain.

The problem was that PRs which would have fixed security issues where not accpeted.

Do I expected perfect code from maintainers or a answer the next day? No, never

Do I think maintainers/creators should merge prs in a timely manner, or ask for help if it get's too much? Yes, otherwise you have multiple forks and the project is not usable anymore.

I mean, anyone can fork it and become a maintainer, and create new guidelines and inclusive rules that ensure the project is steered in the "right" direction. Isn't it the case?

I understand the "we just want a better actix-web", but there are two conflicting concepts, "better", and "actix-web". The way I see it, "better" is whatever the maintainers think it is, and "actix-web" is a project belonging to its maintainers. No community should ever be entitled to try to steal that. They are welcome to build upon it and fork it. This doesn't mean they have to separate ways forever: some forks live happy parallel lives, as so many Linux patchsets have demonstrated over the years. Projects are free to be born, forked, cross-pollinated, merged together, even die, all at the will of their maintainers.

I know that is how it is "supposed to work". However, I've very rarely seen it actually work that way.

The problem is the "first-mover advantage" and it is a hard one to overcome. If you make a "maintained actix-web" fork, most people will still find their way to the dead project. Even worse, many resources and tutorials will point to the old library. A search for "actix" will almost certainly give confusing and frustrating results to the novice.

check, check and check again...

When I signed up for a GitHub account, I don't recall anything about having to agree to an SLA.

I've seen many small projects that I use or monitor where someone will raise an issue or make a PR, and the owner will respond along the lines of "Great, looking into it, but I'm kind of busy right now, will get to it when I have time," and then people going off on them if "when I have time" isn't right now. Usually this is followed by an offer from the owner to give the reporter access or pass the ownership to them, which is invariably followed by crickets.

There has been a lot of talk in this thread about the obligations of project owners. This seems to boil down to fundamental philosophical differences. My view is that if you want people to do shit work and jump when you say frog, you have to pay them for it, rather than bully them.

It actually was not. The article is quite clear that the problem was created by the way the Rust community, particularly the one at Reddit, acted and reacted so poorly with regards to the way a project was maintained.

Let this be as clear as possible: the problem is not nor it ever was any PR. The problem is the appalling way the Rust community attacked the maintainers of a project.

But what exactly are the responsibilities of a maintainer? How far should you go to fix bugs? How thorough should you be about your code's limitations?

If you're doing a project just for fun, should you discourage others from using it in production?

I started to suspect that this was satire with all the talk of inclusive and the use or 'unsafe'. I kept reading and reading in anticipation of gradual escalation that reveals it's satire. In the end there was none. I had to come here to read comments and to see if this was real or just very subtle satire. Apparently this is real.

I just can't wrap my head around the "inclusive community building". What happened to "Those who write the code decide everything" and "You are free to fork if you don't like where this is heading". Any free community is as much about exclusion as inclusion.

If this were true in the strictest sense, then they would be free to put malicious code and trick you into using their stack just to then steal credit card numbers from your database. Of course this is not true, and they would appear to at the every least owe us "good faith" or perhaps some basic guarantee that they are not purposefully trying to criminally attack you. This may seem like a useless edge case to bring up, except for the fact that the law does have some amount of consideration for negligence.

Arbitrary people you don't know owe you nothing too, and yet if you walk onto their premises and get hurt, the law has found in certain circumstances that they are indeed at fault. Expectations and responsibilities evolve with time, and as new scenarios come up. It is not clear to me that putting up a project that invites people to use it in production could not be argued to some extent to be negligent if it willfully blocks and delays fixes that could affect real world customers.

At the end of the day, if people were using my code in production, and a discovered exploit was used to steal people's data and I could have prevented this by merging in code that wasn't 100% to my aesthetic liking, then I think I would feel bad. Fault isn't binary, maybe its the fault of a random company using my framework for not being up to the minute on all vulnerabilities and manually patching the code themselves, maybe its their fault for using my framework in the first place given the youth of the project too. But I don't think I would go to sleep that night feeling great is all I'm saying.

I'm not super familiar with this particular case, but the OP blog post was phrased as kind of wanting to open up a dialog or discussion on the nature of these issues. I am bringing up some thoughts about this stuff I've had for a while and I think at least help to understand some of the moving parts involved. For the record, I don't really know where I stand "absolutely", or if its possible to have a clear principle that doesn't take into account some number of additional variables (how the project was portrayed, how many users it has, etc.).

Of course they do. It’s not legal for you to distribute software that puts others in harm’s way. You’re not allowed to give poisoned food to homeless people as long as it’s free.

Lol. That’s about as legal as saying you can’t be arrested because you’re a sovereign citizen.

The OSS maintainer should clearly, upfront, preliminarily, outline how do they govern the project: how much are they open to change the project's core values, how responsive on average will they be in terms of opened issues and PRs, roughly how often would they engage in technical architectural debates -- stuff along those lines.

I feel many people get toxic if they had unrealistic expectations -- and that's of course not okay.

But IMO the OSS maintainers can be a little more preliminarily proactive in managing expectations from earlier stages.

Why do you think they owe you this? You didn't pay them, and they didn't accept a contract.

When you make something that people use and like and want to improve, you should at least have the common decency to tell them beforehand: "this is my show, not gonna accept PRs".

I don't think it's such an exhausting job to write two lines at the top of the README.

I’m grateful just to see the code and choose to use it, or not. If I think some random volunteer should do something, I’ll attach that suggestion with some money or a contract or at least a beer.

What I love about open source is that it’s a big place that has lots different people. It’s beautiful because someone can write code and never talk to anyone and their code is still good and useful.

Maybe a better, more truthful statement is “OSS maintainers will have better engagement with the community if they proactively manage expectations.” And if the maintainer cares about that, it will apply. But I think there are quite a few projects that don’t really care much about community.

So what is "missing" is a common way to discuss about that kind of issues, as a community, while staying civil and not in a way that is worse than the initial issue. In some cases the end-result could be the kind of the same (if most users flee), but the goal is obviously to improve the ecosystem and if managed more appropriately, it is possible that some maintainers are wanting to improve their software to the state of the art.

> 1. YOU are responsible for your dependencies.

This contributes to the prejudice against `unsafe`. If I wanted to be a full-time auditor, I wouldn't be steering clear of C and C++.

Since I'm a responsible coder, I avoid depending on `unsafe` outside of `std` or the simplest of FFI wrappers with extreme prejudice, to the point where I consider NIHing an alternative or just sticking to a managed language with a more mature ecosystem, depending on the project.

It's not a silver bullet, it will show you areas where memory safety issues could arise, but doesn't necessarily prove the presence of memory safety issues. Memory safety issues aren't the only type of security bug so them being impossible also doesn't mean it's entirely safe. You can think of issues like injection attacks or faulty ACL logic happening without memory unsafety.

There's also cargo-crev, which is an attempt at making a web of trust for reviews of third party packages: https://github.com/crev-dev/cargo-crev - for a longer form article on what crev's goals are and how it works, I found this explained it for me: https://wiki.alopex.li/ActuallyUsingCrev

It's moments like this that I reflect on the past and the public and virtual forums I have participated in... and how my own attitude shifts in favor of cooperation when I must couple my face with my words. And I wonder if others feel the same.

The only limit might be publishing something that is actively intended to do harm. But I can't imagine a plausible example of that...

And if you're intentionally doing any of the things you listed above, then you're not a maintainer. That simply is not what maintaining means.

No it isn't, unless those users are paying.

If you disagree with the notion of someone publishing their work under a free software or open source license being useful for the world, then please post an AskHN about it and you will have _plenty_ of material to convince you of this perspective. However, I think most reasonably clever people can already come to the conclusion themselves.

What you are responding to is a rhetorical response I gave as an argument against the dismissive idea that an open source maintainer should have no responsibility unless they are getting paid. I don't agree. I find that it's a maintainer's responsibility not to extend, but to maintain. That's all I'm arguing.

If someone wants to throw OSS at the wall to see if it sticks with no obligation to maintain, then that's fine. But as soon as someone puts on the maintainer hat, I think it's reasonable to say they are accepting responsibility for that role.

"If that's the case, then why open source it at all?"

This is the part which made me feel you disagreed with it.

However, may I ask if it is your belief something released under an open source license comes with an intent to maintain it (for others)? Or that releasing something under an open source license is a declaration of being a maintainer of said software?

(not trying to be snarky and am just trying to see why we appear to be in disagreement)

> This is the part which made me feel you disagreed with it.

I am aware, and as I already explained, this is a rhetorical device which you mistook for my own personal belief. Obviously I don't believe OSS is bad. It's friggen great.

And that's a fair question. I am absolutely not saying that open source means you must maintain it. I am simply saying if you call yourself a maintainer then you are responsible for maintaining. If you don't want to maintain OSS, then don't. Just don't pretend you're a maintainer and that you have no responsibility to maintain. At best, pass it on to someone willing to maintain it. At worst, pretend you're working on it. As I said in my original comment, others should fork as needed.

And to add, I don't believe the original subject of the article, the now former maintainer of actix-web, did the wrong thing. I am in agreement with their decision to drop out. No one should be held to an unrealistic standard by entitled users and expected to put up with that BS. The part of my original comment that everyone has a problem with is seriously the least consequential phrase. Blows my mind that everyone is hyper focused on taking it out of context as well.

https://en.wikipedia.org/wiki/Software_maintainer

I see it frequently in the FOSS community where someone will suggest some software they made to solve a problem, get told why their software isn't actually that good for the problem, become defensive about it, and then try to play the "entitled user" card.

If someone is terribly dressed according to my taste but brags about how amazing the garb is, I'm not going to tell them how they are wrong unless absolutely necessary because of exceptional circumstances.

Neither does most people who respect others right to their own body, and creativity.

I don't ring up the artists after visiting a gallery to tell them how their art is done, not unless I'm an ass.

Source code is not much different, it is an expression of technical competency, art, taste, and fashion.

If someone asks for feedback, sure, your points are not wrong.

In practicing social dancing, asking if someone wants feedback before giving it generally works out really well. Most people want feedback if you give them the power to choose for themselves, but quite a few really do get hurt if it is unsolicited. There will be some people that get slightly annoyed that you ask, as they prefer more direct approach, but neither they or anyone else get hurt.

Something similar probably works for open source projects too. Engage seriously for a bit, and only then ask if your input on your particular issues would be interesting to the other party.

If they're actively asking me to use their software, isn't that soliciting feedback? If I say 'no, it won't work for me', I've apparently committed some egregious microaggression right? If I just say 'no thanks', what do expect the very next thing they say is going to be?

>> Just because you made a software doesn't mean I have to use it or like it, and if you are actively trying to recruit me to use it then I am indeed entitled to complain about it.

That is what I wrote. That is entirely the context of what I said.

This is the potential problem with “just fork it”. If the library is used by a great many products, and you know of a security vulnerability, merely providing an alternative that fixes it could be argued is not sufficient, while fixing it in the root library will patch the vulnerability in every product that has it in the next update.

It seems we still haven’t figured out (and perhaps never will) the exact responsibilities between all the parties at play.

As a pure hypothetical, imagine a critical bug was discovered in Rails that would potentially allow someone to attack any Rails website and extract personal information. Further, imagine someone quickly submitted a PR with a patch for this, such that Rails could then do a quick release and make sure it gets to every Rails consumer as fast as possible.

What if the Rails maintainers then ignored the patch, and said it was boring. Legally they are under no obligation to do anything really. And you could argue that it's on every one of the thousands of sites that chose to use Rails if they get hacked and expose user information. And further, you could argue that if people don't like this situation, they are "free to fork Rails" with the patched version. All this is fair, but I think others might say that the Rails maintainers at this point did fail in a responsibility. There are arguments for both sides, but I do not think it is as simple as "the maintainers owe people absolutely nothing" as at some point being the nexus of updates actually gives them an almost stopping or blocking power, not just the more passive refusal to fix the problem themselves.

This scenario is clearly different in magnitude from what happened with this project. That being said, my only point is that it is fair to expect a certain amount of activity in a project that bills itself as production-ready (and asks you to use it). I personally would be very weary before committing to telling someone something is production ready casually, regardless of whether the "fault" ultimately rests on them. That being said, this of course does not entitle anyone to treating others poorly, my only point is that the responsibilities and expectations are not well understood in this domain.

Absolutely not. They are compensated with prestige, enjoyment, decision-making power, future employment rewards, and sometimes even money, all of which was their choice to pursue through their labor and time spent on the open source project.

The users of open-source projects, upon which the projects themselves depend, are also not obligated to anything, and can for example (very reasonably) become angry and complain if people prioritize pet features instead of community needs, or unilaterally take projects in unsupported directions.

There is compensation for the work, and there are still social norms. Nobody cares one bit about who is entitled or not entitled to what.

> They are compensated with

> prestige,

That seems associated with the popularity of a project which is largely outside the control of an author. So: how could one publish code (just in case it's useful to somebody else, which seems to be a nice thing to do) and opt-out of the popularity contest?

> enjoyment,

People can have the same enjoyment without publishing the code, so there's nothing open source about that.

> decision-making power,

In their own project? Of course. Again, they could just keep it private, with exactly the same decision-making power - nothing open source about that.

> future employment rewards,

If a developer ships crap code, that issue seems to sort itself out automatically (who would hire a proud author of unsafe code?)

> and sometimes even money,

Those paying money certainly can and do make demands. I haven't heard claims about breach of contract in this case, so that's probably not a factor here?

Huh?

By the way, isn't this a great opportunity? The code is open. Fork it. Seize the day. Become a better maintainer, and build a community around your fork. Ensure the community needs and wants are aligned with yours. Steer that ship. Gain prestige. And money, maybe.

If someone is a bad maintainer, there will be no community, no prestige, and no money.

No. You have a right to be annoyed, and then fork the project if you want.

You do not have a right to become angry unless you're paying for it.

> enjoyment

Riiight

If you do X for enjoyment and it actively hinders some other group because they needed Y and using personal priorities to rank addressing X instead of Y is an egregious violation of community norms, people will take action to bring down the enjoyability of doing X and raise the enjoyability of doing Y, like complaining about X and thanking you for Y.

If you as a user don't like it, ask for a refund.

And I think that is the problem I have with this blog post, It reads to me as trying to spin it as something else with anxiety or Reddit, when what I see the problem is something very different based on principles and values.

Perhaps, but if he claimed that it _was_ vetted, then he took on some responsibility for it (which he probably should not have).

Also, the blog post article claims, that you are never supposed to use "unsafe" code without having vetted it. Honestly, I doubt that very much, but if it's true than that's some responsibility taken too.

When I evaluate a technology for its appropriateness I first look at who's using it: Literally "Who are these people and what are they working on with this stuff?" The answer to this question determines more than 80% of the decision on whether the thing is going to be my choice.

Rust seems to be being used most by people who are interested in blockchain and crypto. They tend to be of a near monolithic ideological caste, too, which has its own problems. Do I want to get into a situation where I might have my hat in my hand with these folks? Not really.

(also the rust compiler is so slow I cannot believe it)

What makes you think that? I don't believe that is true, it's like saying C++ programmers are mostly interested in high frequency trading.

edit: typo

You can easily find counter-examples if you look for them.

Where did you get that from? From what I've seen every single blockchain/crypto post on Rust's subreddit is downvoted into the negatives.

That said, blockchain companies using Rust take security very seriously. It also funds cryptographic research which has a huge need of memory safety, performance and the possibility to implement constant-time primitives.

I don't see why the community of a language that focuses on safety and speed is not excited by having the language being adopted by communities which absolutely cannot compromise on safety and speed (communities referring to both cryptography and blockchain communities as they are distinct).

Disclaimer: I work in blockchain, I implement cryptographic primitives. While I don't use Rust, I do read a lot of Rust code from other blockchain projects or from cryptographers from elliptic curve cryptography to hashing functions.

My reasons can be summed up as: "public blockchain" aka cryptocurrency is toxic — it's horrendously inefficient in the name of achieving censorship resistance, so people are literally burning fucktons of energy to make perfect "crime currency" work. It has fueled the rise of ransomware (and extortion in general) and all kinds of scams. Meanwhile "private blockchain" is just like good old merkle tree/hash chain stuff, infused with hilarious/awful marketing fueled by cryptocurrency hype.

Good talk about this: https://www.youtube.com/watch?v=xCHab0dNnj4

- I agree that cryptocurrency turf fights are toxic

- censorship resistance does not equate privacy. The main blockchains today are actually fully transparent. The perfect crim currency is cash which is almost untraceable.

- The energy burn is to achieve distributed consensus. I don't think there is any distributed consensus algorithms that is not a tremendous energy burn today be it physical voting (transports, broadcasts, special machines, security, ...) or CEOs and diplomats flying around the world.

- The energy burn is still concerning but Proof-of-Work is not the only way to solve the Byzantine General problem via economic incentives. You only need a "rare resource" that cannot be easily replicated to avoid sybil attacks (i.e. not an email address). That can be cryptocurrency (Proof-of-stake) or storage (Proof-of-spacetime)

- I don't think you realize the scale of drug trafficking and other unsavory endeavors that use cash.

- Mostly agreed on private blockchain but there are some industry-wide private blockchains that are starting to emerge (including UNICEF and FAO) with very interesting applications (identity of children refugees and managing food).

None of the "other use cases" have been interesting in any way.

> The main blockchains today are actually fully transparent

So what? If the exchange between the cryptocurrency and real cash is not compromised, the only traceable thing is that some address which you don't know anything about got paid from another address which you don't know anything about.

Again, real world ransomware mostly uses Bitcoin.

> I don't think there is any distributed consensus algorithms that is not a tremendous energy burn today

Anything that is not trustless, even physical voting, should be vastly more efficient.

> Proof-of-stake […] Proof-of-spacetime

Yeah, when did Ethereum promise a switch to proof-of-steak? Where is that again? Has anyone actually proven the security of any of these alternatives?