23 ms·

A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this. I have two simple mantras which establish my philosophy her

• mlthoughts2018 7y ago
  > “ 2. Open source participants are volunteers and owe you nothing.” Absolutely not. They are compensated with prestige, enjoyment, decision-making power, future employment rewards, and sometimes even money, all of which was their choice to pursue through their labor and time spent on the open source project. The users of open-source projects, upon which the projects themselves depend, are also not obligated to anything, and can for example (very reasonably) become angry and complain if people prioritize pet features instead of community needs, or unilaterally take projects in unsupported directions. There is compensation for the work, and there are still social norms. Nobody cares one bit about who is entitled or not entitled to what.
  • pgeorgi 7y ago
    >> “ 2. Open source participants are volunteers and owe you nothing.” > They are compensated with > prestige, That seems associated with the popularity of a project which is largely outside the control of an author. So: how could one publish code (just in case it's useful to somebody else, which seems to be a nice thing to do) and opt-out of the popularity contest? > enjoyment, People can have the same enjoyment without publishing the code, so there's nothing open source about that. > decision-making power, In their own project? Of course. Again, they could just keep it private, with exactly the same decision-making power - nothing open source about that. > future employment rewards, If a developer ships crap code, that issue seems to sort itself out automatically (who would hire a proud author of unsafe code?) > and sometimes even money, Those paying money certainly can and do make demands. I haven't heard claims about breach of contract in this case, so that's probably not a factor here?
    • mlthoughts2018 7y ago
      > “ That seems associated with the popularity of a project which is largely outside the control of an author.” Huh?
  • vvillena 7y ago
    People have a right to become angry. They absolutely don't have any right to override the will of a project maintainer. By the way, isn't this a great opportunity? The code is open. Fork it. Seize the day. Become a better maintainer, and build a community around your fork. Ensure the community needs and wants are aligned with yours. Steer that ship. Gain prestige. And money, maybe. If someone is a bad maintainer, there will be no community, no prestige, and no money.
    • gwd 7y ago
      > People have a right to become angry. No. You have a right to be annoyed, and then fork the project if you want. You do not have a right to become angry unless you're paying for it.
      • vvillena 7y ago
        I'll clarify. I meant that people are entitled to their own emotions, and being angry is ok. What's not ok is to hurl the anger towards somebody. In this case, there are lots of other good options, all of them more productive and compassionate than simply grabbing the pitchforks.
      • mlthoughts2018 7y ago
        No, you do have the right to be angry, even for something you’re not paying for. Absence of a financial agreement does not mean dissolution of basic community norms.
  • mratsim 7y ago
    I didn't think I would see a "I will pay you with exposure" argument.
    • mlthoughts2018 7y ago
      Why? That’s the most likely type of reward you would get from a successful open-source contribution, and should be factored in to consideration of what is a priority.
  • pzixel 7y ago
    > Seems everyone believes there is large team behind actix with unlimited time and budget. (Btw thanks to everyone who provided prs and other help!) For example, async/await took three weeks 12 hours/day work stint, quite exhausting, and what happened after release, I started to receive complaints that docs are not updated and i have to go fix my shit. > enjoyment Riiight
    • mlthoughts2018 7y ago
      I think your quoted comment just proves the point. Without community complaint / critical response, there isn’t incentive for the implementer to do the thing the community needs. If you do X for enjoyment and it actively hinders some other group because they needed Y and using personal priorities to rank addressing X instead of Y is an egregious violation of community norms, people will take action to bring down the enjoyability of doing X and raise the enjoyability of doing Y, like complaining about X and thanking you for Y.
• streb-lo 7y ago
  Exactly this. If it doesn't meet your standards, don't use it. Alternatively, go fork yourself.
  • rusttoxic 7y ago
    The only time ever on earth where a homophone actually has been done well. Thank you.
  • silon42 7y ago
    Personally I plan to vendor all dependencies. It would be nice to have cargo/rustc support 'allow_unsafe' per module and also for dependencies, so you know you have to review a dependency really well.
  • ksec 7y ago
    >If it doesn't meet your standards, don't use it. >Alternatively, go fork yourself. I think this could be the new template for Open Source Author to include in their OS work description should they choose to.
  • guscost 7y ago
    This is my new CONTRIBUTING.md file for personal projects. Thanks!
  • mratsim 7y ago
    But then you get drama about Not-Invented-Here, why are you creating yet-another-X-framework instead of improving the existing ones. Or you get drama like ffmpeg vs libav/avconv.
    • bloodorange 7y ago
      Indeed. Many times, making a real effort and doing something has a real cost and risk associated with it. This is unlike demanding that someone else offer services which solve one's problem(s) while not offering any payment for it. The latter approach has minimal cost: it only harms one's dignity.
• dashwav 7y ago
  > It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change anything in the slightest. I don't think the anger is directed at there being security issues, the anger is directed at the fact that even when security vulnerabilities where found and patched, there was major pushback even getting those patches merged into the library. And regardless of how strongly you feel about 2), the community is extremely validated in saying "Hey this library in a language that professes security isn't secure and the maintainer doesn't seem to care". These statements aren't mutually exclusive
  • ddevault 7y ago
    >the community is extremely validated in saying "Hey this library in a language that professes security isn't secure and the maintainer doesn't seem to care" Yes, but that's not what they said. They were hateful and virtrolous, which is never appropriate. Fork it and fix the problems, create a new library which has the same API but is more sound, promote an alternative library in its place, offer to lend a hand in maintenance - these are the correct solutions.
    • jasondclinton 7y ago
      You're lumping a few bad apples (apparently recruited from Reddit) in with "they". The users who found the bugs and provided patches were largely courteous considering the circumstances.
      • kungtotte 7y ago
        Steve Klabnik makes this point in his write-up, but I'm restating it here for clarity. You don't get to cherrypick who is part of your community or not when these situations arise. Those "bad apples" are part of the Rust community, and the Rust community needs to take responsibility for them the same way any community needs to take responsibility for their bad apples even if it's just to denounce their behaviour. Good thing that those who submitted the patches and PRs were polite; they're not the ones who caused this maintainer to quit though I'd wager...
• rhodysurf 7y ago
  As someone who works for a dod contractor this whole situation sounds crazy. Just because something is available as a crate doesnt mean you are to assume it safe or appropriate for your use. The onus of verifying the dependencies should always be on the consumer.
  • landtuna 7y ago
    Haha - also a dod contractor, and sometimes wonder whether I'm the insane one who can't handle the wild west behavior of HN people surrounding npm packages...
    • dman 7y ago
      Its not just you.
    • rhodysurf 7y ago
      I have some side projects that use react and I dont mind cuz they are small time and react is fun, but seeing that list of dependencies scroll on the terminal makes me extremely uneasy everytime.
    • ryandrake 7y ago
      No, you guys aren’t the only ones. Not currently a defense contractor but was one in a previous life. Whenever I read articles and comments here on HN about dependency management I break out into sweats. It’s shocking how cavalier people are about pulling in third party dependencies, and this dismissive attitude about risk management: what exactly it is that the dependencies do, how suitable they really are for the project, what happens if they become not suitable (contingency plans), how auditable and traceable changes are, etc. It’s just “npm install” and YOLO for a lot of developers!
  • iknowstuff 7y ago
    That's what they were doing. They vetted it, provided patches and examples of triggering UB, and the maintainer called it "boring".
• TheRealDunkirk 7y ago
  Seems like there should have been some sort of response from the maintainer about the _philosophy_ of why he was doing things the was he was, and people could either get onboard with the connecting points of that, or get lost. So far, in all of this drama, I have yet to see where any of that might have been explained. I don't use Rust, but I understand the significance of the experiment, and I think I for one, would have liked to read the author's thoughts about "why."
  • lallysingh 7y ago
    Why is the maintainer responsible for that? They're just another dev who wrote something that became popular. It's almost like watching lottery winners having their lives ruined.
    • TheRealDunkirk 7y ago
      > Why is the maintainer responsible for that? It just seems to me that there's a give-and-take to being the maintainer of a popular open source project. You get help on the project in the form of people contributing patches, right? Doesn't simple human curtesy and a modicum of wisdom suggest that you should explain your rationale in accepting or rejecting them, to manage expectations, so that it doesn't end up like this? I know, I know. I'm taking my crazy pills again. Sorry.
      • amyjess 7y ago
        And this is why I honestly don't ever want to release an open-source project. At the very least, I'm not going to make it easy for people to contribute. I'll keep the git repo private, go without a ticketing system, and just post tarballs full of code on a self-hosted website (I guess like the NetHack team used to do before 3.6, but they had a ticketing system, and I wouldn't). Maybe I'll even use a non-free license just to reinforce my "you take what you can get" policy.
        • pjc50 7y ago
          Why? I mean, if you're that hostile to collaboration, why not just keep it closed source and maybe try to charge for it?
