8 ms·

Personally I felt people on GitHub were being way too harsh. He built something, moved on, and gave it away. He had no way of knowing the person who took it ove

Personally I felt people on GitHub were being way too harsh. He built something, moved on, and gave it away. He had no way of knowing the person who took it over would use it maliciously. Seriously, some of the comments blew my mind. Because he built it, he had a responsibility to maintain it forever, and was responsible for everything that happened with that code forever? Maybe calling free software "Open Source" was a mistake. If something is "free", then you have to accept you may get what you paid for. If you are using somebody else's code, is it their responsibility to look after it years after they have moved on, or your responsibility to make sure it's not full of bugs or malicious code.

madrox 8y ago
Kind of sad that people are more angry at Dominic than the malicious updater. Seems there is a bit of a "boys will be boys" phenomenon going on.
- TAForObvReasons 8y ago
  To an extent it's because his name is in the repo name (dominictarr/event-stream) https://github.com/dominictarr/event-stream https://github.com/dominictarr/event-stream so he is an easy and obvious scapegoat. But it seems people in general forgot that they are not paying and are not entitled to any sort of support.
  - nailer 8y ago
    People in this case aren't asking for support, they're asking for the project to have been given to a trusted maintainer or declared abandoned.
    - mehrdadn 8y ago
      To be honest I wouldn't expect an abandoned project to be any different. I would expect it to have lost its maintainer, not switched from a trustworthy maintainer to a malicious one. Edit: Clarified second sentence.
      - madrox 8y ago
        No maintainer is malicious...until they are. Be honest with yourself: how many dependencies have you vetted the maintainer before including? If n > 0 then you're just as susceptible.
        mifreewil 8y ago
        I wouldn't just add some random maintainer with a new GitHub account to a project I controlled. If they had made some contributions via pull requests, I would consider it or if they were a maintainer of other projects with actual users. In this case, there was no vetting at all. A brand new GitHub account with a couple forks. I'm not placing all the blame on the original maintainer as I understand his philosophy of handing off the torch, but I think it's a naive thing to do, as this has shown. Ultimately, this has been a good demonstration of a weakness with the ecosystem and I think there are a lot of things that could be improved here to help mitigate this in the future.
    - sytelus 8y ago
      How do you suggest finding trusted maintainer who would not turn malicious at later date?
      - nailer 8y ago
        I don’t. No guarantees of anything. But we can probably do better than random Chinese dude with no other projects or contribs
- mehrdadn 8y ago
  I think people are just drawing a distinction between fault and responsibility. Neither is a subset of the other.
  - madrox 8y ago
    This, I think, is a sucker's argument. Responsibility is not putting trust in a dependency they themselves have no control over. Responsibility is not letting yourself get into an obviously bad situation. It's not even the first time this has happened to NPM. Remember left pad? No, this thread didn't happen because a bunch of developed chose to make this a conversation about responsibility more than fault. They're mad they got suckered and Dominic is the best scapegoat.
    - mehrdadn 8y ago
      > This, I think, is a sucker's argument. Responsibility is not putting trust in a dependency they themselves have no control over. Responsibility can fall on multiple people. I don't understand why everyone looks at things in such a binary way. Responsibility, fault, etc. are not binary things. Two or more people responsible for one problem can be both upset at each other perfectly justifiably.
      - randallsquared 8y ago
        Responsibility is a hard problem. It's quite true that more than one person can be responsible for something, in part, but there's only so much responsibility to go around: whatever damage irresponsibility causes, more than one person cannot be responsible for the full damage, if we're going to maintain any consistency.
        marcus_holmes 8y ago
        Authority and Responsibility go hand-in-hand. If you have authority over something/someone, then you are responsible for it/them. You cannot be responsible for something you have no authority over, and you should not have authority for something you have no responsibility for. In this case, every developer has authority over their own code base. If I decide to include some random code from the internet in my project then I am responsible for that decision. If whoever has commit privileges on that random code decides to commit malicious code, then they have responsibility for that. However, that doesn't make them responsible for my project, because they have no authority over my project. Including a dependency in a project is a security vulnerability. It may be worth the risk, it may not, but it is definitely a risk. And responsibility for taking that risk is entirely on the person who took the decision to include that dependency.
