Subject: Minting FS credits for value creation
From: "Forrest J. Cavalier III" <mibsoft@mibsoftware.com>
Date: Sat, 7 Feb 2004 13:15:17 -0500 (EST)

Some further thoughts....

Perhaps real money too scarce and the community
is too widespread to make enough of a difference
in free software development.

In other words, there is way too much value
already being created in Free Software without
hard currency rewards, that it might be silly
to think we can foster much more with hard
currency rewards.  

But there are some who want/will use hard currency
transactions to create more value.  And certainly
I think there is quite a bit of hard currency looking
for a better way to create free software value.

So, I thought about dual-market: having "soft credits"
and "hard credits."  That may work, but it might
create a weird old-soviet-style economy.  I am not prepared
to analyze the dynamics of that, but from what I understand,
it wasn't efficient in an economic sense.  (Was that because
of the disparity in currency value or that the exchanges
in hard currency were officially illegal?)

There is a big advantage in soft credits though:
We can mint as many soft credits as we want, as easily
as we create a database record.  If the signals of transactions
are still present, relative value will become apparent, and
people can and will use the accumulation of soft credits
to guide the flow of hard currency (outside the system) towards
popular features and successful projects and developers.
I imagine Popular/successful developers will get hard currency
contracts to do real work.  Since this leads them to close
more DB records, they will get more soft credits in the
process.

Obviously, it is important to keep even the soft
credits scarce, because that is the only way that
people will be careful with spending them.  We
do not want to limit ourselves to slices from a
fixed pie, since we have an expanding pie.

Now how what do we need to avoid?  Certainly there
are websites (failed or failing) which tried the
funny money thing, like ExpertsExchange.

First, I think it is important that we do not mint
any credits unless someone increases the size of the
pie.  This is to stave off inflation.

But how do we know how big the pie is?

Some value is easy to measure, such as maintaining
the site in working order:
   1 point for classifying a submitted DB record
     to a subject category.  (Expands the pie)

   1 point for reviewing 20 URLs for appropriateness
     for category, kicking out some.  (Functions as
     a necessary feedback loop for the classification
     and review for something I discuss a bit further
     down.)

   1 point for updating down a URL that is now 404.
     (Stops the pie from shrinking.)

Hopefully they are appropriate controls so that no-one
can game the system and let inflation sneak in....

Paid or otherwise limited membership is probably going to be
important to keep out the rif-raff, but maybe one paid
membership could come with 3 free-invites for your
friends/colleagues/whoever, or maybe 3 project insertions.
Or maybe you get one invite a month.

Each membership could comes with a fixed number of points,
but amortized or delayed to prevent the "signup and abandon"
strategy from working.

How do we have more ways to earn credits, but not cause inflation?

I think we can decide that 1 credit should be equal to
a nominal amount of someone's time.  More highly-skilled
people will be able to work faster or choose or be able
to complete the closure of DB records with higher assigned
credits.

I am nearly certain we do not want to just mint new credits for
each member to spend every day.  I think ExpertsExchange and
similar sites did this to jump-start participation.
Isn't that a quick way to cause inflation?

Can we tie it to lines of code?
   Projects come in with 1 point for every 100 lines
   of source code or documentation.  But this should
   be amortized or somehow vetted by the community.

   Maybe it should just be 1 point for every 100
   lines of documentation.  :-)  Get docked points
   for having an unreliable project website.

   Official maintainers can assign 1 point for each
   10 lines of code they accept to close a DB record,
   or the amount that a DB record collected.

   1 point for submitting a bug report with a patch.
   
   1 point for reviewing/trying a patch.

Mint points for participation on mailing lists?

   1 point for each post to a project message board,
     awarded after a delay.

   -2 points if "enough" others reclassify your post during
    URL review as noise, (E.g. "ME too.", "send me a point")

One other advantage of soft credits is that the system becomes
easy enough to set up for one project: there is no need to
have a central website or middleman bank: 

This would enable an individual project to set it up themselves,
and do the work to attract members. They would then have a way
to let the community do distributed decision making.  

Once a few of these sites were set up, if they used the same
way of assigning value, the credits would be compatible, and
you could transfer credits between sites.  (Well, it would
be a mess, because you have to stop counterfieting.  Maybe
transfer credits between sites should only be with hard
currency and gentlemen's agreements.  Kind of like selling
your RPG account on ebay.  Or maybe a parent project like
collab or the ISC could control several cooperating sites
and ensure they didn't cheat with federal funds.)  Or maybe
it is more like corporate mergers and stock swaps....

Lunch time.  bye.