• bionicbits 7y ago
  I wish I could up-vote this 1000 times.
• lallysingh 7y ago
  The best justification for this attitude is that it's the most encouraging of open source development. Other attitudes raise the cost of open source development -- considering that it's already a losing proposition (w.r.t. lost time + opportunity) -- and will result in less quality open source software. People just won't put the work in if all they get back is this entitled bullshit.
  • AnIdiotOnTheNet 7y ago
    I feel as though there's a certain developer entitlement that also needs addressing though. Just because you made a software doesn't mean I have to use it or like it, and if you are actively trying to recruit me to use it then I am indeed entitled to complain about it. I see it frequently in the FOSS community where someone will suggest some software they made to solve a problem, get told why their software isn't actually that good for the problem, become defensive about it, and then try to play the "entitled user" card.
    • lostmyoldone 7y ago
      The opinion that the software isn't that good for the problem is cheap to state, and unless the circumstances are exceptional, I would argue it quite reasonable to see it as entitlement. If someone is terribly dressed according to my taste but brags about how amazing the garb is, I'm not going to tell them how they are wrong unless absolutely necessary because of exceptional circumstances. Neither does most people who respect others right to their own body, and creativity. I don't ring up the artists after visiting a gallery to tell them how their art is done, not unless I'm an ass. Source code is not much different, it is an expression of technical competency, art, taste, and fashion. If someone asks for feedback, sure, your points are not wrong. In practicing social dancing, asking if someone wants feedback before giving it generally works out really well. Most people want feedback if you give them the power to choose for themselves, but quite a few really do get hurt if it is unsolicited. There will be some people that get slightly annoyed that you ask, as they prefer more direct approach, but neither they or anyone else get hurt. Something similar probably works for open source projects too. Engage seriously for a bit, and only then ask if your input on your particular issues would be interesting to the other party.
