Charging for CLI Access

Backstory:

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:

  1. the monetisation does not break/inhibit/slow library/api usage
  2. the paywall conditions are optional, they can soft-fork, consuming the free api for their own cli tooling
  3. 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.

2 Likes

Do you mean that a paid license for using it in CI is needed (for example)?

I don’t fully understand what you would offer at the CLI layer.

It does instinctively make sense. Including as a dependency or generally using as a component would be free usage, yes?

1 Like

This is conceptually similar to folks that “sell” binaries while releasing the source for free. The main questions in my mind are:

  1. How many folks will use a CLI, versus a library?

  2. How much convenience are you selling by doing the CLI for them? Several helper libraries, like docopt and yargs, make hacking up a quick CLI pretty easy.

Correct.

No different license would be necessary, as @kemitchell communicates:


This would certainly be the measurement that needs to be observed as it progresses to make sure I’m getting return on investment.

Focus would be to implement this for things I actually want a CLI for that don’t actually have one. And then expand it out into my more popular projects that already have existing CLIs: DocPad, CSON, getmac. While generally avoiding it, or outsourcing with bounties for the development of new CLIs that I wouldn’t personally use, but others might (which would be discriminated on likelihood of returns).

With that said, a github sponsorship will get you access to all the CLIs, rather than just specific ones. So the more CLIs built, increases the net to catch new customers, but does not increase the revenue from existing customers. Similar to SetApp, the more value they deliver for the same price, the more customers they acquire from the value proposition.

Applying this business perspective is quite useful to evaluating where one should spend their time to actually get a return on it.

Certainly not something to have the answers for yet, but an interesting experiment to measure its success for funding new components of existing and new libraries.

1 Like

This is really “who is the customer” — because this is reminiscent of Dropbox is just rsync :wink:

Particularly tricky with developers who can just be a step away from building their own solutions.

I don’t have an answer here other than considering who the customer is of these CLI solutions carefully. I have a “front end developer” persona in mind who is unlikely to make a quick CLI — but might very well want / need a CLI for certain uses.

1 Like

@balupton, I think the best advice at this point is for you to go out and find a few people willing to pay for a CLI like this. If it’s easier than you thought, that’s a good sign. If it’s hard, that’s a bad sign.

If you’d like to do this through strictEq, I’m happy to help you one-on-one. But feel free to do your own checkout page, sell on the honor system with a PayPal address, or whatever you like. I’ll be happy to hear how it goes, either way.

If you’re not able to find people willing to pay just for a command-line interface, consider some other moves that folks do with this kind of model. Some, like Red Hat, provide guarantees or certifications that only apply to the binaries they build. Others provide value-added features, like better versioning, distribution, or reproducibility, but only for their official, user-facing distribution.

I tend to think of these things like sprinkles on a cupcake. The cake’s most of the treat, but the sprinkles tempt more people to buy in.