tathougies 8y ago
The entitlement mentality of some people is insane.
- tonyedgecombe 8y ago
  Especially when they aren't paying.
vernie 8y ago
Sayre's law, baby.
- QuantumGood 8y ago
  Intensity of feeling is inversely proportional to issue value sometimes. Recent US political discourse seems to violate Sayre's law.
bendmorris 8y ago
>He had no way of knowing the person who took it over would use it maliciously. Then it was, clearly, negligent of him to give it to this person. He gave a stranger the power to do things in his name. He doesn't have to maintain the project forever - it seems like a much easier solution is: don't give away a project with your name on it to someone you don't know. Instead, encourage them to fork and release a new version under their own name. This is a surefire way to never have an exploit spread to thousands of people with your name on it.
- runarberg 8y ago
  As a user of free software you should always accept the risk that it is maintained by a malicious actor. It is just as likely that the original author will turn malicious. You as a user have the responsibility of auditing all the free software you use.
  - bendmorris 8y ago
    People keep casually making this suggestion. In JS this can involve hundreds or thousands of transient dependencies. Have you ever (1) worked on a React app and (2) vetted all of React's 829 dependencies yourself? It's not remotely feasible. The only solution becomes "then don't use React!" - is this the best we can do?
    - RSZC 8y ago
      React does not have hundreds of dependencies: └─┬ react@16.6.3 ├─┬ loose-envify@1.4.0 │ └── js-tokens@4.0.0 ├── object-assign@4.1.1 ├─┬ prop-types@15.6.2 │ ├── loose-envify@1.4.0 deduped │ └── object-assign@4.1.1 deduped └─┬ scheduler@0.11.2 ├── loose-envify@1.4.0 deduped └── object-assign@4.1.1 deduped
      - LeoNatan25 8y ago
        React Native then. 1200+ last I remember.
    - 8y ago
pmoriarty 8y ago
Users have to come to grips with the possibility that the "free" code they download might be malicious. To mitigate the risk they have these options: 1 - Don't use the software. 2 - Audit the software themselves before they use it. 3 - Pay someone to do the auditing for them. Even if they choose options 2 or 3, there's still a chance the some vulnerability of malware could sneak through (especially if they're getting a binary blob or source code written in a language like C that makes obfuscation easy). But if they choose to use unaudited software, they're playing with fire and shouldn't be surprised if from time to time they get burnt.
- rapnie 8y ago
  I wonder if there are projects out there for an option 4: 4) Use an OSS dependency checker tool that reports the risk in your dependency tree 4a) Dependency tool uses a crowdsourced database of audit/review metrics A typical NodeJS project has potentially 1,000's of (transitive) dependencies. Many well-established projects use dependencies versioned e.g. 0.0.1 etc. I guess there are hundreds of similarly unmaintained packages among these. Lacking 4) a small-time developer working on a side-project only has option 1) (or option 0 - Take the risk) as a feasible way to go.
- wstuartcl 8y ago
  Users have to come to grips with the possibility that the "free" code they download might be malicious. denial, anger, bargaining, depression and acceptance. ^^^^^