• einpoklum 7y ago
  > It was never Nikolay's job to vet actix-web for you Perhaps, but if he claimed that it _was_ vetted, then he took on some responsibility for it (which he probably should not have). Also, the blog post article claims, that you are never supposed to use "unsafe" code without having vetted it. Honestly, I doubt that very much, but if it's true than that's some responsibility taken too.
  • xamuel 7y ago
    If a fundamental plank in rust's safety platform involves "apply the honor system to random people on the internet who swear they've vetted something", then that's a problem.
    • K0nserv 7y ago
      That’s not true, the convention is to annotate unsafe blocks with a comment explaining why the code is in fact safe. There are even projects that automate looking for these
• bpfrh 7y ago
  The article was not about that, this is not about vetting anything. The problem was that PRs which would have fixed security issues where not accpeted. Do I expected perfect code from maintainers or a answer the next day? No, never Do I think maintainers/creators should merge prs in a timely manner, or ask for help if it get's too much? Yes, otherwise you have multiple forks and the project is not usable anymore.
  • notyourday 7y ago
    Based on the noise the "maintainer shall/should/must/ought to" crowd is gigantic. It should not be an issue for this group to fork whatever they are kvetching about and do whatever "shall/should/must/ought to". So fork it and implement it!
  • vvillena 7y ago
    If this is the issue, one of those forks will become the new mainline repo everyone contributes to. Expecting a maintainer to behave the way the community wants is unreasonable. Maintainers are not public servants. I mean, anyone can fork it and become a maintainer, and create new guidelines and inclusive rules that ensure the project is steered in the "right" direction. Isn't it the case? I understand the "we just want a better actix-web", but there are two conflicting concepts, "better", and "actix-web". The way I see it, "better" is whatever the maintainers think it is, and "actix-web" is a project belonging to its maintainers. No community should ever be entitled to try to steal that. They are welcome to build upon it and fork it. This doesn't mean they have to separate ways forever: some forks live happy parallel lives, as so many Linux patchsets have demonstrated over the years. Projects are free to be born, forked, cross-pollinated, merged together, even die, all at the will of their maintainers.
    • cogman10 7y ago
      > If this is the issue, one of those forks will become the new mainline repo everyone contributes to. I know that is how it is "supposed to work". However, I've very rarely seen it actually work that way. The problem is the "first-mover advantage" and it is a hard one to overcome. If you make a "maintained actix-web" fork, most people will still find their way to the dead project. Even worse, many resources and tutorials will point to the old library. A search for "actix" will almost certainly give confusing and frustrating results to the novice.
• zpallin 7y ago
  Agreed. I think there is quite a lot of entitlement on the internet and as Klabnik pointed out: on reddit. And while it's definitely a maintainer's responsibility to make their code serve the interest of its users to the best of their ability, fundamental disagreement should result in forks, not vitriol. It's moments like this that I reflect on the past and the public and virtual forums I have participated in... and how my own attitude shifts in favor of cooperation when I must couple my face with my words. And I wonder if others feel the same.
  • nradov 7y ago
    Open source maintainers have no such responsibility. Anything you get for free is a gift, and giving a gift doesn't create any ongoing responsibility for the giver. Take it or leave it.
    • zpallin 7y ago
      I disagree here, but only within the confines of the language I used. A maintainer of open source code is willingly submitting their own work to be used for free by others. They have no responsibility to extend it at all, but to maintain it is to do so in the interest of the users... they have a responsibility to do it to the best of their ability, and if not, the maintenance should be given to someone who will.
      • HorstG 7y ago
        No. Just no. They may do so to the worst of their abilities. Thats their prerogative. The only limit might be publishing something that is actively intended to do harm. But I can't imagine a plausible example of that...
        • zpallin 7y ago
          You might not believe this, but I agree with you! Doing something to the best of your ability includes the right to be able to suck at it also. I am pressing for absolutely no standard of quality, yet you somehow think that's the case. It's not. I just think that if you're going to call yourself a maintainer of something, then you better at least pretend.
• wbl 7y ago
  Do you think we get software like zlib and libjpeg and BLAS and linpack by people shrugging off working for the community and failing to fix bugs? Otherwise we get dozens of half broken forks all over the place. That's no fun for anyone. This wasn't a drive by beg. This was a patch solving real demonstrable problems and at minimum there should have been a transition plan due to basic decency.
  • compiler-guy 7y ago
    "The maintainer owes the community something, simply because the community decided to adopt the project." Doesn't work that way, I'm afraid. The maintainer already gave the community something, and doesn't owe them anything more.
    • mratsim 7y ago
      They owe people who write PR basic courtesy, not refusing patches on ground that it is "boring".
      • compiler-guy 7y ago
        "Basic courtesy" is one thing. Accepting patches because they don't find them interesting is another thing, is different, and not required. Giving someone the mere ability to make a PR is already a gift far beyond what the original author owes.
        • mratsim 7y ago
          I'm not advocating for or against accepting the patch. I'm saying that the tone of the refusal is inappropriate.
• thrower123 7y ago
  When open-source gets up in arms over some guy doing or not doing something on his own time and dime, I just can't muster that level of ire and self-righteous anger. If you as a user don't like it, ask for a refund.
