tldr; Edit 8 Apr 2017
Pulled out of NPM. An alternative is written at prettydiff/biddle and it will become a dependency of Pretty Diff very soon.
Goal
The intention is to find a distribution solution so that Pretty Diff can leave NPM.
Primary Problem
These two quotes from NPM co-founder Laurie Voss (CTO) are the straw that broken the camel's back:
Un-un-publishing is an unprecedented action that we're taking given the severity and widespread nature of breakage, and isn't done lightly,
This action puts the wider interests of the community of NPM users at odds with the wishes of one author; we picked the needs of the many.
Conflict to Open Source
I fundamentally disagree. The needs of a package owner completely and absolutely outweigh everybody else. This is a fundamental issue of open source software. The commercial resolution to this condition exists in various forms of warranties, contracts, and documented obligations. Where such documents are neither expressed nor implied the open source software exists for use entirely at risk to the consuming dependent. This the reality of open source software and is stated as such in the most popular open source software licenses.
NPM forms their position because they are a revenue generating business who sell infrastructure. The most important quality to their business is availability (like any infrastructure model), which, in this case, puts their business into conflict with basic principles of open source software. This is an exceedingly rare edge case even if absolutely fundamental. When availability is in question the value of their service is called into question and their brand is severely harmed.
The reason why this conflict likely exists (speculation) is because NPM traffic growth is largely driven by a dependency model. Use of dependencies requires a choice between freely available work (and assuming all risks of that work and its availability) versus doing that work yourself locally.
Personal Thoughts and Convictions of Liberty
The quoted statement from NPM is the opposite of liberty. I hold the concepts of liberty and leadership above all other sociopolitical establishments and is the primary reason I continue to serve in the US Army after 19 years.
If the subject at hand were of gay rights or racial distinctions, instead of software, people would not be so generally silent on the subject. There would be loud angry boycotts and protests. While the community of NPM users and leaders may distinguish these subjects differently liberty does not. The logical conclusions then are that:
- The community of NPM is not aware of liberty as a concept (ignorant)
- The community of NPM is aware of liberty but finds it antagonistic to other competing values (authoritative)
Regardless of whether the thoughts and actions opposing liberty are willful, as an adherent to the practice of supporting and upholding liberty as a paramount virtue I must remove myself from that community and no longer contribute works toward it. I believe a willful opposition to liberty on principle alone is perhaps the greatest of evils and all that it takes for evil to thrive is for good persons to do nothing.
For the definition of liberty I subscribe to the preeminent treatise On Liberty by John Stuart Mill. I have included a few select quotes from the second chapter, the first of which is the thesis of the essay.
If all mankind minus one, were of one opinion, and only one person were of the contrary opinion, mankind would be no more justified in silencing that one person, than he, if he had the power, would be justified in silencing mankind.
Let us suppose, therefore, that the government is entirely at one with the people, and never thinks of exerting any power of coercion unless in agreement with what it conceives to be their voice. But I deny the right of the people to exercise such coercion, either by themselves or by their government. The power itself is illegitimate. The best government has no more title to it than the worst. It is as noxious, or more noxious, when exerted in accordance with public opinion, than when in opposition to it.
Strange it is, that men should admit the validity of the arguments for free discussion, but object to their being "pushed to an extreme;" not seeing that unless the reasons are good for an extreme case, they are not good for any case. Strange that they should imagine that they are not assuming infallibility, when they acknowledge that there should be free discussion on all subjects which can possibly be doubtful, but think that some particular principle or doctrine should be forbidden to be questioned because it is so certain, that is, because they are certain that it is certain. To call any proposition certain, while there is any one who would deny its certainty if permitted, but who is not permitted, is to assume that we ourselves, and those who agree with us, are the judges of certainty, and judges without hearing the other side.
Security Implications
Package Reassignment
NPM can arbitrarily reassign a package name without owner consent or awareness. I understand the occasional need for this and that such power is used exceedingly rarely. NPM can violate a package maintainers' intentions to unpublish by arbitrarily publishing the same code under the same name for continuity. When these two concerns coincide namespace assignment and management of all associated code are fundamentally lost to the package maintainers. This presents immediate risks to product management (for distribution) and thus secondary consequences of associated branding and product health decisions are lost to maintainers. The third level consequences apply to disruptions of contractual obligations that arise from loss of control of maintained packages.
Weak Software and a Community of Dependency Hell
The problem that precipitated the NPM action and quotes above is due to a catastrophic break from the removal a single tiny artifact. This could be characterized as the removal of a grain a straw that instantly destroyed all the buildings in a grand city upon its plucking. The problem there is not the result of an NPM directed action or the malicious convictions of a single evil agent. The problem is a community entirely reliant upon a system of dependencies, without regard for integrity or health, with NPM directly serving as the primary enabler.
This community problem exists because weak software developers value convenience above other more necessary considerations. Audits are not performed (not regularly, not ever) over included dependencies and the dependencies of the primary dependencies are certainly not thought of. These dependencies are frequently included without constraint or safety of any kind. Emerging software developers who are new to software development take this weakness as standard practice and so the weakness is the new baseline. The consequence is that discussions and thoughts of architecture are avoided out-right thereby avoiding ownership of responsibility, so therefore it becomes the user's fault when software breaks due to the dependency madness.
This problem is observed in numerous posted issues to the Atom-Beautify project. Atom-Beautify is a large project containing many dependencies. Even after the project itself is well-written and does everything it can to reinforce concepts of health and integrity it still suffers from dependency hell due to the madness that comes in from certain grandchild dependencies. When a micro nth level dependency fails to come across the line there is only one solution: We tell the user to kindly reinstall. Clearly, this is a user error (due to no fault of the user) that we are powerless to fix.
Secondary Reasons
Additional and unrelated frustrations that break Pretty Diff:
Tertiary Reason
It is hard to qualify NPM download numbers. This is absolutely not related to any project health or security concern, so it is absolutely minor. NPM download counts appear to be total downloads. This includes counts for specifically requested packages, packages downloaded as any dependency type, packages further down the dependency chain, and various versions of the same package on the same dependent and/or dependency tree. This generates some level of confusion in that a package could get 30 (hypothetical) download counts when a single unrelated package is downloaded.
The challenges:
- There is no way to determine external downloads apart from NPM internal (NPM dependency model) downloads
- There is no way to determine unique (manual) requests apart from total downloads, which speaks to desirability versus unintended inclusion
- There is no way to determine download traffic source
See also: #250
It would be nice to have more qualified numbers. In the reality of open source the numbers matter very little. In the rest of the world it is a validation. The rest of the world includes:
- potential investment
- family (from whom I rob time to write open source)
- software developers who don't contribute to open source
tldr; Edit 8 Apr 2017
Pulled out of NPM. An alternative is written at prettydiff/biddle and it will become a dependency of Pretty Diff very soon.
Goal
The intention is to find a distribution solution so that Pretty Diff can leave NPM.
Primary Problem
These two quotes from NPM co-founder Laurie Voss (CTO) are the straw that broken the camel's back:
Conflict to Open Source
I fundamentally disagree. The needs of a package owner completely and absolutely outweigh everybody else. This is a fundamental issue of open source software. The commercial resolution to this condition exists in various forms of warranties, contracts, and documented obligations. Where such documents are neither expressed nor implied the open source software exists for use entirely at risk to the consuming dependent. This the reality of open source software and is stated as such in the most popular open source software licenses.
NPM forms their position because they are a revenue generating business who sell infrastructure. The most important quality to their business is availability (like any infrastructure model), which, in this case, puts their business into conflict with basic principles of open source software. This is an exceedingly rare edge case even if absolutely fundamental. When availability is in question the value of their service is called into question and their brand is severely harmed.
The reason why this conflict likely exists (speculation) is because NPM traffic growth is largely driven by a dependency model. Use of dependencies requires a choice between freely available work (and assuming all risks of that work and its availability) versus doing that work yourself locally.
Personal Thoughts and Convictions of Liberty
The quoted statement from NPM is the opposite of liberty. I hold the concepts of liberty and leadership above all other sociopolitical establishments and is the primary reason I continue to serve in the US Army after 19 years.
If the subject at hand were of gay rights or racial distinctions, instead of software, people would not be so generally silent on the subject. There would be loud angry boycotts and protests. While the community of NPM users and leaders may distinguish these subjects differently liberty does not. The logical conclusions then are that:
Regardless of whether the thoughts and actions opposing liberty are willful, as an adherent to the practice of supporting and upholding liberty as a paramount virtue I must remove myself from that community and no longer contribute works toward it. I believe a willful opposition to liberty on principle alone is perhaps the greatest of evils and all that it takes for evil to thrive is for good persons to do nothing.
For the definition of liberty I subscribe to the preeminent treatise On Liberty by John Stuart Mill. I have included a few select quotes from the second chapter, the first of which is the thesis of the essay.
Security Implications
Package Reassignment
NPM can arbitrarily reassign a package name without owner consent or awareness. I understand the occasional need for this and that such power is used exceedingly rarely. NPM can violate a package maintainers' intentions to unpublish by arbitrarily publishing the same code under the same name for continuity. When these two concerns coincide namespace assignment and management of all associated code are fundamentally lost to the package maintainers. This presents immediate risks to product management (for distribution) and thus secondary consequences of associated branding and product health decisions are lost to maintainers. The third level consequences apply to disruptions of contractual obligations that arise from loss of control of maintained packages.
Weak Software and a Community of Dependency Hell
The problem that precipitated the NPM action and quotes above is due to a catastrophic break from the removal a single tiny artifact. This could be characterized as the removal of a grain a straw that instantly destroyed all the buildings in a grand city upon its plucking. The problem there is not the result of an NPM directed action or the malicious convictions of a single evil agent. The problem is a community entirely reliant upon a system of dependencies, without regard for integrity or health, with NPM directly serving as the primary enabler.
This community problem exists because weak software developers value convenience above other more necessary considerations. Audits are not performed (not regularly, not ever) over included dependencies and the dependencies of the primary dependencies are certainly not thought of. These dependencies are frequently included without constraint or safety of any kind. Emerging software developers who are new to software development take this weakness as standard practice and so the weakness is the new baseline. The consequence is that discussions and thoughts of architecture are avoided out-right thereby avoiding ownership of responsibility, so therefore it becomes the user's fault when software breaks due to the dependency madness.
This problem is observed in numerous posted issues to the Atom-Beautify project. Atom-Beautify is a large project containing many dependencies. Even after the project itself is well-written and does everything it can to reinforce concepts of health and integrity it still suffers from dependency hell due to the madness that comes in from certain grandchild dependencies. When a micro nth level dependency fails to come across the line there is only one solution: We tell the user to kindly reinstall. Clearly, this is a user error (due to no fault of the user) that we are powerless to fix.
Secondary Reasons
Additional and unrelated frustrations that break Pretty Diff:
Tertiary Reason
It is hard to qualify NPM download numbers. This is absolutely not related to any project health or security concern, so it is absolutely minor. NPM download counts appear to be total downloads. This includes counts for specifically requested packages, packages downloaded as any dependency type, packages further down the dependency chain, and various versions of the same package on the same dependent and/or dependency tree. This generates some level of confusion in that a package could get 30 (hypothetical) download counts when a single unrelated package is downloaded.
The challenges:
See also: #250
It would be nice to have more qualified numbers. In the reality of open source the numbers matter very little. In the rest of the world it is a validation. The rest of the world includes: