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:
At NCN, he quotes Margaret Mead:
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.
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.
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:
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.
To Schema or Not to Schema?
We wrestled with this. Finally, as Flemming says,
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:
Invoice Seller reports the actual results and amount due
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.