• elefantastisch 7y ago
  Meta-comment: Thank you. Online discussion would be much more productive if everyone clearly laid out the principles on which their viewpoint was based. Fundamentally, there are only a few ways honest people can disagree: Different principles, different information, different interpretation, or just plain misunderstanding. (Meta-meta: This is the principle that I believe and based this comment on.) Much of what makes online (and offline) arguments so unproductive is confusion over where exactly people are disagreeing in the first place. There's no point in discussing whether someone did the right or wrong thing if you don't even agree on the principles by which that rightness or wrongness will be judged. If I disagree with one of your principles, we need the discussion to be at that level, or more likely, we simply must agree to disagree. If I think there's another principle you aren't considering, we can debate its relevance. If you're missing key information, I can provide it. If you're misinterpreting something, I can offer my alternate interpretation and justification for why I think it's better. In any case, if I disagree, it's clear how to proceed because your line of reasoning is clear. We can engage in a productive discussion without talking past each other. As it stands, I agree with you 100%, but more importantly, you have raised the bar for discussion on this contentious issue. Thank you again.
  • solipsism 7y ago
    This is a bit Pollyanna. People aren't logic robots that start from first principles and then derive all knowledge from logical reasoning. People are emotional, irrational beings. Those of us who fancy ourselves rational are constantly involved in irrational motivated reasoning helping us maintain that desired worldview. Not to say we shouldn't try to live up to the ideal you set forth. We should do our best. But there's not some category of honest people among whom you can avoid human nature.
    • elefantastisch 7y ago
      To the point of "honest people": I added "honest" in editing to distinguish from people who are just arguing because they like fighting and wouldn't agree if you told them 2 + 2 = 4. There are plenty of those online too, and their reasons for disagreeing clearly aren't covered by my "reasons people disagree" principle. But as I understood you, point taken. The distillation of principles, information, and interpretation into an opinion does not actually occur as idealized in my breakdown. I wouldn't disagree with that.
• kenan_warren 7y ago
  I'm glad you said something because I felt like I was going crazy reading some of these replies. People sometimes seem to forget the phrase "Remember the human" when they interact with maintainers. It's a really frustrating situation to watch because one of the main reasons I make software is as a creative outlet. So, I can see where Nikolay is coming from being frustrated and upset. Sometimes people want to just go around kicking over other peoples sand castles. P.S. Thanks for making Sourcehut.
• fnord77 7y ago
  > It was never Nikolay's job to vet actix-web for you Imagine if the linux maintainers took this attitude. This attitude severely undermines the credibility of opensource. If users of opensource libraries can't have confidence that those libraries are written correctly, we might as well all go back to commercial software.
  • notyourday 7y ago
    They do. It is right there, in the LICENSE file. It is a simple cost/benefit analysis. Your risk of presuming that Linux today is sufficiently good for what you need to do is lower than it was 10 years ago, which is why Linux today is more popular than 10 years ago and a lot more popular than it was 20 years ago.
    • PhaseLockk 7y ago
      Following this logic, if a popular rust crate doesn't prioritize security, it can potentially change people's risk assessment of the rust ecosystem as a whole. So this maintainer's actions could have negative effects on other rust projects with no relation to his. He may not have an obligation to do anything about it, but it's kind of "not cool".
  • carapace 7y ago
    What would be the basis for confidence that those commercial libraries are written correctly since you can't audit the source code?
    • mfo4321 7y ago
      Judging by the feel of the thread, 'professionalism', defined here to be money exchanged. No need to audit the code, just sort by price and take the highest bid!
• skywhopper 7y ago
  I've worked with Rust only rarely, and never built anything real from scratch with it myself, so I'm curious: what tools are available to assess the safety of dependencies? I agree with you in principle that "you are responsible for your dependencies", but how would you go about doing that for a large complex dependency like this?
  • Macha 7y ago
    cargo-geiger will recursively warn you of unsafe code in dependencies: https://github.com/anderejd/cargo-geiger https://github.com/anderejd/cargo-geiger It's not a silver bullet, it will show you areas where memory safety issues could arise, but doesn't necessarily prove the presence of memory safety issues. Memory safety issues aren't the only type of security bug so them being impossible also doesn't mean it's entirely safe. You can think of issues like injection attacks or faulty ACL logic happening without memory unsafety. There's also cargo-crev, which is an attempt at making a web of trust for reviews of third party packages: https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev - for a longer form article on what crev's goals are and how it works, I found this explained it for me: https://wiki.alopex.li/ActuallyUsingCrev https://wiki.alopex.li/ActuallyUsingCrev
    • steveklabnik 7y ago
      miri is another good tool you didn't mention; it runtime sanitizes for undefined behavior.
• ksec 7y ago
  Thank You, you nailed it. There are always a high chances of being heavily downvoted on HN every time the question of entitlement comes into discussion. So I am glad this is the top reply at the moment. And I think that is the problem I have with this blog post, It reads to me as trying to spin it as something else with anxiety or Reddit, when what I see the problem is something very different based on principles and values.
• nickbauman 7y ago
  When you write "... the Rust project saw Rust as more than just the language. The community and the people mattered." I have to ask why anyone thinks this isn't true for ANY code/stack/dep out there? When I evaluate a technology for its appropriateness I first look at who's using it: Literally "Who are these people and what are they working on with this stuff?" The answer to this question determines more than 80% of the decision on whether the thing is going to be my choice. Rust seems to be being used most by people who are interested in blockchain and crypto. They tend to be of a near monolithic ideological caste, too, which has its own problems. Do I want to get into a situation where I might have my hat in my hand with these folks? Not really. (also the rust compiler is so slow I cannot believe it)
  • lukebitts 7y ago
    > Rust seems to be being used most by people who are interested in blockchain and crypto Where did you get that from? From what I've seen every single blockchain/crypto post on Rust's subreddit is downvoted into the negatives.
    • mratsim 7y ago
      Probably related to the Reddit job ads when you read /r/rust. That said, blockchain companies using Rust take security very seriously. It also funds cryptographic research which has a huge need of memory safety, performance and the possibility to implement constant-time primitives. I don't see why the community of a language that focuses on safety and speed is not excited by having the language being adopted by communities which absolutely cannot compromise on safety and speed (communities referring to both cryptography and blockchain communities as they are distinct). Disclaimer: I work in blockchain, I implement cryptographic primitives. While I don't use Rust, I do read a lot of Rust code from other blockchain projects or from cryptographers from elliptic curve cryptography to hashing functions.
      • floatboth 7y ago
        Oh, everyone likes cryptography and is reluctantly thankful that "blockchain" companies fund FOSS projects. But most people don't like "blockchain" because there's a lot of good reasons to dislike it. My reasons can be summed up as: "public blockchain" aka cryptocurrency is toxic — it's horrendously inefficient in the name of achieving censorship resistance, so people are literally burning fucktons of energy to make perfect "crime currency" work. It has fueled the rise of ransomware (and extortion in general) and all kinds of scams. Meanwhile "private blockchain" is just like good old merkle tree/hash chain stuff, infused with hilarious/awful marketing fueled by cryptocurrency hype. Good talk about this: https://www.youtube.com/watch?v=xCHab0dNnj4 https://www.youtube.com/watch?v=xCHab0dNnj4
