Abstract: The Internet was built using the efforts of a worldwide team of programmers that coordinated and competed through laissez-faire methods. Much of the effort was freely provided, or paid for by entities in a process that did not conform to normal commercial revenue-seeking or government regulatory behaviour. This points to major inefficiencies in the market for software. One inhibitor is the large search costs undertaken by managers to acquire new programmers.
On the other hand, there are inherent inefficiencies in the way in which much of the free Internet software is developed. Specifically, there is no efficient way for users to direct the efforts of developers, other than by contracting for entire projects. This often results in a mismatch between development and requirement, as user communities and developer communities are sufficiently culturally different to make communication non-perfect.
We propose a market-based solution that allows many users to each contribute small amounts to projects, and for the sum effect of these contributions to influence and direct the activities of programmers towards tasks that users demand. A range of solutions is presented, from a web billboard bounty market to trading exchange markets for digital financial instruments. Reputational effects, intermediaries and differentiation are considered.
Relying on the existance of efficient electronic payment mechanisms and the efficiency promised by new electronic markets (both web billboard and digital financial instrument forms), we submit that the markets proposed could make small tasks more readily directable over the Internet, and could significantly enhance the efficiency of certain classes of software development.
The Internet and its nodal brother, Unix, were built by a worldwide team of cooperating programmers that generally achieved task distribution by means of laissez-faire competition. In some cases, dozens of competing commercial and non-commercial teams have worked on the same end-result project and have produced similar results, with popularity and distribution of each product determining eventual success (for example, mail front-ends).
Other components, especially internetworking protocols, have been produced using the Request For Comment process, a more formal method of coordination. Both RFCs and solutions can be submitted for consideration, and solutions can be trialled and pushed freely in the market.
The competing blend of software development processes has resulted in enourmous benefit to society; clearly, the Internet is unparalleled in its achievement. In terms of the efficient allocation of programming resources to achieve such a benefit, it would appear to have advantages over models, perhaps even raising new questions in the age-old debate over capitalism versus socialism as means of production [networks].
Dramatic claims aside, the Internet would at least appear to present prima facie evidence of inefficiencies in the market for commercial software development. Commercial project managers will be readily aware of some of these: difficulties in specifying and communicating projects plans and tasks, quality and lead time of resources, unavailability of appropriate tools.
Notwithstanding the apparent success of the Internet, there are some obvious inefficiencies in the way that tasks are distributed across the net:
This paper proposes solutions built on electronic markets, with the objective of reducing inefficiencies in the initiation of tasks by users and distribution to programmers. We make three very important assumptions during the development of our proposal:
The first two assumptions, payment systems and identity methods, are well covered elsewhere in the financial cryptography literature, and are assumed in this paper without further comment. The third assumption is not nearly so well addressed and hence we discuss it in a following section Can Software Development be Traded on a Market?
As a new and unproven concept, there is little existing work on the direct notion of electronic markets for tasks. Known work is documented in Existing Proposals. Then, with a confidence that some software can be managed in this fashion, we propose several forms of structuring markets in Market Designs.
It is not, however, our goal here to dwell on this model. Rather it suffices to demonstrate one area where the market for software development produces inefficient or sub-optimal results.
To do this, we need to develop a framework of costs [Firm]. Within any task, or venture that incurs costs, we can generally divide the costs into production costs and coordination costs. Production costs, in the case of software, might be the the salaries of programmers and designers, and refer to the process of physical production once all inputs are defined.
On the other hand, coordination costs refer to those costs that do not, in themselves, produce a line of code or eliminate a bug. These include a programmer's efforts at CV writing, scanning the jobs sections, attending interviews, improving skills, and billing for results. A software producer must also find and interview programmers, negotiate contracts and pay bills. [Internal&External].
Let us consider a hypothetical project manager entering the contract market to purchase 1 months-worth of labour. We will call him Dave, for consistency with later sections.
One important component of coordination costs is known as search costs - Dave must invest significant resources in procuring the human resources: definition, promulgation, initial selection, interviews, final selection, loss risk, and finally initial training costs. These costs lead to an incentive to allow each cost incurred to be written off over as long a lifetime as possible; in effect, the length of relationship should be long, allowing the once-off cost to be offset against many productive months of programming. In general the risk of failure in selection represents a limit on this incentive, and for this reason, the market for contracted programming labour settles at an optimal contract of 3 months [3months].
In practice, the search costs make contracts of one month a marginal proposition, and anything less is infeasible. This would leave Dave at the mercy of other resources above, but for a one month task, new employment is quickly ruled out, off-the-shelf software is ruled out by assumption, and software companies would tend to prefer longer relationships, larger firms, and higher rates.
In the absence of inhouse resource - which we can generally assume is limited in its breadth and depth by definition, we are left with a hole in the solution set: how to organise a task that is too short to contract, with too low a budget to out-source, and beyond the indigenous capabilities.
At this stage one could comment that the above hole is small and insignificant, but this is easily debunked:
We have proposed that this project is in demand by buyers. It is also possible to show that suppliers exist, by examining the various newsgroups and mailgroups for technologies. It remains to examine potential structures of marketplaces, and to assess whether there is merit in these structures.
In a talk entitled The Universal Piracy Network, Eric Hughes introduced the notion of a market for task completion, where completers were beyond the reach of current legal procedures such as resort to courts [Hughes]. This raised the dilemma that a contract could be accepted but not completed. Hughes suggestion was to insert an intermediary that guarunteed completion of the contract, based on the intermediary's reputation with past completions. Thus, the conflated issue of completion and trust was neatly divided into its two parts and properly placed with a party that specialised in it.
Hughes' design incorporated the use of a completion bond that represented an underwriting on the developer completing the project, along the line of instruments used in the Hollywood Film industry. In the event of failure to complete, funds would be returned to contributors from the underwriter.
However, it is arguable whether the notion of payback on default is universally suitable. In many cases there will be insufficient enthusiasm for restarting the market in a given task, e.g., if buys are small and widely dispersed, unlike, perhaps, the Hollywood notion where default leads to immediate need for replacement. In other cases, where integrated project work is being distributed, there would appear to be a more coherent replacement requirement to be planned ahead rather than invented after the fact [Detail].
A nascent market in Java tools operating at the Java Repository. This market is based on the indicated interest, rather than firm committments, along the lines of the Robin Hanson's Idea Futures [Hanson].
At this stage of development, the market is of the billboard form, where prospective buyers and sellers meet by examining a common information area.
In the first phase of Task Distribution, a Proposer, Alice, [Dramatis_Personae], constructs a contract that includes a specification of a task. That task might be, for example:
Language: Java - class Product: A minimal HTML viewer Features: Handles P, A HREF, B, I, H and UL. Other: It should be extendable. More features to follow. Purpose: For Help screens within Java applications. Quality: Code to be tested. Delivery: Uploaded to the FreeJava Server. Ownership: FreewareThis is a contract that can be presented to the exchange [Exchange], for listing as a task market. On acceptance (an administration detail for the exchange), several events occur:
In the next phase, users who will make use of the task deliverable enter the market. They place bids for the task, providing funds that go some way towards meeting the price required by one or more programmers.
Concurrently, programmers, Bob and Carol, work to meet the specification. The first one to upload the completed code to a stated server earns the bounty.
This method achieves the advantage of employing the programmer with the quickest offer to provide, and is thus an efficient method of allocation. However, its use of the speed metric causes these fundamental drawbacks:
Without there being a mechanism to assess relative merits of delivered products, the market, in whatever form, will result in inefficient results, as, in software projects, all offers and efforts are not of equal utility.
One way to assess results is to use a qualified judge such as Victor. He will check the code and make a pronouncement as to its acceptibility, which will remove the objection of minimal results. The bounty can then be paid out to Bob, or even to Carol, if she takes advantage of any delay imposed by Victor over Bob.
A variant of this is the completion bond proposed by Eric Hughes along the lines of film production. Walter, acting as an underwriter for a completion bond, would sign a contract that specified penalties in the event of failure of Bob to meet any contract or bounty awarded to him. Bob could now expect to demand more money of the market indicating the sum effect of Walter's reputation and his own (this is more useful once the programmers' race is removed, below).
This might, for example, recompense all buyers at the face value of their contributions, allowing them to redirect the funds elsewhere. This could work well where a defined deliverable component of a project fails, thus allowing the lead manager to simply restart with another task market, etc (although does nothing to recompense for lost time or critical path chaos).
A third variant is to employ a professional manager, Dave, to manage all aspects of the tasks, especially useful where there are multiple tasks to combine into a project. Then, Dave's key decisions are similar to user decisions.
Whilst different processes, the above three structures have two similarities. Firstly, they have similar solutions in the market place, discussed further below. Secondly, they raise the following issues:
Notwithstanding the infinite bandwidth of Internet advertising, it does little to aid the intermediary who has trouble turning information into decisions.
An underwriter would typically function remotely to the actual work, using an actuarial basis of risk, that relies mostly on public information. A judge tends to be brought in at the final stages, and goes through some process of immersion in the project. A manager works on a much more complex calculation, using a lot of private information and day-to-day, on-site, input into affairs (normally, this could be considered to be an employer or lead project manager).
Now, at what point does Walter the underwriter or Victor the judge meld into Dave the (remote) manager? On what basis will these models represent the real specialist intermediaries on the Internet, given that distance from projects is no longer applicable? This is not to dispute the need for one over the other, just to wonder to what extent the equalisation of the barrier of distance makes these roles more similar.
Notwithstanding the above uncertainties, there may be a place for the existance of Walter, Victor or Dave, where they enjoy superior information or ability. The lesson to be learnt here is not whether their existance is appropriate or not, but that a system should not be designed to exclude the existance of these forms of risk reduction, and should also explicitly allow the users to bypass these mechanisms as efficiently desirable. The ability of the intermediary to enter the market, gain his own reputation, and perform a useful risk reduction service should be guarantee of the efficiency of the market in this respect.
Fortunately, there is a relatively simple solution to this requirement of efficient intermediation:
Victor (or Walter or Dave) acts directly in the market as a seller on Bob's behalf. The intermediary places the sell order and receives the contract acceptance, and then liases with Bob to have the task completed. This also has the advantage of allowing better control of the project by the simple expedient of phased delivery of the funds [Obligations].
In order to turn the bounty market into a contract market, the following occurs: Once Alice issues a specification, Bob and Carol can now offer prices to take on the task.
Programmers need to assess the nature of the task, and ascribe likely value to it. Once comfortable with the specification, and their analysies of worth, they submit offers to the market. These offers specify the price of taking on the task [Bids&Offers]. This results in the market now having a range of programmers' offers, at differing prices.
Users, those who desire the software, are tempted to place bids for the task, providing funds that go some way towards meeting the price required by one or more programmers.
The third phase occurs when the market clears: that is, the total of the bids sums to provide enough funds to meet the price of the lowest offer (let's assume that Bob submitted the lowest offer). When the market clears, the following occurs:
This achieves the allocation of funds to the programmer with the cheapest offer to provide, and is thus an efficient method of allocation, but by using a different metric of efficiency to the bounty market. The contract market suffers from this fundamental drawback:
The solution presented by Bob may not be as good as the solution that might have been produced by another programmer. In the worst case, Bob may not complete his part of the deal by failing to meet the specification, or even reneging completely.
Which is better, speed or price? Whether time to market or price-performance is your preference is an individual question; to one man's meat, another's poison.
By introducing meat and poison into the market, we challenge an assumption: that the offers are fungible in some sense. In software, there is little chance of fungibility being a common occurance. Indeed, marketing theory would have it so, as the poorer strategy is generally to compete on price (only one can win), and the better is to differentiate your offer into new territory.
So we need a market where the offerings are differentiated, but related around a core commonality of Alice's original specification (see Appendix A for a discussion of market definitions). In order to be readily assessable by users, it should probably include some standard features, and room for extension. For example, the first standard feature would be price (already present in the above), and the second would be delivery time.
The third standard feature is the identity of the programmer. If Bob has submitted the cheapest and fastest bid, then his offer would dominate that of Carol in either of the two markets described earlier. However, if Bob has only 1 month of experience in Java, whilst Carol was part of the original language design team, there are bound to be some people unhappy with the way that Bob's order always wins the bounty or contract.
Now, in general, it is hard for systems to measure intangibles, but plausible for users to do so. Or, at least, users do not hold back in attempting to measure these things. So in order to present users with a choice based on intangibles, we would need to do several things, as driven by this logic:
In order to add differentiation into the market, we propose a market that allows programmers to present differing offers on the same task. The three differentiation paramaters of price, delivery time (after clearance), and identity will be included. To allow for flexibility and innovation, we further add a completely open text field.
Users can see the differing characteristics and can also determine who is making the offer [Identity]. Their bids will specify a list of offers that are applicable. They rationally apply a discount factor to every less than perfectly reputable seller, and they favour offers that best match their own requirements.
If we imagine Bob, Carol and Dave all active in the market, the following might represent a users buy screen:
Price Delivery Cash bids Free-form textual
date min - max additional clauses
Bob 80 60 10 70 fast and furious
Carol 120 90 30 90 Tested to Destruction
Dave 150 85 50 110 Includes Documentation!
Each offer has against it funds that represent summed bids that are committed to just that single offer, and total bids if all switchable funds were put against it.
The Clearance process now has to check each sell to see if the sum total of funds applicable to just that sell will result in clearance. If so, it clears that sell order and advises all parties of a trade. Parties can then either cancel their orders or redirect funds. As there will be many times where it is the user's interests to finance multiple versions, the market remains open with bidding against the remaining offers.
As each task is offered by a given name [Nyms], there is an ability to apply reputation by relating that tag to past efforts (mailgroups, Web advertising, etc). The problem of dissemination of reputational information is best handled outside of the strict trading regime of the electronic marketplace, due to the intangible, variant nature of the information.
It is still possible to assist in the collection of reputational information, by, for example, providing a home page in the PGP id field, and having the user's task market browser access this page (so as to check out written code).
Thus the strategy for programmers becomes one of competing on the differentiated factors. Reputation is something that can only be properly built up over repeated rounds of the market process, supplemented with appropriate web-based advertising. Note that such a multiple-round game presents interesting alternative to the use of an intermediary in order to improve efficiency of the market.
The markets so far proposed do not do much more than distribute the tasks efficiently. Specifically, they leave open questions of ownership, partly in line with our notions of market forces determining the best way to finance, develop and exploit software, and also our preferences for free software in its myriads of forms.
However, markets are normally related strongly to ownership, in that they assume the concept of private property rights, and this section examines extensions necessary to support development, where the deliverable is valuable, in a revenue stream sense.
As in conventional markets, the bids and offers should be orders to trade cash against financial instruments. Then, in order to offer to supply, a programmer must offer a package of instruments that capture the ownership of the project. These instruments will be initially worthless before clearance, then becoming promises to share in whatever of value is to be delivered. On delivery of the project, they become simple shares, possibly earning royalties on sales. This complex pattern of value makes these instruments derivatives rather than simple shares, although the distinction is not important for our purposes [Derivatives].
When the market clears, on Clearance time C, the instruments are delivered to the bidders in the market completion. Users holding these instruments hold something of value, being a share in the future profits of the project, and thus it makes sense that they be tradable. For this purpose, the exchange can maintain an open market in these instruments for buying and selling (although, it is a different form of market to the task market, being more conventional).
Then, on project completion (C+t), the work is uploaded, at which point the market could initiate an advice to the owners of the shares. The futures convert themselves to shares in the deliverable, which as a valuable item will now deliver a revenue stream via, for example, a software shop on the Internet.
This approach has some interesting ramifications:
To add more flexibility, payments can be sent automatically by the market according to a formula in the sell offer of the programmer. This could allow for 3 phased payments: Clearance (C), Delivery (C+t), and post-support (e.g., C+t+s).
In order to address this, we look at the ability of electronic market places to dramatically reduce the search costs. We propose several market microstructures that achieve a range of complexities and efficiencies.
Given the low transactional costs afforded by the Internet, and newly available trading technologies, it is possible to build a market-based solution that could significantly contribute to efficient development of Internet software.
Notwithstanding the brave predictions, it is easy to criticise the approach. As any programmer will affirm, software has a high proportion of tacit information and coordination requirements in it, challenging such assumptions as our highly defineable components [GHM]. This leads to a preference for partnership relationships rather than contractual relationships, something that the task market seeks to reduce [Partners].
Beyond the obvious - that this project is only small on paper - the following are worthy of note:
Dynamic Instruments. The markets built by Systemics were designed on the assumption of each new tradeable item being carefully designed, vetted and mounted as a traded instrument. This followed the real-world markets where initial public offerings (IPOs) are events of at least three months in the making.
With the task market, this assumption is shattered. On clearance, an item of definate value is created, and this must all happen in real time. This heavily strained the design of Systemics' markets, and broke the original rational for us to enter into the project: that it was relatively efficient to add this feature in.
However, where economic reason falters, programmers carry on. The market is now redesigned and reworked to permit dynamic financial instruments. It remains to consider whether there are alternative uses for short term or cheap traded instruments.
Logistics versus Strategy. Sometime during the Gulf War of 1991, General Schwarzkoph said "Journalists talk about strategy. Generals talk about logistics."
The hard part of coding trading markets is not the algorithms to make the clearance decisions but the bulk cash management code that holds and disburses value. As a system, the applications are dominated by the error case, and especially, the need to maintain value in a reliable, consistent state regardless of circumstances.
Free Riders. There is a plausible inefficiency in the existance of free riders, however, we prefer to wait and see whether this represents an issue, on the basis that the Internet is already built on this premise.
Corporate Secrets. Some managers looking for a universal method have been surprised that in order to obtain task completion they have been required to specify the contents of their work plans. The loss of secrecy in activity would appear to be, at this stage, a cost of entering the market.
On a related front, a plausible attack has been suggested: that of using the market as a cover for industrial espionage, e.g., by listing a task that is most efficiently met by stealing and publishing a competitor's trade secrets. This is clearly possible both within this proposal and without, and would appear to reflect the efficiency of this method, rather than present a motive to adjust or defer operation of the market.
Based on the framework described by Yannis Bakos in his 1991 paper on electronic marketplaces, "A Strategic Analysis of Electronic Marketplaces", we summarise some key elements that help our description of the markets developed in the body [Bakos91],
an interorganisational information system (IOS) that allows the participating buyers and sellers to exchange information about prices and product offerings.Markets can fundamentally be divided into two forms: commodity markets and differentiated markets. This division occurs on nature of the product across sellers, with commodity markets characterised by products that are essentially identical, or fungible, regardless of the seller. (Back to text).
Search Costs. Where buyers have imperfect information on entering the marketplace, they must expend time and effort in improving their information to the point of decision. These costs, known as search costs, are key to the sustainability of economic rents, or higher-than-normal profits. (Back to text.)
Transportation Costs. In the event of buying a non-ideal product in a differentiated market, the buyer faces a cost in transporting the product from its supplied state to its ideal state of usage.
Transaction Costs. In each transaction, there will be a fixed component involving the settlement of exchange of goods for currency. These can be formalised, for example, as the margin placed in credit card purchases, or they can be hidden, such as the cost of invoicing through the accounts department. (Back to text.)
Switching Costs. There are fixed costs that an individual incurs in entering into any marketplace for the first time: learning how trades occur, where to search efficiently for information, etc. Once incurred, these become sunk costs, and the decision to change from one marketplace will incur these costs again, making switching a relatively expensive exercise in comparison to not switching.
Most participants are interested in these requirements:
A programmer might trawl for new projects, a user could be planning a new strategy, or a project manager might have other agenda issues such as needing components. Which ever is the case, the needs of the proposer tend to be those of their fundamental activity, simply coupled with the ability to make a proposal.
Web source is at http://www.iang.org/papers/task_market.html
Version 0.9. 28 Aug 1999. Added postnote about AMIX.
Versions 0.8, 0.7. May, Aug 1999. Site corrections, publications details.
Version 0.6. Presented at Financial Cryptography 1997, Anguilla. Rafael Hirschfeld (Ed.) Financial Cryptography '97, LNCS 1318, Springer-Verlag. The entire abstracts for presented papers were published in Journal of Internet Banking Vol 2.4 September 1997. Back.
Ian Grigg can be reached at iang@systemics.com . He is a founder of Systemics, Ltd, a developer of Internet Financial Systems software. Back.
Christopher C. Petro can be reached at petro@suba.com . Back.
Networks. Specifically, the Internet has outstripped efforts by major companies and governments in networking ventures. For example, the combined competitive efforts of AOL, MSN, Compuserve, and Prodigy have been subsumed, and Minitel in France is being overtaken. Back.
The Firm. The nature of costs used here derives from The Theory of the Firm, a branch of microeconomics. Specific framework was extracted almost verbotim from Erik Brynjolfsson, Thomas W. Malone, Vijay Gurbaxani, Ajit Kambil, An Empirical Analysis of the Relationship Between Information Technology and Firm Size MIT Center for Coordination Science Working Paper 123
For reference, see especially Oliver Williamson, Markets and Hierarchy: Analysis and Antitrust Implications, Free Press, New York, 1975; and also Oliver Williamson The Economic Institutions of Capitalism, Free Press, New York, 1985. The Theory of the Firm was sparked by Coase, R. H., "The Nature of the Firm", Economica, New Series (1937), Vol. IV, pp.386-405; reprinted in: Stigler, G. J., and Boulding, K. E., (eds.), Readings in Price Theory published by Richard D. Irwin, Inc., Chicago, 1952. Back.
Internal&External. The theory goes on to divide these costs into internal and external coordination costs, although that distinction is not used here. Back.
3 Months. It is often stated as 3 months + where the plus signifies that the employer has an option for further work, but the contractor does not. Based on the author's experiences, try searching today's contractor positions at JobServe. Back.
1 month. This is a personal observation based on the author's time as contractor. YMMV. Back.
Lee&Kim 96. "A Game-Theoretic Analysis of the IT Paradigm Shift to Network Computing with Component-Ware", presented at Workshop on Information Systems and Economics , Bryngtae Lee (University of Arizona) and Beomsoo Kim (UT Austin). Back.
Bakos 91. "A Strategic Analysis of Electronic Marketplaces," MIS Quarterly, Volume 15, No. 3, September 1991, pp. 295-310. Back. to text or to Appendix A.
AMIX. Postnote: In 1999, amongst a burst of activity with at least 3 identified task markets taking the field, Stig Hackvän also alerted me to the AMIX, an important historical task market:
From: Stig_Hackvän <stig@hackvan.com> To: Ian Grigg <iang@systemics.com> Cc: bizaar@devlinux.com Subject: Autodesk, AMIX, and Xanadu for some AMIX background, check out John Walker's site (links below) and please let me know if you have other links which give perspective on AMIX and it's background/plight/course/fate/whatever... Also included are links to autodesk's xanadu affiliation because that's intertwined with AMIX and also because the xanadu software has just been released (with a very liberal x11 license... http://www.udanax.com/) Hello, Xanadu http://www.fourmilab.to/autofile/www/chapter2_64.html ted nelson joins autodesk... http://www.fourmilab.to/autofile/www/section2_64_1.html Understanding AMIX http://www.fourmilab.to/autofile/www/chapter2_76.html The Information Age Markets Information Markets Obvious Markets Non-critical Issues Why AMIX? digested, textified, and supplemented with an interview http://hackvan.com/etext/understanding-amix.txt Farewell, Xanadu & AMIX http://www.fourmilab.to/autofile/www/chapter2_103.html press releases (autodesk & amix) http://www.fourmilab.to/autofile/www/section2_103_1.html#SECTION001031000000000000000 http://www.fourmilab.to/autofile/www/section2_103_2.html internal discussion of the split with popup commentary on how meddling from california tax collectors nixed funding for AMIX... http://www.fourmilab.to/autofile/www/section2_103_3.html -- Stig ... Friend of Hacking ... 707-987-3236 work@home Hackvän ... http://hackvan.com ... 415-264-8754 mobile We are {b}Org ... http://brainofstig.AI ... stig@hackvan.com |
post on <bizaar@devlinux.com>, 28 August 1999, copied above.
See also this comments on AMIX in this Priceline article (page 3). Back.
Hughes. Eric Hughes, "The Universal Piracy Network," presented at DEFCON IV, July 1996, not published. Back.
Detail. I am indebted to the notes of David Molnay and cypherpunk posts for what information I have on this proposal. The detail listed here could be wildly inaccurate.
Hereafter are some random queries: Is the completion bond on the component or the project? E.g., in the Hollywood film production cycle, is it on the actor who spits the dummy, or the film production that gets bucketed? If the bond is on the former, cost is likely to be difficult to manage due to intricacies (need to re-engage other actors, etc, for re-shoot, or lost time to market). If on the entire production, it is much more manageable in terms of cost, as it becomes built into the dicount factor. However, this implies that the investor can do it themselves (by diversification). Back.
Hanson. Idea Futures is a market for betting on future events. It uses virtual money to generate odds which reflect the prediction of those who betted. Back.
Maslow. The best source of inspiration here is still Maslow's Hierarchy of Needs, IMHO. Back.
Freeware. For example, Systemics publishes the Cryptix library. This library is freeware: essentially free for all-comers. In return for this open benefit, the authors are rewarded by bug reports and reputation, Systemics gains credibility, and all gain sense of belonging to the Internet community. Back.
Dramatis Personae. We will use the cryptographers' friends to play our parts. Specifically, Alice, is a proposer of tasks, and Bob and Carol can be programmers. Dave will be a manager (responsible for the production of others). Victor is a verifier of other's claims. Walter is an intermediary who watches (and protects) the interests of others. Bruce Schneier, Applied Cryptography, 2nd edition. Users are, as always, users, and represent the buying mass of the market. Back.
Exchange. Normally we will talk about a market, the markets and the market without distinction. Where a distinction is necessary, a market will trade one item, and an exchange will consist of many such markets. The market, in the global sense, refers to the sum total of all trading opportunities. Back.
Browse. It is an architectural principle of the Systemics markets, at least, that the traders must have access to the exact contract that is traded. Hence, all contracts are made available for download. Back.
Issuer. An Issuer is a manager of digital value. In this case, it is assumed that the Market will trade cash for contract items (although for some variants this might be overly complex). Regardless, the presence or otherwise of the Issuer does not effect the architecture described. Back.
Bryce. Looking at the Debian group , a loosely organized band of Linux hackers, Bryce suggests that if programmers were to coordinate in off-market channels they could avoid losses such as duplication. There are two counter-arguments to this: firstly, that if programmers can coordinate in this fashion, then they might not benefit from a structured market in the first place, and secondly, that the coordination of resources by non-market means is not as scaleable as that achieved by markets. Post to e$@thumper.vmeng.com on Wed, 19 Mar 1996. Back.
Padgett. Or, as Padgett warmly puts it, "good software takes time to write. Schlock does not." Post to dcsb@ai.mit.edu on Tue, 26 Nov 1996. Back.
Burden. For an explanation of the shifting the burden see Peter Senge, The Fifth Discipline, Currency Doubleday, 1990. Back.
Obligations. In some cases the intermediary could step in at a particular moment, rather than being a central part of the trade. For example, Walter could step into the market on default by Bob to meet their mutually promised obligations. This requires, however, more complexity in the way of out-of-band protocols such as email, or intervention by the Issuer, or open market operations, described later. Back.
Bids&Offers. In markets, we talk about bids to buy and opposing offers to sell. In this type of market, we are really talking about bids to enthuse and offers to hack, but the flow is the same. Back.
Caveat Emptor. The Internet uses caveat emptor as its natural law approach to everything. On top of that is imposed a laissez-faire approach to revenge that tends to be self-regulating: Frequently, reputations have been ruined by mistakes made, and perpetrators of crimes have been hounded by the mailgroups' kangaroo courts. Reputation is a powerful tool in the small and dynamic communities on the net. Back.
Identity. Identity can be established using public key cryptography tools such as PGP. These techniques allow the secure building up of reputations over time, as is often done in newsgroups. Back.
Nyms. Little we have discussed precludes or insists on the presence of psuedonyms (nyms), and we believe the decision to use them or not is orthogonal to the design of the market. One exception is the notion of code checks, although Lucky Green, in a post to e$ (03 March 97) suggests that there are certificate blinding protocols to preserve the essential anonymity. Back.
Derivatives. For traders, these instruments are options on futures on shares. Working backwards, the shares are portions of ownership of the project assets, just like any project such as a company. Then, before delivery but after clearance, the items act as futures on the shares, as the programmer has contracted to deliver, with a time and place. Then, before clearance, the instruments are options on the future, with the option being "in the money" automatically in the event of clearance.
At least, that's what I think they are. YMMV. The problem with this view is that as options, they are valuable, and thus they should be traded. However, to simplify, we assume that they are valueless until clearance; this is clearly challengeable. Back.
Takeovers. Indeed, it should be possible to write a contract that provides software wholey and solely under the control of the owners, thus presenting the possibility of innovative financing techniques to promote attacks on insecure software, a popular task on the net. When a toolkit is complete that enables users to attack badly protected communications, such as satellite transmissions, would the satellite provider feel compelled to buy out the owners? In an anonymous market this might be possible, although Internet programmers have generally been far too responsible to participate in damaging or immoral attacks (although all bets are off when they view the opponents as damaging or immoral). Back.
GHM. A more formal model is the incomplete contracting framework of Grossman, Hart and Moore.
Grossman, S. and O. Hart,
"The Costs and Benefits of Ownership: A Theory of Vertical and
Lateral Integration."
Journal of Political Economy,
24, 4, (1986).
Hart, O. and J. Moore,
"Property Rights and the Nature of the Firm,"
Journal of Political Economy,
98, 4 (1990), 1119-1158.
Erik Brynjolfsson ,
"
An Incomplete Contracts Theory of Information, Technology and Organization
,"
Management Science, revised June 1993.
Back.
Partners. Bakos and Brynjolfsson suggest that as transactions costs go down, encouraging markets, competition shifts to intangible quality aspects. This leads to more partnerships built on sharing the costs and benefits of investment in improvements in quality, which are otherwise difficult to tie down in a contractual arrangement. Their model suggests a natural counterbalance to the shift towards markets.
J. Yannis Bakos ,
Erik Brynjolfsson ,
"
Information Technology, Incentives and the Optimal Number of Suppliers
,"
Journal of Organizational Computing, revised June 1993.
Back.
Reader. The Economic Nature of the Firm: A reader Edited by Louis Putterman (Brown University) and Randall S. Kroszner (University of Chicago), Cambridge University Press 1996
Decentralised Processes. Coordination of Decentral Financial Processes with Electronic Markets
Decentralised Processes. Capital Allocation and Information Processing - A Comparison between Hierarchical and Electronic Market Coordination Mechanisms, angenommener Beitrag für: Third Research Symposium: Emerging Electronic Markets and Their Impact on Industrial Organisation, St. John's College, Cambridge (UK),
"So far market mechanisms were considered to be too expensive because of high transaction costs. With the availability of modern information technology (IT) those information processing and communication costs can be lowered substantially. Under certain conditions electronic market mechanisms become feasible. This is sometimes referred to to as the Electronic Market Hypothesis (Malone et al., 1987)."
Ecology. Miller, Mark & K. Eric Drexler. 1988. "Markets and Computation: Agorics Open Systems", published in The Ecology of Computation, ed. by Bernardo Huberman, North-Holland: Elsevier Science Publishers. Some other inclusions are at Agorics.