The True MINGing of Xpertweb
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.
To Schema or Not to Schema?
We wrestled with this. Finally, as Flemming says,
"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.
11:44:01 AM 
|
|
