> We need an easier way to automatically distribute payments based on certain rules to open source developers.

Has almost nothing to do with Blockchain. This is just called "micropayments"- and blockchains suck for them. At best, you end up doing little payments outside the blockchain, and then settling them occasionally on the blockchain.

You may notice this same approach works quite well for "do little payments outside the existing financial system, and settle them periodically."

> Code and modules need to be multi-signed and certificates should be inexpensive to get and easy to validate.

Code signing is unrelated to blockchain.

Certificates are already easy to get. GPG is free. Certificates signed by a CA sometimes cost money- code signing certs, at least in theory (in practice? hah, not really), cost because they need to be able to verify your actual identity.

Certificates being easy to validate... this is a PKI problem. Blockchain provides nothing of value here.

You might be able to do something like what Keybase does- having some centralized "identity" and making changes to same auditable- with a degenerate Merkle tree. You know what else does this? A HSM from like 2006, which, in each audit log entry, includes the hash of the previous one, to establish exactly this property- changes and edits can be detected.

> One of our dependencies could become a malicious package in the same way we saw it with event-stream. But instead of giving full maintenance or full publishing rights to new collaborators, the original developer would give new maintainers or a CI system only signing rights. So they would sign their releases and after a careful review the original author would countersign stating that he checked and approves these changes.

Not only has this got nothing to do with Blockchain, the proposal here is just "a new maintainer needs to ask the old maintainer for permission to publish for a while", which is quite silly- if the old maintainer is tired of bothering with the maintenance bit, the LAST thing they want to do is careful code audits.

> Later, if our fictional project received an in-app payment there could be some logic within the runtime environment that based on the impact or contribution of this open source module to our project would automatically distribute a couple of cents of each payment to the author who can be determined based on the certificate.

Well, no, the author can't be determined based on the certificate on your binary. The person (or persons) who signed it can be. Asking every contributor to sign every release in perpetuity is silly, of course. Incentivize them to do it with a cut of the profits? Great, now they just rubber stamp everything.

Now, if you mean the maintainer of the module, sure. You know what else works quite nicely for this? Just having a payment address in your Git repo in some file with a well-known name. There's no point in the certificate, here!

"Aha- a payment address! PayPal won't work, not much else that exists will, either. For those smaller payments, only a Blockchain-based approach would work." Well, that's true- for now. Similarly, "free, rapid person-to-person transfers" was largely just Venmo for a while. Then the sleeping giants that are the financial industry woke up, threw some pocket change at the problem, and created Zelle / Early Warning, which does the exact same thing.

There isn't a good way to do microtransactions today because there isn't that much demand for microtransactions. If there is, it'll pop up quite quickly.

This entire article is just... clown shoes. The parts that might work aren't novel and don't require anything besides a degenerate Merkle tree, and the parts that are novel or require a Real Blockchain(TM) are useless.

Why is this? Because the article itself was written backwards! The author started out with "I like and know Blockchain. (more cynically, 'I benefit when $ETH goes up'.) Here is a problem. How can we apply Blockchain to it, and make the world more secure (and more cynically, 'make me richer and my skills more in demand')?"

In so far as this article attempts to solve any problem, the problem is "Blockchain isn't used as much as I'd like it to be."