• deleted 7y ago
  [deleted]
• braythwayt 7y ago
  My viewpoint is as follows: 1. Just because a thing exists, does not give you the absolute moral right to criticize it, especially in a way that is toxic for the person or persons that created it. Criticism affects both the people criticized and the community/universe at large, and not always in positive, productive ways. 2. Just because a thing is free, does not grant the thing or its creator absolute immunity from criticism. Things that exist have an impact on communities or the universe in general, and people are going to be affected. And not always in positive, productive ways. 1 and 2 can both be true, and I think they are both true. There is a judgment call involved as to when criticism is unfounded, unproductive, a distraction, and/or outright toxic, just as there is a judgement call involved as to when a thing’s existence in its current form is a net negative. You are not wrong about user entitlement being a problem, as noted by #1, and you are not wrong in a commercial sense about maintainers not owing any one person anything. But as per #2, I do not believe that is an absolute blanket injunction to never have an opinion about their choices or about the net positive or negative effect of the existence of the thing they maintain in its current form.
  • floatingatoll 7y ago
    #1 is imprecise to me in one respect. Critiquing someone's actions and choices is a founding principle of open source software, politics, and in general most human culture. "I think it was wrong to delete the GitHub issue because my belief structure XYZ" is acceptable. Critiquing someone personally based on their technical choices is not acceptable. Reddit allows it, and thus Reddit is unusable as a social platform for positive outcomes. "I think you are a bad person because you deleted a GitHub issue" is NOT OKAY. That distinction appears to be what led the creator to quit today, because the GitHub issue they deleted (perhaps incorrectly) contained personal attacks that linked their technical choices to their quality of human self (definitely incorrectly). I personally would have chosen to XYZ and I think they'll do so in the future if that comes up in a GitHub issue again — but focusing on that is incorrect here. The focus needs to be on those who wield personal attacks on others over technical choices, and on rewriting communities to prohibit and evict these participants in all cases where such can be done. Shun them, ban them, and prohibit them.
• agentultra 7y ago
  > 1. YOU are responsible for your dependencies. This is an understatement. I work in regulated environments where a software error has consequences. Dependencies must be vetted. If we end up relying on a dependency with known vulnerabilities the auditors are going to want to know what we did to mitigate the risk of this out-come. You need to have an answer for that question. I recommend packaging your upstream dependencies. That way you can patch vulnerabilities you find and ship those fixes today before those patches make it up stream. That's a risk mitigation strategy and often good enough to fend off auditors. Many (all?) open source licenses provide the software without any warranty or guarantee of merchantability or fitness for use. None. At all.
• dbcfd 7y ago
  > 1. YOU are responsible for your dependencies. They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back. Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code. Sadly, that led to some comments by people frustrated with the project, since they had likely invested considerable time at least using, if not more. But this was a situation that is entirely avoidable if Nikolay would have stopped promoting Actix as for production use.
  • aprdm 7y ago
    Where does it say he has to accept patches ? Couldn't they simply fork it instead of acting like entitled kids ?
    • NewsAware 7y ago
      Well, from my perspective it seems common practice in most open source projects which are hosted on GH that maintainers at least consider PRs and typically only reject if the PR is flawed, incomplete or somehow adds feature creep. Of course any maintainer is free to handle it differently, but if going against usual expectations, it would be benefitial for all involved to note reluctance to PRs prominently to the Readme.
      • virtue3 7y ago
        It takes time to validate a PR, to test it, to verify it. He is not being paid for his time, he does not owe -anyone- his time. If you don't like the way a project is being run, fork it and own it yourself. I know that's harsh, and not idealistic, but it's the way people should really think about this. People take FOSS for granted, CONSTANTLY. And maintainers even more so.
        • mratsim 7y ago
          The PR contributor was not paid either to investigate the bug, reproduce it, write a patch and test it. However instead of raising a "don't work, please fix" bug s/he took the time to do all that. Anyone that went to such length deserve basic courtesy, whether the code is accepted or refused. Refusing a patch because it is "boring" is not respecting the time people dedicated to your project. I would understand refusing because the patch makes an unwanted compromise on performance and the maintainer considers performance regressions as bug.
• deleted 7y ago
  [deleted]
• deleted 7y ago
  [deleted]
