It's absolutely correct that people don't have obligations simply by putting some code online. But they do have obligations when they start telling people to use their code. We understand this as humans even in realms far from open source: if I see you approaching a door, I am under no obligation to open it just because I'm physically able to, but if I open a door for you, I'd better hold it until you're finished walking through, or I'm a jerk. By holding the door open, I've made an implicit promise that I'm not going to close it on you.
It's not very hard to say, this is a project for my own technical interest, I don't intend to follow Rust norms about use of unsafe, and you shouldn't rely on it, but here's the code if anyone wants to look. That's fine! (And I do think we need to be better about making it common to do that. GitHub has no good tooling for such a repo, for instance: you can't disable pull requests unless you archive the project or make it private.)
But that's not what Actix's docs say. See https://actix.rs/docs/ for instance: there's nothing to the effect that you shouldn't use or rely on it, and everything to the effect that you should. (In case that page gets taken down, it starts, "Actix is your door to developing web services with Rust and this documentation is going to guide you.") On https://actix.rs/community/ it says you should report bugs to GitHub, implying that bug reports are in fact welcome, and there isn't a single statement that the project goals prioritize the author's technical excitement over correct code.
Again, there's nothing wrong with wanting to prefer your technical excitement over having bug-free code. Just be clear about it.
> if I see you approaching a door, I am under no obligation to open it just because I'm physically able to, but if I open a door for you, I'd better hold it until you're finished walking through, or I'm a jerk. By holding the door open, I've made an implicit promise that I'm not going to close it on you.
This reminds me of an incident years ago. I was on a city bus, very full of people, and we were just about to leave a stop. There's a woman maybe 150 feet away running towards the bus. The driver sees her running and re-opens the door, waiting. Inconvenience to all of us on the bus, but hey, she's running.
The woman, seeing the bus has waited for her, stops running and starts slowly walking instead.
Driver sighs, closes the door, drives away.
I'm not sure what the moral lesson I take from it is, but mainly "if I go out of my way to help you, don't take advantage of my generosity". Maybe that partially applies to situations like this one. Or maybe just "don't annoy transit operators". That's a good one too.
He held the door open for a lot of people. Some people spit at him as they walked through. He doesn't want to hold the door open any more, he's done it enough. He didn't sign up to be a doorman for life.
>
It's absolutely correct that people don't have obligations simply by putting some code online. But they do have obligations when they start telling people to use their code. We understand this as humans even in realms far from open source: if I see you approaching a door, I am under no obligation to open it just because I'm physically able to, but if I open a door for you, I'd better hold it until you're finished walking through, or I'm a jerk. By holding the door open, I've made an implicit promise that I'm not going to close it on you.
Exactly.
Like it or not, there are implicit social contracts if you maintain OSS software.
Yes I've read the birdseed of the various licenses.
I know this will whip up the oft-suffering maintainers and developers in here. But this is the exact kind of trope that stymies wider FOSS adoption.
The artifacts of these little meltdowns are exactly the kinds of things your upper management will cite the next time you suggest using FOSS vs. whatever vendor they're about to push down your throat.
Ignoring security conventions, and then adopting a "take my ball and go home attitude" isn't a ringing endorsement for adopting FOSS, unless it's run by a large entity.
I'm not saying the author should have to endure abuse or harassment, but consistently pushing unsafe code into a web-framework, being cavalier about trivial and widely accepted coding conventions, and dismissing patches as "boring" is exactly how you end up with NPM Ecosystem v2
If some one opens the door for you that was nice of them, they did your work for you, they have no ongoing obligation to maintain the door in an open state.
If some one give you their code that was nice of them, they wrote your code for you, they have no ongoing obligation to maintain your code.
by simply giving you their code they have already provided you with value, a head start for nothing in return, they have opened the door for you, the rest is up to you.
Well put. I’d add on to your metaphor: slamming the door on someone is quite different than just not holding it open anymore. The second is totally acceptable; the first is impolite.
They're right, it was unprofessional... but since the maintainer is not being paid this is not a professional project. It's a personal project. And this seems like a perfectly personal thing to do with something that's preventing happiness.
I absolutely agree with this. The author has spent an insane amount of time to build all this stuff and instead of getting recognition and/or being payed adequately he is getting shitstorm after shitstrom.
As an outsider I have to say that I think what the Rust community has technically achieved is remarkable. But on the social side it is not so bright, avid Rust users constantly spam forums of other programming languages with toxic comments. But this incident shows that the situation is even worse than expected, the Rust community even treats its own peers like sh..
Well, it's easy to get confused when you look at the professional looking website with a well crafted logo, a promo list of features and a copyright notice from the "The Actix Team". The community page even says "We're a welcoming community so don't be afraid to engage.". Ouch!
If you create an organization on GitHub for a project that is meant to remain personal, this kinda sends a wrong signal.
Blaming some users for being rude and entitled, and then deleting an open source repo out of spite... it's a bit hard to feel sympathy for the guy here.
Exactly. It can be argued it's unprofessional to become dependent on third-party software without any background recherche regarding the maintainer's motivation, team size, financial standing, etc., especially when said third-party software isn't a replaceable, standards-based component such as, say, Java Servlet containers and other web components used to be.
Professional pursuits are things related to a vocation, not directly tied to an exchange of money for every interaction under consideration. If you're in the industry of software development, and tie your identity to an open source project, it is de facto professional.
In this example it is held as a significant accomplishment on this individual's linkedin page. Which isn't surprising as professional credibility is a primary motivation driving a lot of open source involvement. We are seeking a different, less direct form of compensation.
So it's fair to say that acting like this is unprofessional.
That doesn't mean it isn't merited, or that they might have been frustrated or had good reason. But professionally they would have been much better served by other means: Simply announcing that they're retiring from the project and encouraging forking and the percolation of a new canonical version, etc.
If you offer code to the public – and present it as an active, dependable project – professional behavior is exactly what you implicitly promise and signed up for. If you can’t offer that (at any time, and for any reason), then you should immediately make that clear, front-and-center, to any current and future users.
It isn’t “entitlement” on part of the users – the users are making reasonable expectations based on promises implicitly made by the the project as it is presented.
> If you offer code to the public – and present it as an active, dependable project – professional behavior is exactly what you implicitly promise and signed up for. If you can’t offer that (at any time, and for any reason), then you should immediately make that clear, front-and-center, to any current and future users.
As far as I can tell, this project was released under the Apache License 2.0.
"7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License."
Other popular free software licenses (namely the GLP) have very similar clauses.
> It isn’t “entitlement” on part of the users – the users are making reasonable expectations based on promises implicitly made by the the project as it is presented.
Expecting labour from someone without paying them is the very definition of entitlement.
As an open source maintainer, you're perfectly entitled to just walk away. Hit that archive button on github so nothing new can come from the repo, and enjoy your life. Nobody could fault on you that. People would prefer you work out a clean transition to a new maintainer, but you have no obligation to do so.
Deleting the repos is the equivalent of setting the house on fire on the way out (especially when they're under their own org). Unlike in reality, it turns out it's totally permitted, but people will still view it as a dick move.
> professional behavior is exactly what you implicitly promise and signed up for. If you can’t offer that (at any time, and for any reason), then you should immediately make that clear, front-and-center, to any current and future users.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
It's in big capital letters there. Explicitly no implied promises.
> It isn’t “entitlement” on part of the users – the users are making reasonable expectations based on promises implicitly made by the the project as it is presented
That is almost literally the definition of entitlement
To assume certain conditions that are not explicitly laid out without even talking to the person providing you the service is literally entitlement. It seems like you've made assumptions that turned out wrong. I've fallen for it too in the past. Not everyone thinks the same thing so people's assumptions are always different. The key thing is, when your assumptions don't turn out true, to learn from it.
In the case of open source, it's worth asking the maintainer what the terms are if you're unsure. The LICENSE always says that authors and contributors are not liable for any outcome, either as an ALL CAPS paragraph or a clearly defined section.
Everything is provided as-is so you can't expect anything. It's on you to pick up after them if you still need the project.
No you don’t. You aren’t alone in assuming that, but it’s an entirely unreasonable expectation. And as evidenced by this exact thread, people like you cause good developers to stop maintaining their projects. Your attitude harms our community.
Practically speaking, if I give you some work I did for free yesterday, and give you some work I do for free today, that does not entitle you to free work from me tomorrow. It does not entitle you to free support on the code I’ve published already. I owe you my time when you’re paying for it. Until then, if I have made something you found valuable you are in my debt for its use. Not the other way around.
As a user of my software I generally give you two rights - you have the right to use the code in your project, and the right to fork the project. And as the maintainer, I have the right to spend my time however I want for the rest of my short life on earth. If the beach looks like more fun than putting up with entitled complaints on github and HN, that is my right.
Strongly disagree. For me, what's implicit is that any software, commercial or F/OSS, can be abandoned at any time - because that's just the way it is. A remedy would be to use software coded to a specification with mulitple implementations such that in case a project folds, you might be able to switch over to a different implementation. The Java EE ecosystem used to be like that until around 2012 or so.
>If you offer code to the public – and present it as an active, dependable project
Not familiar with the project or Rust Ecosystem. Anyone else can comment whether it was presented / marketed / sold as an "active, dependable project" ?
As someone more used to the Ruby Rails ecosystem, I think the communities as a whole generally accept the convention that all open sources, whether they are backed by a single person or cooperate account, are given out as it is ( MIT ) and their maintainer or author will do the support or development as they could when they are FREE. And it is perfectly acceptable of forking it to make your own variation or improvement.
Think about this. Do you really think it makes any sense to try to hold people to promises inferred by alternate parties that aren’t even providing any consideration in return?
> professional behavior is exactly what you implicitly promise and signed up for.
Wise up. Professionals get paid, if you aren't paying some one they are not a professional. This is the reason why opensource projects provide professional support for pay, for professionals who need professional support.
I think that's made pretty clear in pretty much every open source license: "Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND".
Is it entitled? Most would agree, "very" (but that's not my concern nor judgement to make)
Did the maintainer screw over people that were using Actix? Very likely.
I sympathize with both sides here. I've been the unthanked, punching bag contributor on a few notable projects, and I've been a user of software whose leadership got into drama and squabbles, that ultimately fucked me over.
There were times that I pulled certain projects and essays, that had greatly helped people, and taken my ball home because I was fed up with the people I was catering to. There is no correct answer here, dealing with people and their emotions, but there is a way for both sides to handle things without contributing negatively to other's lives.
Now due to that comment actix maintainer has disabled issue too. I don't know why people show such attitude as if they are paying him to do opensource.
In open source you give and take.
The actix author almost certainly (unless they deploy their own kernel) has profited immensely from other peoples work.
This is because as a community we have realized that we don't sell libraries, we sell stuff build with them, so we all win when we share.
It is your choice to use open source software without open sourcing your own work or without contributing.
But by engaging in open source you engage in a social contract, you become part of a community whose goal it is to foster collaboration and help one another, other people start to rely on you, just as you rely on their libraries, compilers, and kernels.
The author choose to break that social contract out of spite. He created a scenario where people choose to rely on him, when they could have relied on other works, and then screwed them over majorly.
You basically can. The cost of free stuff like this is "be nice to the guy giving it to you" or at least don't be actively abusive about it. If the community won't pay that price, expect it to evaporate.
You can retract it. He just did it. You can take down any webpage under your control. I could delete this comment later if I like. You could delete yours. etc.
In open source you give and take. The actix author almost certainly (unless they deploy their own kernel) has profited immensely from other peoples work. This is because as a community we have realized that we don't sell libraries, we sell stuff build with them, so we all win when we share.
It is your choice to use open source software without open sourcing your own work or without contributing.
But by engaging in open source you engage in a social contract, you become part of a community whose goal it is to foster collaboration and help one another, other people start to rely on you, just as you rely on their libraries, compilers, and kernels.
The author choose to break that social contract out of spite. He created a scenario where people choose to rely on him, when they could have relied on other works, and then screwed them over majorly.
Whatever drawbacks Actix may have had, this entitlement has gone too far. There is no defensible reason to tell someone "never write Rust again" because you don't like the code they're making available to you. We need something to remind us that we should be civil and grateful for FOSS contributions.
I recently saw a talk by Atwood about good discourse and how you should remind people of your values before they write their comment, which I think applies here. I'm going to make a single-page website reminding people that FOSS maintainers are volunteers performing a service to everyone else, and that we should keep that in mind.
If nothing else, it'll be an easy think to link people to in my issues sometimes.
"We need something to remind us that we should be civil and grateful for FOSS contributions."
You mean like having the legitimate risk that maintainers will take their ball and go home when people are cruel and others stand around and let it happen?
This is everyone's fault who didn't dogpile the people who were being terrible. We all need to be calling out people being horrible, and provide a little emotional support to maintainers. We worry too much about the feelings of people who contribute nothing, and not enough about the people who build the things upon which we rely.
No, I mean something less remote and which looks less like a random act of God, something that people can read before engaging in discussion and not easily dismiss because "it probably won't happen". We need to raise the level of discourse across the board, not just prevent the most egregious of negativity.
I want people to enter the discussion with the mindset "this is a volunteer effort so I will aim to be productive in my disagreement", rather than "fuck this guy".
> how you should remind people of your values before they write their comment
That sort of thing doesn't work, even if it's shoved in people's faces. The only viable solution I've ever seen for enforcing community standards is to suspend or ban people who violate them. Otherwise, you'll always have trolls and people who want to see you fail looking to poison the well.
> We need something to remind us that we should be civil and grateful for FOSS contributions.
Sort of ironic that the entire commotion started when the Actix maintainer dismissed a contributor's code as boring after they wrote a POC and a patch for a use-after-free bug.
Open source maintainers have a hard time - especially when they're under criticism and receive zero positive vibes. Author mentions it, here's the excerpt:
Be a maintainer of large open source project is not a fun task. You alway face with rude and hate, everyone knows better how to build software, nobody wants to do home work and read docs and think a bit and very few provide any help.
This a big problem with open source - I, as a programmer, like when someone commends me. It might be childish, but if I invest a few days into code and someone finds it useful - I would love to hear it, it would make the day for me. Instead, I had similar experience like the author of actix - hatred, rudeness and a lot of people who don't read the docs, they merely expect everything to work if they drop the library into their project.
Sadly, we're way too negative and don't appreciate OSS maintainers. This trend should change. It's sad to see yet another project go because author was mentally drained due to negativity. We should take care of our own "brothers in arms" (we all write code or deal with tech, don't we?).
I haven't used Actix-web, but I can sympathize with the author. Keep your head up, recharge your batteries and remain creative. Good luck with your future products!
A data point: I've been involved in Open Source for 10+ years, developing projects myself, helping to maintain very popular projects, contributing, and I don't see a trend like this. I've interacted with hundreds of people over the years, and the vibes are overwhelmingly positive; I haven't noticed any hatred or rudeness towards myself. I can't think of a single time interaction with OSS people afected me negatively, but there were a lot of positive (or neutral) interactions.
Over time projects I'm contributing to were changing, and so I was exposed to several different communities (Python web development, data science, web scraping), and all of them turn out to be awesome. Maybe that's just luck, but not all OSS maintainers have it hard - no idea why :)
Yep this is why, more and more, developers are simply doing private repositories. They might exist on GitHub. Or a torrent or something. Rachel goes into more detail about them here.
Basically people fix things and don't commit them back upstream because doing so is too much of a political headache.
> While it's probably true that the dictator does suck at design, the talented user wants no part of the drama which would follow such a report. There is absolutely no benefit to lighting that particular fuse. And so, the problem is never reported, and the patch is never conveyed upstream. It effectively becomes a private fork limited to the talented user's systems.
I've been thinking for a long time that one of the problems with these online shitstorms is that the adults in the room are silent. It would have been so much better if the senior people in the Rust community stepped in to actually say "Hey, we're all using it, yes it's got issues, but thanks for your contribution and don't worry about the idiots". Instead we've got senior people in the Rust community waiting until the damage is done and then hand-wringing about it afterwards.
It's a tricky balance. This is also sort of where I was getting at in my post with the "unofficial" bit; because /r/rust is not official, we do not look into it. And because this happened on Reddit, there was no real opportunity to actually step in. It's quite possible this is simply a failure on our part.
I don’t want to come across as toxic myself, but I think that the toxicity that Evan sometimes has to endure from people in the community is somewhat self-inflicted.
Last year I wrote a web application in Elm. Even though I really liked the language and had lots of fun writing code, I noticed that the users effectively have to rely on Evan to make any meaningful progress. The ‘forkability’ of the project is very poor.
To give you a couple examples of that:
- Elm has a centralized package repository: https://package.elm-lang.org/. There is, however, no functionality in Elm to host your own registry, whether it is public or internal to your organisation. The monolithic compiler/build tool hardcodes the URL of this registry.
- Relatedly, there is no way you can easily fork a package and apply some changes, especially if you have no intent to host it through the official package collection. There is no way to say: “I want to use elm/http with this tiny local patch applied that I have sitting in my tree.”
- Some parts of Elm’s grammar/intrinsics are only permitted to be used by packages with author “elm” (i.e., the official core packages). This means that you cannot fork, say, elm/bytes to yourname/bytes and make local changes, as it can no longer be built.
Because of this, the maintainers of Elm don’t just decide what goes into the tree, they effectively also decide what users may do on their end. They are the folks sitting behind the master control panel and people filing issues/pull requests rely on them to push the buttons for them. I can understand why this causes friction within the community.
Note that this was my experience using Elm early 2019 (January-April). It may well be that Elm improved in these areas since.
I use to do a TON of open source back in the day. i quit cause of the same reason, people suck and feel they are entitled.
i couldn't count how many times someone would yell, kick and scream about an issue they were having and demand that i fix it right away (ain't gonna happen dude). i finally got to the point where i told people that i would only participate in pull requests and nothing else. you could still file issues, but i wasn't gonna even look at them. if you wanted something fixed, open a pull request and i will help you fix it but i'm not wasting my time with an issue that i didn't personally have an investment in. was i being a jerk for doing that? maybe, but my own personal serenity was worth more to me than pleasing you.
i think every open source author starts out with this fire in their heart to make the software world a better place for everyone only to get beaten down by every moron out there. when you are getting paid to do something, you put up with the idiots in your life (how many of us are still at the job that pays well, but HATE the people there?), but when you are doing it on your own time and not being compensated for it, what's the point?
i applaud this dude for doing what he did. i hope his actions has put the people using his project in a position of panic to the point where they reflect on how they treat people and participate in the open source community. pain is the only way we learn and change things about ourselves. i hope the people who caused the author to quit open source change the way they treat people in the future.
Maybe it's because I work on more niche projects, but every time someone contacted me about an issue in one of my repos they were always exceedingly apologetic about "bothering me". My projects only have ~400 downloads per month, so I'm sure it's a matter of sample size. If anything, working through issues with the community has made me enjoy the work more.
For context, this comes after yet another unsoundness bug has been found in Actix-web. Normally people in the Rust community don't get very worked up over these because we know that everyone makes mistakes, but the Actix project has had a consistent history of introducing unsoundness through the use of unsafe for dubious reasons like nebulous performance increases or bypassing Rust's safety guarantees (which is what this last one was about). Furthermore, when someone raised this issue and provided a patch to fix it the actix-web maintainer called the patch "boring"[1]. He also censored comments that talked about the unsoundness and eventually deleted the entire issue. This sort of behavior should not be acceptable from any open source maintainer that runs such a large, foundational part of the ecosystem.
I completely disagree with your last sentence. Think of actix-web as a gift to the world (and judging by its popularity, a very nice gift). Being verbally abused by vocal majority of freeloaders would drive anyone furious.
I think I understand your perspective, though. It would benefit the community to have projects of great importance properly maintained. How to ensure it? Well, by paying people to do it, not necessary developers but active project mantainers. Only then you are entitled to complain about somebody doing a lousy job. To sponsor it, introduce micro-transactions for dependencies.
Obviously being vocally abused is not OK no matter what the victim has done. This is a big problem and I think Steve's article that is currently on the top page of HN gives a good overview of that part of the situation.
My problem with viewing all open source as a gift to the world, take it or leave it, is that when people create open source packages, market them as being ready for production use and as the best option for said production use, and then act unprofessionally towards security issues and reject patches that fix the security issues for no reason other than being "boring" and "not creative enough" people should be able to call them out on it as unacceptable behavior for an open source maintainer. If actix didn't claim to be production ready and instead stated that it was an experimental code base designed to advance the state of the art in web server performance I wouldn't have a problem with how it was managed. However, once you claim that something is production ready I think you need to be ready to take responsibility for it.
You say, "This sort of behavior should not be acceptable from any open source maintainer that runs such a large, foundational part of the ecosystem."
Or what? What's the "punishment" here? Who's going to decide what's acceptable, and what's not?
Seems like you are demanding that the author of Actix do what you want.
Sometimes people take their football and go home. In this case the vocal complaining minority are free to make their own copy of the football, and proceed on their own...which is also known as "put up or shut up".
>Actix project has had a consistent history of introducing unsoundness through the use of unsafe for dubious reasons like nebulous performance increases or bypassing Rust's safety guarantees
sounds like the author had specific strategic vision - "push the boundaries" - which he clearly explained, and there are other people who don't agree with such an approach, both are valid positions in their own right, and instead of being jerks and trying to shove their approach down the project owner's throat these other people should have just started their own project reflecting their more conservative approach.
It is like those people who try to push Linus to use C++ and do other funny stuff in the kernel - one should go and read Linus' responses to the people like these.
"Quite frankly, even if
the choice of C were to do nothing but keep the C++ programmers out,
that in itself would be a huge reason to use C.
[...] I've come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really would prefer to piss
off, so that he doesn't come and screw up any project I'm involved with."
> but the Actix project has had a consistent history of introducing unsoundness through
Then you can stop using Actix and create a better project or fork it and fix these unsoundness bugs and call it ActixSound. I do not see the point to rally up the crowd and raid his Github in the name of soundness. This reflects poorly on the Rust community.
I’m not sure why people are so fork-shy. Forking is the greatest gift of open source. It’s basically the point and the core of what it means to have software freedom. I think the anxiety around forking is unwarranted, especially in scenarios where the author clearly has divergent goals and values from a large number of people.
It seems the forest has been lost from the trees: exercise your freedom, fork, and let diversity lead to longevity. I think a lot of the aversion is because forking and fragmentation is messy. It doesn’t surprise me that the Rust community in particular would abhor such disorder :) (see the JS community for a counter example.) But such disorder is a key element of so many good human systems, like democracy and free markets. Better to embrace them and relish the freedom they bring, than dive deep into conflict with others only due to imagined chains binding you together, chains deliberately lacking due to the selfless altruism of the project creators who bound their work to a free software license, to whom you should be thankful, not resentful.
This whole issue is confusing to me. It's like no one ever heard of fork. It's hardly mentioned in the comments. The author owes people what they paid him to do, which is nothing. If he wants to go unsafe and fast that's his business. I don't have to ride with him. I can make a copy of his car for free and drive it the way I want.
I think this is a case of the end justifies the means. The end: get the maintainer to change his code the way I want. The means: bully and abuse him to force him into it because that sometimes works.
At some point open source got morphed into being about free as in beer and gratis volunteer work by generous souls. But its origin and what the licenses themselves are about are freedom to read and freedom to modify. The entitlement that has crept in and the social contracts that seem to have formed around expectations for people writing Free code are concerning.
Shame on people who forget this, and demand more than those freedoms from authors who so generously grant them to others. Based upon what I’ve read, I would have checked out from this project as the author well before they did given the harassment they’ve apparently been getting for not merging PRs into their repo.
I'll save this link for the next time someone tries to argue that the Rust community is somehow "more welcoming" than some other X community.
All internet-based communities contain some assholes. All of them. Sadly some maintainers don't seem to have the werewithal to tell them to go away. I mean, when you get "asked to change coding style", it's the time to put the banhammer down, because there is no way to please these people without humiliating yourself.
> I'll save this link for the next time someone tries to argue that the Rust community is somehow "more welcoming" than some other X community.
It's deeply disappointing to see this outcome (and r/rust is literally divided into two halves on this drama at least for now, ugh), but I believe it is the statement about the average atmosphere. Not that I have an argument for or against the refined statement, but it doesn't automatically get rejected with a single counterexample.
Nah, it's just the usual delusion of small-but-growing communities. The Python community was great in 2001, a bit less so these days. The Lisp community was probably great at some point in the '70s too. It's just that, with size, the likelihood of attracting undesirable elements inevitably grows until their presence simply cannot be denied. At that point, you either deploy heavy-handed moderation and get branded "unwelcoming" by the assholes, or leave it free for all and get branded "unwelcoming" by the most sensitive not-assholes. Then someone or something will spawn a new community, and the cycle will repeat itself.
This process is basically inevitable, and it has been observed in internet communities for so long that it's basically a science by now. It's just the nature of the (human) beast.
He wouldn't have had the attention or the criticism that he got if it hadn't been so impressive. I think when something's good enough, people may actually criticize more freely. Some of that is because the project becomes worth the scrutiny. But some of it is also a status thing. If your work is good enough to give you a high enough status, you change categories a bit in peoples minds. They start to criticize you in the way that they'd criticize other entities that seem strong enough that they don't need to be protected any more.
I hope that the actix ecosystem can stick around and keep moving forward. But even if not, I think fafhrd91 made impressive contributions and I'm glad to have used and learned from his work.
I've been using actix-web for my work for some time, contributing however I can while learning Rust and myriad other subjects. This was the third major public event involving controversial design and implementation decisions. A great number of people in the Rust community have refused to accept that not everyone subscribes to their ideology about use of unsafe. They've repeatedly tried to impose their values and priorities upon someone who has been more than capable, if not more capable, of reasoning about legitimate issues and risks and who has his own priorities. The author has not been kind towards those who challenge his decisions, and this has not helped him navigate social issues. It's not just that he struggles with English but has a very different value system and set of priorities than those who he's had to interact with. Further, these contributions weren't from neutral parties but rather a group of long-term adversaries who have taken it upon themselves to hold Nikolay accountable for having differences. They blog, they control the narrative in message forums, they basically do everything in their power to cancel Nikolay and his tremendous work, shaping the public narrative as one that suits their goals.
It took great strength to go as far as Nikolay did in spite of these challenges. I understand why he doesn't want to participate in this culture any longer. It comes at a great cost. Unfortunately, the actix projects and its author are not the only ones who have been targeted for having differences. The next example is Ferrous Systems, who have authored a new ecosystem for asynchronous development. The team has been attacked in all sorts of ways and are going to great lengths defending themselves and to help shape the public narrative. Eventually, they will tire from constantly defending their decisions. Some will lose their patience and tempers will flare. Then, an angry mob will re-emerge and do everything in its power to cancel the momentum of their work and attack the reputations of the authors.
I don't know whether this social behavior will change without the culture changing as well. It requires a respect for viewpoint diversity and acceptance of people unlike ourselves, not just in gender orientation but in opinions and values. It includes tolerating disrespect and leaving people alone rather than trying to destroy them. I doubt these social issues are unique to the Rust community. Cancel culture seems to exist in all shapes. We aren't better for it.
I remember when I was young and “diverse opinions” was a phrase as celebrated as “diverse backgrounds” is today. Why we had to lose the former while (rightfully) recognizing the value of the latter is beyond me, and without both we will surely continue to descend into continued tribalism, but of a different kind.
There are only 2 outcomes for Rust not having unsafe blocks:
1. Everything would be unsafe. Same as C/ C++
2. You could not use it to write real software, because not all constructs are expressible in safe code. The std lib requires unsafe to a bigger extend. Talking to the OS does the same.
Unsafe blocks are required to write software. And they are good, because they minimize the amount of code which can not be automatically audited by the compiler.
Unfortunately unsafe blocks seem to get more and more misused as a metric around the quality of software. Which is certainly not their intention.
I am a Rust beginner, and have made a few small projects with Actix Web. Actix Web is the only framework I use in Rust and spent some time learning about it. During that learning process, the docs constantly get updated but there are examples in the repo. Sometimes there aren't examples and I go to their chat room and ask the maintainer directly, and to my surprise, he always answered my question.
He is a busy guy with a life that already put immense effort to create this library and helping people to use it. He is free to do whatever he wants. People who complained, did they even give him thanks? Or donating coffee money? Grow up and stop spending your SWE salary for your vices.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
This is part of the MIT license. Many other open source and free software licenses contain the same thing. It's simple, people provide software they write in their free time or "sponsored" by their company, in return they get nothing and you should expect nothing more than the piece of code that gets published.
People have started assuming that free and open source software is not "true" open source if you don't build a community around your project, gain a following and can take advantage in it professionally somehow.
It's a shame, as it puts a lot of pressure on people, instead of all of us just sharing code because we love coding and want to share it with everyone who also loves it.
> Community: The best things in life are to be shared
> Join us - Want to talk to others about questions? The actix gitter channel or reddit community are your best starting point.
> If you think you found a bug it's best to go to the github directly. There are two repositories that you might want to report against. actix for issues with the actor framework or actix-web for the high level web framework.
> We're a welcoming community so don't be afraid to engage. Interactions are governed by our code of conduct.
I agree with you that projects aren't required to do this. (And I also agree that developers often feel pressured to build up a community for their project.) But still - that's what they wrote.
True, they did write that. But taking into consideration the license open source and free software is usually licensed under, they are free that change those opinions at any time, and you cannot blame them for it.
If you had a contract with the project, I would understand the frustration. But since it's published on a "NO-WARRANTY" and no promises basis, the persons opinion can change at any time, and that's perfectly fine.
So maybe today I feel like, yeah, my open source project should have a community! So I publicly write that. But then 6 months later I change my mind and stop trying. This is also perfectly fine. Annoying, sure, but if you want to avoid that, start making contracts with the libraries that you include in your projects.
I'm on board with your general message, however, the larger actix isn't some independent project. It is clearly endeavored to build and serve a community. And maybe that wasn't the intent of the author/maintainer? I don't know. But I'm going to tell you right now that if you don't want to be part of a community (for better and worse) the best plan is to not join one, especially not one that proselytizes itself in a way similar to many commercial/oss hybrid outfits.
I don't mean to condone people being jerks or the typical reddit brigading that is being talked about. It's just, it doesn't really matter what your license says. If you act like you're going to serve customers, you just might get some customers and if you can't deal with customers then you probably shouldn't act like you want to serve customers.
It's perfectly fine to build a project in the open and license it openly and not accept open participation.
> But I'm going to tell you right now that if you don't want to be part of a community (for better and worse) the best plan is to not join one
Well, you can want to be a part of a community one month, and not the other month, which is fine. We have other stuff going on in our lives too.
> It's perfectly fine to build a project in the open and license it openly and not accept open participation.
It's also perfectly fine to build a project in the open, license it openly and try to push for open participation, but later change your mind and not do that anymore. As mentioned, open source comes with no guarantees, what so ever. Let's keep it that way.
> Why not just leave them in place if you're burned out and see if anyone is willing to take over maintainership.
Because a proper hand-off is also a lot of work, which continues the burn-out and the chances of a new maintainer stepping in are slim-to-none (there were already attempts to find one after the last "actix unsafe discussion").
The entitlement in this thread is astounding. Don't like how the project is maintained? Fork it. If you don't have anything nice to say to the person who gave you the code _for free_, then just don't say anything at all.
Especially weird seeing as Github has made forking a very smooth way to work with a project. You fork it, make the changes you want, and then make the changes available upstream.
If upstream vanishes, your fork is still around.
If upstream doesn't want to merge, people can use your fork instead. And, if your changes are that much better, eventually make it the de-facto standard version of the project.
Yes, and it happens all the time in other projects. There's always "so-and-so's fork that implements feature X and changes Y", and it's awesome that that's a possibility since it means no project is held hostage by its maintainer, and that differences in priorities don't mean the code can't be useful for a range of use cases.
The commits you do in a fork are not visible in your GitHub commit calender until you do a PR and they are merged. For some people this is important so a "forked" project won't have many commits with merging back to master.
Edit: I was not aware he moved it under his personal github account and it’s still accessible.
Nonetheless, I still think removing it is a bit extreme.
This argument confuses and saddens me. If I give away free food which I and others know to be contaminated with foodborne pathogens, is it wrong for them to criticize it? What if I don't know, but I obtain it from a supplier which is known to persistently sell contaminated food? What if I put up a sign in very small print saying that the food comes with no warranty whatsoever and all consumers eat it at their own risk? What if I put up a large sign? What if instead of pathogens, I intentionally add lead-based decorations on the basis that they look and taste good, even if they may be slightly carcinogenic if consumed? What if I clearly state that the decorations must be removed before eating? At what point do I acquire moral culpability for the harms suffered by my customers? These sorts of comments seem to imply that there is no problem with me doing any of this, as long as the food is provided for free and consumers have the choice to not take the food. I would vehemently disagree with that claim. Uninformed choice is not a true choice, and even informed choice cannot excuse certain foreseeable harms.
That is an entirely specious analogy. This code will not cause someone to get sick or die. And "contaminated" vs. "not contaminated" is a binary result for food -- one is the case and one is not the case. With code, there's nearly always room for reasonable disagreement as to what is the right/good or wrong/bad way to do things, and often people argue over two (or more) perfectly fine ways of doing things that just come down to a matter of style.
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
So if some random person on the side of the street gave away browny, and had a sign like that, I'd do a bit of personal investigating first before eating it, like looking at the ingredients, asking for expiry, and all that. Which you can do for open source software, by just looking at the source code.
There's a difference between leaving poisoned but attractive looking food on a sidewalk, and putting code on github. You're losing perspective regarding open source programming -- it's supposed to be fun. There seems to be a political / ideological dimension to this disagreement. Your nanny state would be correct to punish someone for leaving poisoned food out. But we don't need your nanny state in open source software. People can choose to use or not use free software. Anyone whose software has life or death implications would indeed be culpable if they make those choices rashly. But the responsibility does not lie with the maintainer.
Being a maintainer on a popular open source project can be hard. You put expectations on yourself, others put expectations on you, people complain, people trash talk you because they think they can do it better, and so much more.
I think this highlights that maintainers need support systems to help with this. We can use GitHub features to mute or block people. We can have CoCs and try to avoid people who cause issues. But, they still happen and maintainers need help. Someone to talk to, people who have been there, support groups, strategies, and sometimes sabbaticals.
I feel for this guy and hope some time away will help him personally.
We did this to him. [1] We drove him to burn-out. We should reflect on that and make sure we don't ever do that again to any open-source maintainer. And we should pay more of them for their work.
[1]: Including me, as I contributed to a comment thread here about cheating on benchmarks.
I can completely understand how he felt. Similar things happened to my open source projects, admittedly at a smaller scale. Users became so entitled to open source software and became hostile. Well, i nipped the problems at the bud by moving the projects off open source license. There were a few people crying foul and vowed not to use it. Fine. I respected their choices, and let's move our separate way.
There're requests to open source and hand the projects to someone else. No. I want to maintain control of the project development and direction, like directors wanting to maintain artistic control over their movies. If someone is so fired up, they can always write their own open source software.
would you have declined a patch that fixes a real problem because it is boring? i do not really get that kind of thinking either. personally i would have accepted it and replaced with something clever latter on
Yes, I would. Because that patch is a "style" patch. It's not important in the author's roadmap for the project.
People ask for different things and think their things are the most important, and when they don't get their way, screaming and kicking to force them in. They can always fork it or create a separate project if it's so important.
An argument could be made both ways, but I wish people stopped quoting licenses to resolve social issues.
For example, the license does not forbid the user of the software from INSINUATING THAT THE AUTHOR OF THE SOFTWARE IS INCOMPETENT, OR UNFIT TO AUTHOR ANY SOFTWARE, EITHER IN A PARTICULAR LANGUAGE OF THEIR CHOICE, OR IN GENERAL. So one can almost say that anyone who's doing it is exercising their right granted by license.
...But that kind of argument is not really helpful, isn't it? The question is whether some behavior is socially acceptable. License doesn't enter the question.
(BTW, of course I don't support the kind of behavior I endorsed(?) above.)
> ...But that kind of argument is not really helpful, isn't it? The question is whether some behavior is socially acceptable. License doesn't enter the question.
> (BTW, of course I don't support the kind of behavior I endorsed(?) above.)
Let's say someone wants to release some open source software to the world. But they also want to retain the right to remove their currently published copy at any point, their right to reject patches and generally do what they like without being slurred and berated by everyone else.
Aside from adding a plaintext file alongside the code that explicitly says (sometimes in capital letters!) that the code is supplied with no warranty or obligation, explicitly or implied, what should they do?
Isn't it clearly the case that the license explicitly states the social contract?
Closed source is more fun to develop. You get full control over your code, you just have to meet the needs of people who think it is worth enough to pay for it, you can code in whatever eccentric manner you want, and you get to keep the nice wads of cash if it becomes successful. If security is a problem, then the people with wads of cash will leave, but at least there is some incentive there.
I would advise people who decide to embark on large, hard projects like this to stop making them free. Make the source open if you want, but charge money. Either for the product, or for support requests, something. This not only filters out entitled assholes, but it gets you money, money that you can maybe use to pay people to help, or at least to buy a beer.
This is an unfortunate conclusion that I also arrived at after much consideration. I have a proposed dream project in front of me that would take at least 2000 hours to reach MVP. Do I just give it away for free on GitHub under MIT? I spent over a decade honing the skills that allow me to even engage with such a difficult objective. Why should I just give it all away unfettered? What alternative approaches exist in which I share these wonderful new ideas openly and also somehow reap the benefits?
I feel that for certain projects like vendor API integration libraries, opening up the source for all to use freely is the best path. But for others, where years of intellectual property and personal development exist predominantly within the code itself... I think I want to keep this kind of code to myself for now.
Asking for a friend - could someone explain what happened there? The README doc is quite vague - it is more of a personal justification than a rationale (to me).
Sounds like the maintainer writes a lot of code using rust's "unsafe" keyword, and regularly gets issues raised about this (and versioning, and some other bits).
This last issue, which included a patch, has pushed them over the edge after it descended into disagreement.
Net/net they were repeatedly asked to change coding style, didn't want to, and have decided it's better to just avoid the arguments by not publishing code.
The issue was triggered by someone executing a benchmark on http crates and opening an issue on github, that was then deleted after some heated back and forth.
Wow. Talk about a bad response though. No matter how abused you may feel as the sole maintainer you should still not throw a tantrum. Censoring an issue title, body, and comments is a gross overreaction. If you want to throw in the towel then just throw in the towel.
It seems like the overarching issue is that Rust is a house of cards. They added unsafe like Java has null. My favorite part is that you can declare a crate to forbid unsafe, but that then doesn't have to hold for it's dependencies.
The obvious implementation is for unsafe to be infectious like const. You have unsafe code, your crate is unsafe. You depend on an unsafe crate, your crate becomes unsafe.
> The obvious implementation is for unsafe to be infectious like const. You have unsafe code, your crate is unsafe. You depend on an unsafe crate, your crate becomes unsafe.
That would mean everything is unsafe, since every crate depends on core (or on std which depends on core), which has "unsafe" code.
The design of "unsafe" in Rust, instead, is to allow building safe abstractions on top of unsafe code (or be able to clearly mark when the abstraction itself is unsafe). That way, for instance, users of `Vec::push` do not have to worry that it uses uninitialized memory (which is unsafe).
This is a poor comment. You clearly don't understand how unsafe is to be used. No code (of significant size) that you run will be bug free ever. So you might as well start from that assumption and realize you are trying to minimize the amount of unsafe code and bugs; you will never remove all of them no matter what the language.
Using unsafe doesnt necessarily mean you will have undefined behaviour, it just means you have to think really hard about the behaviour because the compiler won't have your back.
I wish there was a better way of handling that in Rust. You should be able to have a few markers in your code:
- uses unsafe
- no unsafe, but dependencies may use unsafe
- no unsafe, no dependencies except the standard library may use unsafe
- no unsafe, not even in the standard library uses
The current situation is the second one, but many cases probably want the third, and occasionally the fourth.
The best part is, this should be fairly easily solved by crates.io upon submission (is there any use of unsafe and are all dependencies marked as strict or more strictly than yours?).
Concerning is what message this sends to other OSS developers. One goes into F/OSS knowing full well there will be little rewards financially - but facing harassment or attacks on their reputation cannot encourage future projects.
Is it too late to set up a SafeActix project, let him keep the Actix name & creative control, and resolve things semi-positively? Seems like the community mistook it as an effort to build something safe, and it was a thousand cuts of misconceptions/asks. Maybe open an issue and give them a week to decide/vote a new name. I don't think there's an obligation per se, it would just be better.
To me, this displays a deep misunderstanding of FOSS on the part of this projects maintainer. He wants to create a project, promote that project to the top of it's field, and completely ignore the perception of his userbase. Then he fell back on "it's my code I'll do what I want with it." That would be fine, but he "sold" people on this code with the understanding that we were all going to take it to it's maximum potential. This was marketed as something which would solve specific needs better than similar products. Most people can handle regression and bugs and regular ongoing refactors as everyone struggles to bring this same piece of code to the next level. What people, especially the dev community, cannot overcome is when they are told that a project has a direction that it clearly doesn't have. If this maintainer had no intention of accepting feedback from his users there should have been a clear indication of that somewhere in the docs.
If you never reconcile your reasoning and expectations with your community then they will deduce reasoning and expectations that you never implied. This maintainer wanted to produce a popular piece of software not to contribute to the Rust community, or because he wanted to make lives easier. This isn't the attitude of someone who is trying to improve his skills or challenge his knowledge of Rust. He obviously didn't do it to get rich. I believe he made actix-web to get famous. He wanted blind recognition for being selfless. He wanted a community of docile dependents who sit up late on GH hitting the refresh button waiting for his next push. He seems to have only wanted to make a product that people revered. When that didn't happen because he never reconciled his goals with the communities expectations he took his ball and went home. "What??? No fame? No glory? Criticism!?!? Fine, no soup for you."
Sad to see this. I'm using Actix in a new project and have been watching the project for a while. Guess I'll be refactoring to use Hyper. If I were farther along I'd probably try to take ownership, but it doesn't make sense given that it's only around 40 LOC in my project that depend on Actix at this point so switching out to another framework is more straightforward than taking ownership of a codebase I don't know.
I understand fafhrd91's (the maintainer) frustration, but it would have been much better to just abandon the project and throw it up for some other volunteer to come in and take it over. Then the project can live on and he can bask in any success it has in the years down the road. Instead, it's a complete mess where all the good work and good will has been undone in a single move.
I've abandoned multiple OSS projects over the years and let other maintainers come in and take them over. Now over 10 years later I can still say I created that project that still gets used because other people have seen value in continuing to contribute and maintain it.
Agree 100% with the maintainer, read some of the comments on /r/rust and on Github, I haven't seen a more rude sanctimonious community in my 12 years programming. Holy shit!
Check out their official channels. Anything on reddit is going to be toxic unless it is highly curated by the subreddit mods. That's just the reality of reddit.
People should really learn to ignore the emotional channel of the comments they receive. Just try to figure out if the message contains any useful information with a quick glance, extract it if it does and ignore the rest. People have to shit - that's physiologically inevitable, and there are people who do it in the streets and there are people who shit in comments/messages. Why take them serious?
> I used to do tech support and some people (not too many) wrote right out rude or nonsensical (like concluding I hate their religion just from the fact our service failed to suit their specific needs).
This isn't at all the same thing. You were paid to do your job, and at the end of the day you could just joke about those weirdos.
When working on an open-source project, everything becomes much more personal because your motivation is fuelled by your own personal attachement to the project. Imagine you're helping elderly people cross the street every day, and every once in a while they yell at you for not doing it better, whatever that means. At some point is it still worth it?
And of course you can't just put that behind you once you're back home, because this abuse happens at home. I remember this time where someone literally told me to kill myself while I was fixing a bug - at midnight - in a project I handle. Or the time I woke up only to see that during the night someone public had decided to openly send me literal fuck emojis on Twitter to right a perceived wrong. Good times.
So yeah - building a shell is the right solution, but it's hard and we really shouldn't have to deal with that in the first place.
I get you point, it makes sense, but I feel like I personally have already grown over that and everybody can: just know what are doing the job for. Are you helping the elderly to get their gratitude? No, just because I'm doing the right thing and I know some of them are jerks because loosing their sanity to Alzheimer's and because of hard life they had. Are you maintaining a free project for users' gratitude? No, I do because it's fun, because it expands my experience, fulfills my own needs, improves my CV and because I'm glad if somebody can use it for good. Never expect a reward if it's not guaranteed in the first place.
For some reason lots of people on HN push stoicism as a virtue. Not all of us are 100% unaffected by dealing with jerks, and we like to get ourselves out of toxic environments that make us unhappy. Is that so bad?
The value in stoicism is that it lets people transcend limitations they have control over. It's a tool and comes in many packages (e.g.: "God, grant me the serenity to accept the things I cannot change, Courage to change the things I can, And wisdom to know the difference.").
Lots of "people on HN push stoicism" because a great many people in all walks of life share life lessons that can be categorized as stoic.
>Not all of us are 100% unaffected by dealing with jerks, and we like to get ourselves out of toxic environments that make us unhappy. Is that so bad?
This is reductive. If you were to undertake a real appraisal of the ideas with a goal to separate the wheat from the chaff, as well as feel out the boundaries of what is often presented as blanket advice (rather than try to get one over on "people on HN"), the advice people are trying to offer would make more sense.
You obviously have never participated in open source and are talking about something you had ZERO experience with. Go participate in a toxic open source community for a couple of months and report back about not only the experience but also you emotional well being. I can guarantee you'll be reading your comment and cringing at what you once wrote.
btw, there is and awesome life lesson in this comment i posted, if you can remove the emotional part of it ;)
Now I consider your message a puzzle and am curious about what awesome life lesson have you hidden in it. I am going to re-read it over and over again :-)
> People have to shit - that's physiologically inevitable
I don't think that's universally true. In fact, I think there's a handful of people who don't know how to treat others like human beings and a lack of accountability for their behavior online.
The fact that there is a thing true of open source---it's a harbor for toxic cultures where people aren't held accountable for talking to each other like garbage---doesn't mean we need to just accept that or look the other way. As this situation demonstrates, toxic culture has costs.
Quite easy to do once you realize you can, adjust the mindset and have some practice. There probably is a lot of garbage in your spam folder - do you take it seriously?
I used to do tech support and some people (not too many) wrote right out rude or nonsensical (like concluding I hate their religion just from the fact our service failed to suit their specific needs). I would just answer such sort of robotically (if their message contained a question which made any logical sense) or ignore them (despite I generally am extremely compassionate and always do my best to help).
Have you ever looked at a glass of a window rather than at an object behind it? Just don't focus on the idea there is a person hating you (there are much more people loving you, by the way, even if they don't write you), instead focus on the fact you are viewing a string which only contains garbage data.
Go to an anonymous image board and look at people writing things which would be unimaginable to see here. Write some yourself perhaps. That can make a nice practice quickly.
I agree with you. Really it is something that probably can be learned over time. I think it helps a lot to just remember how much money this or that dumb hater have paid for their entitlements (i.e. nothing), which -at leas in my eyes- emotionally reduces their words to a child's tantrum.
Sure, but it helps more to realize once and forever: all the shit anybody says is just a "child's tantrum". Real grown-ups don't behave this way, too many people just don't grow up as they age.
"The thing is that, of course, there are totally different ways to think about these kinds of situations. In this traffic, all these vehicles stopped and idling in my way, it’s not impossible that some of these people in SUV’s have been in horrible auto accidents in the past, and now find driving so terrifying that their therapist has all but ordered them to get a huge, heavy SUV so they can feel safe enough to drive. Or that the Hummer that just cut me off is maybe being driven by a father whose little child is hurt or sick in the seat next to him, and he’s trying to get this kid to the hospital, and he’s in a bigger, more legitimate hurry than I am: it is actually I who am in HIS way.
Or I can choose to force myself to consider the likelihood that everyone else in the supermarket’s checkout line is just as bored and frustrated as I am, and that some of these people probably have harder, more tedious and painful lives than I do.
Again, please don’t think that I’m giving you moral advice, or that I’m saying you are supposed to think this way, or that anyone expects you to just automatically do it. Because it’s hard. It takes will and effort, and if you are like me, some days you won’t be able to do it, or you just flat out won’t want to.
But most days, if you’re aware enough to give yourself a choice, you can choose to look differently at this fat, dead-eyed, over-made-up lady who just screamed at her kid in the checkout line. Maybe she’s not usually like this. Maybe she’s been up three straight nights holding the hand of a husband who is dying of bone cancer. Or maybe this very lady is the low-wage clerk at the motor vehicle department, who just yesterday helped your spouse resolve a horrific, infuriating, red-tape problem through some small act of bureaucratic kindness. Of course, none of this is likely, but it’s also not impossible. It just depends what you want to consider. If you’re automatically sure that you know what reality is, and you are operating on your default setting, then you, like me, probably won’t consider possibilities that aren’t annoying and miserable. But if you really learn how to pay attention, then you will know there are other options. It will actually be within your power to experience a crowded, hot, slow, consumer-hell type situation as not only meaningful, but sacred, on fire with the same force that made the stars: love, fellowship, the mystical oneness of all things deep down.
Not that that mystical stuff is necessarily true. The only thing that’s capital-T True is that you get to decide how you’re gonna try to see it."
I very occasionally get death threats to my work email due to people being unhappy with some public facing stuff I do. It's unsettling but I can mostly ignore it. But if it happened all the time and I wasn't able to open my email or interact with a community without getting hate mail I'd go into a cocoon. People aren't machines. When hatred is relentless it is unbelievably difficult to put it aside.
Should they ignore the negative parts or should people who comment be mindful of the fact that a lot of open source they use is created in someone’s spare time and that they have a human being, not a company? I’d think the latter.
Sure. Both should but that would be naïve to expect the others to do. I write "people should" putting myself in place of the protagonist. Going to the woods don't make drama of the mosquitoes biting you.
A web server built on an actor framework and probably the fastest Rust web server out there for many use cases.
I used it because it was easy to fill my niche case (TCP + UDP + WebSockets + HTTP interfaces to the same thing) as well as my boring CRUD apps, and it worked on stable Rust since a long time ago.
The author got a lot of flack for using "unsafe", then fixed most uses of "unsafe" and it has become something of a meme now. Unfortunately, there's an odd, almost religious crusade against unsafe in the Rust community, especially by those who don't really understand the ramifications of using unsafe incorrectly or how to tell whether unsafe is being used correctly.
It's a cool project and I have loved using it. I'm probably going to use something else unless someone steps up with a commitment to maintaining a fork.
It's funny to see history repeat itself with "Unsafe" hooks. JAVA has a number of projects which also do this for speed and it always freaks people out.
I advise that you take some time away and either hand over the project or continue as its leader. Dont let the autistic assholes on the web get to you.
There are plenty of repository clones, that's not the issue. The issue is that people want to contribute back to the same repository so you don't have to figure out which project is the just up to date. When a project like this goes away, it takes some time for everyone to figure out which fork is actually being maintained properly.
The best course of action, IMO, is to state that you're stepping away, perhaps indefinitely, and ask if anyone wants to be added as an admin to take over. That's not required, but it's a nice thing to do.
I'm sad about this on a lot of levels, any I hope the maintainer does what I'd like, but if not, I'll just wait a few months and see how the dust settles. For now, I'll probably go back to investigating other projects.
> and ask if anyone wants to be added as an admin to take over.
That's the worse possible course of action, this is how you get RCE vulnerability or bitcoin stealing malware injected into a popular project. Other random people should not be able to take over any project, they should do the work to promote their own fork and gain their own reputation. At least until we have a language able to protect from threats like that.
One of the downsides to GitHub is that it stores a lot of state that Git cannot capture, and is at the mercy of project maintainers to continue existing unaltered.
In case you're directly impacted by this, https://www.arewewebyet.org/topics/frameworks/ provides a list of web development frameworks for use with Rust. Just pick one with a less cowboy-coding oriented attitude than Actix-web, and you should be OK.
Like it or not, it's best to view this incident as having direct parallels to the NPM left-pad incident.
Ignoring the specifics of what led up to this for the moment, observe that a single person was able to completely annihilate an entire dependency's source.
I think one of the primary requisites to reliable FOSS development and adoption will need to be tooling that maintains immutable records to the best of its ability, so that prior artifacts cannot be revoked; you publish code as FOSS, it is with the clear understanding that you have disposed of your authority to revoke it.
There are cases where something may need to be revoked, but make it a multi-layer process at that point, not a single button and one man's whim.
"Ok... So that was unprofessional. If you don't want to maintain a project anymore, you give it to someone else and link to that repo in your README.
This just screwed me over big time."
https://github.com/actix/actix-web/issues/1#issuecomment-575...
These kind of entitled attitude is probably exactly why the guy just removed everything.
More details / discussion here: https://www.reddit.com/r/rust/comments/epszt7/actixnet_unsou...
It's absolutely correct that people don't have obligations simply by putting some code online. But they do have obligations when they start telling people to use their code. We understand this as humans even in realms far from open source: if I see you approaching a door, I am under no obligation to open it just because I'm physically able to, but if I open a door for you, I'd better hold it until you're finished walking through, or I'm a jerk. By holding the door open, I've made an implicit promise that I'm not going to close it on you.
It's not very hard to say, this is a project for my own technical interest, I don't intend to follow Rust norms about use of unsafe, and you shouldn't rely on it, but here's the code if anyone wants to look. That's fine! (And I do think we need to be better about making it common to do that. GitHub has no good tooling for such a repo, for instance: you can't disable pull requests unless you archive the project or make it private.)
But that's not what Actix's docs say. See https://actix.rs/docs/ for instance: there's nothing to the effect that you shouldn't use or rely on it, and everything to the effect that you should. (In case that page gets taken down, it starts, "Actix is your door to developing web services with Rust and this documentation is going to guide you.") On https://actix.rs/community/ it says you should report bugs to GitHub, implying that bug reports are in fact welcome, and there isn't a single statement that the project goals prioritize the author's technical excitement over correct code.
Again, there's nothing wrong with wanting to prefer your technical excitement over having bug-free code. Just be clear about it.
> if I see you approaching a door, I am under no obligation to open it just because I'm physically able to, but if I open a door for you, I'd better hold it until you're finished walking through, or I'm a jerk. By holding the door open, I've made an implicit promise that I'm not going to close it on you.
This reminds me of an incident years ago. I was on a city bus, very full of people, and we were just about to leave a stop. There's a woman maybe 150 feet away running towards the bus. The driver sees her running and re-opens the door, waiting. Inconvenience to all of us on the bus, but hey, she's running.
The woman, seeing the bus has waited for her, stops running and starts slowly walking instead.
Driver sighs, closes the door, drives away.
I'm not sure what the moral lesson I take from it is, but mainly "if I go out of my way to help you, don't take advantage of my generosity". Maybe that partially applies to situations like this one. Or maybe just "don't annoy transit operators". That's a good one too.
23 replies →
He held the door open for a lot of people. Some people spit at him as they walked through. He doesn't want to hold the door open any more, he's done it enough. He didn't sign up to be a doorman for life.
16 replies →
> It's absolutely correct that people don't have obligations simply by putting some code online. But they do have obligations when they start telling people to use their code. We understand this as humans even in realms far from open source: if I see you approaching a door, I am under no obligation to open it just because I'm physically able to, but if I open a door for you, I'd better hold it until you're finished walking through, or I'm a jerk. By holding the door open, I've made an implicit promise that I'm not going to close it on you.
Exactly.
Like it or not, there are implicit social contracts if you maintain OSS software.
Yes I've read the birdseed of the various licenses.
I know this will whip up the oft-suffering maintainers and developers in here. But this is the exact kind of trope that stymies wider FOSS adoption.
The artifacts of these little meltdowns are exactly the kinds of things your upper management will cite the next time you suggest using FOSS vs. whatever vendor they're about to push down your throat.
Ignoring security conventions, and then adopting a "take my ball and go home attitude" isn't a ringing endorsement for adopting FOSS, unless it's run by a large entity.
I'm not saying the author should have to endure abuse or harassment, but consistently pushing unsafe code into a web-framework, being cavalier about trivial and widely accepted coding conventions, and dismissing patches as "boring" is exactly how you end up with NPM Ecosystem v2
13 replies →
If some one opens the door for you that was nice of them, they did your work for you, they have no ongoing obligation to maintain the door in an open state.
If some one give you their code that was nice of them, they wrote your code for you, they have no ongoing obligation to maintain your code.
by simply giving you their code they have already provided you with value, a head start for nothing in return, they have opened the door for you, the rest is up to you.
9 replies →
Well put. I’d add on to your metaphor: slamming the door on someone is quite different than just not holding it open anymore. The second is totally acceptable; the first is impolite.
1 reply →
If someone is relying on your code, that means they have their own copy of it.
You're not obligated to keep your copy online.
2 replies →
They're right, it was unprofessional... but since the maintainer is not being paid this is not a professional project. It's a personal project. And this seems like a perfectly personal thing to do with something that's preventing happiness.
I absolutely agree with this. The author has spent an insane amount of time to build all this stuff and instead of getting recognition and/or being payed adequately he is getting shitstorm after shitstrom.
As an outsider I have to say that I think what the Rust community has technically achieved is remarkable. But on the social side it is not so bright, avid Rust users constantly spam forums of other programming languages with toxic comments. But this incident shows that the situation is even worse than expected, the Rust community even treats its own peers like sh..
4 replies →
Well, it's easy to get confused when you look at the professional looking website with a well crafted logo, a promo list of features and a copyright notice from the "The Actix Team". The community page even says "We're a welcoming community so don't be afraid to engage.". Ouch!
16 replies →
> It's a personal project.
If you create an organization on GitHub for a project that is meant to remain personal, this kinda sends a wrong signal.
Blaming some users for being rude and entitled, and then deleting an open source repo out of spite... it's a bit hard to feel sympathy for the guy here.
2 replies →
Exactly. It can be argued it's unprofessional to become dependent on third-party software without any background recherche regarding the maintainer's motivation, team size, financial standing, etc., especially when said third-party software isn't a replaceable, standards-based component such as, say, Java Servlet containers and other web components used to be.
Professional pursuits are things related to a vocation, not directly tied to an exchange of money for every interaction under consideration. If you're in the industry of software development, and tie your identity to an open source project, it is de facto professional.
In this example it is held as a significant accomplishment on this individual's linkedin page. Which isn't surprising as professional credibility is a primary motivation driving a lot of open source involvement. We are seeking a different, less direct form of compensation.
So it's fair to say that acting like this is unprofessional.
That doesn't mean it isn't merited, or that they might have been frustrated or had good reason. But professionally they would have been much better served by other means: Simply announcing that they're retiring from the project and encouraging forking and the percolation of a new canonical version, etc.
> And this seems like a perfectly personal thing to do with something that's preventing happiness.
Sure, if you want to spread the misery. That's still kind of a dick move, even if he's perfectly within his rights.
> These kind of entitled attitude
If you offer code to the public – and present it as an active, dependable project – professional behavior is exactly what you implicitly promise and signed up for. If you can’t offer that (at any time, and for any reason), then you should immediately make that clear, front-and-center, to any current and future users.
It isn’t “entitlement” on part of the users – the users are making reasonable expectations based on promises implicitly made by the the project as it is presented.
> If you offer code to the public – and present it as an active, dependable project – professional behavior is exactly what you implicitly promise and signed up for. If you can’t offer that (at any time, and for any reason), then you should immediately make that clear, front-and-center, to any current and future users.
As far as I can tell, this project was released under the Apache License 2.0.
https://github.com/actix/examples/blob/master/LICENSE
Clause 7 of said license says the following:
"7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License."
Other popular free software licenses (namely the GLP) have very similar clauses.
> It isn’t “entitlement” on part of the users – the users are making reasonable expectations based on promises implicitly made by the the project as it is presented.
Expecting labour from someone without paying them is the very definition of entitlement.
8 replies →
Or to put it another way:
As an open source maintainer, you're perfectly entitled to just walk away. Hit that archive button on github so nothing new can come from the repo, and enjoy your life. Nobody could fault on you that. People would prefer you work out a clean transition to a new maintainer, but you have no obligation to do so.
Deleting the repos is the equivalent of setting the house on fire on the way out (especially when they're under their own org). Unlike in reality, it turns out it's totally permitted, but people will still view it as a dick move.
14 replies →
> professional behavior is exactly what you implicitly promise and signed up for. If you can’t offer that (at any time, and for any reason), then you should immediately make that clear, front-and-center, to any current and future users.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
It's in big capital letters there. Explicitly no implied promises.
> It isn’t “entitlement” on part of the users – the users are making reasonable expectations based on promises implicitly made by the the project as it is presented
That is almost literally the definition of entitlement
3 replies →
To assume certain conditions that are not explicitly laid out without even talking to the person providing you the service is literally entitlement. It seems like you've made assumptions that turned out wrong. I've fallen for it too in the past. Not everyone thinks the same thing so people's assumptions are always different. The key thing is, when your assumptions don't turn out true, to learn from it.
In the case of open source, it's worth asking the maintainer what the terms are if you're unsure. The LICENSE always says that authors and contributors are not liable for any outcome, either as an ALL CAPS paragraph or a clearly defined section.
Everything is provided as-is so you can't expect anything. It's on you to pick up after them if you still need the project.
1 reply →
No you don’t. You aren’t alone in assuming that, but it’s an entirely unreasonable expectation. And as evidenced by this exact thread, people like you cause good developers to stop maintaining their projects. Your attitude harms our community.
Practically speaking, if I give you some work I did for free yesterday, and give you some work I do for free today, that does not entitle you to free work from me tomorrow. It does not entitle you to free support on the code I’ve published already. I owe you my time when you’re paying for it. Until then, if I have made something you found valuable you are in my debt for its use. Not the other way around.
As a user of my software I generally give you two rights - you have the right to use the code in your project, and the right to fork the project. And as the maintainer, I have the right to spend my time however I want for the rest of my short life on earth. If the beach looks like more fun than putting up with entitled complaints on github and HN, that is my right.
5 replies →
Strongly disagree. For me, what's implicit is that any software, commercial or F/OSS, can be abandoned at any time - because that's just the way it is. A remedy would be to use software coded to a specification with mulitple implementations such that in case a project folds, you might be able to switch over to a different implementation. The Java EE ecosystem used to be like that until around 2012 or so.
8 replies →
I've never heard of "implicit promises". For me a promise is by definition explicit. Anything else are assumptions, in this case false assumptions.
5 replies →
Yeah, no.
If you put your code out there open, it's still your code. If people start to rely on it, they need to be ready to maintain their branch.
I do not think these expectations are reasonable. This line of thinking is definitely the core issue of the problem.
>If you offer code to the public – and present it as an active, dependable project
Not familiar with the project or Rust Ecosystem. Anyone else can comment whether it was presented / marketed / sold as an "active, dependable project" ?
As someone more used to the Ruby Rails ecosystem, I think the communities as a whole generally accept the convention that all open sources, whether they are backed by a single person or cooperate account, are given out as it is ( MIT ) and their maintainer or author will do the support or development as they could when they are FREE. And it is perfectly acceptable of forking it to make your own variation or improvement.
> you implicitly promise and signed up for
Think about this. Do you really think it makes any sense to try to hold people to promises inferred by alternate parties that aren’t even providing any consideration in return?
Just think about that.
2 replies →
> professional behavior is exactly what you implicitly promise and signed up for.
Wise up. Professionals get paid, if you aren't paying some one they are not a professional. This is the reason why opensource projects provide professional support for pay, for professionals who need professional support.
I think that's made pretty clear in pretty much every open source license: "Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND".
4 replies →
> you should immediately make that clear, front-and-center, to any current and future users.
like, for example, in a license file?
Is it entitled? Most would agree, "very" (but that's not my concern nor judgement to make)
Did the maintainer screw over people that were using Actix? Very likely.
I sympathize with both sides here. I've been the unthanked, punching bag contributor on a few notable projects, and I've been a user of software whose leadership got into drama and squabbles, that ultimately fucked me over.
There were times that I pulled certain projects and essays, that had greatly helped people, and taken my ball home because I was fed up with the people I was catering to. There is no correct answer here, dealing with people and their emotions, but there is a way for both sides to handle things without contributing negatively to other's lives.
> Did the maintainer screw over people that were using Actix? Very likely.
How so? Just find a fork with a decent maintainer, or push your copy to your own repo. Let the Actix guy do his thing and move on with life.
Now due to that comment actix maintainer has disabled issue too. I don't know why people show such attitude as if they are paying him to do opensource.
In open source you give and take. The actix author almost certainly (unless they deploy their own kernel) has profited immensely from other peoples work. This is because as a community we have realized that we don't sell libraries, we sell stuff build with them, so we all win when we share.
It is your choice to use open source software without open sourcing your own work or without contributing.
But by engaging in open source you engage in a social contract, you become part of a community whose goal it is to foster collaboration and help one another, other people start to rely on you, just as you rely on their libraries, compilers, and kernels.
The author choose to break that social contract out of spite. He created a scenario where people choose to rely on him, when they could have relied on other works, and then screwed them over majorly.
14 replies →
Once it's public and people depend on it you can't retract it like that. His goal was to make his work public, not private.
You basically can. The cost of free stuff like this is "be nice to the guy giving it to you" or at least don't be actively abusive about it. If the community won't pay that price, expect it to evaporate.
2 replies →
You can retract it. He just did it. You can take down any webpage under your control. I could delete this comment later if I like. You could delete yours. etc.
1 reply →
The point of open source is that people can maintain their own forks etc. There's plenty of mirrors of actix I'm sure.
Why?
1 reply →
In open source you give and take. The actix author almost certainly (unless they deploy their own kernel) has profited immensely from other peoples work. This is because as a community we have realized that we don't sell libraries, we sell stuff build with them, so we all win when we share. It is your choice to use open source software without open sourcing your own work or without contributing. But by engaging in open source you engage in a social contract, you become part of a community whose goal it is to foster collaboration and help one another, other people start to rely on you, just as you rely on their libraries, compilers, and kernels. The author choose to break that social contract out of spite. He created a scenario where people choose to rely on him, when they could have relied on other works, and then screwed them over majorly.
Dude, sorry to break this to you! But basically any widely used software is supported by major companies just to avoid this problem.
Libraries, compilers and kernels alike.
If you want to rely on software being there, you should be ready to pay for people to support it.
> This is because as a community we have realized that we don't sell libraries, we sell stuff build with them, so we all win when we share.
It is clear to me that is not true anymore. It is really hard to find open source project without clear direct financial incentives.
Again, as a community, we should start to pay for the components we use.
3 replies →
> has profited immensely from other peoples work
Have they? how much $$$ profit did they make?
You aren't paying for shit and yet you think they are making a profit and you are entitled to professional support? Wise up.
3 replies →
Whatever drawbacks Actix may have had, this entitlement has gone too far. There is no defensible reason to tell someone "never write Rust again" because you don't like the code they're making available to you. We need something to remind us that we should be civil and grateful for FOSS contributions.
I recently saw a talk by Atwood about good discourse and how you should remind people of your values before they write their comment, which I think applies here. I'm going to make a single-page website reminding people that FOSS maintainers are volunteers performing a service to everyone else, and that we should keep that in mind.
If nothing else, it'll be an easy think to link people to in my issues sometimes.
EDIT: It's going to go up on https://www.osscoc.com/
"We need something to remind us that we should be civil and grateful for FOSS contributions."
You mean like having the legitimate risk that maintainers will take their ball and go home when people are cruel and others stand around and let it happen?
This is everyone's fault who didn't dogpile the people who were being terrible. We all need to be calling out people being horrible, and provide a little emotional support to maintainers. We worry too much about the feelings of people who contribute nothing, and not enough about the people who build the things upon which we rely.
No, I mean something less remote and which looks less like a random act of God, something that people can read before engaging in discussion and not easily dismiss because "it probably won't happen". We need to raise the level of discourse across the board, not just prevent the most egregious of negativity.
I want people to enter the discussion with the mindset "this is a volunteer effort so I will aim to be productive in my disagreement", rather than "fuck this guy".
1 reply →
> "This is everyone's fault who didn't dogpile the people who were being terrible."
That presumes that "dogpiling" would actually stop the behavior, rather than getting people to dig in their heels and further inflame tempers.
2 replies →
> how you should remind people of your values before they write their comment
That sort of thing doesn't work, even if it's shoved in people's faces. The only viable solution I've ever seen for enforcing community standards is to suspend or ban people who violate them. Otherwise, you'll always have trolls and people who want to see you fail looking to poison the well.
> We need something to remind us that we should be civil and grateful for FOSS contributions.
Sort of ironic that the entire commotion started when the Actix maintainer dismissed a contributor's code as boring after they wrote a POC and a patch for a use-after-free bug.
>I recently saw a talk by Atwood ...
Interesting, if you could share a link or some other source me and my dinner would appreciate it :)
I'm rather sure it was this one:
https://www.heavybit.com/library/video/civilized-discourse-b...
1 reply →
Open source maintainers have a hard time - especially when they're under criticism and receive zero positive vibes. Author mentions it, here's the excerpt:
Be a maintainer of large open source project is not a fun task. You alway face with rude and hate, everyone knows better how to build software, nobody wants to do home work and read docs and think a bit and very few provide any help.
This a big problem with open source - I, as a programmer, like when someone commends me. It might be childish, but if I invest a few days into code and someone finds it useful - I would love to hear it, it would make the day for me. Instead, I had similar experience like the author of actix - hatred, rudeness and a lot of people who don't read the docs, they merely expect everything to work if they drop the library into their project.
Sadly, we're way too negative and don't appreciate OSS maintainers. This trend should change. It's sad to see yet another project go because author was mentally drained due to negativity. We should take care of our own "brothers in arms" (we all write code or deal with tech, don't we?).
I haven't used Actix-web, but I can sympathize with the author. Keep your head up, recharge your batteries and remain creative. Good luck with your future products!
A data point: I've been involved in Open Source for 10+ years, developing projects myself, helping to maintain very popular projects, contributing, and I don't see a trend like this. I've interacted with hundreds of people over the years, and the vibes are overwhelmingly positive; I haven't noticed any hatred or rudeness towards myself. I can't think of a single time interaction with OSS people afected me negatively, but there were a lot of positive (or neutral) interactions.
Over time projects I'm contributing to were changing, and so I was exposed to several different communities (Python web development, data science, web scraping), and all of them turn out to be awesome. Maybe that's just luck, but not all OSS maintainers have it hard - no idea why :)
+1 to recharge the batteries!
The Python community has probably the nicest people of all languages!
Yep this is why, more and more, developers are simply doing private repositories. They might exist on GitHub. Or a torrent or something. Rachel goes into more detail about them here.
Basically people fix things and don't commit them back upstream because doing so is too much of a political headache.
> While it's probably true that the dictator does suck at design, the talented user wants no part of the drama which would follow such a report. There is absolutely no benefit to lighting that particular fuse. And so, the problem is never reported, and the patch is never conveyed upstream. It effectively becomes a private fork limited to the talented user's systems.
https://rachelbythebay.com/w/2018/10/09/moat/
I've been thinking for a long time that one of the problems with these online shitstorms is that the adults in the room are silent. It would have been so much better if the senior people in the Rust community stepped in to actually say "Hey, we're all using it, yes it's got issues, but thanks for your contribution and don't worry about the idiots". Instead we've got senior people in the Rust community waiting until the damage is done and then hand-wringing about it afterwards.
It's a tricky balance. This is also sort of where I was getting at in my post with the "unofficial" bit; because /r/rust is not official, we do not look into it. And because this happened on Reddit, there was no real opportunity to actually step in. It's quite possible this is simply a failure on our part.
2 replies →
Evan Czaplicki (Elm designer) has a great talk about this issue "The Hard Parts of Open Source" https://www.youtube.com/watch?v=o_4EX4dPppA
I don’t want to come across as toxic myself, but I think that the toxicity that Evan sometimes has to endure from people in the community is somewhat self-inflicted.
Last year I wrote a web application in Elm. Even though I really liked the language and had lots of fun writing code, I noticed that the users effectively have to rely on Evan to make any meaningful progress. The ‘forkability’ of the project is very poor.
To give you a couple examples of that:
- Elm has a centralized package repository: https://package.elm-lang.org/. There is, however, no functionality in Elm to host your own registry, whether it is public or internal to your organisation. The monolithic compiler/build tool hardcodes the URL of this registry.
- Relatedly, there is no way you can easily fork a package and apply some changes, especially if you have no intent to host it through the official package collection. There is no way to say: “I want to use elm/http with this tiny local patch applied that I have sitting in my tree.”
- Some parts of Elm’s grammar/intrinsics are only permitted to be used by packages with author “elm” (i.e., the official core packages). This means that you cannot fork, say, elm/bytes to yourname/bytes and make local changes, as it can no longer be built.
Because of this, the maintainers of Elm don’t just decide what goes into the tree, they effectively also decide what users may do on their end. They are the folks sitting behind the master control panel and people filing issues/pull requests rely on them to push the buttons for them. I can understand why this causes friction within the community.
Note that this was my experience using Elm early 2019 (January-April). It may well be that Elm improved in these areas since.
Similar experience. Some OSS users have some very entitled mentality.
I use to do a TON of open source back in the day. i quit cause of the same reason, people suck and feel they are entitled.
i couldn't count how many times someone would yell, kick and scream about an issue they were having and demand that i fix it right away (ain't gonna happen dude). i finally got to the point where i told people that i would only participate in pull requests and nothing else. you could still file issues, but i wasn't gonna even look at them. if you wanted something fixed, open a pull request and i will help you fix it but i'm not wasting my time with an issue that i didn't personally have an investment in. was i being a jerk for doing that? maybe, but my own personal serenity was worth more to me than pleasing you.
i think every open source author starts out with this fire in their heart to make the software world a better place for everyone only to get beaten down by every moron out there. when you are getting paid to do something, you put up with the idiots in your life (how many of us are still at the job that pays well, but HATE the people there?), but when you are doing it on your own time and not being compensated for it, what's the point?
i applaud this dude for doing what he did. i hope his actions has put the people using his project in a position of panic to the point where they reflect on how they treat people and participate in the open source community. pain is the only way we learn and change things about ourselves. i hope the people who caused the author to quit open source change the way they treat people in the future.
Maybe it's because I work on more niche projects, but every time someone contacted me about an issue in one of my repos they were always exceedingly apologetic about "bothering me". My projects only have ~400 downloads per month, so I'm sure it's a matter of sample size. If anything, working through issues with the community has made me enjoy the work more.
Yeah, it's important to remember that most of the time people are very nice.
Of course there are "problem kids" out there who screamd about an opinion they disagree with or tries flirt with female contributors on IRC..
Having co-workers, a code of conduct, and a community organizer you can escalate to can help a lot.
We are all on notice. Be nice. Support and protect the people contributing to the world... or write it yourself.
For context, this comes after yet another unsoundness bug has been found in Actix-web. Normally people in the Rust community don't get very worked up over these because we know that everyone makes mistakes, but the Actix project has had a consistent history of introducing unsoundness through the use of unsafe for dubious reasons like nebulous performance increases or bypassing Rust's safety guarantees (which is what this last one was about). Furthermore, when someone raised this issue and provided a patch to fix it the actix-web maintainer called the patch "boring"[1]. He also censored comments that talked about the unsoundness and eventually deleted the entire issue. This sort of behavior should not be acceptable from any open source maintainer that runs such a large, foundational part of the ecosystem.
[1] https://web.archive.org/web/20200116203731/https://github.co...
I completely disagree with your last sentence. Think of actix-web as a gift to the world (and judging by its popularity, a very nice gift). Being verbally abused by vocal majority of freeloaders would drive anyone furious.
I think I understand your perspective, though. It would benefit the community to have projects of great importance properly maintained. How to ensure it? Well, by paying people to do it, not necessary developers but active project mantainers. Only then you are entitled to complain about somebody doing a lousy job. To sponsor it, introduce micro-transactions for dependencies.
Obviously being vocally abused is not OK no matter what the victim has done. This is a big problem and I think Steve's article that is currently on the top page of HN gives a good overview of that part of the situation.
My problem with viewing all open source as a gift to the world, take it or leave it, is that when people create open source packages, market them as being ready for production use and as the best option for said production use, and then act unprofessionally towards security issues and reject patches that fix the security issues for no reason other than being "boring" and "not creative enough" people should be able to call them out on it as unacceptable behavior for an open source maintainer. If actix didn't claim to be production ready and instead stated that it was an experimental code base designed to advance the state of the art in web server performance I wouldn't have a problem with how it was managed. However, once you claim that something is production ready I think you need to be ready to take responsibility for it.
3 replies →
You say, "This sort of behavior should not be acceptable from any open source maintainer that runs such a large, foundational part of the ecosystem."
Or what? What's the "punishment" here? Who's going to decide what's acceptable, and what's not?
Seems like you are demanding that the author of Actix do what you want.
Sometimes people take their football and go home. In this case the vocal complaining minority are free to make their own copy of the football, and proceed on their own...which is also known as "put up or shut up".
Or he will lose the reputation, that's what.
> This sort of behavior should not be acceptable from any open source maintainer that runs such a large, foundational part of the ecosystem.
And the better solution wouldn't be to harass the guy, but to recommend and try to move the ecosystem away from actix.
>Actix project has had a consistent history of introducing unsoundness through the use of unsafe for dubious reasons like nebulous performance increases or bypassing Rust's safety guarantees
sounds like the author had specific strategic vision - "push the boundaries" - which he clearly explained, and there are other people who don't agree with such an approach, both are valid positions in their own right, and instead of being jerks and trying to shove their approach down the project owner's throat these other people should have just started their own project reflecting their more conservative approach.
It is like those people who try to push Linus to use C++ and do other funny stuff in the kernel - one should go and read Linus' responses to the people like these.
http://harmful.cat-v.org/software/c++/linus
"Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.
[...] I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really would prefer to piss off, so that he doesn't come and screw up any project I'm involved with."
> but the Actix project has had a consistent history of introducing unsoundness through
Then you can stop using Actix and create a better project or fork it and fix these unsoundness bugs and call it ActixSound. I do not see the point to rally up the crowd and raid his Github in the name of soundness. This reflects poorly on the Rust community.
I’m not sure why people are so fork-shy. Forking is the greatest gift of open source. It’s basically the point and the core of what it means to have software freedom. I think the anxiety around forking is unwarranted, especially in scenarios where the author clearly has divergent goals and values from a large number of people.
It seems the forest has been lost from the trees: exercise your freedom, fork, and let diversity lead to longevity. I think a lot of the aversion is because forking and fragmentation is messy. It doesn’t surprise me that the Rust community in particular would abhor such disorder :) (see the JS community for a counter example.) But such disorder is a key element of so many good human systems, like democracy and free markets. Better to embrace them and relish the freedom they bring, than dive deep into conflict with others only due to imagined chains binding you together, chains deliberately lacking due to the selfless altruism of the project creators who bound their work to a free software license, to whom you should be thankful, not resentful.
This whole issue is confusing to me. It's like no one ever heard of fork. It's hardly mentioned in the comments. The author owes people what they paid him to do, which is nothing. If he wants to go unsafe and fast that's his business. I don't have to ride with him. I can make a copy of his car for free and drive it the way I want.
I think this is a case of the end justifies the means. The end: get the maintainer to change his code the way I want. The means: bully and abuse him to force him into it because that sometimes works.
At some point open source got morphed into being about free as in beer and gratis volunteer work by generous souls. But its origin and what the licenses themselves are about are freedom to read and freedom to modify. The entitlement that has crept in and the social contracts that seem to have formed around expectations for people writing Free code are concerning.
Shame on people who forget this, and demand more than those freedoms from authors who so generously grant them to others. Based upon what I’ve read, I would have checked out from this project as the author well before they did given the harassment they’ve apparently been getting for not merging PRs into their repo.
I'll save this link for the next time someone tries to argue that the Rust community is somehow "more welcoming" than some other X community.
All internet-based communities contain some assholes. All of them. Sadly some maintainers don't seem to have the werewithal to tell them to go away. I mean, when you get "asked to change coding style", it's the time to put the banhammer down, because there is no way to please these people without humiliating yourself.
> I'll save this link for the next time someone tries to argue that the Rust community is somehow "more welcoming" than some other X community.
It's deeply disappointing to see this outcome (and r/rust is literally divided into two halves on this drama at least for now, ugh), but I believe it is the statement about the average atmosphere. Not that I have an argument for or against the refined statement, but it doesn't automatically get rejected with a single counterexample.
Nah, it's just the usual delusion of small-but-growing communities. The Python community was great in 2001, a bit less so these days. The Lisp community was probably great at some point in the '70s too. It's just that, with size, the likelihood of attracting undesirable elements inevitably grows until their presence simply cannot be denied. At that point, you either deploy heavy-handed moderation and get branded "unwelcoming" by the assholes, or leave it free for all and get branded "unwelcoming" by the most sensitive not-assholes. Then someone or something will spawn a new community, and the cycle will repeat itself.
This process is basically inevitable, and it has been observed in internet communities for so long that it's basically a science by now. It's just the nature of the (human) beast.
5 replies →
I’d argue any community that crosses Reddit and Open Source would cross this issue eventually - it’s not necessarily a Rust issue.
What he created and did was and is amazing.
He wouldn't have had the attention or the criticism that he got if it hadn't been so impressive. I think when something's good enough, people may actually criticize more freely. Some of that is because the project becomes worth the scrutiny. But some of it is also a status thing. If your work is good enough to give you a high enough status, you change categories a bit in peoples minds. They start to criticize you in the way that they'd criticize other entities that seem strong enough that they don't need to be protected any more.
I hope that the actix ecosystem can stick around and keep moving forward. But even if not, I think fafhrd91 made impressive contributions and I'm glad to have used and learned from his work.
Agreed, nice work fafhrd91!
-from another impressed but silent user of your project
I've been using actix-web for my work for some time, contributing however I can while learning Rust and myriad other subjects. This was the third major public event involving controversial design and implementation decisions. A great number of people in the Rust community have refused to accept that not everyone subscribes to their ideology about use of unsafe. They've repeatedly tried to impose their values and priorities upon someone who has been more than capable, if not more capable, of reasoning about legitimate issues and risks and who has his own priorities. The author has not been kind towards those who challenge his decisions, and this has not helped him navigate social issues. It's not just that he struggles with English but has a very different value system and set of priorities than those who he's had to interact with. Further, these contributions weren't from neutral parties but rather a group of long-term adversaries who have taken it upon themselves to hold Nikolay accountable for having differences. They blog, they control the narrative in message forums, they basically do everything in their power to cancel Nikolay and his tremendous work, shaping the public narrative as one that suits their goals.
It took great strength to go as far as Nikolay did in spite of these challenges. I understand why he doesn't want to participate in this culture any longer. It comes at a great cost. Unfortunately, the actix projects and its author are not the only ones who have been targeted for having differences. The next example is Ferrous Systems, who have authored a new ecosystem for asynchronous development. The team has been attacked in all sorts of ways and are going to great lengths defending themselves and to help shape the public narrative. Eventually, they will tire from constantly defending their decisions. Some will lose their patience and tempers will flare. Then, an angry mob will re-emerge and do everything in its power to cancel the momentum of their work and attack the reputations of the authors.
I don't know whether this social behavior will change without the culture changing as well. It requires a respect for viewpoint diversity and acceptance of people unlike ourselves, not just in gender orientation but in opinions and values. It includes tolerating disrespect and leaving people alone rather than trying to destroy them. I doubt these social issues are unique to the Rust community. Cancel culture seems to exist in all shapes. We aren't better for it.
I remember when I was young and “diverse opinions” was a phrase as celebrated as “diverse backgrounds” is today. Why we had to lose the former while (rightfully) recognizing the value of the latter is beyond me, and without both we will surely continue to descend into continued tribalism, but of a different kind.
I wonder to what degree the entire incident happened because Rust has unsafe-blocks.
There are only 2 outcomes for Rust not having unsafe blocks:
1. Everything would be unsafe. Same as C/ C++
2. You could not use it to write real software, because not all constructs are expressible in safe code. The std lib requires unsafe to a bigger extend. Talking to the OS does the same.
Unsafe blocks are required to write software. And they are good, because they minimize the amount of code which can not be automatically audited by the compiler.
Unfortunately unsafe blocks seem to get more and more misused as a metric around the quality of software. Which is certainly not their intention.
the unsafe blocks were the catalyst
I am a Rust beginner, and have made a few small projects with Actix Web. Actix Web is the only framework I use in Rust and spent some time learning about it. During that learning process, the docs constantly get updated but there are examples in the repo. Sometimes there aren't examples and I go to their chat room and ask the maintainer directly, and to my surprise, he always answered my question.
He is a busy guy with a life that already put immense effort to create this library and helping people to use it. He is free to do whatever he wants. People who complained, did they even give him thanks? Or donating coffee money? Grow up and stop spending your SWE salary for your vices.
Tried to write it down and help to enhance the documentation, or written an own documentation? So that reoccurring questions could be reduced.
During that time the actix web library was planning to do some breaking changes because of 1.0 target
This is part of the MIT license. Many other open source and free software licenses contain the same thing. It's simple, people provide software they write in their free time or "sponsored" by their company, in return they get nothing and you should expect nothing more than the piece of code that gets published.
People have started assuming that free and open source software is not "true" open source if you don't build a community around your project, gain a following and can take advantage in it professionally somehow.
It's a shame, as it puts a lot of pressure on people, instead of all of us just sharing code because we love coding and want to share it with everyone who also loves it.
The MIT license isn't the only thing Actix wrote. They also wrote this:
https://actix.rs/community/
> Community: The best things in life are to be shared
> Join us - Want to talk to others about questions? The actix gitter channel or reddit community are your best starting point.
> If you think you found a bug it's best to go to the github directly. There are two repositories that you might want to report against. actix for issues with the actor framework or actix-web for the high level web framework.
> We're a welcoming community so don't be afraid to engage. Interactions are governed by our code of conduct.
I agree with you that projects aren't required to do this. (And I also agree that developers often feel pressured to build up a community for their project.) But still - that's what they wrote.
True, they did write that. But taking into consideration the license open source and free software is usually licensed under, they are free that change those opinions at any time, and you cannot blame them for it.
If you had a contract with the project, I would understand the frustration. But since it's published on a "NO-WARRANTY" and no promises basis, the persons opinion can change at any time, and that's perfectly fine.
So maybe today I feel like, yeah, my open source project should have a community! So I publicly write that. But then 6 months later I change my mind and stop trying. This is also perfectly fine. Annoying, sure, but if you want to avoid that, start making contracts with the libraries that you include in your projects.
1 reply →
I'm on board with your general message, however, the larger actix isn't some independent project. It is clearly endeavored to build and serve a community. And maybe that wasn't the intent of the author/maintainer? I don't know. But I'm going to tell you right now that if you don't want to be part of a community (for better and worse) the best plan is to not join one, especially not one that proselytizes itself in a way similar to many commercial/oss hybrid outfits.
I don't mean to condone people being jerks or the typical reddit brigading that is being talked about. It's just, it doesn't really matter what your license says. If you act like you're going to serve customers, you just might get some customers and if you can't deal with customers then you probably shouldn't act like you want to serve customers.
It's perfectly fine to build a project in the open and license it openly and not accept open participation.
> But I'm going to tell you right now that if you don't want to be part of a community (for better and worse) the best plan is to not join one
Well, you can want to be a part of a community one month, and not the other month, which is fine. We have other stuff going on in our lives too.
> It's perfectly fine to build a project in the open and license it openly and not accept open participation.
It's also perfectly fine to build a project in the open, license it openly and try to push for open participation, but later change your mind and not do that anymore. As mentioned, open source comes with no guarantees, what so ever. Let's keep it that way.
Removing the repos seems to be a bit much especially since he is planning on making them private and then deleting them.
Why not just leave them in place if you're burned out and see if anyone is willing to take over maintainership.
Given, I don't know the history, but I always feel a bit of pain when code gets lost or destroyed in the heat of the moment.
They have been moved to his personal account for the time being:
https://github.com/fafhrd91/actix-web
https://github.com/fafhrd91/actix-net
> Why not just leave them in place if you're burned out and see if anyone is willing to take over maintainership.
Because a proper hand-off is also a lot of work, which continues the burn-out and the chances of a new maintainer stepping in are slim-to-none (there were already attempts to find one after the last "actix unsafe discussion").
The entitlement in this thread is astounding. Don't like how the project is maintained? Fork it. If you don't have anything nice to say to the person who gave you the code _for free_, then just don't say anything at all.
Especially weird seeing as Github has made forking a very smooth way to work with a project. You fork it, make the changes you want, and then make the changes available upstream.
If upstream vanishes, your fork is still around.
If upstream doesn't want to merge, people can use your fork instead. And, if your changes are that much better, eventually make it the de-facto standard version of the project.
Yes, and it happens all the time in other projects. There's always "so-and-so's fork that implements feature X and changes Y", and it's awesome that that's a possibility since it means no project is held hostage by its maintainer, and that differences in priorities don't mean the code can't be useful for a range of use cases.
The commits you do in a fork are not visible in your GitHub commit calender until you do a PR and they are merged. For some people this is important so a "forked" project won't have many commits with merging back to master.
2 replies →
I made much the same point in the other conversation about this.
The beauty of open source code is you can take it, modify it, and even improve and rename it in a lot of cases.
So much of today's internet has to be a fight or a shitstorm. For no reason at all.
The repo currently contains a single README.md.
https://github.com/actix/actix-web
Edit: I was not aware he moved it under his personal github account and it’s still accessible. Nonetheless, I still think removing it is a bit extreme.
Yea, because the maintainer was tired of being abused.
9 replies →
He moved the repo's to his personal account. Still there (for now): https://github.com/fafhrd91/actix-web
This argument confuses and saddens me. If I give away free food which I and others know to be contaminated with foodborne pathogens, is it wrong for them to criticize it? What if I don't know, but I obtain it from a supplier which is known to persistently sell contaminated food? What if I put up a sign in very small print saying that the food comes with no warranty whatsoever and all consumers eat it at their own risk? What if I put up a large sign? What if instead of pathogens, I intentionally add lead-based decorations on the basis that they look and taste good, even if they may be slightly carcinogenic if consumed? What if I clearly state that the decorations must be removed before eating? At what point do I acquire moral culpability for the harms suffered by my customers? These sorts of comments seem to imply that there is no problem with me doing any of this, as long as the food is provided for free and consumers have the choice to not take the food. I would vehemently disagree with that claim. Uninformed choice is not a true choice, and even informed choice cannot excuse certain foreseeable harms.
That is an entirely specious analogy. This code will not cause someone to get sick or die. And "contaminated" vs. "not contaminated" is a binary result for food -- one is the case and one is not the case. With code, there's nearly always room for reasonable disagreement as to what is the right/good or wrong/bad way to do things, and often people argue over two (or more) perfectly fine ways of doing things that just come down to a matter of style.
8 replies →
I mean, the license state:
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
So if some random person on the side of the street gave away browny, and had a sign like that, I'd do a bit of personal investigating first before eating it, like looking at the ingredients, asking for expiry, and all that. Which you can do for open source software, by just looking at the source code.
There's a difference between leaving poisoned but attractive looking food on a sidewalk, and putting code on github. You're losing perspective regarding open source programming -- it's supposed to be fun. There seems to be a political / ideological dimension to this disagreement. Your nanny state would be correct to punish someone for leaving poisoned food out. But we don't need your nanny state in open source software. People can choose to use or not use free software. Anyone whose software has life or death implications would indeed be culpable if they make those choices rashly. But the responsibility does not lie with the maintainer.
Being a maintainer on a popular open source project can be hard. You put expectations on yourself, others put expectations on you, people complain, people trash talk you because they think they can do it better, and so much more.
I think this highlights that maintainers need support systems to help with this. We can use GitHub features to mute or block people. We can have CoCs and try to avoid people who cause issues. But, they still happen and maintainers need help. Someone to talk to, people who have been there, support groups, strategies, and sometimes sabbaticals.
I feel for this guy and hope some time away will help him personally.
We did this to him. [1] We drove him to burn-out. We should reflect on that and make sure we don't ever do that again to any open-source maintainer. And we should pay more of them for their work.
[1]: Including me, as I contributed to a comment thread here about cheating on benchmarks.
Good for him to make a stand!
I can completely understand how he felt. Similar things happened to my open source projects, admittedly at a smaller scale. Users became so entitled to open source software and became hostile. Well, i nipped the problems at the bud by moving the projects off open source license. There were a few people crying foul and vowed not to use it. Fine. I respected their choices, and let's move our separate way.
There're requests to open source and hand the projects to someone else. No. I want to maintain control of the project development and direction, like directors wanting to maintain artistic control over their movies. If someone is so fired up, they can always write their own open source software.
would you have declined a patch that fixes a real problem because it is boring? i do not really get that kind of thinking either. personally i would have accepted it and replaced with something clever latter on
Yes, I would. Because that patch is a "style" patch. It's not important in the author's roadmap for the project.
People ask for different things and think their things are the most important, and when they don't get their way, screaming and kicking to force them in. They can always fork it or create a separate project if it's so important.
2 replies →
An argument could be made both ways, but I wish people stopped quoting licenses to resolve social issues.
For example, the license does not forbid the user of the software from INSINUATING THAT THE AUTHOR OF THE SOFTWARE IS INCOMPETENT, OR UNFIT TO AUTHOR ANY SOFTWARE, EITHER IN A PARTICULAR LANGUAGE OF THEIR CHOICE, OR IN GENERAL. So one can almost say that anyone who's doing it is exercising their right granted by license.
...But that kind of argument is not really helpful, isn't it? The question is whether some behavior is socially acceptable. License doesn't enter the question.
(BTW, of course I don't support the kind of behavior I endorsed(?) above.)
> ...But that kind of argument is not really helpful, isn't it? The question is whether some behavior is socially acceptable. License doesn't enter the question.
> (BTW, of course I don't support the kind of behavior I endorsed(?) above.)
Let's say someone wants to release some open source software to the world. But they also want to retain the right to remove their currently published copy at any point, their right to reject patches and generally do what they like without being slurred and berated by everyone else.
Aside from adding a plaintext file alongside the code that explicitly says (sometimes in capital letters!) that the code is supplied with no warranty or obligation, explicitly or implied, what should they do?
Isn't it clearly the case that the license explicitly states the social contract?
Closed source is more fun to develop. You get full control over your code, you just have to meet the needs of people who think it is worth enough to pay for it, you can code in whatever eccentric manner you want, and you get to keep the nice wads of cash if it becomes successful. If security is a problem, then the people with wads of cash will leave, but at least there is some incentive there.
I would advise people who decide to embark on large, hard projects like this to stop making them free. Make the source open if you want, but charge money. Either for the product, or for support requests, something. This not only filters out entitled assholes, but it gets you money, money that you can maybe use to pay people to help, or at least to buy a beer.
This is an unfortunate conclusion that I also arrived at after much consideration. I have a proposed dream project in front of me that would take at least 2000 hours to reach MVP. Do I just give it away for free on GitHub under MIT? I spent over a decade honing the skills that allow me to even engage with such a difficult objective. Why should I just give it all away unfettered? What alternative approaches exist in which I share these wonderful new ideas openly and also somehow reap the benefits?
I feel that for certain projects like vendor API integration libraries, opening up the source for all to use freely is the best path. But for others, where years of intellectual property and personal development exist predominantly within the code itself... I think I want to keep this kind of code to myself for now.
I wish that the author have read this "The Hard Parts of Open Source" by Evan Czaplicki https://www.youtube.com/watch?v=o_4EX4dPppA
I thought about exactly that as well :).
Asking for a friend - could someone explain what happened there? The README doc is quite vague - it is more of a personal justification than a rationale (to me).
Sounds like the maintainer writes a lot of code using rust's "unsafe" keyword, and regularly gets issues raised about this (and versioning, and some other bits).
This last issue, which included a patch, has pushed them over the edge after it descended into disagreement.
Net/net they were repeatedly asked to change coding style, didn't want to, and have decided it's better to just avoid the arguments by not publishing code.
The maintainer can choose whatever style they damn well please, if you don't like it don't use it.
What is hard about this?
17 replies →
The issue was triggered by someone executing a benchmark on http crates and opening an issue on github, that was then deleted after some heated back and forth.
https://www.reddit.com/r/rust/comments/epoloy/ive_smoketeste...
From the maintainer point of view, it seemed to have been the straw that broke the camel back, but I don't know the whole background.
Still seems like a sad story
Wow. Talk about a bad response though. No matter how abused you may feel as the sole maintainer you should still not throw a tantrum. Censoring an issue title, body, and comments is a gross overreaction. If you want to throw in the towel then just throw in the towel.
https://www.reddit.com/r/rust/comments/epszt7/actixnet_unsou... context for the "boring" patch.
Actix is full of "unsafe" blocks and the maintainer got a constant stream of criticism over it.
https://www.reddit.com/r/rust/comments/epszt7/actixnet_unsou... has more context.
The Wayback Machine links don't seem to work anymore, unfortunately.
It seems like the overarching issue is that Rust is a house of cards. They added unsafe like Java has null. My favorite part is that you can declare a crate to forbid unsafe, but that then doesn't have to hold for it's dependencies.
The obvious implementation is for unsafe to be infectious like const. You have unsafe code, your crate is unsafe. You depend on an unsafe crate, your crate becomes unsafe.
> The obvious implementation is for unsafe to be infectious like const. You have unsafe code, your crate is unsafe. You depend on an unsafe crate, your crate becomes unsafe.
That would mean everything is unsafe, since every crate depends on core (or on std which depends on core), which has "unsafe" code.
The design of "unsafe" in Rust, instead, is to allow building safe abstractions on top of unsafe code (or be able to clearly mark when the abstraction itself is unsafe). That way, for instance, users of `Vec::push` do not have to worry that it uses uninitialized memory (which is unsafe).
This is a poor comment. You clearly don't understand how unsafe is to be used. No code (of significant size) that you run will be bug free ever. So you might as well start from that assumption and realize you are trying to minimize the amount of unsafe code and bugs; you will never remove all of them no matter what the language.
That would prevent you from using the stdlib.
https://doc.rust-lang.org/src/alloc/string.rs.html#1215-1230
Using unsafe doesnt necessarily mean you will have undefined behaviour, it just means you have to think really hard about the behaviour because the compiler won't have your back.
I wish there was a better way of handling that in Rust. You should be able to have a few markers in your code:
- uses unsafe - no unsafe, but dependencies may use unsafe - no unsafe, no dependencies except the standard library may use unsafe - no unsafe, not even in the standard library uses
The current situation is the second one, but many cases probably want the third, and occasionally the fourth.
The best part is, this should be fairly easily solved by crates.io upon submission (is there any use of unsafe and are all dependencies marked as strict or more strictly than yours?).
Concerning is what message this sends to other OSS developers. One goes into F/OSS knowing full well there will be little rewards financially - but facing harassment or attacks on their reputation cannot encourage future projects.
Is it too late to set up a SafeActix project, let him keep the Actix name & creative control, and resolve things semi-positively? Seems like the community mistook it as an effort to build something safe, and it was a thousand cuts of misconceptions/asks. Maybe open an issue and give them a week to decide/vote a new name. I don't think there's an obligation per se, it would just be better.
Poor guy, writing code for fun and maintaining an OSS project long term aren't the same thing. Nor do they require the same skill set.
With abit of elbow grease we can pick the project up again, "reputational damage" is not the end https://en.wikipedia.org/wiki/Service_recovery_paradox
To me, this displays a deep misunderstanding of FOSS on the part of this projects maintainer. He wants to create a project, promote that project to the top of it's field, and completely ignore the perception of his userbase. Then he fell back on "it's my code I'll do what I want with it." That would be fine, but he "sold" people on this code with the understanding that we were all going to take it to it's maximum potential. This was marketed as something which would solve specific needs better than similar products. Most people can handle regression and bugs and regular ongoing refactors as everyone struggles to bring this same piece of code to the next level. What people, especially the dev community, cannot overcome is when they are told that a project has a direction that it clearly doesn't have. If this maintainer had no intention of accepting feedback from his users there should have been a clear indication of that somewhere in the docs.
If you never reconcile your reasoning and expectations with your community then they will deduce reasoning and expectations that you never implied. This maintainer wanted to produce a popular piece of software not to contribute to the Rust community, or because he wanted to make lives easier. This isn't the attitude of someone who is trying to improve his skills or challenge his knowledge of Rust. He obviously didn't do it to get rich. I believe he made actix-web to get famous. He wanted blind recognition for being selfless. He wanted a community of docile dependents who sit up late on GH hitting the refresh button waiting for his next push. He seems to have only wanted to make a product that people revered. When that didn't happen because he never reconciled his goals with the communities expectations he took his ball and went home. "What??? No fame? No glory? Criticism!?!? Fine, no soup for you."
Is this the same actix that won recent Techempower benchmarks? What a pity!
Yes.
The very normal path of growing up as a leader:
1. people are good -> trying to do something good
2. doing good -> realizing many people are not good
3. stop doing good thing, start being frustrated
4. realizing one doesn't need to let people pull oneself down -> start doing good again
5. helping others to do good things and surviving the first shock of being visible
6. $$$
Similar burnout happened with Ecstatic, a very popular Node.js static file serving library.
https://github.com/jfhbrook/node-ecstatic/issues/259
It should be noted that the code wasn't deleted, but forked to his private repo, where it's still open for anyone to use, download, fork, ...
if the issues are so bad and the author doesn't want to fix them, just fork it and avoid all the arguments that won't lead anywhere.
Sad to see this. I'm using Actix in a new project and have been watching the project for a while. Guess I'll be refactoring to use Hyper. If I were farther along I'd probably try to take ownership, but it doesn't make sense given that it's only around 40 LOC in my project that depend on Actix at this point so switching out to another framework is more straightforward than taking ownership of a codebase I don't know.
I understand fafhrd91's (the maintainer) frustration, but it would have been much better to just abandon the project and throw it up for some other volunteer to come in and take it over. Then the project can live on and he can bask in any success it has in the years down the road. Instead, it's a complete mess where all the good work and good will has been undone in a single move.
I've abandoned multiple OSS projects over the years and let other maintainers come in and take them over. Now over 10 years later I can still say I created that project that still gets used because other people have seen value in continuing to contribute and maintain it.
Reminds me of this "Open Source is Not About You": https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
Agree 100% with the maintainer, read some of the comments on /r/rust and on Github, I haven't seen a more rude sanctimonious community in my 12 years programming. Holy shit!
Rustaceans my ass! From now on Rudeaceans.
Check out their official channels. Anything on reddit is going to be toxic unless it is highly curated by the subreddit mods. That's just the reality of reddit.
People should really learn to ignore the emotional channel of the comments they receive. Just try to figure out if the message contains any useful information with a quick glance, extract it if it does and ignore the rest. People have to shit - that's physiologically inevitable, and there are people who do it in the streets and there are people who shit in comments/messages. Why take them serious?
> I used to do tech support and some people (not too many) wrote right out rude or nonsensical (like concluding I hate their religion just from the fact our service failed to suit their specific needs).
This isn't at all the same thing. You were paid to do your job, and at the end of the day you could just joke about those weirdos.
When working on an open-source project, everything becomes much more personal because your motivation is fuelled by your own personal attachement to the project. Imagine you're helping elderly people cross the street every day, and every once in a while they yell at you for not doing it better, whatever that means. At some point is it still worth it?
And of course you can't just put that behind you once you're back home, because this abuse happens at home. I remember this time where someone literally told me to kill myself while I was fixing a bug - at midnight - in a project I handle. Or the time I woke up only to see that during the night someone public had decided to openly send me literal fuck emojis on Twitter to right a perceived wrong. Good times.
So yeah - building a shell is the right solution, but it's hard and we really shouldn't have to deal with that in the first place.
I get you point, it makes sense, but I feel like I personally have already grown over that and everybody can: just know what are doing the job for. Are you helping the elderly to get their gratitude? No, just because I'm doing the right thing and I know some of them are jerks because loosing their sanity to Alzheimer's and because of hard life they had. Are you maintaining a free project for users' gratitude? No, I do because it's fun, because it expands my experience, fulfills my own needs, improves my CV and because I'm glad if somebody can use it for good. Never expect a reward if it's not guaranteed in the first place.
For some reason lots of people on HN push stoicism as a virtue. Not all of us are 100% unaffected by dealing with jerks, and we like to get ourselves out of toxic environments that make us unhappy. Is that so bad?
The value in stoicism is that it lets people transcend limitations they have control over. It's a tool and comes in many packages (e.g.: "God, grant me the serenity to accept the things I cannot change, Courage to change the things I can, And wisdom to know the difference.").
Lots of "people on HN push stoicism" because a great many people in all walks of life share life lessons that can be categorized as stoic.
>Not all of us are 100% unaffected by dealing with jerks, and we like to get ourselves out of toxic environments that make us unhappy. Is that so bad?
This is reductive. If you were to undertake a real appraisal of the ideas with a goal to separate the wheat from the chaff, as well as feel out the boundaries of what is often presented as blanket advice (rather than try to get one over on "people on HN"), the advice people are trying to offer would make more sense.
2 replies →
You obviously have never participated in open source and are talking about something you had ZERO experience with. Go participate in a toxic open source community for a couple of months and report back about not only the experience but also you emotional well being. I can guarantee you'll be reading your comment and cringing at what you once wrote.
btw, there is and awesome life lesson in this comment i posted, if you can remove the emotional part of it ;)
Now I consider your message a puzzle and am curious about what awesome life lesson have you hidden in it. I am going to re-read it over and over again :-)
> People have to shit - that's physiologically inevitable
I don't think that's universally true. In fact, I think there's a handful of people who don't know how to treat others like human beings and a lack of accountability for their behavior online.
The fact that there is a thing true of open source---it's a harbor for toxic cultures where people aren't held accountable for talking to each other like garbage---doesn't mean we need to just accept that or look the other way. As this situation demonstrates, toxic culture has costs.
Easy to say, not so easy to do.
Quite easy to do once you realize you can, adjust the mindset and have some practice. There probably is a lot of garbage in your spam folder - do you take it seriously?
I used to do tech support and some people (not too many) wrote right out rude or nonsensical (like concluding I hate their religion just from the fact our service failed to suit their specific needs). I would just answer such sort of robotically (if their message contained a question which made any logical sense) or ignore them (despite I generally am extremely compassionate and always do my best to help).
Have you ever looked at a glass of a window rather than at an object behind it? Just don't focus on the idea there is a person hating you (there are much more people loving you, by the way, even if they don't write you), instead focus on the fact you are viewing a string which only contains garbage data.
Go to an anonymous image board and look at people writing things which would be unimaginable to see here. Write some yourself perhaps. That can make a nice practice quickly.
3 replies →
I agree with you. Really it is something that probably can be learned over time. I think it helps a lot to just remember how much money this or that dumb hater have paid for their entitlements (i.e. nothing), which -at leas in my eyes- emotionally reduces their words to a child's tantrum.
Sure, but it helps more to realize once and forever: all the shit anybody says is just a "child's tantrum". Real grown-ups don't behave this way, too many people just don't grow up as they age.
1 reply →
"The thing is that, of course, there are totally different ways to think about these kinds of situations. In this traffic, all these vehicles stopped and idling in my way, it’s not impossible that some of these people in SUV’s have been in horrible auto accidents in the past, and now find driving so terrifying that their therapist has all but ordered them to get a huge, heavy SUV so they can feel safe enough to drive. Or that the Hummer that just cut me off is maybe being driven by a father whose little child is hurt or sick in the seat next to him, and he’s trying to get this kid to the hospital, and he’s in a bigger, more legitimate hurry than I am: it is actually I who am in HIS way.
Or I can choose to force myself to consider the likelihood that everyone else in the supermarket’s checkout line is just as bored and frustrated as I am, and that some of these people probably have harder, more tedious and painful lives than I do.
Again, please don’t think that I’m giving you moral advice, or that I’m saying you are supposed to think this way, or that anyone expects you to just automatically do it. Because it’s hard. It takes will and effort, and if you are like me, some days you won’t be able to do it, or you just flat out won’t want to.
But most days, if you’re aware enough to give yourself a choice, you can choose to look differently at this fat, dead-eyed, over-made-up lady who just screamed at her kid in the checkout line. Maybe she’s not usually like this. Maybe she’s been up three straight nights holding the hand of a husband who is dying of bone cancer. Or maybe this very lady is the low-wage clerk at the motor vehicle department, who just yesterday helped your spouse resolve a horrific, infuriating, red-tape problem through some small act of bureaucratic kindness. Of course, none of this is likely, but it’s also not impossible. It just depends what you want to consider. If you’re automatically sure that you know what reality is, and you are operating on your default setting, then you, like me, probably won’t consider possibilities that aren’t annoying and miserable. But if you really learn how to pay attention, then you will know there are other options. It will actually be within your power to experience a crowded, hot, slow, consumer-hell type situation as not only meaningful, but sacred, on fire with the same force that made the stars: love, fellowship, the mystical oneness of all things deep down.
Not that that mystical stuff is necessarily true. The only thing that’s capital-T True is that you get to decide how you’re gonna try to see it."
Because it is very very hard to ignore.
I very occasionally get death threats to my work email due to people being unhappy with some public facing stuff I do. It's unsettling but I can mostly ignore it. But if it happened all the time and I wasn't able to open my email or interact with a community without getting hate mail I'd go into a cocoon. People aren't machines. When hatred is relentless it is unbelievably difficult to put it aside.
Should they ignore the negative parts or should people who comment be mindful of the fact that a lot of open source they use is created in someone’s spare time and that they have a human being, not a company? I’d think the latter.
Sure. Both should but that would be naïve to expect the others to do. I write "people should" putting myself in place of the protagonist. Going to the woods don't make drama of the mosquitoes biting you.
3 replies →
Is this sort of action unprecedented?
What was Actix-web?
A web server built on an actor framework and probably the fastest Rust web server out there for many use cases.
I used it because it was easy to fill my niche case (TCP + UDP + WebSockets + HTTP interfaces to the same thing) as well as my boring CRUD apps, and it worked on stable Rust since a long time ago.
The author got a lot of flack for using "unsafe", then fixed most uses of "unsafe" and it has become something of a meme now. Unfortunately, there's an odd, almost religious crusade against unsafe in the Rust community, especially by those who don't really understand the ramifications of using unsafe incorrectly or how to tell whether unsafe is being used correctly.
It's a cool project and I have loved using it. I'm probably going to use something else unless someone steps up with a commitment to maintaining a fork.
Thanks for the explanation.
It's funny to see history repeat itself with "Unsafe" hooks. JAVA has a number of projects which also do this for speed and it always freaks people out.
I advise that you take some time away and either hand over the project or continue as its leader. Dont let the autistic assholes on the web get to you.
The open source equivalent of the rage-quit hehe.
I don't get it. This is a Git project. So did none of these people actually bother to clone it?
Probably easier to just rely on binaries . . . suckers!
There are plenty of repository clones, that's not the issue. The issue is that people want to contribute back to the same repository so you don't have to figure out which project is the just up to date. When a project like this goes away, it takes some time for everyone to figure out which fork is actually being maintained properly.
The best course of action, IMO, is to state that you're stepping away, perhaps indefinitely, and ask if anyone wants to be added as an admin to take over. That's not required, but it's a nice thing to do.
I'm sad about this on a lot of levels, any I hope the maintainer does what I'd like, but if not, I'll just wait a few months and see how the dust settles. For now, I'll probably go back to investigating other projects.
> and ask if anyone wants to be added as an admin to take over.
That's the worse possible course of action, this is how you get RCE vulnerability or bitcoin stealing malware injected into a popular project. Other random people should not be able to take over any project, they should do the work to promote their own fork and gain their own reputation. At least until we have a language able to protect from threats like that.
The Linux kernel has no central repository, they use email & stuff. I believe that is what the author of Git intended.
1 reply →
One of the downsides to GitHub is that it stores a lot of state that Git cannot capture, and is at the mercy of project maintainers to continue existing unaltered.
But forks prevent that, right?
1 reply →
In case you're directly impacted by this, https://www.arewewebyet.org/topics/frameworks/ provides a list of web development frameworks for use with Rust. Just pick one with a less cowboy-coding oriented attitude than Actix-web, and you should be OK.
Like it or not, it's best to view this incident as having direct parallels to the NPM left-pad incident.
Ignoring the specifics of what led up to this for the moment, observe that a single person was able to completely annihilate an entire dependency's source.
I think one of the primary requisites to reliable FOSS development and adoption will need to be tooling that maintains immutable records to the best of its ability, so that prior artifacts cannot be revoked; you publish code as FOSS, it is with the clear understanding that you have disposed of your authority to revoke it.
There are cases where something may need to be revoked, but make it a multi-layer process at that point, not a single button and one man's whim.