Is Open Source a diversion from what users really want?

Blog
#133

That’s true of any active large code base, but there’s still more code to navigate, more code to compile, more dependencies to install, and so on.

I had a look at investigating a problem with Ardour just the other week but here’s the laundry list of dependencies I would need to find and install before I can compile the software Ardour - Nightly Builds, and here are the build instructions to accompany them: ardour - the digital audio workstation.

In contrast, here are the build instructions for my window manager: README - dwm - dynamic window manager

#134

Well of course you have to be able to compile it to test out your changes. Since I do a lot of compiling anyway I didn’t find installing the extra dependencies too much of a hassle, it’s all part of the process.

#135

Right, but that’s kind of the point: you do a lot of compiling anyway.

I mean it’s clear from Ardour’s own documentation that even the Ardour devs don’t want to have to deal with the hassle of compiling on macOS, and they’re actual programmers who know what they’re doing. So what chance is your average music producer who wrote a website once going to have?

@paul’s original question was something like, is the ability to edit the source code really such a useful feature for end users? I think it is because it brought Harrison Mixbus to the market, which is at least useful enough to be worth the money its users spent on it, but I don’t think that’s what he meant.

I think what he meant was, why is Reaper’s lesser scripting feature so much more valued by its users than the superior option we provide them with? And the answer is probably that the lesser feature has a low enough barrier to entry as to actually be useful, whereas the superior option doesn’t.

3 Likes
#136

The only real code contribution I made that ended up in the official Ardour source was an addition to the scripting API :slight_smile:

#137

A few days ago Microsoft released Windows Package Manager 1.0. Relevantly the tool includes an import option, which allows it to read a JSON formatted collection of packages (and install them) where you can describe 3rd party sources. It is available on github, which I’ve included a link to, as well as on their “App Store”. I use GNU/Linux so I can’t really help out much here if someone wants to use this.

Notably there is also WSL, or the Windows Subsystem for Linux, which does provide an integrated Linux environment quite well from what I’ve heard but I don’t really have much experience with it. Still, I think that could be an avenue for Windows users who want to contribute without having to go through the process of booting into a different environment to do it.

#138

FWIW there’s an old thread here from someone else who wanted to get involved:-

To give him his credit, the OP spent months giving MSVC a try but eventually gave up. It might be worthwhile to post there and ask if he’ll describe his experiences - but as Robin said earlier, I think it was mostly due to problems compiling the support libs. I’m someone who does build Ardour with MSVC and I can confirm that Ardour itself is the easy bit. The support libs tend to have little or no support for building with MSVC any more :frowning:

#139

I think the real solution right now is to just not build with MSVC, there are ways around this that seem like they would be much less painful to deal with, even if you do have to learn to work with a different environment. Microsoft has had a very long time to deal with this growing problem of dying support for MSVC. Their “we <3 open source” initiative and native tools like wpm (which is not a replacement for a good build system) are a step in the right direction. Then again, it also looks like their actual solution to this problem might be slapping a GNU/Linux VM on top of Windows with some convenience features (WSL) and calling it a day. Take it for what you will, but I personally think anyone on Windows who wants to contribute would be better off using WSL, or MinGW.

#140

Many years ago there was a third party project which aimed to distribute a full ‘dev’ version of the GTK+ stack for MSVC (i.e. pre-built binaries + header files). But back in those days,there was little compatibility between different MSVC versions - so if their stack was built with (say) VS2013, you couldn’t use it with any other version. But IIRC Microsoft itself became interested and improved the compatibility between different MSVC versions. Unfortunately, I can’t remember what the project was called - and I can’t remember if it offered GTK+2 libs or only GTK+3 Can anyone else remember this? I’m sure I didn’t imagine it.!

#141

I found the project here - the good news is that the pre-built bundle supports GTK+ ver 2. The bad news is that it only goes as far as GTK itself. So there’s no support for atkmm / gtkmm etc. And of course it won’t include libraries which GTK itself doesn’t need - such as libsamplerate / vamp / serd / sratom etc.

Maybe useful as a starting point though…

#142

Many libs that Ardour depends on have already switched to use meson as build-system, others use cmake. It should be a lot easier these days.

#143

