Two questions

[Andrew Dalke]

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.

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.

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.

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
(e-mail address removed)