Mitch generally agreed with yesterday’s blow-by-blow dissection of Xpertweb’s measures to avoid hardening of the data arteries. But he adds four important points on the specific biases that are usually embedded in enterprise data design. These are the biases to avoid by providing for gradual system evolution.
Participation and modality biases, that define how and when users should contribute to the group’s dialog; this may take the form of forcing people to use a form or that they learn some esoteric mark-up language to participate—maybe some of your team is most comfortable using email, but cannot do so to submit information to the workgroup application (why do they have to change? Because a programmer said so? Not a good enough reason when those people earn $80,000 a year already and do just fine communicating by email);
Which is why Xpertweb v 1.0 will be able to read your email (or a dedicated email account). It’s not certain though whether the messages will be organized in a way that a script can make sense of it. Certainly they will if they’re script generated, but you never know about those pesky humans.
I’ve always felt that modality bias is the greatest challenge in networked human interaction. Modality is the mode of interface dictated by the software’s User Interface and data categories. Most of us are comfortable with email, as Mitch points out, though we forget how recently we’ve adopted that mode. When you force people into a new modality, you’d better have some damn good reasons, which is not always the case.
But the web’s theme the past few years has been about unstructured content becoming structured. Web pages like this are unstructured. Even if the content is worth something (unlikely as that may be), it’s hard to find and aggregate the nuggets to establish meaning, because HTML is a presentation tool, not a data-tagging tool. That’s what led to the formulation of XML and XHTML, which requires authors to tag their content by categories. XML adoption has been slow, except by enterprises using it to encode data between two otherwise uncooperative data bases. It’s a pain to tag your data, which is Mitch’s point.
Just as so many mastered the email modality in the early 90’s, so have we mastered online purchasing in the later 90’s. It seems to me we’ve become as comfortable with forms used to buy things on line as we have with the familiar three-paned email interface. So, if the Xpertweb forms can look a lot like other online experiences, we’ve got a shot at providing a friendly user modality.
Semantic biases, evident both in the range of options available for categorizing information, from labeling every new topic as a “problem” to be solved instead of a business opportunity (this evolving from the quality-assurance based practices of software programmers) to limited ranges of choices in pop-up menus that prevent the group from straying outside the well-defined lines that the program lays out;
Bingo! Labeling is a huge problem, since programmers can’t get the lingo and categories right without enthusiastic collaboration with the people who will use the system. Such collaboration is rare because users have no interest in pitching in on the design until the piece of dreck is switched on. I can think of only three ways to reduce the semantic bias problem:
Rely on language and processes so well-established that they’re naturally comfortable.
Provide some metadata describing the terms as they’re presented (the tooltips approach).
Provide a way to evolve form design and add or redefine datatypes easily. (without needing permission or great expertise)
Time and skill biases, based on the presumption that every user has the same amount of time each day to participate in a group project to assuming that it takes everyone the same time to perform chores in the interface (that they all have the same skill level with the technology);
Here’s evidence of the steep gradient between the early adopters and the rest of us. The early adopters see the value of the new tools and are adept at responding to new modalities, unlike you and me. Too bad they’re never around when you need some guidance. Fortunately, time spent is a matter of skill, and skill is usually a matter of time and patience. I learned in the Air Force that there are brilliant pilots and the rest of us, but time in the seat is the great skill leveler–most pilots are average pilots. Motivation is the skills leveler. If you have a strong reason to master something you will. Think of all the grandparents who’ve mastered email to stay in touch. Now they’re even exchanging pictures! Money can also be a strong motivation, and Xpertweb has some explicit rewards built into the system to inspire enthusiastic mastery of the bit of procedurality that can’t be avoided.
Historical bias, the preservation of outmoded knowledge because of the rigidity of technology. What if your company has moved from making buggy whips to airplanes and the software you use still is designed for a buggy whip company? Often, it is the failure of software to evolve with the organization that makes it utterly useless—this has happened in many media companies, where digital technology was designed for outputting paper or television signals and has locked companies that could be exploiting the Internet and on-demand multimedia networks into outmoded business models.
All of us are seeing Mitch’s historical bias example. Consider how hard it is on the RIAA. Heh.
Historical bias is assured when the data structures, datatypes, data forms and output protocols can’t be evolved to keep up with the people evolving away from the system. But if someone is motivated to fix the problem and the means are easily engaged, then the changes will be done and the curse of legacy avoided.
I sense that Mitch has concerns about the predetermined stages of an Xpertweb transaction: Discover, Identify, Negotiate, Commit, Invoice and Evaluate. The reason to have discrete stages is because the purpose is to sensibly organize work, without requiring an organization. The asynchronous imperative of a transaction record requires that the data needs of each stage be met before moving to the next stage.
The evaluation (our core value) can’t be captured until the invoice data is entered and presented
The invoice can’t be presented until completion can be recorded
The work can’t be committed to until the order details have been negotiated
The details can’t be negotiated until the buyer’s preferences are recorded
The buyer preferences can’t be entered until a service/product is identified
The item can’t be identified until the Expert is discovered
At the risk of being doctrinaire, we feel the need to provi
de at least that much of a skeleton for the transaction record. If Xpertweb can avoid being haunted by that skeleton, it’s because all data and structures reside at the level of the user. Some think the idea is unworkable, but that’s a question that will be solved simply by seeing if it works. Similarly, many experts once wondered why you’d want bit-mapped displays so you could see formatted text onscreen. They also wondered why in the world you’d want to see formatted text.
Data for the rest of us is similarly untried and, by many, still unsought. Our design indeed raises problems. Unlike a central data store, there’s no team to manage and maintain it. It’s not optimized for compactness and speed. It assumes the proper functioning of the Xpertweb scripts on each user’s computer. It assumes that there are enough people who will learn a new (to them) technology and a new way of dealing. A determined techie could find another half a dozen objections.
Living With Diversity
We never set out to create a weird data architecture just to be different. We had no choice, since all conventional methods rely on the kind of centralized data hegemony that would eventually pervert our purpose. Xpertweb’s distributed data store is kind of holographic, present on at least four web sites (2 parties to a transaction and their two mentors). The mirroring of identical data on those sites imputes validity. Validation is further promoted by a validation tool built into every installation. This tool verifies the file structure, to make sure it conforms to this model. It also provides a schema to validate the XML structures, and to validate other sites, on a schedule or on request, so your mentor’s site is continually validating your site’s structure and file conformance to your schema.
The schema provides for the datatypes that are obvious and any optional datatypes the owner may designate using the XWriter tool. These would most typically be added to describe attributes of a service or product. Another compelling reason for adding new datatypes is to transform your ID.xml file into a full-fledged Digital ID using Liberty Alliance protocols to become your own Identity Provider.
The Open Source Haven
In facing these challenges, the Xpertweb model is fortunate to not be a business. If it were a business, we’d be capitalized to hire a crew of programmers and arrange for office space and computers and furniture and all the rest. Development would be done in secret so competition wouldn’t get wind of our gazillion dollar concept. Naturally we’d have a business plan to promise a Return On Investment with a stated marketing budget and rollout and the server farm, etc. Once the code was “done” (always a more-or-less state), we’d have a limited horizon to satisfy the nervous investors, so we’d move heaven and earth to inspire massive adoption by our target demographic. As with most new software, despite the promising number of enthusiastic early adopters, the press and the public would note that it’s interesting and worth looking into some day and would go back to business as usual.
Then would start the decade of dimming hope and rising anguish as the shrinking team of stakeholders tries to wring some value out of what has become an old idea that didn’t quite work out.
Xpertweb has no burn rate and no central software or servers. It will put its genetic material out there, with the means to further propagate it. Starting with just six users and spreading slowly at first, we expect to wring it out, make a few adjustments and then, as they say, let ‘er rip.
Naiveté
Perhaps we’re naive to think that ordinary people will choose to, or even can, master these new skills. But it seems less naive than assuming that our current skills and hierarchies will spontaneously inspire higher productivity and individual work satisfaction.
Mitchresponds to the Count the things that count blogalogue that Ross Mayfield and I conducted earlier this week. On Monday, Ross had suggested, in regard to the rating of experts,
A rating is a price. We define a good and deliberate over its value through signals. Sometimes we express price not for transaction but to communicate value in its simplest form (a guy at Stanford won a Nobel Prize on this). A price is the simplest method of communicating value.
A rating is a mode of communication. What I value when. When I send a smiley to someone, its a rating.
A rating is a signal of trust. Whom I value when. Trust is credit and credit is priced.
Perhaps we need a systems approach, where we conceive a model transaction, one that serves both parties equally, and removes the data dominance factor. Of course, that’s the purpose of our little design study. We think we’ve come up with the 6 essential states in every transaction (Discover, Identify, Specify, Negotiate, Invoice, Evaluate); and we think we’ve identified the Atomic Elements of transactions (People, Products & Tasks).
If we’re right, and our standard transaction model simplifies selling and buying, then it might lead to more and better buying and selling. In any event, we’ll be counting some things that haven’t counted before. Like Quality ratings.
Flemming, still jet-lagged, gave the post a thumbs-up but Mitch urges us to not repeat the errors that have marked so many endeavors: Establishing technical standards that enshrine data, or a way of thinking about it, that becomes dogma. The dogma then dooms the participants to follow the old flawed patterns, perhaps not even realizing what assumptions are baked into their enterprise:
My take is that this is all great thinking, but we need to keep clearly in front of us the idea that human relationships is what we are talking about. The technology is a nice-to-have accelerator, but it can be profoundly alienating. Technology, because it is usually deployed en masse is a blunt force instrument that treats everyone the same way, especially within the confines of a small group where starkly different beliefs and styles of learning and communicating come into sharp conflict.
There is no doubt in my mind or any manager’s that an organization should pick tools that enforce its priorities to some degree. It would be impossible to cook a meal in a kitchen where knives were forbidden and every company, because they do largely deal with the manipulation of information, needs to define the range of data it will try to process. So, some dogma is a very good thing. The very act of defining an organization requires managers invent a bit of dogma, a dollop of determinism in an otherwise chaotic environment—after all, we can’t be in the business of doing everything. A deterministic system is purposeful and supports goal-setting.
The mistake would be to get locked into those goals by a technology infrastructure that constantly enforced initial-state biases. If, after achieving your first-year goals for establishing internal competencies and product development, you had to go back and spend a year and a large amount of capital to retool your company for delivering its product or services to the market, instead of having these capabilities be an implicit result of your first year’s efforts, your company is not likely to succeed. Think about how many times your company or a company you know has had to retool information technology to support new processes and the consequences of setting and forgetting dogmas becomes painfully apparent.
I agree with Mitch, and not just because he is a valued advisor and the expert entrepreneur in the booth of this quiz show. The failure of organizations to understand their data strategies is one of the reasons they’re so frustrating to work with and for. But this design study could easily repeat those kind of mistakes, even if our aims seem more open. So I want to address Mitch’s points in serial fashion to give us a chance to question assumptions behind the current Xpertweb design.
Let’s start at the top: “we need to keep clearly in front of us the idea that human relationships is what we are talking about” To which I respond with a firm, “Well, yes and no!” (Never equivocate on important points…;-).
Yes. I’m inclined to wax rhapsodic when glimpsing a future with a kinder, gentler economy based on human connections across the globe or around the corner. And I do believe that our current structures devalue the creativity most of us pour into our work and the deep and vital relationships we form with partners we transact with. And I think Xpertweb improves the chances of forming and maintaining those relationships, compared to proprietary hierarchies, which would be the most social benefit of our socialware.
No. However, there’s also a pragmatic edge to getting things done, which is why an Object-Oriented, “Open Resource” economy is so attractive, where the obvious expert is easy to find, easy to engage and easy to pay. Just as programmers can plug other people’s code objects into a program, so do we need to plug other people’s expertise into our activities, on-the-fly, and get on with our day. When I use a piece of open source code, admirable for its elegance and price, to do something otherwise impossible or lengthy, it’s just a tool that I use without forming a relationship. As my long-time friend, client and author, Jerry Vass teaches his Fortune 500 clients, “Your company may be impressive, but the buyer doesn’t care if the seller lives or dies, as long as he doesn’t die on the premises.”
Mitch has challenged us to strike the right balance between over-determining behavior or making the design so loose that there’s no value. There’s no way to respond without specifics, so please indulge a detailed overview of the Xpertweb approach, including our allowance for flexibility. Maybe you’ll have some ideas about whether it’s too rigid or loose, and how it could be improved.
The Xpertweb Bottom Line
All we’re really after is to elicit a rating from each transaction and to make it indelible in the public record. The rating needs to be both quantitative (1-99%) and qualitative (a written comment). We all know that we rarely fill out rating surveys after the fact, so the rating must be required at the moment of payment in th
e invoice, perhaps with an incentive to the buyer.
Therefore, at a minimum, we need to provide an invoice form. Ideally, an invoice should summarize the transaction so the buyer can make a rating based on more than memory. That means it’s useful to capture the history of the transaction. We decided to provide some basic transaction forms and a dead-simple data capture system for the transaction details, including the one we care most about, the final rating.
Last time, I revealed my horror of proprietary data–that both parties to a transaction need all the data so they are full peers. Flemming agreed and so does Mitch, if we strike the right balance between rigid and useless. That’s what drove the decision to give everyone the same data tools and to require a web server for both parties to each transaction. It was the only choice left standing after all the other choices wouldn’t work. Data that’s not on both web servers is suspect, since one of the parties may have changed or deleted something. Validation is by duplication.
When you’re designing a campus, put the sidewalks where the grass wears out.
The 5,000 Year-old Flow Chart
How do we know what forms to provide to lead up to the one we actually care about, the evaluation? On March 18, I suggested that we have an ancient model to follow for the Xpertweb transaction flow:
It’s obvious the transaction record must reflect the real-world dynamics of the special kind of conversation called a transaction, which, for the same 5,000 years, has had six distinct stages:
Discover Find a seller to deal with
Identify Select the specific product
Negotiate Resolve delivery location, timing, quality, etc. (often a back-and-forth between buyer & seller)
Commit Buyer and Seller commit to the negotiated terms (Goods or services are delivered between steps 4 & 5)
Invoice Seller reports the actual results and amount due
Evaluate Buyer rates seller and vice versa (this is the vital metadata of relationship, now made explicit rather than as a general impression. Or worse, hidden from the market by the seller )
Notice that Xpertweb doesn’t attempt to describe the actual work nor to manage the payment details. Work details are too specialized for our generalized data capture, though it’s described by the “Productid.xml” metadata and can also be discussed in task remarks. As for payment, that’s left to whichever means the parties prefer, though some third party payer is required, one which sends a confirming email to buyer and seller upon taking irrevocable responsibility for payment. Third party payer commitment closes out the transaction.
Why Do We Need a Flow Chart?
Transactions are asynchronous.
The buyer, having discovered a vendor and a product,
identifies the buyer’s interest and basics like delivery details.
The seller must, at a minimum, agree to the delivery location and timing, but may need more details–color, size, scope, etc. Those negotiations are related to the parties’ needs and the product type. Whether the negotiation is complex or just the seller’s simple “works for me, I’ll do it”, we need to provide a form for the dialogue.
Naturally negotiations end upon the parties’ definitive commitment.
After the work is performed, the seller submits an invoice–the form Xpertweb really cares about,
a)…where the evaluation by the buyer is recorded, in numbers and words. followed by payment using mutually agreeable means. b) After payment, the seller evaluates the buyer’s role in the task.
All those things happen in the real world, but the evaluation is maintained privately by each party, and then not explicitly. Xpertweb intends to make evaluations explicit and public.
Okay, we think we’re clever enough to design those forms, but we need a data store that’s flexible and searchable. There are few examples of open, pure-XML data stores. There’s a lot of data on web pages, but it’s hard for computers to organize and aggregate web info for us, so they’re not really data. A lot of “real data” are served by web pages, but the data are buried in proprietary data bases that Google and the rest of us can’t get at without permission. A Peer Economy must be a permission-free zone.
So, we found ourselves going the eccentric route again. Xpertweb users will store their data on their own web servers, in pure XML format. It won’t require UDDI or SOAP or XML-RPC or anything else exotic to get at user records. You can do it with a browser or a search engine. RSS will provide pointers to help people find what they want.
Why is Data So Difficult?
There are two ways that data systems lock their users into the kind of rigid structures Mitch is warning us against. The data structure itself may not be malleable or the data language may make it hard to design and integrate new forms to gather inputs (old or new) for the database and display the gathered data.
Most companies maintain a little bit of info about a lot of people. Xpertweb users need a lot of data about relatively few people. So instead of using a huge array to store the data, An Xpertweb site will keep three kinds of small datasets:
A person type data set for the owner of the site. (“youruniqueid.xml“) (this as complete a Digital ID as the owner wants to make it).
A product type data set for each product. (“Widget1a.xml“)
A transaction type data set for each transaction. (“sellersuniqueID.buyersuniqueID.numberofunixsecondsatstart.xml“)
Within each of those datatypes, the trick is to have just enough structure that the data needs are served, but to avoid freezing that structure. Let’s think about data strategy. Every data design specifies data types (first name, last name, city, zip, etc.) and data forms (rolodex card, product sheet, etc.). The problem with the data tools we’re used to is that, as Mitch suggests, they’re too rigid:
arbitrary structures–not enough design input from on-the-street business units.
Specialized languages and tools–hard to find experts to maintain or modify
Obscure code–dependent on continuing involvement of a few staff or consultants
Those factors combine to make it difficult to do what every data structure should: facilitate new types of data and new forms for novel inputs and display of the old and new data types.
This design study tries to avoid those traps. The design is as public as possible
and welcomes pushback. We’re describing only the data structure and the three data types. Data collection and display will be by plain old HTML forms using whatever CGI language that works. There are a few required datatypes that are obvious, but any optional datatype is allowed. For starters, we’re providing free PHP code which Nobody will own, Everybody can use and Anybody can improve, like the Internet itself.
Because the data forms are HTML, there are thousands of people able to modify them or add new ones. HTML skills are possibly the most common computer specialty, so form design and modification can be learned or hired out reasonably, probably as an Xpertweb-rated specialty.
Aha! you say. There may be tens of thousands of HTML-aware people with Front Page or other editors, but only a small fraction of them know how to design the code to equip HTML to save or display data.
That’s the sad truth, esteemed Effendi. Where’s the data design tool for the rest of us that will let someone’s niece or nephew build or modify data forms? I saw an article today praising a barebones 300 page book on web data that he used every day, rather than the several thousand other pages on his shelf.
We call it XWriter and it will be part of the code we’ll provide to every user. XWriter will let any HTML author add the required data calls (inputs or display), working with any of the six types of HTML input widgets (text box, text area, value list, value popup menu, check box and radio buttons). XWriter 0.8 was built by Hurai Rody and Flemming will write Version 1.0 using techniques he’s used on other projects.
So What’s the Point?
If we’re doing this right, these are the most likely reasons:
Data structures are restrictive when the users don’t help design it.
A lot of people are chiming in on this one, and every one of those people is a buyer and a seller of stuff.
Data structures are rigid when the data formats are obscure and rigid.
Structures are standardized and data sets are small, simple and publicly visible
Datatypes are hard-wired by designers with no sense of the business logic
Required data types are only the obvious ones (name, XWURL, XWID, etc.) Optional datatypes may be added at any time by listing it in XWriter.
Data code is difficult, often obscure, with few skilled enough to create or maintain forms.
Xpertweb is based on HTML, the most common presentation format, with XWriter available to add the PHP data calls.
This has been a lot of detail, but it’s the only way to find out if we’re headed down the slippery slope Mitch warns us against. Isn’t the reason there are so many poor data solutions that the owners aren’t willing to dig around in the details? I’ve consulted on data projects and the users are so rarely involved, it’s no wonder they aren’t ideal. Many bloggers and bloggees have experienced detail aversion first hand, and it’s not a pretty sight.
Fifteen years ago when I funded and later tried to run the Dynamac Computer project, we would send an extra stick-on keyboard key with each computer. It was red with white letters: DWIM. Do What I Mean. It’s what every database customer wants and it’s what most data designers are forced to guess at. We hope that we’re looking at enough details to avoid the DWIM trap, and we hope you will too.
Ross Mayfield noted my Social Software post and added the important insight that what we’re doing, when web services start counting things previously uncountable, is like the arrival of coins in the days of barter:
“Harkening back to the days of yore, in the medieval bazaar, some crazy guy was probably going around trying to get everyone to agree on the concept of coinage. Initially people resisted. A cow is a cow and a sheep is a sheep and never the twain shall meet. If I think gold is worth one thing and you think its something else and lord knows what it will be tomorrow, how can one commodify? But, lo and behold, you can carry a coin in your pocket and a cow only with great difficulty.
People are in constant pursuit of the commoditzation of everything. Not just goods, mind you. We abstract concepts in commonly digestible forms. We archetype and then debate over value. Things must be simplified to be social or we end up talking about different things.
A rating is a price. We define a good and deliberate over its value through signals. Sometimes we express price not for transaction but to communicate value in its simplest form (a guy at Stanford won a Nobel Prize on this). A price is the simplest method of communicating value.
A rating is a mode of communication. What I value when. When I send a smiley to someone, its a rating.
A rating is a signal of trust. Whom I value when. Trust is credit and credit is priced.
If there is a theme that indicates we need new counting tools its when things become too complex and when we need to simplify through the language of a rating.”
Bingo! When things get too complicated, we need new counting tools to simplify through the language of a rating. This design study intends to implement a peer economy because clearly, the big-E Economy has grown too complicated. It’s complicated because complexity suits the purposes of people better able to make the rules and hire analysts and lawyers and accounting firms to follow, and bend, the rules. That’s why the stock market systematically moves funds from the less informed to the better informed.
Data is the Basis of Economic Complexity
As one of my favorite economists, Tom Robbins said,
“During periods of so-called economic depression, societies suffer for want of all manner of essential goods, yet investigation almost invariably discloses that there are plenty of goods available. Plenty of coal in the ground, corn in the fields, wool on the sheep. What is missing is not materials but an abstract unit of measurement called ‘money.’ It is akin to a starving woman with a sweet tooth lamenting that she can’t bake a cake because she doesn’t have any ounces. She has butter, flour, eggs, milk, and sugar, she just doesn’t have any ounces, any pinches, any pints.” *
That’s complexity at work. But just recognizing complexity isn’t enough for our design study. We need to get our hands around the choke point that’s preventing the right things from being counted. I suggest that the check point is who controls the data and thus the character of the data kept. We assume that data is always kept by the seller, but is that so?
Consider this:
Whenever a seller and a buyer intersect, the data is maintained by the seller, as we expect.
Whenever an employer and an employee intersect, the data is maintained by the employer. (Who is the buyer of the services.)
In the first case, the data keeper is the seller, not the customer. In the second, though, the keeper of the data is the customer, purchasing the employee’s work. So it’s not about the roles of the players, It’s about size and who is the designer of the transaction. Data is the asset of the designer of the business agreement, and a liability to the other party to the agreement, who’s subservient to the keeper’s records.
I emphasize designer of the transaction because transactions are designed ad hoc, one-at-a-time, like component parts in machines before Eli Whitney invented standardized parts. Perhaps our economy has become too complicated to let transactions be designed for the sole benefit of whoever thinks it up first and has superior data resources.
Proprietary Data is the Basis of Tyranny
Perhaps we need a systems approach, where we conceive a model transaction, one that serves both parties equally, and removes the data dominance factor. Of course, that’s the purpose of our little design study. We think we’ve come up with the 6 essential states in every transaction (Discover, Identify, Specify, Negotiate, Invoice, Evaluate); and we think we’ve identified the Atomic Elements of transactions (People, Products & Tasks).
If we’re right, and our standard transaction model simplifies selling and buying, then it might lead to more and better buying and selling. In any event, we’ll be counting some things that haven’t counted before. Like Quality ratings.
I’m reminded again that everyone discovers DNA at the same time. The social software meme seems to be everywhere. By software, I think everyone means web applications. Yesterday, citing an earlier Ross Mayfield post, I suggested:
“If the Net’s open protocols weren’t in place and agreed upon, we could never improve it with the more highly abstracted, software-only, permission-free improvements, social software really, that we can now imagine together. Our primary hope depends on our shared imagination, freed from the limited horizons of those who would manage us into irrelevance. As the ad says, we’ve already got the shoes. Now Just Do It.”
“The physical and logical infrastructure of the web has reached a maturity while usage has surpassed a tipping point where it is ingrained in most people’s lives. As people have become participants on the web, they are building a new social infrastructure, connection by connection.”
“The above table provides a framework for understanding how Social Networking Models differ by how personal connections are made. When a community is served by Social Software, its design places limits on how relationships are formed, especially in how strangers make initial connections.”
(And conversely, design might focus participants’ energies to surpass current norms. FWIW, Xpertweb is an explicit network. Every data item is entered by the participants.)
This is an important entry by Ross, who posts important things several times a day. Here are some other excerpts:
“Social Software design fosters specific social norms by regulating possible behavior. Regulation is a good thing. A stem cell can grow into any cell in the human body not by hard coded instructions of what to become, but regulators telling it what not to become. Simple rules in complex adaptive systems, like social networks, yield complex results. And as Clay Shirky said, Social Software encodes political bargains that are required because of natural social tension.”
“…Trust ascends through these different models. You are more likely to trust someone introduced through a referral than someone you know through conversation than someone you meet in person for the first time than someone who declares their background and interests. However, speed descends through these models. You can quickly navigate and introduce yourself through an Explicit Network, especially compared to working your way through a Private Network.”
Aha, the trust thing again, as Stuart Henshall urges us to focus upon.
I’m a Johnny-come-lately to the social software conversation, and no match for Ross Mayfield. But I find we’ve been working on social software for years. I can’t imagine software more social than Xpertweb which, though its purpose is unabashedly commercial, intends to socialize its users by the character of user ratings it tracks and publishes. You might say that Xpertweb is a set of values expressed through users’ valuations. As Einstein is quoted, “Everything that can be counted does not necessarily count; everything that counts cannot necessarily be counted.”
Social software then, at a minimum, should at least make sure that things that matter are easier to count than they are without the software. Any other attributes may make the software elegant or compelling or easy to use, but the social part seems to be the trick of newly exposing communal activities or opinions that were not previously visible.
So that sets the bar for social software. We recognize it because it lets us start to count things we care about, but the designer has to figure out what those things are. Presumably they’re not obvious yet, or we’d already be counting them. What characteristic, theme perhaps, might indicate something needs new counting tools?
Homeless to Harvard
. . . is the name of a new Lifetime movie about the rise of Liz Murray, whose story was profiled on 20/20 last fall,
“By age 15, Murray was homeless, her mother had died of AIDS and her father was on the streets. Murray determined after her mother’s death that her life would be different. She refused to end up like her mom. The best way to avoid that fate was to go back to school.”
So Elizabeth finished High School in two years, got a job and scholarship through The New York Times and got accepted at Harvard.
We will all be inspired by this movie, as we must be by Liz Murray’s story. But oddly enough, it resonates with a quote from a retired Air Force General talking about the current war plan.
Ordinary Need Not Apply
General Merrill A. “Tony” McPeak, retired former chief of staff of the U.S. Air Force, interviewed last Wednesday by OregonLive.com, said:
“I never made a plan that relied on the courage of my own troops. You hope that — and they generally will — fight bravely. Your plan ought to be predicated on more realistic assumptions.”
McPeak’s point could be applied to societies. Should it be necessary to be so above average to achieve the dreams that we tell ourselves are our birthright? Our society’s accepted wisdom is that anyone can achieve their dream, yet so few even glimpse that dream that the conventional wisdom sounds like marketing. Maybe it’s a lottery ad.
The dominant fiction of our time is that we in the U.S. of A. don’t need no stinkin’ social safety nets or universal health insurance or the other attributes of the advanced European societies. We don’t need them because we’re in the land of unfettered opportunity. Look at the Liz Murray example. Or the late Senator Moynihan, or so many others who had what it takes to rise out of poverty. The problem is that not many people like that achieve their dream. Hell, most people can’t achieve their parents’ dream. The stories may support our national fiction but the facts don’t. A shrinking percentage of the population has the opportunity to live as well as their parents did and work as little as their parents did and have acceptable health care, including people who go to Harvard on scholarship. If software is to be social, those attributes are reasonable design goals: to return to a pattern in which each generation’s prospects are statistically better than their parents’ prospects. Think of it as compassionate conservatism–advocating a return to past expectations.
Those are the goals of Xpertweb. Will it work? Your guess is as good as mine. But from the nettle of depressing observations, we might pluck some positive notions that are still so hard to prove, we can’t yet count on them:
Most productivity comes from people who do not feel secure.
Most of the money is in the hands of people who do not feel secure.
Many people who do not feel secure don’t feel they have the opportunities they need.
Many people who do not feel secure spend a lot of time not doing much.
People may not need explicit organizations if equipped with software that organizes their energies as well.
Perhaps social software could help people who do not feel secure to bootstrap, together, a better tomorrow.
If it is possible, that’s the kind of software we’re designing here.
11:35:07 PM comment [commentCounter (115)]
After a thousand Brooklyn Bridges, hundreds of thousands wow goldof pet rocks and millions of Creed albums later, ol’ P.T. may have been on to something. But Tuesday night, wow goldthe fans — the consumers — got it right and got their money’s worth.
I had a couple of good meetings last week with smart guys who want to make the world more sensible. It’s pretty amazing how universal that urge is and how many smart people there are, especially among the bottom 98% of the people in the big-E Economy who do the heavy lifting.
Erick the Well-Read
On Thursday, spring smiled on NYC and I met with Erick Herring at a sunny table at the Redeye Grill, named in honor of the number of its patrons who fly the redeye between the coasts. Erick Herring is the proprietor of Lasipalatsi, Finnish for “Glass Palace”. He spent his formative years in Denmark and Norway and speaks fluent Danish:
“During that time, he built the higher education segment for NeXT Computer’s dealers in both countries, ran a private consulting practice, was the chief architect for the first Internet-enabled library system deployed in Europe, built a secure, nationwide IP network for the Aalborg University Library in Denmark, taught courses and lectured on the Internet, network security, software development, and operating systems, and served as a Senior Management Consultant and lecturer at the Danish Technology Institute. Erick attended the University of Texas at Arlington and Aalborg University Center in Denmark, is published in English and Danish, and founded the Danish Java Developers Group (DJUK) in 1996.”*
. . . meaning he actually understands the terms I fling around so cavalierly. Erick had quoted extensively from five of my little essays, so I wondered if we might get together. Sure enough he was headed to New York on a consulting gig. (Coincidentally, I had stayed at a hotel 5 blocks from his Santa Monica office about a week earlier—life is a karmic strip). Erick is the Chief Security Officer for Digital Evolution, inventors of the DE Management Server. As I understand it, it’s like a firewall with a bigger brain that assists people in an enterprise to safely engage open standards services without being exposed to security risks on ports that the firewall doesn’t monitor.
Erick knows there’s a better way to run our society, and is willing to help out with the Xpertweb design study. Aside from being off-scale smart, he lives close to our code architect and deep thinker Flemming Funch, who’s Danish! I’m probably spoiling the surprise, but I can’t wait for Flemming to pick up the phone to hear a Danish greeting about tech rather than Havarti. That’s the good news. The bad news is that Mitch and I may have to decipher tech notes that look like this.
Erick generally agreed with my take on the Liberty Alliance DigID initiative, as much due to its grand ambitions as its tech, which he feels serves us better than MS PassPort. His greatest contribution to Xpertweb may be to ensure that our DIY DigID is actually useful. Under the Xpertweb model, the risk is to the vendor, who delivers value before the buyer pays, as discussed by Mitch in his Caveat Venditor post. Since every Xpertweb buyer maintains a DigID file on her Xpertweb site, the seller’s site can require the buyer to pass an authentication test at her own site prior to committing to the task or sale. Then the seller knows that the work is being requested by the person who owns the reputation on the buyer’s site. Did that make sense? Well Erick says it can be the basis of a Good Thing, and that’s what’s important.
Isn’t that cool? Xpertweb code flowering under the care of a couple of guys with Scandinavian sensibilities who believe thoughtful people can live together in peace and prosperity.
Spiral Unbound
Stuart Henshall’s Unbound Spiral and this blog have cross-linked a few times, so we met by phone on Friday. Stuart’s firm consults to organizations to get them to act smarter by realizing they need to see their work as “serious play.” The operative word is serious, not solemn, to correct how too many groups approach progress. He must be good at it, if you trust the recommendations of people like Jay Ogilvy and Gary Anderson, Chmn./CEO of Dow Corning. Actually, Stuart’s insights are about how to employ the fact that we trust those men’s ratings more than others.
He’s been doing some deep thinking about the core value, trust, as opposed to the general description, reputation, especially in his “Identity Trust Circles” post on March 24. As we talked I understood Identity Trust Circles for the first time, and a very cool way to apply Stuart’s principles to Xpertweb.
Since Xpertweb users expose their transaction data as willingly as we blog our thoughts, It’s straightforward to find all the plumbers who work in your zip code, or all the programmers in Bangalore who hack PHP-XML. It’s simply a matter of applying Google APIs to find instances something like,
<xwspecialty>residential plumber</xwspecialty> and <workzip>98040</workzip> <xwspecialty>web programmer</xwspecialty> and <skillset>PHP</skillset> and <skillset>XML</skillset>
There will also be RSS feeds aggregated up through the mentor chain to find skills. Once you find the skill sets you need, they can be filtered by average grade overall, last 6 months, by product, etc. We had already envisioned all that, calling it reputation.
But Stuart suggested that finer level, trust, by using an even more Googlish approach. We each develop confidence in others through their blogs and acquaintance and probably by how they handle their transactions. So Stuart suggested that we need to be able to filter ratings by who made them. How do the people in our Identity Trust Circle rate potential vendors? How do other skilled judges rate providers? For instance, what do people who write O’Reilly books think of programmers? Stuart has provided an important insight.
Such filters are easy for any reasonably skilled mentor to set up in a couple of hours. It also occurred to me that we might also weight opinions by location. For instance you might want to know–in a hurry–how people in your small census tract rate the local plumbers.
In his Identity Trust Circles post, Stuart notes something that Doc has also been alluding to. There are a lot of people working the reputation meme and providing the web services to back up their op
inions. Technorati and Ryze and BlogShares come most easily to mind, but there are others, like our gestating favorite.
This flowering wouldn’t be possible if the Net hadn’t progressed beyond its basic protocols to the point we’ve reached: a permission-free zone where anybody with an idea can launch a web service without a preliminary buy-in by existing vested interests. This freedom to innovate is the third leg of the Net’s NEA stool: Nobody owns it, Everyone can use it, Anybody can improve it. If the Net’s open protocols weren’t in place and agreed upon, we could never improve it with the more highly abstracted, software-only, permission-free improvements, social software really, that we can now imagine together.
Our primary hope depends on our shared imagination, freed from the limited horizons of those who would manage us into irrelevance. As the ad says, we’ve already got the shoes. Now Just Do It.
Money velocity is a big deal, but only economists talk about it. I’m no economist, but I know what I like. Money velocity measures how many times the average dollar changes hands in a year. The GDP measures all the transactions we do in a year. When we get a dollar, we spend that dollar, which gets measured as a $2 addition to the GDP. If consumers and businesses feel confident, they spend money faster and the GDP goes up and we proclaim ourselves successful, If we hang on to our dollars a little longer, we’re less successful. I don’t know what the current figures are, but I recall money velocity being about 12-14 times a year when I took my single Econ course. (Obviously, you should look elsewhere for your economic insights.) The calculation is made by dividing the money supply (no simple calculation, that) into the GDP.
If money’s zinging around the economy at the rate of 1 move per month (12 per year) and it slows by just a day, the GDP drops by 3%, which is a big deal. It gives us an idea why the consumer confidence rating is so important. It’s safe to assume that money velocity was higher in 1999 than it is now, and that difference may account for the relative weakness in the economy.
The Easy Refunds “Bounce”
A few decades ago, no one but the big catalogue companies did any mail order business. Then it began to catch on and lots of businesses started mail order operations. In those days you had to have a reason to return an item to a store. I remember clerking at Macy’s in high school when you actively resisted returns, unless the goods were obviously defective. The new mail order companies were equally reluctant to accept returns and people started complaining to the Federal Trade Commission. Legislation was passed requiring mail orders to be returnable for thirty days after shipping, at the customer’s whim, no reason required. Naturally the companies bitched and moaned that it would ruin them. You know, like Jack Valenti excoriating video tapes and file exchanging.
What actually happened was unexpected. The mail order business exploded! Released from the fear of getting stuck with the wrong goods, customers came out of the woodwork. This was one of many lessons about large effects from small changes. Although consumption is a double-edged sword (wasting resources and trapping human consciousness on the material plane), if you’re using your economics filter, you like more activity, since it’s the only way we know to raise living standards.
How’d that work again? Oh yeah. If we increase customer’s confidence in purchases, they start to spend just a bit faster, and those dollars end up back in their pockets sooner, go out sooner, yada yada. A righteous cycle.
Caveat Venditor
As Mitch said the other day, Xpertweb inverts the traditional balance of caution in a transaction. Instead of a wary buyer, we let the vendor beware. This shift is analogous to shifting the mail order risk from the buyer to the seller. The Xpertweb mantra is that every vendor and every customer has a grading history and the seller allows the buyer’s grade to affect the price. You can never predict effects, but that is likely to cause people to open their wallets just a little faster and start that righteous money velocity cycle.
Velocity = Generosity
Imagine an economy that’s cooking along with an exuberant P2P model that’s no worse than Xpertweb. Now you’ve got folks spending more freely on stuff, and sellers find it easier to employ more and better people, because they’re rated also. The stage is set for a kind of looseness in the economy that characterized the late 90’s, when people and governments felt they could afford to do more of the right thing. Under this romantic economic model, you start to see a similarity to the gift economy, where people produce freely and put their stuff out there and just assume plenty of gifts will show up real soon.
So maybe the name of the magazine should be Fast Money rather than Fast Company.
Doc has an enlightening article in Linux Journal about the annoyance of marketing as we know it and how hard it is to be a well-known customer rather than a cynically-pitched faceless consumer. The stimulus was an automated telemarketing call from Disney:
I hung up.
Right now, it’s all up to Disney. Our relationship is entirely producer/consumer, which means we don’t have a relationship at all. Disney sets all the terms and conditions. I can buy their goods, join their clubs and what not; but I can’t initiate any kind of relationship that proceeds on my terms, even if that relationship might be good for them. The same goes for airlines, credit card companies, banks and various other entities whose relationships with me are manifest in the plastic cards that thicken my wallet. In fact, these asymmetrical producer/consumer relationships are so deeply embedded in our economy and culture that we hardly can imagine any kind of truly symmetrical power relationship with a large company–much less one in which we, as customers, are truly in charge.
(Doc’s good at this presentation. When he does it in person, he fans his credit and club cards across the table like a Vegas dealer.)
So let’s imagine one . . . What this requires is something we don’t have right now: a new identity infrastructure–one provided by open APIs, protocols and other standards that serve no agenda other than to enable useful dealings between buyers and sellers of products and services. Like the Web and e-mail infrastructure that are already part of the Net, this new infrastructure would be a full-fledged service on the Net. And it won’t become that unless it’s something nobody owns, everybody can use and anybody can improve. Again, like the Web, e-mail and the Net itself.
Since this infrastructure won’t be built around any corporation’s agenda (though it will prove quite handy to corporations wishing to do business with free-range customers in a real marketplace), it necessarily will be centered around customers. After all, we’re the ones with the money, right?. . .
. . . Let’s say I have engaged a new category of business–a relationship registrar called MyID–to certify, authenticate and otherwise substantiate the preferences, permissions and other variables that might be involved in mydentity-based relationships with participating companies and other organizations (including federal, state and local public ones). When I’m not using this mydentity, I still default to anonymity or to the relationships provided by current systems. . .
. . . When I spoke at Digital ID World last Fall, I said I didn’t believe any of this would begin to happen in a meaningful way until we had an invention that mothered some necessity–a dirt-simple killer application or killer protocol that would spread like wildfire and carry its own default infrastructure to ubiquity. I’m not sure Liberty supports that, but I don’t know. It kind of depends, I guess.
Right now there are other moves afoot, too premature to talk about, all intended to build out a mydentity-based infrastructure. I may hear more about these over the next four days, when I attend PC Forum, which combines big company CEOs and presentations with disruptive subjects. . .
. . . One concern I have is the need for simplicity, for the Principle of Good Enough that accounts not only for the success of the Net, the Web, e-mail and their founding protocols but for infrastructural building materials like Linux as well. To me, Liberty looks too complicated for that.
The Emerging Mitch-based SMI Protocol
Mitch climbs on Doc’s giant shoulders and exposes an idea he’s been baking for a while, the Strip Mall Infomediary (SMI), to implement Doc’s proposed Relationship Registrar business category. Since Xpertweb has a role to play in the market space, his idea must be good. And it plays a utilitarian background role, which is even better.
Mitch has seen what all of us will eventually get: carbon, not silicon, is the key element for the future of networked business. Messrs. Gates, Jobs, McNealy et. al. are required by their shareholders to imagine a world of complex rules and pipes and code intermediating our futures, but Mitch suggests that, for our most important needs, only a plugged-in human will do:
We cannot take time to manage access to our interests all the time, just as most people rely on money managers to help with their finances, doctors to keep track of their health, and so forth. The infrastructure that Doc describes, that Andre Durand has described here and here and Eric Norlin talks about when suggesting we “hijack” the Liberty Alliance protocol is necessary, but not sufficient. We also need people who are motivated to begin collecting the information that revolves around each of us and to organize that information for exploitation on behalf of the individual.
His non-obvious point is crucial. Our needs will always transcend our machines’ abilities to serve us. When they catch up to our current needs, we’ll have moved on to richer, more subtle requirements. Mitch describes how his infomediaries would arrange Doc’s ideal Disney vacation, but it extends to less obvious excursions. How soon will an automated travel agent like Expedia design the fulfilling trip to Florence and Venice that David Weinberg wants this week, for which he seeks pointers from his readers? Obviously there’s no current satisfaction index, or David would be using it.
When will code-based travel routers match the subtlety of the carbon-based Parker Company, renting seductive Italian villas only to clients they speak with on the phone? Why even ask? Check out Parker’s gorgeous, evocative site for a hint of the rich future of human-centric services—it’ll inspire you to break out that neglected pasta maker.
Mitch’s SMIs will know how to find villas like this one, 30 minutes from Florence, as easily as the downtown Marriott, but less dear at $90/night. Either one may be stocked with the wine and flowers you prefer. This is how the infomediaries of the Very Rich work already, so it’s just another digital divide for us to cross. But we netizens are on the wrong side of this one. Is that OK with you?
Citing the proliferation of financia
l services companies like Edward Jones in retail Generica, Mitch suggests that the relationship registrar will build on whatever Digital ID infrastructure emerges, selectively shielding and exposing the client’s presence, generally deflecting the intrusive, opportunistic side of sellers, while narrowly engaging the responsive service sides of the same sellers (without that proven responsiveness, they don’t even get a shot).
The second part of the supporting infrastructure is what Flemming calls “SMTP for reputation”—Xpertweb. For the strip mall infomediary, Xpertweb is just a background utility, tracking clients’ satisfaction as thoroughly as their portfolios reflect financial satisfaction. As rhapsodic as I may get about a Peer Economy, we need to remember that the Xpertweb protocols are just a black box to aggregate and depict quality with incorruptible integrity. What you do with the protocol is your business. Literally.
Mitch then describes the icing. A ready, willing and able buyer is the most precious resource in the economy and he’s worth a lot to sellers. The quality of the infomediary’s clients is proven to the sellers he works with, so, like the rug merchant at the bazaar, they’re ready to deal. Whether it’s a discount or extras, the infomediary’s client will be way ahead of the unassisted customer:
The infomediary is incented not only to protect the client’s information, but also to develop new ways to make money for the client using that information — just as Wall Street has created a thousand derivatives to create more value it can extract.
We’ve never considered Mitch’s idea so it couldn’t work, could it? But the infrastructure is imminent and free. Digital ID will be free. Xpertweb will be free. Web space might as well be free. You can rent furniture cheap and often get strip mall space for six month’s free rent to start, which I found out when I built one…;-). There’s no Cost Of Goods Sold and no SABRE terminal to lease.
I cannot explain a strange ennui that I’ve felt the last few days which has kept me off the air. Perhaps it’s the reaction of an ex-warrior to the sight of yet another generation embracing war as the answer to an existence not quite “meaningful” enough? …driven yet again by transient office-holders whose exquisite mix of idealism and cynicism and ego celebrates the triumph of brilliant execution performed in a vacuum of wisdom.
Don’t get me wrong. I’m not categorically against this “war,” which is at once a geopolitical necessity in the historical sense but also a violation of the most important new way of thinking about power since the Magna Carta—our new collective sense that violence in any form is an affront to our humanity. It’s a failure of our country’s management to let go of its legacy systems.
Not Getting Through
My ennui may have been at work Friday. Just as I don’t discuss science with creationists, I don’t discuss the Xpertweb design with people who don’t “get” the Internet or who believe that its purpose is to enable B2C commerce. As a result, I live in an artificial state of grace of enthusiastic support. But yesterday I couldn’t articulate the protocol’s plumbing and its larger promise to a guy who totally gets the Internet and believes it’s destined to connect individuals in unprecedented, useful ways. His commitment to the assumptions behind Xpertweb may precede and exceed mine, but he seems so sated with the failure of people to embrace small procedural changes that he can’t imagine a subculture of process-driven zealots embracing the ritual of an alternate economy, filling in forms to hire a plumber. That view seems to me to ignore our willingness to use a form to buy a $6.95 paperback. Certainly he can’t imagine the protocol growing beyond the early adopters and scaling through the use of their servers. Mitch says it’s exactly the position he took before he dug beneath the surface.
It’s simply a difference in points of view, but my failure to reach him somehow felt like part of my larger reluctance to engage since Wednesday. Maybe I’m naive to conduct this design study or maybe he knows too much to accept its idiosyncratic premise. We’ll see.
Fraternité, Égalité, Trivialité
We can assume that a smooth running Peer Economy won’t pump as much adrenalin as managerial capitalism. Prosperity can be pretty boring and a smoothly running peer-based economy won’t sound jazzy compared to the corporate vocabulary of conquering markets, killing the competition and clawing up the corporate ladder by launching killer products through triumphant vendor shoot-outs and fly-offs. Much of this silliness may attract thrill-seekers to combative businesses.
I totally understand that urge. I was a thrill junkie most of my life, spending a lot of time on mountains with and without snow and wrecking one each of three kinds of conveyance—car, motorcycle and airplane (coming so close so many other times). Extenuating circumstances aside, I purposely put myself in conditions that heightened the likelihood of an inelegant person-earth interface.
We all strive to be of consequence and so we chafe at the restraints of the pecking order. Young men are particularly wired to challenge order and that urge is unlikely to disappear in the presence of P2P prosperity as dramatically different as is ours from our (anybody’s!) ancestors. The need to distinguish ourselves is at the root of ambition, whether athletic, academic, entrepreneurial or political.
So where’s the thrill in Xpertweb? If there is one, it would be in participating in a new wave economic system with data structures designed to focus company-founder levels of reward on its early and almost-early adopters. Perhaps a lot of restlessness is driven by economic dissatisfaction and the young and the restless will happily trade the adrenalin for the quiet abundance of any peer economy, whether Xpertweb or another.
Or perhaps we are once again at the dawn of a fundamental shift in the type of person who thrives in the new structure. The world was once dominated by violent warrior kings, ruling by what John Perry Barlow described as “the divine right of thugs.” The people who prevail now couldn’t wield a battleaxe to save their family jewels, but they’re better than others at organizing capital. Just as they replaced the brutes before them, a new personality type may rise to the top in a Peer Economy, though it’s hard to know what type that may be.
Might it be people a lot like you?
The Obvious Economy
My skeptical expert is convinced that people won’t extend themselves to fill out a form, even if the result might be a dramatic transformation of their lives.
One of the keystones of my Obvious Culture notion is that it will include an obvious economy. The tools of obviousness are also the means to help a community to form around a successful protocol. Each Xpertweb site will point at many others and each will publish its data in well-documented, highly discoverable ways. But that’s just the beginning of the fun. Of course we’ll deliver tools to tabulate seller ratings and customer generosity and all the Xpertweb plumbers in your zip code who are available right now. Like having your own specialized OMB, you’ll be able to list the success rates of all mentors and their protegés, by region, specialty, last name or any other way you want to view them.
But it can get better. If you’ve never visited Kartoo, go there now to see how a search engine can disclose web connections graphically as you’ve never imagined. Who knows how current or accurate it is, but Kartoo’s mix of various sized 3D URL orbs and their explicit links makes their data obvious. We’ll provide a similar tool to depict the growth of the Xpertweb community.
So, using Xpertweb forms, you’ll be able to see where you stand relative to others, how various sellers and their mentors are doing, where the money is moving around the community and in what volumes. This might be a microeconomy, but it’ll be the best documented economy in history. Xpertweb provides a strong incentive to its users to train others who then train even more others. The payment rituals encouraged by Xpertweb roll a lot of little bits of cash into the accounts of the early and almost-early adopters. If Xpertweb users conform to the forms generated by their own web servers, they’ll transform the lives of a lot of people who serve others well and teach others that
habit of quality service. And, should they do so, it will be obvious to everybody just how much and how fast high quality work and high quality money is moving through the system.
As we begin to observe, in real time, the work and money moving among Xpertweb users, sometimes in great amounts, even the skeptical will have a choice to make: Can you stand to have that much money moving past you without moving through you?
Flemming Funch, AKA Ming the Mechanic, has posted an overview of Xpertweb’s precepts and processes, emphasizing that everything’s public and everything’s decentralized and there’s no central greedpoint. Ming’s description carries more weight than others, since he’s the guy who’s putting it into practice. His approach to building this web app is to make it as simple as possible—notice that he calls himself the mechanic, not the theoretician. We both believe that code must follow custom, not enforce behaviors. Like, when you’re designing a park, put the sidewalks where the grass wears out.
I’ve admired Flemming since I discovered him last December, when I mirrored his entire Organization Archive in a blog titled “Ming’s Dynasty“. He learned a lot about reputation systems as originator and designer of the New Civilization Network, which now has thousands of participants:
“If there is a list of people’s reputation ratings as numeric values, ordered in descending numeric order, people change their behavior and get competitive about getting better numbers.”
At NCN, he quotes Margaret Mead:
“Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has.”
Who better to birth the Xpertweb code than a programmer-philosopher? And civilized—he’s a great Dane
GUI and EUI
As the posts by Flemming, Mitch and Doc suggest, our little design study is morphing back into programming mode. That means we’ll be finalizing our Graphic User Interface, of course, but also developing an Economic User Interface—the essential events that define economic activity. Fortunately, when you’re not trying to design a multi-national lock-’em-in enterprise, the economic imperatives customers care about are pretty straightforward.
Caveat Venditor
Mitch wrote Sunday about Xpertweb’s inversion of web-based economics, whereby work is done first and satisfaction-based payment later. That simple inversion opens doors for less selling, more buying, and a healthy microeconomy of satisfied peers.
The secret sauce we are adding to our microeconomy is reputation. In order to do that, we must collect every task rating without exception. To ensure 100% compliance, we need to embed the rating—a numeric grade and a written comment—in the invoice so it cannot be put off and thus not entered. If we’re to rely on ratings, they can’t be entrusted to sellers nor should they be centralized: why do all this work to build a closed system bound to collapse under its own weight?
So it’s mandatory to have open data co-hosted by the seller’s and buyer’s synchronized web sites. The data set includes the surprisingly few types of promises and outcomes common to every transaction: due date, description, price, etc.
Project Background
Over the last four years, five programmers worked on various aspects of the project, proving that we could synchronize the buyers’ and seller’s transaction records and equip users to create and modify data forms even if they couldn’t spell XML.
When Flemming and I started talking, he was very diplomatic. He said the programmers had done a good job of implementing what I’d asked for. His point was, of course, that I’d been asking for the wrong things. I appreciated his restraint.
I had always felt that our data files need to be as simple as possible, which meant well-formed XML but not validated against a strict schema or DTD. This was due to the overarching need to avoid centralization in any form, even an “official” namespace, to preclude any future possibility of a determined party gaining control of the namespace server and steering the community away from openness.
The decentralized approach also seemed to dictate a truly aberrant file structure: each datum would have its own 3-line xml file, avoiding any assumptions about how a data collection might be structured. Verbosity seemed a reasonable penalty for the simplest possible data structure. Our users won’t be data managers.
As Flemming and Mitch and I discussed architecture, we realized that we might have a data structure if it reflects the real world. In the Agora, there have been three kinds of things worth knowing for 5,000 years:
People (“youruniqueid.xml”, sometimes selling and sometimes buying), Products (“Widget1a.xml”) and Transactions (“sellersuniqueID.buyersunique.numberofunixsecondsuponsubmitbutton.xml”).
So we’ve declared those three categories to be the core datasets for the Xpertweb universe. It seems so obvious now, but that’s hindsight. Sometimes the obvious takes 5,004 years to sink in. For me, anyway.
That People datatype includes the Digital ID part of Xpertweb, which may be a pretty exciting byproduct. Xpertweb gives DigID something to do.
“Certain relationships are built-in. Both providers and customers have mentors, who both might act as helpful consultants in making this all work, but who also serve a function in letting their software verify and aggregate activity for the people they have sponsored. That introduces some checks and balances that makes the system more fault-tolerant, and that fosters synergetic relationships.”
At the beginning, Flemming’s will be the only code at work, so there’ll be no need for a schema or DTD to enforce structural rules. However, Many Xpertweb users will embrace and extend Flemming’s code, so we’ll be adding a validation tool and a schema located on each site. That solves the decentralization problem, but still provides confidence that the directory structure will conform to other users’ expectations, and so that data forms and those three kinds of data sets are structured correctly.
Jon Udell suggested that we not build the schema first, but wait until we’ve banged on Flemming’s code for a while. Who are we to argue with Jon Udell?
Each Xpertweb site’s validation tool will also be able to validate another site. Specifically, a mentor’s validation tool will monitor her protegé’s sites’ integrity, and any site will accept validation requests from another site.
Unearthing a 5,000 Year Old Flow Chart
It’s obvious the transaction record must reflect the real-world dynamics of the special kind of conversation called a transaction, which, for the same 5,000 years, has had six distinct stages:
Discover Find a seller to deal with
Identify Select the specific product
Negotiate Resolve delivery location, timing, quality, etc. (often a back-and-forth between buyer & seller)
Commit Buyer and Seller commit to the negotiated terms (Goods or services are delivered between steps 4 & 5)
Invoice Seller reports the actual results and amount due
Evaluate Buyer rates seller and vice versa (this is the vital metadata of relationship, now made explicit rather than as a general impression. Or worse, hidden from the market by the seller)
Notice that Xpertweb doesn’t attempt to describe the actual work nor to manage the payment details. Work details are too specialized for our generalized data capture, though it’s described by the Productid.xml metadata and can also be discussed in task remarks. As for payment, that’s left to whichever means the parties prefer, though some third party payer is required, one which sends a confirming email to buyer and seller upon taking irrevocable responsibility for payment. Third party payer commitment closes out the transaction.
Reputation – The Secret Sauce of Decentralized Bookkeeping
Employees go to work for an accounting system, not the management. Managers hate that truth, but we all know what’s really going on. When you see an office full of busy people, you conclude the reason they showed up is the company is making payroll, so you agree to work today in anticipation of payment later.
Most of the compromises in our lives are based on our need to find a reliable accounting system, in the presence of which we agree to fritter away our days and imagination. What we really want is that future payment but hold the fritters, please.
After a series of Xpertweb transactions, some of us will be provably reliable and some less so. When that happens, even for a single expert and customer, we will have succeeded in reinventing communal reputation.
An expert will perform work for a reputable customer without needing to see that office full of busy people. That’s the EUI—Economic User Interface we’re designing. Will it work? No way to know for sure, but like GUI design, you take your best shot. To our design team, the EUI is just another feature of the web application and, since we’ve all done a lot of buying and selling, what we design for ourselves will probably work for others. But just to be safe, we’re including a tool to let anyone generate or modify the PHP forms so they can roll their own EUI.
If the Xpertweb EUI causes people to be more useful and to readily send money to each other, that EUI design is valid. If not, we’ll work on it. Eventually it will take.
I’m on my way back to NY this Sunday night from LA, having met with Doc on Saturday and Flemming Sunday. I had spent barely any face time with Doc and had never met Flemming in person. Flemming, “Ming the Mechanic,” has taken on the chore of rewriting our code, based on a new model he’s suggested, whereby each Xpertweb site will validate its own structure and xml data, and a mentor’s site will provide validation services to protegé sites. It’s an exciting and vital extension of the protocol.
Something’s Coming
…is how Doc described Xpertweb yesterday. Doc Searls is my blogging mentor, having exhorted me to start this blog as we held long phone conversations last summer about Xpertweb and everything else. Maybe it was just a way for him to get back to work. Saturday at lunch, Doc said, “Until now, you’ve had my divided attention,” meaning he hadn’t really got his head around it until then.
It’s interesting that I hadn’t got my head around Xpertweb until I read Doc’s and David‘s World of Ends model. That was when I saw that, like the Internet, Xpertweb is only an agreement, something like this, with just enough code to let the parties deliver on their commitments. The agreement describes what a mentor does for his people, and generally how each Xpertweb user will store and preserve and mirror shared data as a good citizen of this protocol-based economic collective.
Doc’s the infrastructure guy. He went into detail about the infrastructure pluses and minuses of the Internet vs., surprisingly, the Local Area Networks that preceded the Net. We take it for granted that our LANs will provide file, print, messaging, directory, etc. services. To be truly useful, the Net needs to provide all those services (and more, as with the web). Sure, the file and messaging services are well established, but there’s still no printing service, which is the lowest common LAN denominator. “Why should I have to fax you something? Why can’t I print it to your printer?”
The Net needs some other services, that Anyone can provide, like the critical but missing ID piece that Andre and Eric and Bryan and Doc and Mitch and others have been describing. I’ve suggested that the only way to really own your ID is to host it as your own web service on a server only you control. And that’s the model for Xpertweb ID services. Each user’s id, xpwid.xml, is one of the three core Xpertweb datasets, along with Productname.xml and taskname.xml.Your ID file provides the usual datatypes plus any optional datatypes you like, so subsets of your data can be selectively exposed on any basis you like. Or not. Your info, your server, your rules.
Doc described how the Cluetrain meme, “Markets are conversations” was received by third world people who actually have those conversations. Freed from our limited sense of markets we’ve never really lived, these free-market experts embraced and extended Cluetrain’s central point: markets are more than conversations, they’re relationships. People come together repeatedly in the market over the years and so they matter to each other, ultimately more than the goods and services they had come to the market to trade. It’s a rich model that we’d do well to emulate.
So Doc thinks we need a way to parse relationships, not just conversations. We concluded that’s really how Xpertweb can best serve, as a relationship API.
The Mentor Thing
And that brings us back to the mentoring thing. Our world revolves around mentorship, but our acknowledgement of mentors is so perfunctory as to trivialize their contribution. Doc mentored me into blogging, which forced me to tease these ideas out of their cocoon. Blogging hooked me up with Flemming and Mitch who saw where their contribution could make a difference. Others are coming forward.
In Xpertweb, advice and reputation and money moves vertically along the links among mentors and their protegés as they invest in others’ growth and are rewarded for that investment. Work and reputation and money moves laterally among buyers and sellers, point-to-point across the hollow sphere of their world of ends. It starts to feel like a wireless mesh network, with signals moving ad hoc where useful. Think of it as a cluefulness mesh.
As Doc said yesterday, it’s a simple system when you break it down, but it seems complicated for now. As I suggested in my corollary to the 10 WoE points, most of this stuff seems complicated until we can do it, like trying to explain to your great grandfather about googling an ATM location and driving over to squeeze cash out of plastic.
The logical extension of that sequence will be here when we are constantly replenishing each other’s plastic, rewarding each other for the skills we enjoy using, and bootstrapping each other into doing this.
Escapable Logic 
After a thousand Brooklyn Bridges, hundreds of thousands wow goldof pet rocks and millions of Creed albums later, ol’ P.T. may have been on to something. But Tuesday night, wow goldthe fans — the consumers — got it right and got their money’s worth.