Forgive me if I respond before reading all the responses. It seems to me that this post isn’t really about either Open Source or users. As a user, I wouldn’t use it if it wasn’t not only Open Source, but actually DFSG compliant. End of, I run Debian exclusively and have done for 20 years.
This seems to be about extending Ardour through scripting; what I would describe as ‘softcode’. Mostly you’re talking about Lua and Python, my two favourite scripting languages, because I’m one of the generation you’re talking about. Both of them are Open Source. You seem to have just said that “all this” isn’t possible through scripting as a result of your and Robin’s joint intention. I don’t really understand how it being Open Source is the problem here. That’s partly because I’m not a ‘real’ (i.e. C) programmer and partly because I’m a FOSS fanboy :grinning:

#144

Hi All,

I’m an occasional Ardour user but use other DAWs for my work. In the past I studied music (university level) then music technology, got into programming and have worked as a C/C++ programmer. More recently I’ve returned to the world of audio production working primarily as an audio editor.

A few years back I was interested in contributing to Ardour and went as far as trying to get a build working. This was on OS X (now macOS). To build the software was very time-consuming, in particular (as has been mentioned) building all the libraries especially GTK. I recall the build instructions starting with something like “Do you really want to do this?”! In the end I gave up because I didn’t have the time to devote to it. I just checked the link to the source code. Below the link is the following:

You’ll need to build this yourself. That can be a challenging and complex process, especially on Windows and macOS. We don’t provide help for this process, and we can’t support the end result. But if you’re hoping to modify Ardour or get involved in our development process, this is where to start.

If there’s no help and no support why would anyone spend their time on such a task?

Also, even if someone succeeds in building Ardour, what is the documentation like? Most OS projects (or ones that I’ve seen at least) have next to no documentation. If something were to happen to the lead developers the project would die a quick death. But without documentation it’s almost impossible for anyone to understand how a codebase like Ardour’s works. Now I haven’t checked Ardour’s documentation, but if it’s like other OS projects then it’s likely to be a major hindrance to new contributors to the project.

Anyway, that’s my 2c worth!

Cheers,

Chris

#145

And just a bit more about the complexity of the build:

Ardour developers in general do not provide assistance with this task, so please don’t ask us for help.

Building GTK+ (the graphical toolkit we use) from source is a monumental task and can require a lot of other libraries to be built and installed along the way. This is particularly true on OS X, where many of GTK’s own dependencies are not easily (or correctly) available.

#146

We don’t have the resources to make building the dependency stack simpler. Every once in a while, someone shows up with a promise/offer to e.g. build a Docker image. But it never happens. We’d rather work on features and bug fixes, and think that’s a better result for users. We could be wrong about that.

If there’s no help and no support why would anyone spend their time on such a task?

If there’s no help or support, why would anyone ever sit down to write a DAW? Intrinsic motivation is the main answer to both questions, IMO. If you plan to use a system running macOS to try to do development work on Ardour, I would assume that you have some fondness for macOS that makes it worth dealing with the issues the platform puts in your way. If that’s not the case, I’m not sure why you’d choose to do this.

We also can’t change the fact that neither Apple nor Microsoft have any declared or apparent interest in cross-platform development. The tools for doing this will always be “foreign” to both platforms - that’s just a cost of wanting/needing to do cross-platform stuff. The Apple-native and/or MS-native tools might be very nice, but you can’t use them in any meaningful sense to do work across platforms.

1 Like
#147

That’s fair enough and I completely understand. But I don’t think you can have it both ways. If you want to encourage new developers to join the project then the “price of admission” needs to be lower. I imagine most developers interested in contributing would only have a limited amount of time to dedicate to the project, say, a few hours a week. If they can’t get a build happening in that time then why would they stay? I was interested in doing this on a Mac because that’s what I was familiar with and had available. But from what I can see, support for a Linux build is similar:

We do not provide support for building from source. We do not make regular efforts to keep this page up to date. Please do not ask for help with this process.

To me, that’s a bit disheartening!

Now I’m not here to lecture anyone about how to run a project. I actually think Ardour is an amazing achievement. I do think though, that having a large and diverse group of people actively developing the project is “a good thing”. Because at some point the current developers will have to move on. What happens then?

Cheers!

#148

Does anyone know what proportion of Ardour’s support libs are ‘C’ compared to C++?

The reason I’m asking is that for ‘C’, it’s usually possible to supply a suite of pre-built dev libraries (with header files) for each platform and the pre-built ones can be used with various compilers. Unfortunately this doesn’t work for C++ because of name mangling… though I suspect the majority in Ardour’s case are probably conventional ‘C’.

In the early days, Ardour incorporated its own versions of some of the C++ libs (e.g. sigc++ / glademm / gnomecanvasmm / rubberband / vamp etc). So if there’d been pre-built ‘C’ libs available it could’ve been quite a help for attracting new developers.