aikah 8y ago
People are dealing with a lot of negativity in their life, they shouldn't have to deal with that entitled bull-crap online, especially when doing unpaid work. Should the maintainer have been more cautious? no, he should have straight out closed the project and just ask people to fork it or use something else. If you are not going to maintain something anymore, don't even bother worrying about passing the torch. That way nothing is your responsibility anymore. The people who complain, insult the maintainer in Github issues right now will be at the root of a shift of mindset from contributors that will end the "golden age of open source".
- kylecordes 8y ago
  I think this is the clearest, easiest, correct answer. If you no longer have the time and motivation to maintain a project, and are also not in a position to hand over control to someone you have good reason to trust, the easy, safe answer is to retire it, and have others fork. Then in the original project you can say “the last version of this project is N.N; here are some possible candidate successor forks, which have not been vetted”. This way no one who is merely keeping up with version numbers will accidentally step off of a reasonably good package on to a fraudulent package.
  - Novashi 8y ago
    >I think this is the clearest, easiest, correct answer. If you no longer have the time and motivation to maintain a project, and are also not in a position to hand over control to someone you have good reason to trust, the easy, safe answer is to retire it, and have others fork. To prescribe some preventative advice based on this: it's probably not a good idea if your project gets popular to continue being a solo developer in open source. So plan ahead based on your popularity. And your project isn't likely to explode in popularity over-night and be a dependency for 1000+ other projects, so you should be able to see this coming. Of course, this is super-easy to prescribe in hindsight.
  - wpietri 8y ago
    I 100% guarantee you that if he did that, he'd be getting a lot of static about how he should have handed the package over to some contributor.
Y7ZCQtNo39 8y ago
It's impractical, on an individual level, to vet your entire dependency tree. Installing something like react alone will put 100+ modules in your dependency tree. A more mature project will have a 4-figure number of dependencies. Things like Node Security Platform (which was absorbed by NPM) exist for a reason. There's no reason for every person to vet every single package they use -- it'd be an awful lot of duplicated energy. If there was no implicit trust in the community, and we had to act as vigilant as you describe, there would be no community.
- reitzensteinm 8y ago
  This is a bit of a strawman. It absolutely is your responsibility, but that doesn't mean you can't outsource it.
  - Y7ZCQtNo39 8y ago
    It's the kind of thing where, if everyone with this problem chipped in $5/month, we could have a central repository of vulnerabilities. So, not absolving yourself of responsibility, but also way more efficient to outsource.
- RSZC 8y ago
  (React does not have 100 dependencies, it has 5 including indirect dependencies)
  - deleted 8y ago
    [deleted]
  - Y7ZCQtNo39 8y ago
    A more mature project wouldn't have just React as a dependency. Point is, it's a lot of code to vet. React may have 5 indirect dependencies, but in my projects, I have 30 or more direct dependencies.
coleifer 8y ago
I experienced a twist on this. A guy who had very different aesthetic taste wanted me to merge some patches. He got real entitled about it, eventually I banned him. THEN he did the "appeal to Twitter" and made malicious edits to the project page on wikipedia. He made a huge stink and wasted hours of both of our time. It was unreal! I wish I was joking. I wrote about it, discussing my motivations for open source: http://charlesleifer.com/blog/your-idea-sucks/ http://charlesleifer.com/blog/your-idea-sucks/
- danso 8y ago
  A. Damn, I would think a CTO would know to quit this dispute and fork his own purportedly superior version, if his company's survival is so dependent on it. B. Really like the elegant style (visually, though the writing is also elegant!) of your blog.
- glogla 8y ago
  You shouldn't have hidden his name. We should know who it is, in case we meet him or something.
  - coleifer 8y ago
    Then I'd be doing exactly what he did, just dressed up a little in a blog instead of twitter.
    - glogla 8y ago
      No. Complaining about horrible behavior is not horrible behavior about itself.
