9 ms·

As a maintainer, it is his choice which patches to accept. If you're not happy with his decisions, choose another project, fork it, or pay someone to do it for

• cforrester 7y ago
  That doesn't mean it's wrong to criticize his choices, so long as it's done without being insulting.
  • deng 7y ago
    Of course you can criticize, but people are continuously demanding things, like "he should have labeled it as a toy project", "he should have given reasons why he didn't accept the patch", etc. And Drew is very right to say: No, he didn't have to do any of that.
    • unethical_ban 7y ago
      You know, there is a lot of "He isn't required" but I will say there are reasonable expectations that people have when a project gets to a certain level of exposure/downloads/etc. and while someone should not be "cancelled" or tarred and feathered for not accepting a merge request, if your project is a leader in its niche (Rust web frameworks) you should do better. You publish your code to Github, you're part of a community. You make it open and allow for contributions and see people are using it, you should be clear about your level of give-a-shit.
      • deng 7y ago
        > You publish your code to Github, you're part of a community. Hell no. It that were the case, I'd never publish anything. > You make it open and allow for contributions and see people are using it, you should be clear about your level of give-a-shit. It is YOUR responsibility to see that for yourself by watching how the project is actually maintained.
        • unethical_ban 7y ago
          Both are true. I obviously can't trust that maintainers will do what they SHOULD do via common sense and online civility, so I SHOULD vet them appropriately. Why do so many people insist on being aloof and unhelpful in communicating to users of their software? What is so hard about offering a modicum of context for what people can expect of you as a maintainer? It's so ideologically rigid and unreasonable.
      • pgeorgi 7y ago
        > You publish your code to Github, you're part of a community. Maybe. The main issue I see with github is that it's impossible to disable pull requests there. We have that issue in the coreboot project, which uses github as a read-only mirror. Maybe we should just shut that down to make clear that coreboot is not part of the "GitHub community".
      • bloodorange 7y ago
        I urge you (or anyone else who feels similarly) to seek a full refund for what you paid for the maintenance of that piece of software.
        • unethical_ban 7y ago
          I urge you to stop thinking about how aloof and unhelpful you are permitted to be, and consider how minimally helpful you could be in communicating to users of your projects.
          • bloodorange 7y ago
            Ah! Imagine the joy of the maintainers! They are "permitted" to not support software for free.
            • unethical_ban 7y ago
              Correct.
    • tssva 7y ago
      You are right that he didn't have to do any of the things people pointed out but that doesn't mean choosing not to do them isn't fair game for criticism and "he should have labeled it as a toy project" and "he should have given reasons why he didn't accept the patch" seem more like fair criticisms than making demands.
      • pgeorgi 7y ago
        > "he should have labeled it as a toy project" and "he should have given reasons why he didn't accept the patch" seem more like fair criticisms than making demands. Those are demands. The toy project one is relatively low cost, but "he should have given reasons" brings with its lots of effort to do right - and then you get to do it over and over again, because the masses can fling shit at you faster than you can reason about it.
        • tssva 7y ago
          demand: an insistent and peremptory request, made as if by right. critcism: the expression of disapproval of someone or something based on perceived faults or mistakes. "he should have ..." is clearly an expression of disapproval.
    • pfortuny 7y ago
      You can criticise but you are not allowed to COMPLAIN. That is my view.
    • temac 7y ago
      > he didn't have to do any of that Of course he didn't, in the legal sense of the term. And then people didn't have to stop criticizing him, in the legal sense of the term. And obviously for the ethical / moral point of view, people have vastly different opinions, otherwise there would not be this debate.
  • danso 7y ago
    Seems like the premise of Klabnik's article is that it was not done without being insulting.
• izacus 7y ago
  > As a maintainer, it is his choice which patches to accept. If you're not happy with his decisions, choose another project, fork it, or pay someone to do it for you. Sure, but that DOES NOT mean you're immune to criticism, especially when it comes to security. Your type of argument could otherwise be used for pretty much everything - even large corporations. It's not useful.
  • deng 7y ago
    > Your type of argument could otherwise be used for pretty much everything - even large corporations. It's not useful. No, if you pay for things, you have a contract and things are immediately different.
    • makomk 7y ago
      So basically, if you use open source code in your code, you should expect there to be security vulnerabilities which people know about and are keeping quiet about because it'd be unfair to the unpaid creator to criticise them? Tbat sure makes it sound like it's morally irresponsible to use open-source rather than purchased commercial code in something like a web-facing service in 2020, especially given what we know now about the damage compromises can do and the resulting legal climate.
      • komali2 7y ago
        You can report on security vulnerabilities in a library without being vitriolic. Find vulnerability. Already, awesome of you to have done. Issue patch request. That's 10x even better, you're a boon to the community. You submit it, it gets rejected, you find out why and it's the maintainer is just not feeling it or some other irrational reason. Fork, put in the readme why you forked, write a blog post without being a dick about it, done. The article we're talking about is referring to the bloodbath of a Reddit pile-on. That's totally unacceptable behavior from an adult.
      • deng 7y ago
        Please don't twist my words. I never said you have to keep quiet or that you're not allowed to criticize. If you see that a project has serious issues, feel free to write a blog post about it. Maybe offer to help, but don't demand your help being accepted.
