>>>>> "Kevin" == Kevin Karplus <karplus at cse.ucsc.edu> writes:
Kevin> I'm generally in favor of having source code available for any
Kevin> software I buy or use, but reluctant to part with source code
Kevin> that I have spent years working on.
I think the technical term for that position is "wanting to have your
cake and eat it too". 8^)
Kevin> On the other hand, it also makes it much harder for the
Kevin> originator of the program to keep the program maintained.
I disagree.
Kevin> Bug fixes that are done at one site are unlikely to propagate
Kevin> back to the original release. We have local bug fixes and
Kevin> enhancements for several of the open-source programs we use,
Kevin> and I have no idea whether the people who did the fixes sent
Kevin> them back to the original maintainers of the programs, or if
Kevin> they did, whether they were incorporated into the official
Kevin> version. If we pick up a new release, we may get something
Kevin> much buggier than what we currently have.
>From your example, it's plain that users failing to propagate bug
fixes back to the developer doesn't hurt the developer, it hurts the
_users_. If the developer runs into a bug, she'll fix it -- that's
what developers do. If _you_ run into a bug that the developer
doesn't, and you don't send your fixes back 'upstream', the only
person really hurt in the long run is yourself -- because you end up
locked into your personal fork of the project. The way to avoid this
is to do the right thing and send in the patch -- Open Source gives
more power to the end-user, but that includes the power to shoot
yourself in the foot -- it's your responsibility not to do that.
</soapbox>
Kevin> If you decide (as our University encourages us) to sell the
Kevin> program to commercial companies, while giving it away to
Kevin> academics, government labs, and non-profits, then you have to
Kevin> retain control of the source code, or it is too easy to pirate
Kevin> the code. This doesn't mean that the source code needs to be
Kevin> secret, but it may need to be protected by license agreements.
How is this different than Free or Open Source software? It's
protected by license agreements too. Freeing your software doesn't
mean you lose control of your software; it just means your software
gains the potential to grow without your explicit effort.
</soapbox> (No, really this time.)
Kevin> It turns out that most users don't care about the source code,
Kevin> so just distributing executables and documentation satisfies
Kevin> over 90% of the users (how many of you have had to get source
Kevin> code for BLAST?). If you want to retain control over your
Kevin> program (an idea that is anathema to some in the open-source
Kevin> community), then a two-tier license agreement is often the best
Kevin> strategy---most users get a simple license with permission to
Kevin> use the executables, and those who really have a need for the
Kevin> source code get a more detailed license.
Agreed, most users don't care. Heck, most of them _don't_ want the
code; it's just useless text files taking up disk. But, to return to
the context this thread started in, the concept of peer review seems
to me to require that you expose your code _at_least_ to a few outside
reviewers. Not just the output of running the program, but the actual
code -- because otherwise, the correctness of your results can not be
verified.
(See, I didn't even go near that 'anathema' comment. Didn't think I
could do it, did you?)
john.
--
----------------------------------------------------------------------------
[ John S Jacobs Anderson ]------><URL:mailto:jacobs at genehack.org>
[ Genehack: Not your daddy's weblog ]------><URL:http://genehack.org>
