Nice idea, little light on the execution though. It leaves a few issues on the table which will likely hurt its adoption (aside from social/cultural aversion to paid open source software)<p>1. there’s not a good way to delineate the what is charged for, so it makes reusing parts of the software a challenge. This levels it up to developers to effectively clarify what each part of the software is worth in order to avoid an argument over things like how much they should have to pay for only using the HTTP header parsing code from a HTTP requests library. The library might monetise per request, so how much is a sub component supposed to charge?<p>2. There’s not really a good infrastructure for automatic micropayments… which is why this feels like a subtle crypto currency plug. There’s the one mention of web3 which makes me suspect that’s how they have monetised their upcoming project. I’ve looked into this for past projects several times. The two easiest solutions I’ve been able to define boil down to either. A points style preloaded accounts with the person getting paid so the software triggers a deduction of X points via some api call which can be kept track of in order to keep a running tally of when the $10 the customer paid has been eaten up by their software usage. Alternatively it’s cryptocurrency stuff where the balance/wallet is shifted into the client software and it sends the money via the usual cryptocurrency mechanisms. The first is a lot of headache to the point where your basically building a business not just making open source software and the second is cryptocurrency with all the attendant issues. The trouble is how to handle this for people who aren’t buying into a cryptocurrency world… or to normalise the cryptocurrency world sufficiently that this stops being a problem. An item the author has basically left up to the reader.