• tolmasky 7y ago
  There’s an interesting gray area here: am I as a customer responsible for knowing the dependencies of a service I use? Most of the time that’s impossible. And things like GDPR seem to imply that people believe users are entitled to some degree to demand certain standards (privacy/security) from all web services. This is the potential problem with “just fork it”. If the library is used by a great many products, and you know of a security vulnerability, merely providing an alternative that fixes it could be argued is not sufficient, while fixing it in the root library will patch the vulnerability in every product that has it in the next update. It seems we still haven’t figured out (and perhaps never will) the exact responsibilities between all the parties at play.
  • HorstG 7y ago
    GDPR binds an operator of a service. The developer can do as he likes.
    • tolmasky 7y ago
      My point is that GDPR raised the bar of our expectations of what a consumer can demand from a provider. As such, perhaps it is not unreasonable to expect that there would be an expectation from other services, especially if they are integral to the operation of many services that have personal information of millions of people. As a pure hypothetical, imagine a critical bug was discovered in Rails that would potentially allow someone to attack any Rails website and extract personal information. Further, imagine someone quickly submitted a PR with a patch for this, such that Rails could then do a quick release and make sure it gets to every Rails consumer as fast as possible. What if the Rails maintainers then ignored the patch, and said it was boring. Legally they are under no obligation to do anything really. And you could argue that it's on every one of the thousands of sites that chose to use Rails if they get hacked and expose user information. And further, you could argue that if people don't like this situation, they are "free to fork Rails" with the patched version. All this is fair, but I think others might say that the Rails maintainers at this point did fail in a responsibility. There are arguments for both sides, but I do not think it is as simple as "the maintainers owe people absolutely nothing" as at some point being the nexus of updates actually gives them an almost stopping or blocking power, not just the more passive refusal to fix the problem themselves. This scenario is clearly different in magnitude from what happened with this project. That being said, my only point is that it is fair to expect a certain amount of activity in a project that bills itself as production-ready (and asks you to use it). I personally would be very weary before committing to telling someone something is production ready casually, regardless of whether the "fault" ultimately rests on them. That being said, this of course does not entitle anyone to treating others poorly, my only point is that the responsibilities and expectations are not well understood in this domain.
• bcrosby95 7y ago
  I completely agree. This is why, as a small company, we prefer languages that have large organizations backing their open source libraries - such as Java - and prefer not to touch things like Rust with a ten foot pole.
• pdimitar 7y ago
  Agreed 100%. May I add one point? The OSS maintainer should clearly, upfront, preliminarily, outline how do they govern the project: how much are they open to change the project's core values, how responsive on average will they be in terms of opened issues and PRs, roughly how often would they engage in technical architectural debates -- stuff along those lines. I feel many people get toxic if they had unrealistic expectations -- and that's of course not okay. But IMO the OSS maintainers can be a little more preliminarily proactive in managing expectations from earlier stages.
  • xscott 7y ago
    > The OSS maintainer should clearly, upfront, preliminarily, outline how do they govern the project Why do you think they owe you this? You didn't pay them, and they didn't accept a contract.
    • pdimitar 7y ago
      I don't feel I am owed this at all. I feel only that it's being a good open-source citizen. When you make something that people use and like and want to improve, you should at least have the common decency to tell them beforehand: "this is my show, not gonna accept PRs". I don't think it's such an exhausting job to write two lines at the top of the README.
      • xscott 7y ago
        Appealing to "common decency" is just the same as "being owed". I think you're mincing words to avoid sounding entitled, and I don't think anyone is even entitled to two lines in a README, much less at the top.
        • pdimitar 7y ago
          All I am doing is saying that it takes very little effort to be upfront and hopefully avoid future confusion. You are free to disagree. ¯\_(ツ)_/¯
• ckdarby 7y ago
  > Open source participants are volunteers and owe you nothing. Equally, someone gets hit by a car while crossing the road. I don't owe them anything to go help them but society, morality and being decent are these unwritten rules that kind of do force you into owing something. Yes, I agree, volunteers don't owe anything but there are some unwritten rules that when broken should be frowned upon and I'd probably go as far as saying should be held against them. As a reader of this, you could be thinking, wow this sounds extreme but here is the easiest example I can give. - Someone writes library - Library comes insanely popular - Author refuses to allow the community to take over original project - Author wants to maintain status, ownership, etc - Entire community now suffers because the author doesn't owe anyone anything "Just fork the repo", is the most common response but let's be real, nearly nobody uses the forks and every other repo that uses this popular library is using the non-forked repo.
  • mottosso 7y ago
    Here's another one. 1. Someone writes a library 2. Library becomes insanely popular 3. Users receive value out of library 4. One day, users stop receiving value from library Is the author not responsible for the value generated by this library? At what point does the author become required to continue providing value? "Just fork it" is an excellent response to (4), anything else is what entitlement looks like.
    • oaiey 7y ago
      There should be a "then take over maintenance" option. A good maintainer also steps back and hands over the project. That is less troublesome for the community I think this is a good practice. But ignoring good practice: a unpaid maintainer owns nothing to anyone.
  • jhasse 7y ago
    > Equally, someone gets hit by a car while crossing the road. I don't owe them anything to go help them but society, morality and being decent are these unwritten rules that kind of do force you into owing something. In most countries they actually have written laws which require you to help in such a situation though.
• johannkokos 7y ago
  Given that Chromium is a open source project, and lost of people here are strongly against Google's proposal to limit the ability of ad block extensions, with much stronger words compared to this incident. What's your opinion on that?
  • Turing_Machine 7y ago
    Google is a gigantic, profit-making corpration, not a guy doing something for free as a side project/hobby.