jxramos 8y ago
I caught that notion they had > I've shared publish rights with other people before. Of course, If I had realized they had a malicious intent I wouldn't have, but at the time it looked like someone who was actually trying to help me. Can anyone cite perhaps a handful of examples where this malicious open source usage ultimately bit them?
mwfunk 8y ago
Well they certainly couldn't call it "free software", that involves many more assumptions than "Open Source", and it might not even be free of charge. :) Blame Richard Stallman for using an incredibly common word with many meanings to refer to something that has one incredibly specific meaning which is unintuitive to most people, and to pretty much anyone who isn't a developer. I think several decades of Open Source boosterism may have eventually given some people the wrong idea about what it's all about. Two annoying trends I've noticed in the last 10 years: (1) (what this poor guy seems to be running into) People treating Open Source as anything other than charity from the people who put it out there. The people who make it generally don't owe anyone anything, including the people who use their code. I sometimes see very harsh criticism from people within the community that assumes anyone putting anything out there has to accept all sorts of responsibilities: maintaining a community, keeping on top of bug reports, acting as an integrator for people who want to send in patches, making sure that all packaging and documentation conform to some very high bar and/or specification, etc. Just because somebody puts something out there doesn't mean it has to be a second job for them, and doesn't mean that they are obligated to do anything for anyone, including responding to emails or dealing with bug reports or patches. It's perfectly fine to stop maintaining something after a while, or to just throw code over the wall and never touch it again after it's out there. (2) (not this case) People treating Open Source as some avenue to professional fame or an eventual source of income. Yeah, that can happen, but it very rarely happens, and it's not a good reason to write it in the first place. This is the result of too many people using business arguments as a fundamental justification for doing Open Source, and people saying stuff like they only hire people who have projects on Github, and only if they like what they see. If someone's primary motivation is fame or money, Open Source is a terrible way to accomplish that. It's possible, just highly unlikely, plus I think it's much less likely to happen if that's someone's goal from the outset.
- jungler 8y ago
  I think there is an underlying root cause to how we treat Open Source, and it's similar to the IT "cost center vs value creator" problem: Open source packages are treated as consumer goods, and creators in turn will engage with that by marketing them as consumable products. Many of these things which are distributed as packages are actually code snippets. They could be maintained in the form of a Stack Overflow answer to copy-paste into your code. The question-answer system exposes the code to the necessary competitive evaluation: a malicious answer soon gets downvoted. When the packaging metaphor is laden over them, the whole chain of responsibility lapses back to the vendor-consumer model. And this works when packages are large and take pains to reduce their own dependencies, even if it means common functions get duplicated across different packages. But prolific authors currently are rewarded by being vendors of undersized packages: they enjoy large download numbers, Github stars, and so on. Without any kind of curation to impose friction on this process, they can do the wrong thing for a very long period and get zero feedback indicating that their actions create a problem. And on the consuming side nobody pays a lick of attention when the prompt says it's going to install 50 things with cute-but-opaque names. If they are under a page of code each, you could probably just print the code. When I create projects now, I tend to grab some packaged code to start with, but apart from a few to do core functions like I/O I will treat them as placeholders and seek ways of reworking the code to make myself the sole maintainer. The alternative is to be a software consumer and to complain like a consumer - i.e. in a largely powerless fashion - when other people's code doesn't do what I want.
B-Con 8y ago
> Maybe calling free software "Open Source" was a mistake. This conflation is definitely a bad thing. Words with an actual meaning get over-used, simplified, stripped of their original meaning, and then merged. It would be 100% to the detriment of our language if it happens in this case. Open source does not mean free (as in freedom or beer), free (as in beer) does not mean open source. Free as in freedom almost always means open source. Side rant: Also, open source doesn't mean "open to contributions". Giving access to the source code does not mean obligation to accept contributions to said source.
- type0 8y ago
  > Side rant: Also, open source doesn't mean "open to contributions". Giving access to the source code does not mean obligation to accept contributions to said source. How true, this is such a common misunderstanding among newcomers to FOSS, it can't be repeated enough times.
sytelus 8y ago
This problem can be solvable by introducing “Verified Identity” on GitHub. Anyone who wants to be maintainer of popular project can be asked to get Verified Identity. If this person turned out to be malicious, he risks getting tracked down by law enforcement fairly easily. For getting Verified Identity, simplest thing might be validation of phone number. Bit more complex thing might be Verified bank account or credit card. Assuming GitHub has 1M active users and each user verification costs $5, the cost of solving this problem is less than 0.1% of GitHub valuation but can hugely improve trust levels.
- jdorfman 8y ago
  Good idea although $5 to a person writing malicious code and out of jurisdiction isn't much of a deterrent IMO.
- peterbraden 8y ago
  Why on earth would anyone want to be on the hook for liability like this for an unpaid maintenance job? Open source licenses state this clearly: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND"
