3 ms·
One problem I see is that for more tech-savy Linux users, which are the people most CLI software is targeted at, convenience means simply installing something v
by leotaku 6y ago
One problem I see is that for more tech-savy Linux users, which are the people most CLI software is targeted at, convenience means simply installing something via their distributions package manager. I am not interested in downloading your precompiled static binary or setting up your private repository. I want to run `foo install bar` and get on with my work.
On the other hand there are some more mainstream optionally paid for (via Steam/Windows Store) GUI tools that I can freely download using my package manager, presumably because the main target audience actually prefers the paid distribution channels.
I think the GUI/CLI app markets could be more different than you think.
- dgellow 6y agoYou’re right regarding the convenience point, to have a chance to work it has to be as straightforward as possible to buy and then install your tools. I understand the difference people expect from GUI vs CLI, I just don’t think it really makes sense to be ok to pay for one but not the other, and I see it as a missed opportunity for tool creators. Edit: Regarding Linux users as the main target, I don’t know if that’s true. I had mostly macOS in mind (I know I explicitly mentioned APT in my initial comment, that’s just what I had in mind at that moment), mac users seem to be ready to pay good money for their tools, there is a healthy market for GUIs. Something equivalent to homebrew cask but with an economics component may have its users if the tools being sold are considered valuable enough.
- leotaku 6y agoI fully agree that it is unfair to creators that they cannot reasonably generate income from CLI apps. Still, I am unconvinced that the model you are proposing could gain viable traction. It might be that I am in a sysadmin bubble here, but I just think that the "paid store" model conflicts with how people use CLI software. For example, I suppose even the MacOS developers you mentioned would be interested in running e.g. `jq` on remote servers, virtual machines, docker, ... How could good UX possibly be achieved here? If you lock your hypothetical store down even a little bit, users now have to do complicated secrets management. If you don't and simply hope that everyone actually pays, you might as well just ask for donations.
- dgellow 6y agoThe docker case as an example: - your prod docker images are already very likely to be built by your CI - a Dockerfile typically does: apt update + install, git clone a private repository with your scripts, then build whatever you have to build - so you already have secrets to manage, given that you need to access your private git repository - in an environment such as Jenkins, Travis, Github Action, GitLab equivalent, secrets for your CI pipeline are equivalent to env vars that you add to your pipeline settings. It's quite unlikely that you have setup your own. - let's say you want to avoid to have the private repository as a point of failure, just store the downloaded archives to your own registry. Not too different from storing build artifacts. I'm not saying there isn't some friction, but it doesn't seem to be a deal breaker to me.
- sammorrowdrums 6y agoCertainly I'm interested to see if many people have been clicking the "x packages are looking for funding" links with `npm` and could imagine that sort of in other package managers too... Personally I'm happy to see it. I keep thinking I'll ask my company to support ones we use, every time I run `npm install`, and I plan to do it soon.