OTOH Ardour was a much simpler product back then… Nowadays it’s likely not the kinda product that budding devs can learn in just a few hours per week.

#149

There is currently a bus factor of around 2 1/2, and if you include derivative products like Harrison Mixbus, the number is significantly larger.

Anyway, finding out how to install build dependencies is trivial compared to writing realtime-safe code for massive multi-threaded C++ application.

But before starting to build everything from source, I suggest to search for “homebrew ardour” and/or “homebrew audio”. While homebrew has issues if you want to create distributable applications, it is a perfectly fine starting point (the same is true for packages provided by most GNU/Linux distributions).

Indeed, but to my surprise it recently took an intern at Harrison under 2 days to get started. If one is focused on fixing a specific bug, or contributing to control surface code, reading and understanding the whole codebase is not needed.

In any case reading doc/source_tree_layout.txt might come in handy.

1 Like
#150

Have a read of this article, especially the comments:

https://sourceforge.net/blog/open-source-growing-not/

Cheers!

#151

I would respectfully make a few points.

I know quite a few people inside the world of proprietary audio software development. Through conversations over many years with them, I know what hiring developers looks like when you can offer a fairly competitive salary: it looks terrible. There are very, very few people with the skills and background needed to work on the core aspects of a DAW.

As Robin noted above, and as we have seen over the 22+ years of the project’s life, people are able to “jump in”, typically most successfully when they have a relatively constrained goal. Our developer credits list currently has 81 names in it. That’s a lot more people than have worked on most proprietary DAWs and way way more people than have worked on other FLOSS DAW.

Would it be totally awesome if anyone who was interested in contributing to Ardour could spend 10 minutes to set up their environment and then get started? It absolutely would.

Do we have any idea how we could do in a way that did not act as a continually resource drain on the time of the existing developers? We do not.

There’s a lot of stuff written about contributing to FLOSS projects that is either misinformed in general, or significantly less true when applied to a project like Ardour. We would love it if it was easier to get started, but we also do not believe that doing so will open the floodgates to substantial numbers of new developers. The projects that benefit from an attention to “on-boarding” generally tend to those with relatively low barriers to entry in terms of skills. That’s just not the case for Ardour: it’s a big, very complex code base based on technologies that very, very few developers have much exposure to.

If someone were ever to volunteer to maintain a ready-to-use, always-up-to-date version of the dependency stacks, we would gladly host them. If someone were to step up and volunteer to function as an “on-boarding coordinator”, we would welcome them gladly. However, it is our (my?) fervent and serious belief that that return from the existing (2.5) developers spending time on either of these tasks is not an appropriate use of our time, given the expectations of the thousands of people who fund our work on the project.

4 Likes
#152

we don’t support you if you want to build the software yourself (cause we provide binaries for a fee)
why don’t we have more developers?!?!
you know, does Ardour even need to be open source if noone understands it?
but we will not support you if you want to understand it

:clown_face:

Man, Krita is extremely successful and even has a Steam version and you can just download the binaries anyway and the maintainer, Boudewijn Rempt is extremely supportive of anyone who wants to build from source.
Edit: Here, even nightly builds, for windows.
https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/

but if noone pays for Ardour then we can’t work on it fulltime anymore

Then dont work on in fulltime anymore. Such a phrase does not make me feel pity or anything, it conveys to me that you want to do other, more lucrative things but “ony stay with Ardour as long as it pays but you’d rather do the other thing youd be doing if you weren’t paid for it”
So stop working on Ardour. Do the thing you’d do otherwise, and see what happens.

No really, do see what happens.

This is the youtube/media conundrum. “Without your support on patreon then we wouldn’t be able to make these videos”
Yeah well then quit!
“But I want to make videos…especially the attention w$%$e kind where I get to be a cool video personality”
Yeah, you do. So do it.

It’s also the chicken and the egg thing.
Did you get financed from the very start? If not, then how did Ardour even come to life?

Anyway. Instead of lamenting about open source being too obtuse, why don’t you teach people how to do it, beyond the basics on whose page you even go “Stop, do you really have to do this?” ?

Perhaps it would spark a passion in someone who might create something as good and accessible to everyone in the future, like ardour could be.

But yeah, I really really loathe the “I can’t work on this fulltime otherwise” thing prevalent in media.
Then don’t. Stop lowballing yourself with your ardour pity party and do your actual lucrative thing in the one lifetime you’re getting.