Why would anybody start writing a DAW in 2005?
JF: It grew out of frustration with the existing software that I'd tried to use. My career is as a programmer, but a few years before [Reaper], I started playing music for fun. Christophe turned me on to Vegas — I think it was Vegas 4.0. I used it for a while, and got a little annoyed with some of the limitations it had for audio. At a certain point I decided that I would like to have control over the environment I would work in to make music, and I started making my own, just for fun. It kinda went from there.
Was it just you at the time?
JF: Initially, and Christophe joined in 2006.
I remember reading about Reaper back then. The product was evolving very quickly.
JF: We were pretty productive. If you look back at what we've done in the last four years, given the number of people involved (which at this point is up to three) we've definitely come a long way.
Other DAW companies are easily 10, if not 100, times as big as yours.
JF: Yeah. Our overhead is really low, and because we're making software, we don't have per-unit costs. We can take the time and do things right. We don't have a big machine that we need to support and we don't ever need to push out new releases in order to increase revenue. We own the company, so we're only accountable to ourselves. In that sense we don't compromise the product or the way we treat users in order to meet some arbitrary goal. There's also an emphasis on keeping it so we don't have to deal with additional bullshit, which is easier when you keep things small. As a developer, being able to build everything quickly and easily is important. Being able to update the website and post builds online for people is important. If our program was a gigabyte [in size], say we included a ton of samples, a lot of things wouldn't be possible. This is a good example — in software development, there's something called QA, which is quality assurance. The big company process is that you have elaborate QA processes where you test all kinds of different things for every release. It's somewhat effective, but in software, there's just so much complexity, so many states things can be in, that anyone who thinks QA is even north of 50 percent effective is delusional. You are never going to come close to getting all these states tested. So you try, and you waste a ton of time and effort testing things, which then slows down your release cycle, and slows down development as a result. It ends up decreasing the efficiency of the process for some margin level of effectiveness, and it's mostly a cover your ass sort of measure. We obviously do some internal QA, but for the vast majority we rely on a group of testers who test builds when we add new functionality.
So you have users who are willing to be ongoing beta testers?
JF: Users who are psyched to be using a latest and greatest feature and to give feedback suggesting how things should be. It's open — anyone who wants to do it can. Generally speaking, it is more effective than any QA process I've ever seen in a corporate environment, and it's much more efficient.
A big aspect of Reaper seems to be your relationship with your users, versus the way users are probably accustomed to being treated by large companies.
JF: That's something that we've felt strongly about from the beginning, and it's something I felt when I started my first company — which I then lost control of and sold.
