Hacker News Reader

Comment by dgellow | Hacker News Reader

What about charging for build and distribution? Krita does something like this for their Steam and Windows Store versions, that helps finance their development. I personally believe that could also work for other distribution channels, such as a private APT repository, or equivalent to other platforms.

People could still build by themselves from sources if that's what they want, and if you want convenience you buy the software. Has that been tested? I personally think that could even work for CLI tools if a great distribution channel exists (that's something I have in mind since a while now, see this ask HN from 5 months ago: https://news.ycombinator.com/item?id=22178949).

View on HN

I guess the problem is that once there is a paid CLI tool, some other dev will make a clone for his CV / GitHub where even the compiled binaries are free. Now people have to choose between the OG tool and maybe pay for it or use the mostly feature complete (or feature complete for a specific use case) free version. I would even go as far as the community will continuously switch to the free tool until the free tool has enough clout / traction to actually supersede or replace the OG tool.

Theory: At this point, tutorials which are consumed by the beginners in the field will select the free tool (because it has a bigger target audience, so better SEO), which makes this whole thing a generational thing? „Oh in the early days we had to pay for this, now we use XY which is newer and shinier and even free, thus better“

Krita is free to download, so it doesn't really apply.

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.

You’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.

I 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.

The 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.

Certainly 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.

That's exactly what Aseprite (a pixel-art tool) does. I think it's great, I got it to build on Windows but eventually ended up buying it on Steam because it's so good.

Wait, Aseprite is open source?! I didn't know that, it's an awesome program.

Edit: Sources available, but not open source license as far as I understand the EULA. https://github.com/aseprite/aseprite

More fully explained here : https://dev.aseprite.org/2016/09/01/new-source-code-license/

The license and FAQ are somewhat confusing as to if you need to pay for a license even if you compile from source.

It would be interesting to test this mode. I work for free on the source code, and you can get that for free. But if you don't know what to do with it (i.e. build it) or don't want the hassle of setting up a build environment, you can always pay the project for that effort.

I'd argue this would need a special license deviation from the typical OSS ones to prevent distros from packaging it. Otherwise, this model would break down the moment an Ubuntu or Fedora decides to package the software and then the incentives to contribute some money in exchange for convenience dissappear.

Yes, I arrived to this conclusion too, that to work it would likely not be actual open source (as defined by the Open Source Initiative).

I think Ardour is doing the same. You can get the code and build it youtself, or you can pay them and get a proper build.

Of course Linux distros are still building and shipping it.

"What about charging for build and distribution? Krita does something like this for their Steam and Windows Store versions, that helps finance their development."

Ardour[1] does this too, and from what I understand its lead developer manages to support himself from this.

The Linux distribution that I use is Gentoo, and it has Ardour in its package repository, but that version is always old compared to the newest version of Ardour.

So if I want the newest version I have to compile it myself (which I can and have done, as I have the technical expertise to follow their build instructions), but for others who want the latest pre-compiled and/or want to support Ardour's development, they can donate.

There's also Harrison Mixbus[2], which is a commercial product built on top of Ardour by another company.

[1] - https://ardour.org/

[2] - https://harrisonconsoles.com/site/mixbus.html

This is the model for the Ardour DAW on Windows. You get the source or either a free binary that disables audio output after a few minutes or a paid for binary eithout that restriction. I don't know how well it works.

Reply on news.ycombinator.com