[music-dsp] To open source or to not open source...
gogins at pipeline.com
gogins at pipeline.com
Wed Jan 28 10:01:20 EST 2004
Thanks to both Andrew and Ross for a good discussion of the issues in a
My advice to Andrew: Make a thorough investigation of existing software to
see if it does what you are planning to do, or could fairly easily be
extended to do what you are planning to do. If it does, or can,
FUGGEDABOUDID. Do the extensions, or write plugins, or make music, or
Second, if you choose to proceed with your project, another factor
influencing the open source decision is whether your project would use much
open source software. If you find yourself using PortAudio, libsndfile,
FLTK, wxWindows, FFTW, Python, Lua, boost, etc., etc., then I would argue
that this means your own software also should be open source. This, of
course, is especially true if you use free software.
The basic argument is that if software is made from other software,
everybody benefits ECONOMICALLY from open source and free software. In that
case, if you need to make money, I would suggest charging for services.
Nobody's figured out how to do that in music, however... oh yes they
have... it's called "producing.":
From: Andrew \"Silver Blade\" Greenwood lists at silverblade.co.uk
Date: Wed, 28 Jan 2004 09:28:59 -0000
To: music-dsp at shoko.calarts.edu
Subject: Re: [music-dsp] To open source or to not open source...
Hi again Ross :)
> I recently read "Free as in Freedom", a book about GNU project founder
> Richard Stallman, there's an online version here:
> It might give you some insights into the GNU free software philosophy. It
> certainly help me understand the differences between open source and free
I may take a look later on. I understand the basic difference - that open
source is free in the sense that you're given the freedom to do things with
the source code, rather than not having any freedom and being "locked in" to
whatever program it is. But free software means freeware, as in, you pay
nothing, really, doesn't it?
Did a little research on this over the past couple of lunchtimes at work and
that's the general idea I got anyway.
> One key is that you need
> to actually have the business people available to capitalise -- you can't
> it yourself by spending most/all of your time writing code. On the other
> hand, even a small closed-source shareware application can bring in money
> you pay attention to detail and have something people actually want to pay
Hmm. Attention to detail is something I'm focusing on a lot more now. I
usually make a few mock-ups of window layouts and control placement, and
then see what people think is most logical. But you probably mean detail as
in, not just graphical.
> - I also think you may encounter a situation where your paid-for
> are competing with free open-source extensions developed by other people.
> This isn't so much of a problem, but it's worth keeping in mind.
I did think of that, and that's one of the "against" reasons for me to
open-source my project. I wouldn't mind people getting alternative modules
for it (free or otherwise), but in that case, I'd rather charge something
for the basic sequencer (even if it is a little amount.)
> The above is pretty pessimistic, partly due to the fact that I have yet to
> see someone make money from an open-source arts-oriented application. If
> want to make open source "go for it" as someone else said, but if you want
> to make money there are some pretty successful models from the business
> world. Reason is a great example of giving users exactly what they think
> they want with packaging and pricing aimed at maximising return on
True, and that's my main concern - if I made my app open source, it'd be
virtually impossible to make money from it (other than donations from
On the other hand, I don't want to be greedy and charge a fortune for my
program, and it'd also be difficult to compete with other apps (like Reason)
if it were more expensive.
> If you can partition your market so that the people that buy the packaged
> version (perhaps even shrink wrapped in stores) don't know/care about the
> free version then this could work well. I'm not a marketing expert though,
> so don't take me too seriously. Note that if the open-source version isn't
> well documented/promoted/supported you're unlikely to get much input from
> open-source developers.
Good point. I'd love to make a packaged version available eventually, but to
begin with it should be fine just available to order from my website, I
> This may require some tricky licensing if you want to be able to
> re-incorporate bug fixes and positive changes to the open source version
> into your commercial version. However there are certainly people who take
> this approach. Mozilla had 3 different licenses to choose from, Qt has a
> depending on what platform you are on. Usually this kind of licensing
> require a legal team and a well considered business case -- probably
> you don't yet have if you're asking for advice on musicdsp ;-)
Well thats a good reason not to fork the code. Leaning more to the
closed-source direction more and more...
> There are of course rewards other than money, but you probably need money
> live, so working out a balance is important. I guess you have to ask
> yourself what it is that you would feel comfortable receiving as
> in return". Some motivations I can think of:
> Everyone balances the above and other factors according to their own
> and circumstances.
My main aim would be to make the software widespread, hence why I'd make a
"lite" edition of some form available for free, and then a paid-for version
with whatever functions were missing. This seems to work for my existing
project (despite it being quite old now and with an ugly UI), although I
haven't made much money from it, it still seems to be popular (freeware
> You might want to consider joining forces with some other projects rather
> than being another under-resourced start-up project.
I just need to find a project that would integrate well with mine. Besides,
I'm also doing this for the experience of doing it, so writing a majority of
the code myself would, I feel, be educational for me.
> There are many different kinds of musicians. Sometimes they don't buy
> software (their parents do, or they use unlicensed copies), sometimes they
> are hobbyists with high-paying careers in other areas, or they are
> musicians, or professional musicians. There are musicians who have never
> used a computer for music, even if they own one, and there are musicians
> only use their computer for music. If you look at the range of prices of
> commercial music software you can see that different products are
> different socio-economic strata. I'm not necessarily promoting "market
> segmentation" as a fundamental principle, but saying that the people
> purchasing your software are "Musicians" is just too broad to usefully
> your decision making.
In that case, I guess my product would be aimed mostly toward musicians who
use a computer for making music, with or without additional studio
equipment. By itself, it'd be a basic sequencer, but with external hardware
and internal virtual devices, it'd be more powerful than just a basic
> Sorry about the philosophical rant, but ultimately I think the choice of
> to run a software development project is a big decision, and I encourage
> to seek advice from as many people as possible.
Well, you have given me some good advice. Previously when I mentioned to
people that I was going to work on a sequencer, I was told I should make it
open-source and that commercial software sucks basically. But at the end of
the day, I'm not a big corporation trying to squeeze customers for every
last penny (or cent) they have. I just want to be successful.
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews,
mail2web - Check your email from the web at
More information about the music-dsp