Two questions

[Andrew Dalke]

Steven D'Aprano wrote:
> The existence of one or two or a thousand profitable software packages
> out of the millions in existence does not invalidate my skepticism that
> some random piece of software will directly make money for the
> developer.

'Tis true.  I think (but have no numbers to back me up) that most software
in the world is developed in-house and is not distributed.  Eric Raymond
at http://www.catb.org/~esr/writings/magic-cauldron/magic-cauldron-3.html
says it's <5%

For example, all my income has been from consulting and contract work, and
none from product development.

> Even assuming that the money-making ability would be lost if the source
> code was available, which is not a given (id software open-sources old
> versions of their rendering engines, and MySQL is quite profitable and
> their software is available source code and all).

Regarding id, see section 10.3 of
 http://www.catb.org/~esr/writings/magic-cauldron/magic-cauldron-10.html

They open their software when there isn't much money to be made from it. 
See also John Carmack's comments at
 http://slashdot.org/interviews/99/10/15/1012230.shtml

> Going open-source from development day one with a game probably doesn't
> make much sense. Design by committee doesn't work particularly well, and
> for something with as much popular appeal as games, the signal to noise
> ratio would probably be very low.
 ...
> I am going to be releasing the majority of the code for Q3 soon, but
> there will still be proprietary bits that we reserve all rights to.
> We make a fairly good chunk of income from technology licensing, so
> it would take some damn good arguments to convince everyone that giving
> it all away would be a good idea.

MySQL isn't relevant; I know there's companies that make money
that way.  There's also those that don't, and there are times
when obsfucation (compiling, .pyc, etc) changes the economic landscape
enough to bring in enough extra money that overrides what is to
many the low or non-existent moral obligation to provide the
original source in an easily usable and re-distributable form.

> Software rarely makes money for the developers directly. The odds are
> against any developer, hence my skepticism.

Software and restaurant startups have high failure rates.  But
people like to think they are special and can beat the odds.  Some do.
 
>>  - stock market trading companies make money in part by having
>>     specialized software to help with market trading, forecasts, etc.
> 
> You are mixing up a number of seperate issues here.

Yes, I am.

> If they distribute the software externally, then they almost certainly
> have more protection from licence agreements and copyright than they get
> from merely hiding the source. If they even do hide the source code,
> which is not a given.

Ahh, I thought by "hide the source" you meant "not open source".  Of
course there are many schemes whereby purchasers also get access
to the code but don't have redistribution rights.

> In-house use of market forecasting software falls into the "carpenter's
> hammer" category, not the "make money by selling software" category.

I was actually thinking of market trading software that was sold.
It's rather absurd to hide software from yourself.

One story I heard at the Python conference in Houston ('98, I think)
was of a company that developed this sort of package.  They redid
it and in-house used the newer version but sold the older and less
capable version to other companies, including competitors.

Nothing to do with open/closed/hidden/etc. but an interesting story.

> As for selling forecasting software, well, you haven't demonstrated that
> making the source code available would harm the ability to make money
> from it. Firstly, very often the value of the software is not the
> algorithms they use (curve fitting software and extrapolation algorithms
> are hardly secret), but the data used by the algorithm. So long as you
> keep the financial data proprietary, keeping the source code secret adds
> nothing.

At the 2000 Python conference in DC, Eric Raymond was the keynote.
He presented his ideas from "The Magic Cauldron"
  http://www.catb.org/~esr/writings/magic-cauldron/magic-cauldron.html

One of the examples he gave of a program that should not be open-sourced
was from a company that developed software to optimize lumber cutting
from a tree.  In that case the value *was* the algorithm used.

Note by the way that there were several objections to his presentation.
One was to his "Give Away the Recipe, Open A Restaurant"
http://www.catb.org/~esr/writings/magic-cauldron/magic-cauldron-9.html#ss9.3

In his talk he mentioned a famous restaurant, and pointed out you could
get the recipes for the meals.  One guy from the audience said he
worked for a sister restaurant to the one cited, that they signed
NDAs, and that the published recipes often excluded a few key parts, to
make it hard to duplicate.

>>   You are the US government developing software to design/test the next
>>   generation nuclear weapons system and don't want any other country to
>>   use it.  (GnuNuke?)
> 
> Then don't distribute the software, object or source code.

What about the software in the weapon itself?  When used it's
certainly delivered. As I joked with Greg Ewing - might as well
include the source code with the warhead.

>>   You are a student working on a take-home example and you aren't
>>   allowed to work with/help anyone else
> 
> Er, I don't see how this is supposed to work. An example of what? How
> does keeping the source code secret prevent the student from working
> with others?

There's an ethical obligation.  I could modify the situation a bit;
turn it into an assignment instead of a test, and have the user
testing & QA with other classmates be part of the assignment but
that sharing code isn't.  Distributing a .pyc might be considered
sufficient protection if a plagarism charge is investigated.


				Andrew
				dalke at dalkescientific.com