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

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

On 2006-04-16, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>
> If you open the fridge each morning and find beer there, should this
> observation lead you the conclusion, that fridges brew beer?

Good example - faulty conclusion.  You can conclude from that
observation that you have cold beer, and therefore don't need to make
any changes to the fridge to ensure that it cools the beer, or changes
to your procurement process for getting the beer.  Likewise, open
source continues to grow substantially, so you can conclude that
additional rewards are unnecessary for the growth to continue.

>> From this observation alone, you know that there is a mechanism of
>> rewards to promote such development.
>
> I don't know how it works. What if my brother, who loads the fridge
> with beer would turn to abstinence?

Remedial action would then become necessary.  So if the open source
community loses all its developers, only then will lack of rewards
become a problem (and even then it's a matter of perception).  As of
now, death of open source would be entirely hypothetical, and we're
not living in a hypothetical world.

>> 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.
>
> This is a model of wasting human resources in first place. 

Wasteful in what sense?  Wasteful does not describe gaining something
for nothing, it describes losing something you have and failing to
gain.  The more eyes on the code, the more opportunity to improve the
product.

> Secondly it effectively puts a limit to the complexity and quality
> of the software.  

Quite the opposit.  It's the closed source model that limits
complexity as well as quality.  You can be limited to the mental
capacity of those hired, or you can be limited to the mental capacity
of a subset of the world population, which can well exceed the size of
any one company.  

This is precisely why published encryption algorithms are accepted
more readily than closed crypto algorithms.  You cannot rely on a few
brains to find the flaws in a complex system.

> Millions of incompetent eyes cannot replace an educated one. 

Who's to say "the educated one" is not an open source developer?  And
who's to say incompetence is not in the workplace?  Incompetence
thrives in the workplace, particularly in software, where the
extrinsic rewards are high enough to motivate folks who have no
interest in software or the quality thereof.

> Any project manager knows that each new programmer increases risk
> for the project to collapse.

This does not support your claim that the number of brains is
inversely proportional to quality, because you're not accounting for
the economic factors behind the risk you describe.  The logistics are
substantailly different in the scenario of *hiring* the extra talent.
Among other differences, the value of their contribution minus the
overhead they bring must exceed what you pay them.

>> 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.
>
> I meant division of labor. Customer is somebody who is specialized to
> produces something else. 

Even that definition is unrealistic.  Consumers are not necessarily so
specialized that they're incapable of tailoring tools that are
initially generic to help them do their job better.  But even if they
were, open source consumers still have the option of hiring
contractors to tailor their tools.  Closed source consumers are stuck
with a black box, and must either modify the way they work to adapt to
the tool, or try to motivate the vendor to modify it for them at a
reasonable price, or hire someone to build the tool from the ground
up.  So open source consumers have all the same options that closed
source consumer have, and then some.

> Now, my these is: hiring only qualified applicants must be the rule
> for *all* types of job, if we consider a quality-oriented
> production.

Not necessarily.  Developers grow their skill when they are faced with
challenging tasks that they have not experienced.  Quality need not
suffer in such cases because peers guide, reviewers correct, and in
extreme cases, skilled developers overhaul.  Unqualified developers
exist in both models.  However, in cases of unqualified developers
writing open source production code, more reviewers may be finding
flaws and making improvements than a closed source project can
possibly justify hiring.

Furthermore, open source developers get the hind sight benefit of
seeing the changes even years after they've moved on, and learning
from it.

> When I say that neither of existing systems works, I mean that this
> selection does not happen. Firstly, there is no efficient mechanism
> of selection.  

Right, so you cannot be completely dependant on selection of talent
for quality products.

> Secondly, there is no motivation for people to become
> selected. Qualified programmers don't grow on trees. 

Who's to prevent a qualified programmer from producing open source?

> If the reward is to work 42 hours washing dishes and 30 contributing
> at night to a GNU project, then I don't see why students should
> spend 10+ years studying CS. They could become managers, advocates
> instead.

The unusual dishwasher case you bring up is not likely to be the
lifestyle of someone with an extensive formal education.  

> The attitude "it is no matter how much we pay them, because they
> would do the work anyway" is deeply rooted in both systems. This is
> why quality suffers.

Explain.  

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