Subject: Re: Bug Bounties. Making $ from bugzilla.
From: "Karsten M. Self" <>
Date: Mon, 26 Nov 2001 23:52:57 -0800
Mon, 26 Nov 2001 23:52:57 -0800
on Mon, Nov 26, 2001 at 11:42:48AM -0500, Ben (Ben
> Kragen wrote:
> > Brendan Macmillan wrote:
> [...]
> > > It's a *little* bit like that newsgroup dot-com, where people got
> > > paid for answering questions.  I can't remember the name, or find
> > > any links to it, so that doesn't bode well.    However, there
> > > might be some lessons from their
> >
> > QuestionExchange.  I remember it because it made everybody on
> > comp.lang.perl.misc mad --- the extra incentive to answer questions
> > induced people who didn't know the answers to guess, and guess wrong,
> > misleading people.
> I remember it as well.  I got paid something like a hundred dollars
> there, then discovered  It was interesting.
> QuestionExchange paid people money as an incentive to give good
> answers.  PM pays nothing but makes it fun to be there.
> So what happened?
> The attempt to give people incentives at QuestionExchange stifled all
> conversation.  There was a constant stream of questions I could answer
> but I didn't learn something by being there.  By contrast at PM I
> found a lot of conversation, some of which I learned a great deal
> from.  And a lot of the best conversation comes from discussion and
> criticism of merely adequate answers.
> As a result I have given orders of magnitude more time and energy to
> PM than I ever did to QuestionExchange.  Furthermore I have seen PM
> make a far bigger difference in the quality of new Perl programmers
> than I think the QuestionExchange format could possibly do.
> And upon reflection, I don't think that this difference is fixable.
> When you offer incentives for behaviour, people tend to do what they
> are incented to do.  PM offers very silly incentives for high quality
> interaction, and they get it.  QuestionExchange offered much better
> incentives for routine answers, and that is all that they ever got.
> I fear that trying to motivate open source development would have a
> similar result.  Pay people for fixing immediate bugs, and that is all
> that you will get.  Pay people to produce a system that solves problem
> X, and that is all you will get, with no eye to whether the system is
> high quality, will grow, etc.  Make good programmers live with a
> program for a while, and they develop all sorts of esoteric concerns
> about things like code quality, architecture, etc.

This is an excellent overview of what I feel is one of the more
critical, and less understood (particularly outside the free software /
open source communities) social dynamics.

I'm not even sure that it's the official incentives built into PM as
much as the unofficial ones -- recognition, feedback, constructive
criticism, and new ideas offered by other monks.  In my case, I spend a
lot of time one a number of discussion lists, in particular the
"debian-user" list, which has *no* official award mechanisms.  I still
find the experience highly productive.

This is a theme that runs through John Seely Brown's  The Social Life of
Information .  This is possibly one of the better books on the
behavioral aspects of what comprises free software methods, that never
mentions free software.  JSB comes => <= this close to absolutely
 getting  it, but never mentions GNU/Linux, free software, open source,
Richard Stallman, Linus Torvalds, or even Apache.  The latter is
particularly poignant:  Xerox (JSB ran Xerox PARC) is a document
management, duplication, and distribution company.  Apache provides more
documents in a day than Xerox likely produces in a month, if not a year.
This for a book published in 2000.

Oversights notwithstanding, what JSB *does* get is the very vital role
 informal  networks and structures play in the propagation,
promulgation, discovery, and synthesis, of information.  Chapter 4,
"Practice Makes Process", in particular, is required reading, as is
"Home Alone", chapter 3.  Both cover the often overlooked, largely
intangible, elements which make the traditional office environment
productive for most workers.  

Brown castigates Chiat/Day for its "hotdesking" experiment (a dismal
failure), opens chapter 3 with an all-too-familiar diary of
technological mishaps experienced by a would be home-working
telecommuter (though my own marginalium for the sentence "The more
cavalier futurists sometimes appear to work with a magical brand of
computer not available to the rest of us." is the inscription "Linux",
and a smiling cartoon).  He talks of informal support networks in
offices around the planet.  This is a phenomenon usually looked at from
the cost perspective (informal technical support is thought to add $5000
to the annual costs of office automation), but on the benefit side, it's
a case of users, familiar with tasks, technology, glitches, and
workarounds, helping users.  Far more efficient than getting
cookie-cutter solutions from front-line tech support unfamiliar with
tasks and institutional experience.

Where "Home Alone" looks at hidden infrastructure costs (Brown cites
Andrew Odlyzko, at Bell Labs [1] putting capital costs at only 20% of
the total cost of office automation technology), "Process Makes Process"
emphasizes the benefit side of informal networks.  The skewered cow in
this case is business process reengineering, in particular as applied to
management and R&D:

    [D]espite talk of rebuilding from the bottom up and empowerment,
    business process reengineering tends to be relentlessly top down.
    Indeed, some suggest that it is of necessity a top-down,
    command-and-control procedure....  Business process reengineers tend
    to discourage exactly the sort of lateral links that people pursue
    to help make meaning.  Focussed on longitudinal cross-functionality,
    they dislike, and often try to discourage or even dismempower,
    occupational groups, job categories, and local workplace cultures.

I see the proposed "Bug Bounty" system as following this deathmarch
rather precisely.  It creates a vertical association between developers
and clients, while discouraging the inter-developer networking which is
so beneficial for creating, identifying, and refining useful solutions.
Brown's examples include healthcare claims processors, tech support
dispatch centers, on-site repair techs.  One particularly telling
example is the informal social meetings techs would engage in --
breakfast, lunch, coffee, end-of-day -- in which much idle chatter
occurred, but also much technical discussion, some war stories, some
discussion of active problems.

On another list I monitor, SAS-L, a young turk [2] has suggested the
heretical notion of setting up an IRC chat devoted to SAS topics.
There's been much negative response to this, mostly boiling down to 

    From experience of terminal messaging within a mainframe, (an older
    but probably not too dissimilar technology), I know that less than
    half of the traffic was task related.    

To which I responded:

    Your discussion of the mainframe messaging system is focusing on
    the wrong half of the equation.  It's not the lack of value of half
    the discussion, but the amount of value in the other half.  By your
    logic, the record labels and venture capital should shut up shop and
    go home.  Three in ten ventures are profitable, one in ten a major
    success.  In the recording field, it's 0.4% of artists that are
    successful.  Read again:  99.6% of artists never make back their
    recording costs.

People are fundamentally very good at pattern recognition.
Specifically:  sorting through a large array of inputs, and identifying
from them those that are of specific interest.  This process is
generally facilitated by providing somewhat unrelated information which
may prove useful in the future ("oh yeah, I remember some discussion on
that last week"), rather than by providing an extremely streamlined set
of communications.

PerlMonks and similar channeled, but nonexclusive, forums, provide a
context in which there are appropriate, personally targeted, incentives
to participate.  The loss of a few hundred dollars of direct income is
largely supplanted by directly applicable personal information,
notoriety, personal skillset enhancement, and increased employment
prospects.  Direct transactional approaches on the scale of
QuestionExchange simply cannot match this in overall efficiency.

There's a wide range of literature which falls outside the traditional
scope of free software discussion, which I feel is particularly
appropriate.  JSB is one author,  The Innovator's Dillemma  (cited by me
several times here) another.  Lessig's books.  There's a recent RAND
study, "Networks and Netwars: The Future of Terror, Crime, and
Militancy", which I feel is strongly appropriate.  There was apparently
a strong military interest in the recent O'Reilly P2P conference in
Washington, DC.

I feel one of the strong benefits of white-hat vs. black-hat networks in
general is freedom of communications.  There is more to be gained by
information swapping than by constraining communications.  The largest
distinction between white and black networks in this sense is the degree
to which communications can be made overt.  

In a white-hat network, most discussions can be open, trust
relationships are open, reputations are open, and corroboration is open.
Not always -- people and businesses do have some secrets, but this is
generally the exception rather than the rule.  Interesting corollary, my
primary interest in GPG is largely (though again not exclusively) for
authentication, rather than encryption.

In black-hat networks, communications and associations are generally
covert.  Trust is essential, but always in question [3]
several attacks on the Al Qaeda network I've seen suggested are
essentially trust attacks to turn factions against one another.  One
conversation I had early after Sept 11 started with my saying "now we
know how Microsoft feels",  pointing to relationships between the
decentralized nature of free software and Microsoft's frustrated efforts
to try attacking the movement.  On reflection I thought, no, actually,
it's more Microsoft that's like the terrorists, with a strong central
authority and safe haven, but a large number of independent operatives
(VARs and other partners).   Microsoft is vulnerable to similar attacks
-- decapitation (say, an effective DoJ settlement, unlikely as that
appears at the moment) or a disruption of trust relationships among
partners and customers.

Free software  has no center .  There are loci of power, but no real
central organization.  The strength of the movement derives from its
capacity for universal (or near universal) benefit.

This also means that structures can form and dissolve freely within the
free software community.  Structures that promote connectivity seem to
be grossly favored over those which constrain it. [3]


1. If you haven't hit Andrew's article cache yet, run, don't walk:

2. No.  Not me. 

3. BTW, if anyone's not got the picture yet, I generally don't care for
   the suggestion.  However I find some of the discussion points raised
   quite interesting and informative.

Karsten M. Self <>
 What part of "Gestalt" don't you understand?             Home of the brave                   Land of the free
   Free Dmitry! Boycott Adobe! Repeal the DMCA!
Geek for Hire           

["application/pgp-signature" not shown]