I have made over 100 npm packages, that get about 70 million downloads a month: https://github.com/sponsors/balupton — however, they only earn me a few dollars a month. Even despite bumps of sponsorship from the large donor here and there, splitting out the revenue from FOSS (about $60kUSD) over the years that I’ve been doing it (17 years), would be a pittance, despite the workload being a full-time demand; irrespective of the demanded workload, I have matured my approach since an existential crisis between 2014-2016 to only meet supply (my labor) with demand (their payment, or my own rewards; aka my own usage), this has helped remedy the broken trade situation (unpaid labor for alien consumption), but not resolve it.
I’m considering updating my 100 or so npm packages which are mostly libraries, with additional CLI tooling that is paid to use (the CLI will check if you are a github sponsor, of if your organisation is a github sponsor; and if neither condition is satisfied, it will prompt to become a sponsor and exit). The advantage of this approach over prior attempts that I’ve seen is that:
- the monetisation does not break/inhibit/slow library/api usage
- the paywall conditions are optional, they can soft-fork, consuming the free api for their own cli tooling
- license remains the same
Why consume the source API instead of forking the whole project? Well if they don’t consume the API, and do a hard-fork, then they have an unpaid maintenance burden. Whereas I benefit from paid maintenance of the free API via its CLI monetisation, therefore there is more resource potential within that duality (they benefit from indirect paid maintenance of the API, that they leverage), than hard forking (which reduces resource potential, as they no longer benefit from the resources I accumulate from monetisation that is used to continue API maintenance for free to them).
I’m planning to put this into place after my current batches of work are finished. So sometime in 2021.
Interested on the potential reception to this.