AsyncAwait 8y ago
Agree with you, just note that the term "free software" doesn't actually refer to software price at all.
type0 8y ago
> Maybe calling free software "Open Source" was a mistake. If something is "free", then you have to accept you may get what you paid for. Since no one seems to care about the freedom aspect of it, maybe we could rename it to "fee software" - give it away for free and encourage everyone to contribute with time and money. Will people stop being selfish because we changed the name? I don't think so.

madrox 8y ago

Kind of sad that people are more angry at Dominic than the malicious updater. Seems there is a bit of a "boys will be boys" phenomenon going on.

TAForObvReasons 8y ago
To an extent it's because his name is in the repo name (dominictarr/event-stream) https://github.com/dominictarr/event-stream https://github.com/dominictarr/event-stream so he is an easy and obvious scapegoat. But it seems people in general forgot that they are not paying and are not entitled to any sort of support.
- nailer 8y ago
  People in this case aren't asking for support, they're asking for the project to have been given to a trusted maintainer or declared abandoned.
  - mehrdadn 8y ago
    To be honest I wouldn't expect an abandoned project to be any different. I would expect it to have lost its maintainer, not switched from a trustworthy maintainer to a malicious one. Edit: Clarified second sentence.
    - madrox 8y ago
      No maintainer is malicious...until they are. Be honest with yourself: how many dependencies have you vetted the maintainer before including? If n > 0 then you're just as susceptible.
      - mifreewil 8y ago
        I wouldn't just add some random maintainer with a new GitHub account to a project I controlled. If they had made some contributions via pull requests, I would consider it or if they were a maintainer of other projects with actual users. In this case, there was no vetting at all. A brand new GitHub account with a couple forks. I'm not placing all the blame on the original maintainer as I understand his philosophy of handing off the torch, but I think it's a naive thing to do, as this has shown. Ultimately, this has been a good demonstration of a weakness with the ecosystem and I think there are a lot of things that could be improved here to help mitigate this in the future.
  - sytelus 8y ago
    How do you suggest finding trusted maintainer who would not turn malicious at later date?
    - nailer 8y ago
      I don’t. No guarantees of anything. But we can probably do better than random Chinese dude with no other projects or contribs
mehrdadn 8y ago
I think people are just drawing a distinction between fault and responsibility. Neither is a subset of the other.
- madrox 8y ago
  This, I think, is a sucker's argument. Responsibility is not putting trust in a dependency they themselves have no control over. Responsibility is not letting yourself get into an obviously bad situation. It's not even the first time this has happened to NPM. Remember left pad? No, this thread didn't happen because a bunch of developed chose to make this a conversation about responsibility more than fault. They're mad they got suckered and Dominic is the best scapegoat.
  - mehrdadn 8y ago
    > This, I think, is a sucker's argument. Responsibility is not putting trust in a dependency they themselves have no control over. Responsibility can fall on multiple people. I don't understand why everyone looks at things in such a binary way. Responsibility, fault, etc. are not binary things. Two or more people responsible for one problem can be both upset at each other perfectly justifiably.
    - randallsquared 8y ago
      Responsibility is a hard problem. It's quite true that more than one person can be responsible for something, in part, but there's only so much responsibility to go around: whatever damage irresponsibility causes, more than one person cannot be responsible for the full damage, if we're going to maintain any consistency.
      - marcus_holmes 8y ago
        Authority and Responsibility go hand-in-hand. If you have authority over something/someone, then you are responsible for it/them. You cannot be responsible for something you have no authority over, and you should not have authority for something you have no responsibility for. In this case, every developer has authority over their own code base. If I decide to include some random code from the internet in my project then I am responsible for that decision. If whoever has commit privileges on that random code decides to commit malicious code, then they have responsibility for that. However, that doesn't make them responsible for my project, because they have no authority over my project. Including a dependency in a project is a security vulnerability. It may be worth the risk, it may not, but it is definitely a risk. And responsibility for taking that risk is entirely on the person who took the decision to include that dependency.

tathougies 8y ago

The entitlement mentality of some people is insane.

