Re: Making money on open source, if not by selling _support_, then how?

[Justin Gombos <rpbkbq.xax.gld@uluv.kbq>]

On 2006-04-13, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Thu, 13 Apr 2006 02:58:50 GMT, Justin Gombos wrote:
>> 
>> Absolutely.  It supports the anti-copyright /part/ of your point.
>> This is why the closed source cathedral approach fails.  CopyLEFT
>> on the other hand opens distribution to the public - so this is
>> where open source succeeds in getting creative works to the
>> consumer.  If I understand you, you're claiming that the lack of
>> rewards is a "problem" for both models, but you've failed to show
>> this for open source.
>
> No, the burden of proof / enlightenment is on your side. I don't see
> any functioning mechanism of rewarding in either model.

To see it, you only need to observe the fact that open source software
exists, and continues to grow.  From this observation alone, you know
that there is a mechanism of rewards to promote such development.

> I fully agree with "openness" as a legal right of each citizen to
> know what is going on in the things directly influencing his/her
> life. It is no different from ingredients list of a food
> product. But it isn't a major component of quality, neither it is a
> way of rewarding.

The openness of the code *is* one of many components of quality.
Besides the quality built into the process of open source development,
you also have the benefit of potentially millions of eyes looking at
the product and discovering defects in the code.

And with respect to "ways of rewarding," this still remains a solution
looking for a problem.  Regardless of what's in place, /additional/
rewards are unnecessary; this is easily verifiable by observing growth
rate of publically available open source software.

>> It solves the problem of getting the tools to the consumers.  It
>> solves this problem very well, particularly because unsatisfied
>> consumers are further empowered serve themselves by modifying the
>> product as needed.
>
> This is another inherently invalid argument. A consumer, by
> definition, is somebody unable or unwilling to produce the product
> by itself. "Unable" here means, in particular, economically,
> technically, mentally, physically etc infeasible.

That's a rather strange definition for "consumer."  My argument is
well grounded because GNU consumers have relatively unrestricted
access to the works.  If the consumer (by your odd definition) is not
economically able to acquire the software they need, or the equipment
needed to run the software, they would not be getting any closed
source software either.

But even with your handicapped consumer, such consumers still have
much greater access to open source software, primarily because it's
free of cost, enabling widespread unrestrained distribution of
software.  The fact that they have the option of modifying it is an
extra benefit (whether they do the mods themselves or hire a
contractor) - and you can neglect those cases when talking about a
consumer handicapped in the way that you describe, and still see that
the work gets widely distributed (rather than locked up and released
for a price).

>> Flight control software is an excellent example of something that
>> should be open source; particularly because it would not require
>> volunteers.  The federal government (a likely consumer who is
>> prohibited from copyright) could hire contractors to produce flight
>> control software under a contract that prohibits the contractors
>> from copyrighting it.
>
> I.e. as soon as we take a thing where mission is critical (=quality
> is paramount), you give up and let the government to intervene. This
> presumes a better motivation of programmers, than ones operating at
> the bazar.

The client (the feds in this case) hires who they want, and will
likely hire only qualified applicants.

>> Sure, this is an issue with closed source, where you must take the
>> whole black box in one piece.  You might not want IE, but if you
>> need Windows, too bad.  Again, the open source model solves this by
>> enabling the user to be as selective as they are technically able
>> to, from keeping tools small, and right down to trashing code
>> fragments and recompiling.
>
> No, I don't want to do the integration work by myself. I am a
> customer. I want to do only my job. This is independent on
> openness. Example: Linux distributions.

Linux distributions is an excellent example here.  If you want all the
tools rolled into one distro, you simply select the distro you need.
If none exists to meet your need, and you don't want the integration
effort of rolling your own, you have the option of hiring a contractor
to do the dirty work for you.

Again, these options are largely non-existent if not greatly limited
in the closed source paradigm.  You're at the mercy of the vendor to
offer a modified product - and when they do, you better have deep
pockets because there is no one to compete against them to offer mods
on their product.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.