From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, HK_RANDOM_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,afb4d45672b1e262 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx02.iad01.newshosting.com!newshosting.com!130.81.64.211.MISMATCH!cycny01.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc07.POSTED!20ae255c!not-for-mail Newsgroups: comp.lang.ada From: Justin Gombos Subject: Re: Making money on open source, if not by selling _support_, then how? References: <7NOdne-iYtWmIafZnZ2dnUVZ_tWdnZ2d@megapath.net> <292bf$443bb4e4$45491254$20549@KNOLOGY.NET> <1oc8e78n8ow5e.1mhfktiyo0wur$.dlg@40tude.net> <_pd0g.5775$yQ.1726@trnddc07> <1x8oeb12n9s76$.1msb6vrl8k885$.dlg@40tude.net> User-Agent: slrn/0.9.8.1 (Linux) Message-ID: Date: Sun, 16 Apr 2006 14:55:32 GMT NNTP-Posting-Host: 129.44.77.228 X-Complaints-To: abuse@verizon.net X-Trace: trnddc07 1145199332 129.44.77.228 (Sun, 16 Apr 2006 10:55:32 EDT) NNTP-Posting-Date: Sun, 16 Apr 2006 10:55:32 EDT Xref: g2news1.google.com comp.lang.ada:3838 Date: 2006-04-16T14:55:32+00:00 List-Id: On 2006-04-16, Dmitry A. Kazakov 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.