tonyedgecombe 8y ago
Especially when they aren't paying.

vernie 8y ago

Sayre's law, baby.

QuantumGood 8y ago
Intensity of feeling is inversely proportional to issue value sometimes. Recent US political discourse seems to violate Sayre's law.

bendmorris 8y ago

>He had no way of knowing the person who took it over would use it maliciously. Then it was, clearly, negligent of him to give it to this person. He gave a stranger the power to do things in his name. He doesn't have to maintain the project forever - it seems like a much easier solution is: don't give away a project with your name on it to someone you don't know. Instead, encourage them to fork and release a new version under their own name. This is a surefire way to never have an exploit spread to thousands of people with your name on it.

runarberg 8y ago
As a user of free software you should always accept the risk that it is maintained by a malicious actor. It is just as likely that the original author will turn malicious. You as a user have the responsibility of auditing all the free software you use.
- bendmorris 8y ago
  People keep casually making this suggestion. In JS this can involve hundreds or thousands of transient dependencies. Have you ever (1) worked on a React app and (2) vetted all of React's 829 dependencies yourself? It's not remotely feasible. The only solution becomes "then don't use React!" - is this the best we can do?
  - RSZC 8y ago
    React does not have hundreds of dependencies: └─┬ react@16.6.3 ├─┬ loose-envify@1.4.0 │ └── js-tokens@4.0.0 ├── object-assign@4.1.1 ├─┬ prop-types@15.6.2 │ ├── loose-envify@1.4.0 deduped │ └── object-assign@4.1.1 deduped └─┬ scheduler@0.11.2 ├── loose-envify@1.4.0 deduped └── object-assign@4.1.1 deduped
    - LeoNatan25 8y ago
      React Native then. 1200+ last I remember.
  - 8y ago

pmoriarty 8y ago

Users have to come to grips with the possibility that the "free" code they download might be malicious. To mitigate the risk they have these options: 1 - Don't use the software. 2 - Audit the software themselves before they use it. 3 - Pay someone to do the auditing for them. Even if they choose options 2 or 3, there's still a chance the some vulnerability of malware could sneak through (especially if they're getting a binary blob or source code written in a language like C that makes obfuscation easy). But if they choose to use unaudited software, they're playing with fire and shouldn't be surprised if from time to time they get burnt.

rapnie 8y ago
I wonder if there are projects out there for an option 4: 4) Use an OSS dependency checker tool that reports the risk in your dependency tree 4a) Dependency tool uses a crowdsourced database of audit/review metrics A typical NodeJS project has potentially 1,000's of (transitive) dependencies. Many well-established projects use dependencies versioned e.g. 0.0.1 etc. I guess there are hundreds of similarly unmaintained packages among these. Lacking 4) a small-time developer working on a side-project only has option 1) (or option 0 - Take the risk) as a feasible way to go.
wstuartcl 8y ago
Users have to come to grips with the possibility that the "free" code they download might be malicious. denial, anger, bargaining, depression and acceptance. ^^^^^

aikah 8y ago

People are dealing with a lot of negativity in their life, they shouldn't have to deal with that entitled bull-crap online, especially when doing unpaid work. Should the maintainer have been more cautious? no, he should have straight out closed the project and just ask people to fork it or use something else. If you are not going to maintain something anymore, don't even bother worrying about passing the torch. That way nothing is your responsibility anymore. The people who complain, insult the maintainer in Github issues right now will be at the root of a shift of mindset from contributors that will end the "golden age of open source".

kylecordes 8y ago
I think this is the clearest, easiest, correct answer. If you no longer have the time and motivation to maintain a project, and are also not in a position to hand over control to someone you have good reason to trust, the easy, safe answer is to retire it, and have others fork. Then in the original project you can say “the last version of this project is N.N; here are some possible candidate successor forks, which have not been vetted”. This way no one who is merely keeping up with version numbers will accidentally step off of a reasonably good package on to a fraudulent package.
- Novashi 8y ago
  >I think this is the clearest, easiest, correct answer. If you no longer have the time and motivation to maintain a project, and are also not in a position to hand over control to someone you have good reason to trust, the easy, safe answer is to retire it, and have others fork. To prescribe some preventative advice based on this: it's probably not a good idea if your project gets popular to continue being a solo developer in open source. So plan ahead based on your popularity. And your project isn't likely to explode in popularity over-night and be a dependency for 1000+ other projects, so you should be able to see this coming. Of course, this is super-easy to prescribe in hindsight.