• weberc2 7y ago
  It's also the choice of anyone else to criticize him for not accepting security patches.
• derefr 7y ago
  Sure, but once you’ve forked, now you have a fork only you use, but which you know is more secure than its upstream for reason X. That’s an unstable equilibrium—you want others to know of your fork, and to switch to it, so that other downstream projects can also be more secure. Adding to this, you might still transitively depend on the upstream through your other deps in ways you can’t change without either forking all your deps... or getting them to switch. And what does “getting the ecosystem to switch” look like? It looks a lot like complaining about the upstream, such that others in the community understand what the problem is that your fork is solving.
  • asjw 7y ago
    Or you could pay someone to do it If you depend so much on that code, if the security of your software depends on someone else's free work, why don't you hire that person to fix the bugs?
  • notyourday 7y ago
    The level of entitlement here is absolutely insane. If the community cares about security then should this happen: > Sure, but once you’ve forked, now you have a fork only you use, but which you know is more secure than its upstream for reason X. That’s an unstable equilibrium—you want others to know of your fork, and to switch to it, so that other downstream projects can also be more secure. The community would move onto your secure fork and the author of said fork would become a maintainer. As Dave Rand, the CTO of AboveNet used to say to newcomers who used to say 'X should be done!' -- "Thank you for volunteering - you are now in charge of X."
    • fragmede 7y ago
      Following Dave Rand's framework, the conversation went something like: "Atrix-web should not use unsafe" "Thank you for volunteering - you are now in charge of making atrix-web not using unsafe" "Thank you for delegating responsibility of making atrix-web not use unsafe, to me. I accept responsibility for this piece, but you are still the leader of $PROJECT." <workworkwork> "Here is a PR that makes atrix-web less unsafe." "I don't accept your PR." Dave Rand's advice doesn't apply here, as several people picked up responsibility for making atrix-web less unsafe, put forth the work to do so, but were rejected. It's one thing for me as a user to feel entitled to everyone else doing what I think they should, while not putting in any effort, but IMO it's less clear cut when I'm putting my money when my mouth is, and submitting PRs.
• Ygg2 7y ago
  As a maintainer, I treat almost all PR submission with kind words. What actix developer did was, to pardon my French, inexcusable. Deeming security patch boring? Making your own `Cell`, implementing it badly and misusing it, because it's faster on some stupid benchmark site? If we designed cars like that, they would have no breaks, no gears and no cabin. Honestly, I think it's better Rust abandons `actix` asap. Before it gets any real traction.
  • oaiey 7y ago
    The same "stupid" benchmark site let to dramatical improved .NET Core performance , re-engineered the .NET Server stack and even changed the C# language on the way. I do not know how the Rust community manages performance comparison, but the .NET bubble was broken by that page and resulted in awesome results for the platform. PS: just pointing out what the page achieved somewhere else. The discussion about the maintainer and what happened there is a different topic.
    • Ygg2 7y ago
      That might be true for Dotnet. But from what I heard, to get where it is, actix developer took some really bizzare shortcuts. E.g. hardcoding parts of response. On top of general unsafe usage. I think the benchmarks are flawed, since they don't account for such "optimizations".
      • oaiey 7y ago
        The benchmark is very smart in that sense. It has multiple stages (e.g. plaintext, db access,...). It proves with each stage deeper into your stack. You can disable there parts of your stack (e.g. middlewares, views, controllers, ...) and just operate on low level http request response pairs. And there you can hardcode on top then (as the application). The stages of the benchmark are optimized for testing individual disciplines like the connection and memory management of the low level http server and parser. In .NET case they changed the language in response to the needs of the Techempower benchmark (and the Unity3d engine) to allow safe and performing ops. .NET also has the unsafe keyword for low level ops and is surely also used. The advantage of .NET is that it was a team with a central manager who pushed all areas, http framework, base class library and language into the same direction. A community like Rust does not have that privilege.