Hacker News Reader

Comment by laveur | Hacker News Reader

It disappoints me that that they charge for pre-built binaries... Yes I can go and build it from source but it just doesn't feel right to have an open source project distributed like this. Shame on them for flaunting what I think is the spirit of Open Source.

View on HN

- First there's nothing wrong per se about charging for binaries in a GPL project, other projects did it before them (XChat comes to mind) and others will do. Doing so is absolutely not flaunting anything for a GPL project, if you think so you should read about what Free Software means.

- Second, in the case of Ardour, just read https://community.ardour.org/node/8288 . These people are doing what they can to keep the project alive.

Thanks for digging up that link. I had forgotten I wrote that. Things have been better since it was written, but the project could still really use at least another 1/2 full time developer (it could use 50 more, but hey ...) let alone someone to do web stuff rather than me.

What sort of web stuff? Just website management, or design, or backend, or social media, ... or all of the above?

all of the above.

I think it is a great way to fund development. In any case various Linux distros will have gratis packages available at some point.

That's already happening: KXStudio, a Linux distro for audio work, has pre-packaged Ardour binaries.

Not just specialized distros like KX, Ardour is at your fingertips in vanilla Debian and Ubuntu

- http://packages.ubuntu.com/search?searchon=names&suite=all&s...

- https://packages.debian.org/search?keywords=ardour

Note that because distros build Ardour using their stock GTK+ stack, there are a few issues with their builds that are not present in the bundles from ardour.org.

We (ardour.org) do not (and cannot) support distro-built versions of Ardour.

Why would stock GTK+ cause problems?

The most common reason is that we ship our own version of the clearlooks theme engine to ensure that we control the appearance of GTK+ widgets, and we load our own GTK2 RC file to define colors etc. for those widgets.

This leads to 2 errors, one irritating, one that prevents the program from functioning.

Irritating: GTK+ loads the system GTK theme during a call to gtk_init(). If this theme is based on clearlooks but contains declarations unknown to our (older) version of Clearlooks, you get errors.

Blocking: GTK+ loads the system GTK theme during a call to gtk_init(). If the theme file defines a "color theme", then when Ardour defines its own, GTK will block for ever, because of a bug in GTK+2. This doesn't happen if the system GTK theme has no color theme definition.

Those are the two main issues. They cannot be worked around without rebuilding the GTK+ stack so that it cannot or will not load the system GTK theme.

Thank you for explaining!

If you've contacted GTK about upstreaming your patches, what was their response? I'd be surprised if they didn't want to.

I interact regularly with GTK+ developers, and have been a regular contributor to GTK+ on OS X. They don't want our patches - they are very specialized and intended to deal with cases in Ardour that are not really a part of ordinary desktop apps. GTK+2 is now in maintainance mode anyway.

I think this is a great method. People always want more Open source software right? Look at this a different way, if you can't charge money for it to be OSS then it will have to be closed source right? (Advertising 'nstuff, I don't think that pays well...reddit...)

Just build your own binary if you don't want to pay. You can't really complain when they're giving the source code to you for free.

Yes you can, but that's beside the point. For a complicated application like this there obviously is value in both the source code and the pre-built binaries. I think people would be a little less annoyed if this didn't seem to be copping sales techniques from sketchy outdated proprietary business models (Prices not posted up front? Free version has time limitations??) and instead did something that was more sustainable. What this would be, I'm not quite sure of. Part of the problem probably is that desktop applications are not really a big market anymore. Maybe they should run a proper marketplace for free (as in freedom) audio plugins?

There is no price "up front" because you get to define the price (the model is taken from Radiohead's release of "In Rainbows", actually). What non-sketchy model do you have for a demo version? We used to make one that simply didn't save your plugin settings, but then realized that users could accidentally destroy an existing session like this. So we switched to "silence after 10 mins; ask for more time; silence after 5 mins; ask for more; silence after 2 mins; ask for more; silence after 1 min; ad infinitum". If you've got a better for how to create a demo copy that has some incentive for the user to change to the full one, I'm all ears.

And as you note, you don't know what the "something that was more sustainable is", whereas I've been doing this for 16 years, and have been through almost every "how to make money with open source" idea that there is. The vast majority don't apply to niche software, even on the odd occasion that they work for some other things.

I've made a living (of some kind) from working on Ardour for nearly 8 years now, and worked on it without need of income for 8 years before that. I think i'm

Personally as a fellow free software developer, I take whatever opportunities I can to look closer at what value the software is really providing for the user. Is your primary user actually interested in the freedom and community the software provides, or are they just looking for "Pro Tools on GNU/Linux" with a low price tag? It's probably a combination of the two for most users, and as you have found there is tons of tweaking that can be done to optimize for the middle-ground. I personally choose to lean more towards optimizing for freedom and community, but the downside to this is it requires more infrastructure to support it.

From the download page it looks like your anchor point is a one-time $45 for unlimited upgrades. This is already fairly cheap for DAW software, but I would be interested to know which of your pricing options actually does generate the most revenue. That would probably give you clues as to how to build a stronger free (gratis) version that doesn't reduce overall value for the user. Subscriptions being popular means you can probably consider paid add-ons and services. User wants to use proprietary plugins? It's added maintenance costs, make them pay for it. One-time purchases being popular means you probably need to pursue sponsorships. Unfortunately I don't know a good way to do this at scale without either A) embedding obnoxious advertising, or B) finding generous corporate benefactors. Everyone obviously wants option B and option A sucks for everybody. Whoever can find the equilibrium in between these will get rich.

I also want to add that I tremendously respect what you're doing and how far you've come, and that I probably would not be a musician if Ardour did not exist :)

  > there obviously is value in [...]
  > the pre-built binaries

Yet you object to having to pay for that value? If it's of no value, compile it yourself at no cost.

Reply on news.ycombinator.com