3 ms·

The latter solution isn't much better - all the community momentum of the first project is instantly gone. Now you have a set of forks, all with a different sma

by RSZC 8y ago

The latter solution isn't much better - all the community momentum of the first project is instantly gone. Now you have a set of forks, all with a different small set of patches on top. Which are maintained? Which will be maintained going forwards? Any new user looking for this functionality has no idea. Maybe none of them. He didn't give anybody the power to do things in his name. He gave a stranger the power to contribute to a shared codebase. He never claimed to be a BDFL of this codebase. Your vitriol would be much better aimed at node modules which depended on non-fixed code which they didn't audit.

trickstra 8y ago
losing the "momentum" on an abandoned package is a much better choice than having it fall into the wrong hands together with all the people who use it and didn't even know about the change of owner.
- RSZC 8y ago
  That's a false dichotomy. The actual options are: 1. Dead project 2. You share access to lots of people and they act responsibly 3. You share access to lots of people and they act irresponsibly #2 is waaaay more likely than #3. Still seems to me like people are blaming the wrong person here. If you're writing a cryptocurrency-related module (the target of this specific attack) and you're using npm modules written by somebody you don't know, what the hell are you doing?
  - bendmorris 8y ago
    #2 is more likely than #3 because a reasonable person gives access to another contributor or someone they spent a few minutes vetting, not a total stranger with no GitHub history.
wpietri 8y ago
Exactly. Both ways have have costs and benefits. It's certainly easy take this one example and say, "All projects should optimize for this very rare failure case." But you can bet that if he just closed his 700 packages down, we'd have plenty of people explaining how that was the wrong solution, that he should work to find maintainers. As far as I'm concerned all of this "he should have" stuff is more proof that he's right: maintaining a popular open-source package for free can be no fun at all.
bendmorris 8y ago
>The latter solution isn't much better It is unquestionably better than your users, whose trust you've earned over time, suddenly finding that their app is mining cryptocurrency. >He didn't give anybody the power to do things in his name. His name is still on the project he gave away access to, so yes, he did. >Your vitriol would be much better aimed at... I think criticism is warranted here, but I don't think I've been especially vitriolic about it. Frankly, OP made a poor choice and is now making excuses by complaining about not being rewarded for maintaining the project rather than own up to it. There was a better way to do this without him having to perpetually maintain the project. And moreover, the herd of commenters here on HN are projecting their dissatisfaction with entitled open source users onto anyone who criticizes OP.

by RSZC 8y ago

trickstra 8y ago

losing the "momentum" on an abandoned package is a much better choice than having it fall into the wrong hands together with all the people who use it and didn't even know about the change of owner.

RSZC 8y ago
That's a false dichotomy. The actual options are: 1. Dead project 2. You share access to lots of people and they act responsibly 3. You share access to lots of people and they act irresponsibly #2 is waaaay more likely than #3. Still seems to me like people are blaming the wrong person here. If you're writing a cryptocurrency-related module (the target of this specific attack) and you're using npm modules written by somebody you don't know, what the hell are you doing?
- bendmorris 8y ago
  #2 is more likely than #3 because a reasonable person gives access to another contributor or someone they spent a few minutes vetting, not a total stranger with no GitHub history.

wpietri 8y ago

Exactly. Both ways have have costs and benefits. It's certainly easy take this one example and say, "All projects should optimize for this very rare failure case." But you can bet that if he just closed his 700 packages down, we'd have plenty of people explaining how that was the wrong solution, that he should work to find maintainers. As far as I'm concerned all of this "he should have" stuff is more proof that he's right: maintaining a popular open-source package for free can be no fun at all.

bendmorris 8y ago

>The latter solution isn't much better It is unquestionably better than your users, whose trust you've earned over time, suddenly finding that their app is mining cryptocurrency. >He didn't give anybody the power to do things in his name. His name is still on the project he gave away access to, so yes, he did. >Your vitriol would be much better aimed at... I think criticism is warranted here, but I don't think I've been especially vitriolic about it. Frankly, OP made a poor choice and is now making excuses by complaining about not being rewarded for maintaining the project rather than own up to it. There was a better way to do this without him having to perpetually maintain the project. And moreover, the herd of commenters here on HN are projecting their dissatisfaction with entitled open source users onto anyone who criticizes OP.