• anaphor 7y ago
  This is a good reason to use Github only as a read-only mirror and just do all development elsewhere. That way you don't have to deal with drive-by issues / PRs from people who just want to complain or won't put in follow up effort.
  • juped 7y ago
    Why even have the read-only mirror?
    • anaphor 7y ago
      CI integrations, other tooling, etc can still be useful
      • juped 7y ago
        let me plug https://builds.sr.ht https://builds.sr.ht
• juped 7y ago
  I would add one more: your patch isn't good just because it exists. Maintainers should, in general, refuse more patches, or they're not really maintaining anything, just overseeing a disaster.
• nathell 7y ago
  > User entitlement is totally unjustified and will burn out maintainers faster than almost anything else. That's correct. Here's Rich Hickey's take on it: https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
  • rossjudson 7y ago
    +1000. That should be required reading for anyone starting or using an open source project.
• nabla9 7y ago
  As a someone who don't use Rust.. I started to suspect that this was satire with all the talk of inclusive and the use or 'unsafe'. I kept reading and reading in anticipation of gradual escalation that reveals it's satire. In the end there was none. I had to come here to read comments and to see if this was real or just very subtle satire. Apparently this is real. I just can't wrap my head around the "inclusive community building". What happened to "Those who write the code decide everything" and "You are free to fork if you don't like where this is heading". Any free community is as much about exclusion as inclusion.
  • edflsafoiewq 7y ago
    Rust has a strong culture of shame. The whole language surrounding unsafe is pregnant with the vocabulary of shame. Using unsafe or writing in a memory-unsafe language instead of Rust are grounds for public shaming.
• dcolkitt 7y ago
  > 1. YOU are responsible for your dependencies. This is a nice idea, but in an era of one-button package managers it just doesn't work like that. You're trying to fight against New Jersey style. Which in the entire history of software has never been a winning approach. The reality is that for 95%+ of active software developers, done is better than perfect. Yes there may be a small subset of developers working on super-critical defense systems or nuclear reactors. Who have the time, resources, know-how and organizational support to meticulously and carefully audit all of their dependencies. But the vast majority of developers are not in these types of environment. The mantra of the entire tech industry is "move fast and break things". Try being a Silicon Valley startup engineer and trying to justify to your manager that you could standup functionality with one call to "npm install", but that's not sanitary and you need to audit the entire dependency tree. Now assume that the next round of VC funding for your cash-strapped startup is on the line. How well do you think that concern will go over? The reality is that if something can be instantly installed in 30 seconds, then it will be. We can give as many "caveat emptors" as possible, but convenience trumps safety every single time. The way to solve this is to enforce consistency on an ecosystem level. The best example of this is the Debian project. There's very firm guidelines about QA and safety before a package is allowed into stable. The Debian people are probably right about another thing too: language-level package managers should be considered harmful. Many of these problems could be avoided if we strictly used apt-get instead of pip, crate, and npm. For one distro maintainers tend to have a lot more experience and competence at evaluating stability and safety. Two, since a system only has one distro package manager, but potentially many runtime environments, it prevents a race to the bottom. Harried developers will just gravitate towards the least strict runtime with the most low-quality packages. This lesson is probably very tough for the Rust community to swallow. Crate is considered one of, if not the most, compelling features of Rust. If we acknowledge that it was a mistake, it really undercuts the argument for adopting Rust.
  • pjmlp 7y ago
    It sure does work like that. Our package managers have in-house mirrors, only validated dependencies by legal are allowed on those mirrors. Installing in 30 seconds is not allowed by design.
  • 7y ago
• Alex3917 7y ago
  > Open source participants are volunteers and owe you nothing. Of course they do. It’s not legal for you to distribute software that puts others in harm’s way. You’re not allowed to give poisoned food to homeless people as long as it’s free.
  • nomadnomad 7y ago
    Of course they don't. It is Free OSS. And you implying that the maintainer put someone's life in harms way is simply not true. And the LICENSE says - no warranty or guarantee whatsoever... Use at your one risk. And the homeless people analogy makes very little sense, excuse me for being blunt. You are comparing software developers who use FOSS to homeless people??? You are comparing someone's FOSS project on github to poisoned food??? Are you for real??
    • Alex3917 7y ago
      > And the LICENSE says - no warranty or guarantee whatsoever Lol. That’s about as legal as saying you can’t be arrested because you’re a sovereign citizen.
      • nomadnomad 7y ago
        You keep using bizarre analogies and terminology. Homeless people, poisoning food, arrested... It is as sounds as saying a dragon gorilla group consumes errors in the background...
• Wowfunhappy 7y ago
  > Open source participants are volunteers and owe you nothing. I can't agree. Not for all participants. Let's take Linus. He's in charge of the Linux project, which thousands (millions?) of people contribute to every day. If Linus suddenly stopped merging any and all patches—but refused to officially step down—what do you think would happen? Oh, the project would more than survive—someone would fork it and that would become the de-facto new mainline kernel—but there'd probably be a couple weeks of chaos. Does Linus bear zero responsibility because he's a volunteer? --- Every Saturday, I volunteer as an assistant teacher (they call us "facilitators") at a Girls Who Code club, a free weekly class to teach computer science to young girls. I don't get paid for it, but that's okay—the kids are adorable and teaching them is fun. The primary teacher is also a volunteer. If we both decided to just not show up one week, and parents brought their children to the library and found an empty room, would that be okay? Personally, I do think I owe something to those students, and to the primary teacher. I've made a commitment to show up every week and do what I can to help a group of children. My commitment is what matters, not whether it generates income. Now, there's actually second GWC class for slightly older students which starts right after the first one. Sometimes I help teach that one, and sometimes I go home. I told the primary teacher I'll stay "when I can", which actually means "when I feel like it". There's certainly a place for doing work without a commitment to continue, but your intentions need to be clear. Most large projects are not going to function without a commitment from someone somewhere in the chain. One weekend in October, the primary teacher had plans to go traveling in Europe. She asked if I could cover both classes that week. I said I would, and I did.
  • oaiey 7y ago
    Linus is paid to carry that responsibility. Others are not.
    • Wowfunhappy 7y ago
      True, but for the reasons I detailed above, it's not the payment that matters. Linus could also probably make more money on a different project, but he's committed to Linux.
