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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 15 Apr 2006 21:17:46 GMT, Justin Gombos wrote:

> 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.

If you open the fridge each morning and find beer there, should this
observation lead you the conclusion, that fridges brew beer?

> 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?

> 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. Secondly it
effectively puts a limit to the complexity and quality of the software.
Millions of incompetent eyes cannot replace an educated one. Any project
manager knows that each new programmer increases risk for the project to
collapse.

> 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.

... which bears all signs of pop-culture, by the way. Public involvement
destroys quality and even common sense. Turn MTV on, if you want an
example. Openness /= direct democracy.

>>> 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.

I meant division of labor. Customer is somebody who is specialized to
produces something else. What you describe reminds me natural economy,
which was died off especially because it was unable to provide quality,
diversity, volume of products, didn't reward invention, couldn't ensure
sustainable growth.

>>> 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.

Now, my these is: hiring only qualified applicants must be the rule for
*all* types of job, if we consider a quality-oriented production. 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.
Secondly, there is no motivation for people to become selected. Qualified
programmers don't grow on trees. 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 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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de