A Free Software Auction Service
Warnings
This article is available under
the GNU General Public License (GPL), version 2 or later.
Feel free to contribute encouragements, suggestions, money, or whatever.
Read more detailed warnings
about my articles.
Faré
Table of Contents
A Free Software Auction Service
Foreword
I started writing this article on 1998-12-26,
to express my growing feeling of need for such a service as described.
I hope that someone will undertake the task proposed,
and become rich thanks to it.
I have neither time nor will to undertake the task myself,
though I would gladly act as an advisor
during the construction and maintenance of such a service,
or as a referee for bids that are within my domain of proficiency.
The article is still a draft at this time.
It was begun on 1998-12-26.
On 1999-01-25, I wrote down the main ideas, to be developed later.
I invite discussions to happen on the publicly archived mailing-list
cybernethics@tunes.org.
A Free Software Auction Service
Introduction and Rationale
I've argued in other articles
about the theory of free software and free information:
my Manifesto of Free Information (in French),
my page on Free Software (in French),
my reply to Eric S. Raymond's articles (in English),
my (still draft) essay on the Catallactics of Free Software (in English).
I would like to now contribute a bit to the practice,
by proposing a charter for a much needed service:
providing an efficient, reliable, trusted way
for people to buy and sell free software development.
Providing adequate information (for any notion of adequacy) is a
service,
and calls for proper retribution.
Now, in a world long dominated
by undue priviledges of "intellectual property",
there exists no infrastructure that allows
The whole economy, and even the mentality of people,
is such that
The Problem of Getting Software Development Paid For
Developing software is a service.
Now, software must be free.
So how will software development get paid for?
Let's imagine that I am ready to offer $5
for some software component to be written.
That's not enough for anyone to consider the offer.
Now, let's imagine that another 1000 or 10000 or 1 million people
are ready to pay as much.
That's likely more than enough money to get the software written,
but unless there's a way to reliably raise the money
and have it spent in an adequate way,
the software won't get written.
Because the people who are ready to pay for the service
have no one to give the money to,
that they can trust to provide them with the software,
they won't pay.
Because the people who are able to provide the service,
but need spend resources to do it
(including their precious time)
can't get paid for that service,
they won't provide it.
In the end, no one is satisfied,
since the software user gets no software,
and the software writer gets no money.
But that needn't be.
Just because the current monopoly-oriented economical infrastructures
can't do it
doesn't mean it can't be done.
It can be done easily, and will be done soon.
Here is how.
Providing Trust is a Service
The problem is one of lack of trust.
Some people request a service,
but they trust no one to provide it.
Other may provide the service,
but they trust no one to pay for it.
Now, there may come an intermediate;
that intermediate would gather money from requesters,
and pay providers with it.
It would maintain good repute,
so that requesters can entrust it with their money,
and providers can trust it to pay them for software they write.
This intermediate allows for people to trust each other and cooperate
without having to know each other.
It's the same kind of progress in civilization as brought trade in general.
Only the service you trade is purely immaterial,
and it's made of trust, rather than of material objects.
This intermediate is a trust broker,
and the service it provides is trust.
It concentrates the desires of people who want software,
and can delegate to it the hassle of raising the money,
and organizing the development.
It provides programmers with a regular source of programming jobs,
that they can trust to pay them.
....
Mechanism of a Trust Broker
....
Providing Insurance is a Service
Programmers want be paid regularly, as salaried people.
Users want a no-hassle way to achieve reliable result.
Both want to avoid the complications of legal conflicts.
Insurance
against lack of job,
against lack of result,
against lawsuits,
is a service.
For that, will appear yet other intermediates.
Some will be brokers of actual programming services;
they will hire programmers on a permanent basis,
providing programmers with safety,
and providing users with availability.
Some will be brokers of software solutions,
providing users with safety,
and providing programmers with opportunities.
Some will be brokers in legal trust,
resolving conflicts for people in a way as cheap as possible,
and as fair as possible,
so that challenging the refereed decision would expectedly be costlier
than abiding by it.
A service is something that saves time to achieve a possible result,
possibly an amount of time that couldn't otherwise be afforded.
Trust in free software is a service
because it dispenses the customer with
spending the time necessary to achieve the confidence needed
to build the customer's project upon the given software.
To Do
- the FSAS is about raising money in a fine-grained way so as to allow
internet-wide paid development of free software!
- The main service sells TRUST:
a requester who needs software is guarranteed
that he'll either get correct software or not pay;
a provider of software services is guarranteed
that if he does write software, he will get paid.
- Separate services of trusted conflict resolving from insurance vs risk:
parties must agree in advance on a referee,
and whoever serves as a referee must be equally paid by both parties.
The ones who use his service pay, and no one else.
However, people who enter contracts are strongly encouraged
to also subscribe to an insurance contract,
and the initial contract form must include either a proof
that the party is already insured, or an associated insurance contract,
or an explicit disclaimer according to which the party declares
that he will be assume all the risk.
- Any possibility of appeal from the decision of the referee,
to the decision of "higher instances" must be specified
in the initial contract.
- The auctions may be renegociated
between the service requester and the declared candidates;
if there are no candidates,
then the terms of the auction may be freely modified by the requester.
- Candidates are encouraged to register,
and to negociate.
- So as to allow easier accumulation of money offers,
it is recommended to requesters that they split their specifications
into parts they may be solved separately.
For instance, their main specification
may avoid precise speed requirements,
but they may offer additional prizes
for answers that come fast, or that run fast,
or that are certified correct by a proof checker,
or by a given committee, etc.
- For first-code-wins contracts,
something should be done to discourage people
who do not register as candidates before they submit,
and thus make things hard for people who played it fair
by declaring themselves.
Something like a "challenging period" (week long?)
after the first correct submission
is declared to post rival submissions.
After the week is passed, submissions are closed
and code is made available for public review.
- Public review allows referees and requesters
to take into account broader insight
on the relative qualities of code.
- In case of multiple winners,
the rules should be known as to who gains how much.
The distribution of prizes must take into account,
in decreasing order of importance:
(1) what entries the referee considers more fit
(2) what entries the requester(s) consider more fit.
There will be bonuses for the first to declare code
that the referee judges as correct.
Since there might be several referees and several requesters,
each prize might get distributed among submitters
- Entries may evolve between the moment submissions are closed,
and the moment referees and requesters pay.
New entries may even be submitted after the challenging period;
However, they shouldn't be allowed to compete,
and enhancements shouldn't be taken into account,
all the less since code from submitted entries was available.
Or at least, people with regular entries should be given
a bonus, or be reserved a part of the prize.
- To be fair towards people with the actual talent that be too slow
to submit in time,
requesters should really be encouraged to split their prizes
in small pieces,
and standard contracts should include special "post facto" prizes,
meant to pay the people whose code will actually prove the "best",
which can only be decided at least a few months after the first
code was published.
- It looks like "closed source until submissions are closed"
encourages cathedral rather than bazaar development,
which is only good for small independent components.
Larger projects should be split.
When they cannot (why not?)
there should be a CVS server write-accessible to declared candidates,
where they are required to checkin stuff,
with the referees judging contributions.
- It looks like the model doesn't scale for too large projects.
It works only for small components.
- For large projects, there already exist software service providers;
only with free software,
there may be intermediates who sell real independent counsel,
for checking the works, or insuring the results, etc.
- Free competition among brokers to keep fees low.
- Brokers specializing each in some field of expertise.
- Meta-brokers allowing to synchronize auctions among brokers.
- There is already a
Free Software Bazaar,
but it cannot work much, since it refuses funding,
and (hence) doesn't provide much active service.
It suffers from both large payment overhead
and low capital attractiveness (max bid $200).
A fsas must actively seek funders and developers
(if possible among companies),
it must provide strong warranties to both parties,
etc.
Still, the FSB is a very good initiative,
that could serve as a basis for the FSAS.
- If it considers that more money was donated than should be necessary
to produce the software,
the auction service reserves the right to turn an auction
into contractual work,
by finding or choosing a developer and paying him a fixed amount
for the job.
If people have registered as prize claimers,
they should have priority in being auditionned as contractors;
moreover, turning a prize into a contract should be done
long enough in advance so as not to deceive registered developers,
who may earn the full prize if they return their program in time.
- Of the money saved by turning an auction into contractual work,
the service may keep part for itself,
and will return the rest to funders,
at a rate proportional to their stake.
The funders must have the opportunity
to get their money back,
but for both their convenience and that of the auction service,
they may instead store it to an account managed by the service,
until they choose to bid for another auction,
to cash it back after all,
or to donate it to some free software organization.
- Free Software Developers may in turn ask for funding,
and propose some services for a fee.
The auction service may organize the donation
(particularly important if the service cannot be rendered
below a minimum funding),
and it may also connect existing donators and existing developers,
should the desires of the former match the proficiencies of the latter.
- street performer protocol
- bounty
Browse back to: