# Re: the free software paradigm [was Re: Amazon used lisp & C exclusively?

Kent M Pitman <pitman@xxxxxxxxxxx> writes:

Suppose I have written a piece of software ... [which] helps
programmers--the ones who expect not to pay anything for anything.

Suppose I believe it is something others will want to use.
Something that doesn't exist. Something that will save time.
Something that long ago we would have said "people would pay for".
But now, well, ... the question is, what do I do now, in the present
day, the one I'm supposed to get used to and not fight.

I guess there are two questions:

(a) Suppose I grant for argument that it's a brave new world and we
do things differently now. Enlighten me. I have mouths to
feed in my household. I have something I think people want.
something that will feed my family...

My answer is: you don't - at least, not at first...

The answer to this is based on two related things:

* complexity of the solution

The more complex your solution is, the longer it takes for a
"sniper" to present an equivalent (or even 80%) approximation. For
at least some of the duration of this time interval you can charge
for the solution and get some % of the market to pay for it. Even
those who expect to pay nothing will sometimes pay when they have
to.

After you've claimed the intial market-share (100% of the paying
marketplace = N), you'll see that the "sniper" expands the market by
introducing a lower-cost (\$0.00 USD) solution. As the market
expands to M, we could assume that 100% of the expanding market (- M
N) goes to the \$0.00 solution, but that's not very realistic,
especially if your product is a complete solution and the other is
only an 80%. Instead, some small % [O here] will chose to adopt
share due to inertia. So, you end up with market-share of (+ N O)
that likes your product and is, presumably, willing to keep paying
for it.

When the revenues from (+ N O) are not sufficient to justify your
continued expenditure of time/effort/capital on development and
maintenance of the product, you open-source it to capture the
"goodwill" of the (+ N O) % of the market. This "goodwill" can then
be translated into:

* market share for another product
* paid consulting time funded by end-users
* employment with some firm that will now hire you to try to
capitalize on the "goodwill" you have built up

If we assume that the initial market-share is too small to justify
the intial productization of your solution, and the projected
increase to (+ N O) is too small to help justify the cost in the
long run, then you can only really release it open-source in the
first place. In this case, see the answer to part b.

(b) Suppose your answer is "you can't get money" or "don't expect
enough to feed your family" or even "don't expect enough to
make it worth your while to have made the item... Why should I
release it at all?

For ego purposes.

Why should anyone? Why shouldn't I just burn it and wait for
someone who values their time less than I to put something out?
Where is the incentive to make anything in this new world?

While I hesitate to reference him, Eric Raymond does posit that
the ultimate justification in this case is ego, pure and simple.
Everyone has some need to have their ego buoyed by others - and for
many people, their peers are the best source of ego strokes. Even
if you are well paid for other work, you may not get the necessary
ego boost you need to keep your outlook positive from the folks you
work with or your non-programming peers.

Let's not forget also that to someone who is a programmer, running
a business may seem complicated. They may well have the chutzpah to
say "I can do better" in terms of writing an actual program. But
they may feel that they won't actually ever be able to sell it
successfully - or that they'll get taken advantage of by
helps to deflect the anxiety these thoughts produce.

Where is the ability of the market to act as a natural
aggregator of wealth by directing people with a need to join
together to fund people with a product?

In theory, the open-source user-base becomes the market that is
willing to act in this fashion. I do not know of any particular
case where this has actually happened, although Google's Summer of
Code is a start. Perhaps it will become a bigger thing that
transcends Google in particular and even pays enough to fund
non-students.

Must this always be a "pull" process? Only build things the

In your hypothetical situation where no one will pay anything for
software, you've set it up as a buyer's market. As a seller, you
have no power to influence price (and therefore, no power to
influence demand). This is a "pull" process exactly. I don't think
the world is like this (yet).

Does that mean people who are inspired to innovate and who
want to "push" have no value? Because you're open to having a
free software sniper instantly de-value innovation and claim
its only value was the construction cost...

In the real world, it hasn't come to this - see my answer to part a.

I ask these questions not in the abstract. I ask what we tell
people in our community who want to deliver product. Because what
point is there writing programs if you can't sell them? Just for
fun? I came to this as a career and if the answer is that it's only
a hobby now, I should just get another line of work.

Open-source software has fragmented the marketplace. Niche
markets are where it is at. Within the right niche, you can make it
a career. On the other hand, if you don't work in a niche, you're
much more liklely to end up as just a hobbist.

I may not be an Einstein, but what I have to offer is not labor,
it's inspiration.

In the open-source world, inspiration is cheap. It's the ability
to transform that inspiration into working code that is lacking.
There are endless numbers of users who have wailed and gnashed their
teeth in order to attempt to influence the open-source gods to
release code that deals with issues of importance to the mere
mortals. The answer given is: godhood is within, master the tao of
programming and scratch your own itch.

And if you don't like my inspiration, at least acknolwedge the
possibility that there are people who are inspired. And that you
might want to incentivize them. What should they do with their
inspired ideas to get some money so they can eat? Plan for
vacation? Take care of themselves and their family in the case of
catastrophic illness? Perhaps hire another person to help them?
Build equity and value.

This seems less a quality related to open-source software in
particular and more to the overall trend to devalue R&D in general.
Short-term profit motives are part of the problem. The idea that
there are endless supplies of young (hence inexpensive) programmers
who will innovate because they can't help it - they don't know any
better - means that paying for software innovation is foolish. A
better plan is to wait for some young ones to flounder as they try
to establish a new idea, swoop in and buy them up and viola -
instant product. Of course, this doesn't work as well as it might,
but it's still (arguably) cheaper than paying old dogs to be
innovative.

If you can't suggest a process that will at least somewhat reliably
lead to income--enough that people can tell their families they're
going to risk their livelihood on without getting divorced, then why
are you building a superior society over the one we had before I
indulged this hypothetical, where there was an established mechanism
for selling for income... If there is a relatively reliable path,
I'm just overlooking it and eagerly awaiting insight.

As in many things these days, youth if valued over age and
experience in the world of software. Few people are thinking of the
long term.

The best thing you can do to help this process is to do something
similar to what Paul Graham has done with Y-Combinator - help to
setup systems that make the process of forming and running a company
to sell a productized solution easier and more foolproof. Some
ideas (for gratis, because none of them are new):

* Set up a co-operative development firm where members receive
benefits similar to those available via open-source software, but
non-members must pay to license the technology. These licensing
fees can then be shared as dividends to the co-op members.

* Start up a firm to publish the programming output of independent
programmers. A software label, so to speak. The label pays
staff programmers to enhance and maintain the product, while the
innovator gets a % of every copy sold. If such a company had a
reputation for honest dealing (unlike, say, a music publishing
label) it could become the easiest way to convert programming
acumen into \$\$\$\$\$.

--jon
.