- wpietri 8y ago
  I 100% guarantee you that if he did that, he'd be getting a lot of static about how he should have handed the package over to some contributor.

Y7ZCQtNo39 8y ago

It's impractical, on an individual level, to vet your entire dependency tree. Installing something like react alone will put 100+ modules in your dependency tree. A more mature project will have a 4-figure number of dependencies. Things like Node Security Platform (which was absorbed by NPM) exist for a reason. There's no reason for every person to vet every single package they use -- it'd be an awful lot of duplicated energy. If there was no implicit trust in the community, and we had to act as vigilant as you describe, there would be no community.

reitzensteinm 8y ago
This is a bit of a strawman. It absolutely is your responsibility, but that doesn't mean you can't outsource it.
- Y7ZCQtNo39 8y ago
  It's the kind of thing where, if everyone with this problem chipped in $5/month, we could have a central repository of vulnerabilities. So, not absolving yourself of responsibility, but also way more efficient to outsource.
RSZC 8y ago
(React does not have 100 dependencies, it has 5 including indirect dependencies)
- deleted 8y ago
  [deleted]
- Y7ZCQtNo39 8y ago
  A more mature project wouldn't have just React as a dependency. Point is, it's a lot of code to vet. React may have 5 indirect dependencies, but in my projects, I have 30 or more direct dependencies.

coleifer 8y ago

I experienced a twist on this. A guy who had very different aesthetic taste wanted me to merge some patches. He got real entitled about it, eventually I banned him. THEN he did the "appeal to Twitter" and made malicious edits to the project page on wikipedia. He made a huge stink and wasted hours of both of our time. It was unreal! I wish I was joking. I wrote about it, discussing my motivations for open source: http://charlesleifer.com/blog/your-idea-sucks/ http://charlesleifer.com/blog/your-idea-sucks/

danso 8y ago
A. Damn, I would think a CTO would know to quit this dispute and fork his own purportedly superior version, if his company's survival is so dependent on it. B. Really like the elegant style (visually, though the writing is also elegant!) of your blog.
glogla 8y ago
You shouldn't have hidden his name. We should know who it is, in case we meet him or something.
- coleifer 8y ago
  Then I'd be doing exactly what he did, just dressed up a little in a blog instead of twitter.
  - glogla 8y ago
    No. Complaining about horrible behavior is not horrible behavior about itself.

jxramos 8y ago

I caught that notion they had > I've shared publish rights with other people before. Of course, If I had realized they had a malicious intent I wouldn't have, but at the time it looked like someone who was actually trying to help me. Can anyone cite perhaps a handful of examples where this malicious open source usage ultimately bit them?

mwfunk 8y ago

Well they certainly couldn't call it "free software", that involves many more assumptions than "Open Source", and it might not even be free of charge. :) Blame Richard Stallman for using an incredibly common word with many meanings to refer to something that has one incredibly specific meaning which is unintuitive to most people, and to pretty much anyone who isn't a developer. I think several decades of Open Source boosterism may have eventually given some people the wrong idea about what it's all about. Two annoying trends I've noticed in the last 10 years: (1) (what this poor guy seems to be running into) People treating Open Source as anything other than charity from the people who put it out there. The people who make it generally don't owe anyone anything, including the people who use their code. I sometimes see very harsh criticism from people within the community that assumes anyone putting anything out there has to accept all sorts of responsibilities: maintaining a community, keeping on top of bug reports, acting as an integrator for people who want to send in patches, making sure that all packaging and documentation conform to some very high bar and/or specification, etc. Just because somebody puts something out there doesn't mean it has to be a second job for them, and doesn't mean that they are obligated to do anything for anyone, including responding to emails or dealing with bug reports or patches. It's perfectly fine to stop maintaining something after a while, or to just throw code over the wall and never touch it again after it's out there. (2) (not this case) People treating Open Source as some avenue to professional fame or an eventual source of income. Yeah, that can happen, but it very rarely happens, and it's not a good reason to write it in the first place. This is the result of too many people using business arguments as a fundamental justification for doing Open Source, and people saying stuff like they only hire people who have projects on Github, and only if they like what they see. If someone's primary motivation is fame or money, Open Source is a terrible way to accomplish that. It's possible, just highly unlikely, plus I think it's much less likely to happen if that's someone's goal from the outset.