• trunnell 7y ago
  That's good advice on how to treat others-- don't act entitled toward open source maintainers. Thank them for their work. But what exactly are the responsibilities of a maintainer? How far should you go to fix bugs? How thorough should you be about your code's limitations? If you're doing a project just for fun, should you discourage others from using it in production?
• MadWombat 7y ago
  While it is tempting to agree, I feel that if you take these principles to their logical conclusions, you lose any incentive to actually participate in any open source projects. If I cannot expect the author to even look at my code or read my issue reports, there is no reason for me to write the reports or share my fixes. If all my dependencies are my responsibility, the logical way to go is to fork every code base I am going to use, review all the code, fix whatever issues I find in my fork and never share any of it with the original project because there is no reason to.
• temac 7y ago
  While I 100% agree with you, project having chronically technical issues are bound to get a bad reputation. So what is "missing" is a common way to discuss about that kind of issues, as a community, while staying civil and not in a way that is worse than the initial issue. In some cases the end-result could be the kind of the same (if most users flee), but the goal is obviously to improve the ecosystem and if managed more appropriately, it is possible that some maintainers are wanting to improve their software to the state of the art.
• hinkley 7y ago
  > Open source participants are volunteers and owe you nothing. And a lot of the internet has this wrong, including you. Let me start by saying that Open Source is not a zero-sum game. I can make a library like your library and it doesn't have to be an adversarial relationship. I have users, you have a few less users. But there are costs to having more. There is still only so much space in the ecosystem for so many actors. The more logging libraries we have the harder they are to find, the more drama there is over picking one... The best analogy I have is a party. If I throw a party this weekend, and your birthday is next month, then I'm not hurting you. If I throw it the weekend of your birthday, knowing it's your birthday, I'm kinda being a dick. That's not cool, and you have every right to be upset. Okay, but what does any of this have to do with Open Source projects, hinkley? I'm within my rights to throw a party. But my guests are within their rights to be upset if I throw a shitty party. They showed up. They could have been doing something else. But I insisted on taking up space and now I'm being ungracious about it. It's my party and I can treat people how I want is technically the truth, just like "I can do Open Source and ignore the concerns of my users" is technically the truth. What I'm saying is that the people who show up don't have to like it. They're entitled to complain to people about it, especially if I don't apologize and say I'll do better next time, or get help. It's my party, I can cry if I want to, but people are gonna talk. [edit to add] I think the problem is that we have a bunch of people who throw themselves into software at a young age because of or at the expense of social awkwardness, and we insist on treating things and other people as if they are machines instead of people who are also just trying to do the best they can. I'm fully aware that this observation cuts against my argument as well as supporting it, but we can't go on coddling people and organizations for ignoring the very real social aspects of our work. For being poor hosts. And it's really hard, believe me I know. But people want to see that you're at least trying, or they will paint you the villain.
• tolmasky 7y ago
  > 2. Open source participants are volunteers and owe you nothing. If this were true in the strictest sense, then they would be free to put malicious code and trick you into using their stack just to then steal credit card numbers from your database. Of course this is not true, and they would appear to at the every least owe us "good faith" or perhaps some basic guarantee that they are not purposefully trying to criminally attack you. This may seem like a useless edge case to bring up, except for the fact that the law does have some amount of consideration for negligence. Arbitrary people you don't know owe you nothing too, and yet if you walk onto their premises and get hurt, the law has found in certain circumstances that they are indeed at fault. Expectations and responsibilities evolve with time, and as new scenarios come up. It is not clear to me that putting up a project that invites people to use it in production could not be argued to some extent to be negligent if it willfully blocks and delays fixes that could affect real world customers. At the end of the day, if people were using my code in production, and a discovered exploit was used to steal people's data and I could have prevented this by merging in code that wasn't 100% to my aesthetic liking, then I think I would feel bad. Fault isn't binary, maybe its the fault of a random company using my framework for not being up to the minute on all vulnerabilities and manually patching the code themselves, maybe its their fault for using my framework in the first place given the youth of the project too. But I don't think I would go to sleep that night feeling great is all I'm saying. I'm not super familiar with this particular case, but the OP blog post was phrased as kind of wanting to open up a dialog or discussion on the nature of these issues. I am bringing up some thoughts about this stuff I've had for a while and I think at least help to understand some of the moving parts involved. For the record, I don't really know where I stand "absolutely", or if its possible to have a clear principle that doesn't take into account some number of additional variables (how the project was portrayed, how many users it has, etc.).
• ssokolow 7y ago
  However, everything has its downsides. For example: > 1. YOU are responsible for your dependencies. This contributes to the prejudice against `unsafe`. If I wanted to be a full-time auditor, I wouldn't be steering clear of C and C++. Since I'm a responsible coder, I avoid depending on `unsafe` outside of `std` or the simplest of FFI wrappers with extreme prejudice, to the point where I consider NIHing an alternative or just sticking to a managed language with a more mature ecosystem, depending on the project.