Copyright (c) 2005, Steve Traugott http://www.stevegt.com
This work is licensed under a Creative Commons License.
Equity instruments led to the joint-stock company and enabled the creation of heavy industry and mass manufacturing. Service-based instruments, including derivatives, will enable the growth of a new, open class of service organizations, and could restructure what is now the largest sector of the global economy. In tangible terms, using the computer industry alone as an example, Service Derivatives can provide for more realistic financing and management of IT Infrastructure as well as open-source software and hardware development projects.
The term "Service Derivatives" was coined by myself in late fall of 2002. As of January 18th 2005, Google still showed no hits at all for the term "Service Derivatives" -- this document was first published on that date. This term is not trademarked, and I do encourage its use by others; see the copyright section and license referenced above.
While in the USAF in the late 80's, after working in the data communications industry for 5 years, it struck me that, while the U.S. military is a well-run heirarchy, most companies aren't, and the contrast got me thinking about better ways to organize effort and capital versus static heirarchies. When you think about it, our modern form of corporate governance dates back to the railroads and other early industrial-age organizations, and was enabled in large part by the telegraph; in a structural sense we haven't really evolved much over the last century, even though our communications capabilities have.
In a nutshell, putting it in contemporary terms, I think we can do for organizations what open-source has done for software.
I was looking ahead for ways to structure the then-nonexistent Commercial Space Transportation industry. The Challenger accident, and the organizational disfunction which led to it, was still fresh in my mind -- it's sad to see how many of the Columbia preconditions were similar. This is no way to do rocket science...
After leaving active duty, my own work on this concept continued at a slow but steady pace over the next decade, while I talked the ears off of any friends and co-workers who would listen (sorry, all). ;-) Things got easier after the general public discovered the Internet, and laypeople started being able to see the potential of electronic communications. (I'm sorry, but the late 90's wasn't a "new economy" -- it was a "new storefront"; in most orgs the Internet was a new way of selling product via only one of the Internet's myriad protocols (HTTP) while leaving the same organizational structure intact behind the web server.)
Work picked up rapidly after 9/11; my wife Joyce and I decided that, since the bad guys were already figuring out how to use non-heirarchical organizational techniques against free markets and open societies (including our friends and relatives in lower Manhattan), then we'd better pick up the pace in response. We had our first meeting of around a dozen interested friends at our home in California in October 2001.
There appear to be (at least) three areas of human endeavor which should be able to benefit from Service Derivatives: human rights, economics, and technology.
It might seem odd to think of human rights in the context of corporate structures, but most of us spend most of our waking hours subject to the policies and procedures of the structures we work within. Our standards of lifetime happiness, security for our family's future, and satisfaction of a job well done are more often than not defined relative to those same structures. (The current health-care debacle in the U.S. is a symptom of how badly things can go wrong when these structures fail.) Coming up with better tools to enable more flexible structures appears to be worthwhile if only for the human rights benefits, let alone economics or technology; the power of heirarchy is easily abused, and few organizations have in place the checks and balances needed to prevent that abuse. (Surprisingly enough, the U.S. military's own checks and balances prevent abuse of authority better than most U.S. companies.)
From the economics angle, we find an enigma: We know from the last 60 years of world history that planned economies don't do as well as even partially open markets. And yet our companies adhere to many of those same methodologies that the western world loves to hate; closed governance, planned economy, central budgeting, closed borders, and a central employment office which manages the pay, rank, and title of each working citizen. I believe that the only reason this inefficient arrangement works is because our companies' competitors are run the same way. A possible piece of evidence that would support this belief is the tendency for large industry-leading companies to be brought down by swarms of small businesses which aren't even cooperating with each other.
The benefits of technology development and scientific progress in an open market, where there is a free exchange of information, are clear. We can again reference the results of the planned development and top-heavy decision-making in communist-bloc countries for comparison. But right now, openness and freedom of movement are only common between our organizations -- within a given company, the decisions to pursue and fund "official" projects, and the constrained mobility of the people themselves, are the very model of a centrally planned effort.
One strawman argument that's been proposed against decentralized organizations is this: "But how will anyone ever be able to aggregate capital, and plan and execute truly large projects?" My favorite counter-example is the Internet itself -- you would never have been able to get the venture capital to fund it, or the global approval to build it. The entire net is based on a simple concept -- a text-based instrument known as the Request for Comments. This series of humble documents has enabled the creation and maintenance of the largest and most expensive project in the history of mankind, with no direct financial incentive for the vast majority of the authors.
Many RFC authors, like open-source developers, hope to benefit financially from better salaries, more consulting clients, and other informal derivative results. There is no clear structure for delivering these benefits though; the problem is similar to that of raising capital prior to the development of joint-stock companies. Service Derivatives hope to reduce the friction of the public service market by providing a concise contract with results which are clear at the outset.
The greatest risk with Service Derivatives isn't that they won't help to produce truly large and complex projects, but that their use, added to the enthusiasm of volunteers in some of the areas they are likely to be applied first, can itself reinforce that volunteerism in ways that we may be ill-prepared for.
The following example is simplistic, and focused on basic mechanics. But understanding the mechanics is the hard part -- our brains are used to a certain supply chain; Service Derivatives cause us to re-examine what we think we know about the delivery of services...
Consider this scenario: Tom plans to paint a fence. Nobody is going to pay him to do so -- it's his own fence. He posts a prospectus on a service derivatives exchange, describing a financial contract which is worth $1 if the fence is fully painted, and worth $0 if the fence is bare. He then places a bid order for 100 contracts at $0.20 each.
One of Tom's neighbors, Becky, thinks the street will look better if the fence is painted, and she wants to help out (her altruism has nothing to do with the fact that an appraiser is on the way to her own home next week). She sells 40 contracts to Tom at $0.20; she's planning to lose money if it'll get Tom to paint that fence. A speculator named Huck doesn't think Tom will ever get around to painting the fence -- he sells 60 contracts to Tom, also at $0.20. Huck expects to profit if the fence doesn't gets painted. Jim thinks the fence will get painted and places a bid for 30 contracts at $0.30.
Tom now needs money to buy paint -- he sells 30 contracts to Jim at $0.30, takes the $9 and buys paint. Then Tom paints the fence. He still holds 70 contracts, now worth $1 each. Becky has lost $0.80 on each of 40 contracts, as she had planned -- she pays Tom $32. Huck pays Tom $48. Tom pays Jim $21. Tom has made $59 painting his own fence ($50 after paying for paint).
This example skips a lot of details -- exchange structure, expiration triggers, verification, transfer and settlement, among others. These details are hard and worth discussing, but this document is only intended to be a simple introduction. There are also many other contract structures which could be used here -- see the references below for some variations. The key points of each include an ability for service providers and recipients to participate, and for speculators to increase liquidity.
Here's a detailed breakdown of what just happened, by account:
|Becky sells Tom 40 @ $0.20||-40 +$8||+40 -$8|
|Huck sells Tom 60 @ $0.20||-60 +$12||+60 -$12|
|Tom sells Jim 30 @ $0.30||+30 -$9||-30 +$9|
|Contract expires @ $1||+40 -$40||+60 -$60||-30 +$30||-70 +$70|
Here's what the expiration and ending balances would have looked like if Tom had instead gone fishing and not painted the fence -- one interesting thing to note here is that Jim has some incentive to put his project manager hat on, go find Tom, drag him back home, and help him get the fence done before this happens:
|Contract expires @ $0||+40 -$0||+60 -$0||-30 +$0||-30 +$0|
|© Copyright 2013 Steve Traugott, Joyce Cao Traugott|
|In cooperation with CD International.|