Re: economic efficiency of free software

"Stephen J. Turnbull" <[email protected]> wrote:

[snip]

> I think there is a real opportunity here.  Figure out a way to get
> people to pay for software indexing and review, and channel their bug
> reports and feature requests to the developers, and generate a revenue
> stream from that.  It would work like electronic publishing in
> academia, except that (see below) the problem is aggregating the
> signals of customers, not peers.

OH MY WORD!  That's it!

Maybe this email is too small to hold my proof.  :-)

Some Background:
----------------
I have not done anything with rocketaware.com for oh, 2
years now.  (And it was even way longer before that Dale D. at
O'Reilly had my ear.)  It still is around, high google ranking,
thousands of page views a day, even though it has many really
stale references which return 404.

I have the cost of integrating data elements into a heirarchy down
to a science.  With software assist, I can do 400 inserts an hour
into the catalog of a few hundred categories and a few tens of thousands
of listings.  I have a good idea how to scale it to more than one
maintainer, and still maintain high efficiency, and not overwhelm
the visitor with stuff they do not want to see (the point of the
UI design.)

I mention this because my experience is that the marginal cost to
insert a DB record into a large catalog is something way less than a
$1.

The innovation after reading Stephen's email:
--------------------------------------------
What if in addition to software, I added DB records for
individual bug reports and feature requests to the index,
and then people could somehow decide which particular DB
records they wanted to promote.

People who have an interest in particular software package,
or a particular un-implemented feature, or a particular bug,
could pay to have the web site promote the DB record of their
interest closer to the top of its category page.

Items closer to the top would be more likely to attract the
attention of other users ("hey, yes, that is something I want
fixed too!") and the attention of software developers (official
maintainers, and freelance contributors.) 

Follow me so far?  The primary intent of this setup is
efficient distributed decision-making.  The second intent
to allow a distributed free software community to provide
an economic incentive to those who increase software value.

How/Why do members pay?
-----------------------
1. Suppose "Apache" or OpenBSD got grant money for unspecified
improvements.  We can run this like one of the funded-by-charity
seed exchanges: The charity invites all the suppliers and seed
users, and gives out vouchers to the users and lets them
decide on what seeds and suppliers.  The suppliers turn in
the vouchers to be reimbursed with real money.

2. The system will collect a per-category membership fee (e.g. Databases,
or NNTP) that permits participation.  Viewing will always be available
to non-paying members.

3. Members can pay a fee to get a project listed (a DB record
inserted) and shown.

   In return the member gets "credits" in proportion to
         their fee
       + a pro-rated share of the grant funding pool 
       - a pro-rated share of site operation expenses (which are low.).  

How do members participate?
---------------------------
4. Members "spend" their credits by assigning them to specific DB records,
which are for projects, features, bugs, or other members.

DB records are generally shown by credit counts, so high-value items will
appear first.  On-site text "ads" will promote DB records, with higher
valued records appearing more often or in preferred page positions.

5. Anyone can offer credits to first-time insert a new DB record for
a bug or feature for a project. The official maintainers have to approve
or not.  If not, or not done in a reasonable amount of time, the
member gets back their offer and the DB record is not inserted.

6. The official maintainers for a project can take credits away from
the project's DB record in order to pay for the bulk insertion of DB records for
particular bugs or features.

What induces creating value?
----------------------------
7. For projects, the official maintainers[see note 1, below] can take
credits away from the DB record, and get real money back.  They can spend this
however they want: no strings attached.  The official maintainers will
want to induce members to spend their credits by transferring them to
their project.  They can do this however they like, but generally it
will be in ways not controlled or measured by the system.  The
members do that.

8. Developers create value by adding features and fixing bugs.  Official
maintainers are responsible for inducing development.  One way they
can induce members to be developers is by closing a DB record,
which consists of:
   - Providing documentation/link to explain why the record is closed.
   - Designating how the assigned credits are to be distributed (to what
     members or DB records) after the comment and feedback period.

When "closed," the DB record does not disappear, it enters a "comment and feedback
period".  Members who paid credits to the DB record will get a notification,
and can then post comments, approvals, or complaints about the closure.

The system will not enforce a particular complaint/approval level, the
comments are for users and the official maintainers to assess and communicate
about quality.  If within the comment-and-feedback period, they record
can be re-opened.

9. Official maintainers can also take project credits and assign
them to developer members.

10. A member can receive cash payment in proportion to credits they
have received from projects or were assigned during closures that they
want to convert to cash.  They cannot cash out the amount which was
their membership fee or pro-rated grant money.

Questions
---------
OK, I expect everyone to shoot holes in this.  Please please do.
I want to see why this is a really bad idea.

Sure, there is a lot to flesh out.  I think one key to making this acceptably
not cumbersome is to design it so that the transfers of credits on close are
automatically done with a project's existing defect tracking/resolution/cvs
process, not a separate step.

One other big problem might be that credit transfers between members
may be taxable, not just the cash outs, and the DB record may be taxable
property since it has cash value.  Any opinions on that?  (U.S. Tax Protestors
need not answer that one, because I am pretty sure I know what they would say.)

How could the entity running this be non-profit?  Taking in money and holding
on to it with payouts in the indefinite future is going to trip over some banking
laws I think.  What if no one actually paid until closures happened?  That 
might avoid _some_ of the banking and tax implications, since credits would have no
cash value until they were transferred into a member or project account.

Anyone interested in trying this?  Did collab or anyone else ever consider 
something like this?  Brian B, are you reading?  Comments?

--------------------------------------

[1] By "official maintainer", I mean merely who is responsible for
inserting the DB record in the first place.  The DB record will
point back to a maintainer-owned URL somewhere. Members will quickly
distinguish who is "official."  People are paying real money
in order to insert these DB records for projects.  We can require
some confirmation that they own the URL, maybe email@domain, maybe
requiring a reciprocal link, not sure, but probably not a big
problem for the community of members to sort out who is official.