4 ms·

The problem is A, but everyone is attacking B. The issue: developer pulled their package off NPM, which many packages depended on. The solution: keep all pack

by munro 11y ago

The problem is A, but everyone is attacking B. The issue: developer pulled their package off NPM, which many packages depended on. The solution: keep all packages in NPM. If the software is open sourced, we can legally continue to redistribute the software even though author may not want us to. Ecosystems with this issue: Python, Ruby, Go (google it) Ecosystems without this issue: Maven, Haskell I respect someone wanting to pull embarrassing or private data, or even just out of spite. In that case the package can be made undiscoverable, but still accessible from direct download. Non relevant issues: laziness; micro vs standard vs kitchen sink libraries; package security; package quality; package maintainer coordination; ... but the color of the bike shed is just so interesting.

tariqali34 11y ago
"If the software is open sourced, we can legally continue to redistribute the software even though author may not want us to." Right, you can legally redistribute the software, but can you ethically do so? Some people have complained about the bad precedent set for allowing left-pad to be reuploaded again after it was deleted, and the reason they complained is because the developer has lost control over the fate of his own package. These people can't complain too loudly, as the author in question did indicate that he was willing to give ownership of his npm packages over to someone else. But you could easily see a situation where a developer would want his stuff deleted and not be accessed, period. Why should this request be refused? The idea that the developer has lost all moral rights whatsoever to his/her work just because they attached a LICENSE text document feels wrong to me. Just because a license says you can 'do whatever you want' doesn't mean you should do whatever you want.
- munro 11y ago
  See my second to last paragraph for my response.
  - tariqali34 11y ago
    And I think that's a pretty good compromise that I'll accept. I could also suggest a manual deletion process as well in case you accidentally released security credentials or something very private that really shouldn't be open source. (Manual in the sense that you have to send an email to tech support and wait for them to respond...)
    - mgkimsal 11y ago
      iirc packagist.org (for php libs) allows deletions for packages that have been downloaded < 100 times, which covers the situations where something was published accidentally and needed to be reverted.
- mbrock 11y ago
  The author explicitly chooses an open source license and publishes to a public repository for other people to depend on. That action releases the package into the public sphere. If the author then wants to undo this action, that simply will be difficult—more so the more people depend on the package. If several people depend on the package, then they will try to put it back again, unless they sympathize strongly with the author's intention to unpublish. That's just open source working as intended. There's no ethical framework that compels people to have that sympathy, in general.
- mcphage 11y ago
  > Right, you can legally redistribute the software, but can you ethically do so? Yes, you can. If you're sharing your code with the world, that entails certain responsibilities. You're telling people that they can depend on your code, and you should not be allowed to violate that. Open Source isn't just about getting attaboys for being such a cool dude—it's about working together to build a library of code. If you don't want to be part of that, if you don't want to take under consideration any of the people who will be using the code you're sharing—then don't do it. Just don't release your code. Find something else to do with your time.
- deleted 11y ago
  [deleted]
zer00eyz 11y ago
Golang, Python and Ruby all have solutions for this: vendoring. I know first hand that Python and Golang have OPTIONS for how you vendor code... My current Python project and ONE of my Golang projects are "non standard". The last time I used NPM, vendoring the code wasn't really a viable option, and it seems that things haven't improved. When googling NPM and vendoring, I learned that this isn't the FIRST time that this sort of issue has bitten the NPM user base. This article from 2 years ago http://www.letscodejavascript.com/v3/blog/2014/03/the_npm_debacle http://www.letscodejavascript.com/v3/blog/2014/03/the_npm_de... makes it clear that the community as a whole hasn't learned. Vendoring still seems much harder than it needs to be and based on my search results is activly discouraged.
rootlocus 11y ago
The issue: you have a fever. The solution: take a cold bath to bring the temperature down. Addressing the disease, not the symptom, is not bike shedding.
- munro 11y ago
  Thanks, that's another way of looking at it. Not sure if you agree or disagree, the metaphor helps explain the point. By having a larger std lib, or less dependencies, it only treats the symptom of the disease, which is dependencies disappearing. To treat the disease we need to make sure open source packages are always accessible. This issue runs through a lot of other areas as well, not just package managers, which is why projects like IPFS are exciting!

by munro 11y ago

tariqali34 11y ago

"If the software is open sourced, we can legally continue to redistribute the software even though author may not want us to." Right, you can legally redistribute the software, but can you ethically do so? Some people have complained about the bad precedent set for allowing left-pad to be reuploaded again after it was deleted, and the reason they complained is because the developer has lost control over the fate of his own package. These people can't complain too loudly, as the author in question did indicate that he was willing to give ownership of his npm packages over to someone else. But you could easily see a situation where a developer would want his stuff deleted and not be accessed, period. Why should this request be refused? The idea that the developer has lost all moral rights whatsoever to his/her work just because they attached a LICENSE text document feels wrong to me. Just because a license says you can 'do whatever you want' doesn't mean you should do whatever you want.

munro 11y ago
See my second to last paragraph for my response.
- tariqali34 11y ago
  And I think that's a pretty good compromise that I'll accept. I could also suggest a manual deletion process as well in case you accidentally released security credentials or something very private that really shouldn't be open source. (Manual in the sense that you have to send an email to tech support and wait for them to respond...)
  - mgkimsal 11y ago
    iirc packagist.org (for php libs) allows deletions for packages that have been downloaded < 100 times, which covers the situations where something was published accidentally and needed to be reverted.
mbrock 11y ago
The author explicitly chooses an open source license and publishes to a public repository for other people to depend on. That action releases the package into the public sphere. If the author then wants to undo this action, that simply will be difficult—more so the more people depend on the package. If several people depend on the package, then they will try to put it back again, unless they sympathize strongly with the author's intention to unpublish. That's just open source working as intended. There's no ethical framework that compels people to have that sympathy, in general.
mcphage 11y ago
> Right, you can legally redistribute the software, but can you ethically do so? Yes, you can. If you're sharing your code with the world, that entails certain responsibilities. You're telling people that they can depend on your code, and you should not be allowed to violate that. Open Source isn't just about getting attaboys for being such a cool dude—it's about working together to build a library of code. If you don't want to be part of that, if you don't want to take under consideration any of the people who will be using the code you're sharing—then don't do it. Just don't release your code. Find something else to do with your time.
deleted 11y ago
[deleted]

zer00eyz 11y ago

Golang, Python and Ruby all have solutions for this: vendoring. I know first hand that Python and Golang have OPTIONS for how you vendor code... My current Python project and ONE of my Golang projects are "non standard". The last time I used NPM, vendoring the code wasn't really a viable option, and it seems that things haven't improved. When googling NPM and vendoring, I learned that this isn't the FIRST time that this sort of issue has bitten the NPM user base. This article from 2 years ago http://www.letscodejavascript.com/v3/blog/2014/03/the_npm_debacle http://www.letscodejavascript.com/v3/blog/2014/03/the_npm_de... makes it clear that the community as a whole hasn't learned. Vendoring still seems much harder than it needs to be and based on my search results is activly discouraged.

rootlocus 11y ago

The issue: you have a fever. The solution: take a cold bath to bring the temperature down. Addressing the disease, not the symptom, is not bike shedding.

munro 11y ago
Thanks, that's another way of looking at it. Not sure if you agree or disagree, the metaphor helps explain the point. By having a larger std lib, or less dependencies, it only treats the symptom of the disease, which is dependencies disappearing. To treat the disease we need to make sure open source packages are always accessible. This issue runs through a lot of other areas as well, not just package managers, which is why projects like IPFS are exciting!