jungler 8y ago
I think there is an underlying root cause to how we treat Open Source, and it's similar to the IT "cost center vs value creator" problem: Open source packages are treated as consumer goods, and creators in turn will engage with that by marketing them as consumable products. Many of these things which are distributed as packages are actually code snippets. They could be maintained in the form of a Stack Overflow answer to copy-paste into your code. The question-answer system exposes the code to the necessary competitive evaluation: a malicious answer soon gets downvoted. When the packaging metaphor is laden over them, the whole chain of responsibility lapses back to the vendor-consumer model. And this works when packages are large and take pains to reduce their own dependencies, even if it means common functions get duplicated across different packages. But prolific authors currently are rewarded by being vendors of undersized packages: they enjoy large download numbers, Github stars, and so on. Without any kind of curation to impose friction on this process, they can do the wrong thing for a very long period and get zero feedback indicating that their actions create a problem. And on the consuming side nobody pays a lick of attention when the prompt says it's going to install 50 things with cute-but-opaque names. If they are under a page of code each, you could probably just print the code. When I create projects now, I tend to grab some packaged code to start with, but apart from a few to do core functions like I/O I will treat them as placeholders and seek ways of reworking the code to make myself the sole maintainer. The alternative is to be a software consumer and to complain like a consumer - i.e. in a largely powerless fashion - when other people's code doesn't do what I want.

B-Con 8y ago

> Maybe calling free software "Open Source" was a mistake. This conflation is definitely a bad thing. Words with an actual meaning get over-used, simplified, stripped of their original meaning, and then merged. It would be 100% to the detriment of our language if it happens in this case. Open source does not mean free (as in freedom or beer), free (as in beer) does not mean open source. Free as in freedom almost always means open source. Side rant: Also, open source doesn't mean "open to contributions". Giving access to the source code does not mean obligation to accept contributions to said source.

type0 8y ago
> Side rant: Also, open source doesn't mean "open to contributions". Giving access to the source code does not mean obligation to accept contributions to said source. How true, this is such a common misunderstanding among newcomers to FOSS, it can't be repeated enough times.

sytelus 8y ago

This problem can be solvable by introducing “Verified Identity” on GitHub. Anyone who wants to be maintainer of popular project can be asked to get Verified Identity. If this person turned out to be malicious, he risks getting tracked down by law enforcement fairly easily. For getting Verified Identity, simplest thing might be validation of phone number. Bit more complex thing might be Verified bank account or credit card. Assuming GitHub has 1M active users and each user verification costs $5, the cost of solving this problem is less than 0.1% of GitHub valuation but can hugely improve trust levels.

jdorfman 8y ago
Good idea although $5 to a person writing malicious code and out of jurisdiction isn't much of a deterrent IMO.
peterbraden 8y ago
Why on earth would anyone want to be on the hook for liability like this for an unpaid maintenance job? Open source licenses state this clearly: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND"

AsyncAwait 8y ago

Agree with you, just note that the term "free software" doesn't actually refer to software price at all.

type0 8y ago

> Maybe calling free software "Open Source" was a mistake. If something is "free", then you have to accept you may get what you paid for. Since no one seems to care about the freedom aspect of it, maybe we could rename it to "fee software" - give it away for free and encourage everyone to contribute with time and money. Will people stop being selfish because we changed the name? I don't think so.