4 ms·
All for compensating OSS devs, and doing so automatically and implicitly via contributors and the packages they built on is a neat idea. But the blockchain. Ugh
by and0 5y ago
All for compensating OSS devs, and doing so automatically and implicitly via contributors and the packages they built on is a neat idea. But the blockchain. Ugh.
Going by the owner's blog, which is a bit more in-depth on his reasoning and less hyperbolic:
- Packages will be immutable (no more left-pad incidents)
Don't need blockchain for this. Just add a ToS that you can't pull packages from the centralized repo.
- Packages will always be available (we’ll use decentralized storage)
NPM availability hasn't been an issue, but could be. Blockchain still not needed for decentralization. Anyone who has to download the entire chain... yeesh, gonna be huge. Scaling issue greater than NPM or Github in my opinion.
- Releases will be signed by the maintainers themselves (rather than a middleman you are told you can trust)
Doesn't seem to be an issue with NPM? When this happens they usually hijack an account or the github. Some sort of token to sign with can also be grabbed, especially shared between maintainers or (inevitably, because no one actually enjoys decentralization) just becomes an automated feature of Github etc. Even then this issue is solvable with NPM, don't need a blockchain to sign releases.
- Tools can be built to fundamentally verify the integrity of your app’s open source constitution
Don't need a blockchain. I've thought of building these myself for NPM, maybe something to check VCS release tag hash vs package.
- Token can flow through the graph
(this is re: financing devs) Don't need a blockchain for this, though my inner dev likes the automation.