[wiki-standards] pragmatic standardization
sunir at sunir.org
Sun Oct 23 20:33:16 CEST 2005
0. Hello, folks.
I feel like just stating outright how I'd like to
work and why. I'm open to responses and changes
to my thinking. This is just where I am right now
after many years of thinking and working in this
1. You need developers
There's no sense writing up a standard before we have
developers ready to implement them (*). Consider, for
relevant instances, the TikiWiki WikiMarkup RFC, or
to a much lesser extent, Murray Altheim's wiki
In TikiWiki's case, they wanted the rest of the 'Net
to standardize on their syntax. Despite the enthusiasm
from the TikiWiki crowd, it's hard to attract other
developers to switch their user bases (and themselves)
to another syntax when it is not appreciably better.
So, this initiative failed to spread.
In Murray's case, his work was not followed through
simply because he's a busy Ph.D. student. It's still
valuable for those who want to keep moving forward on
that, but it requires some marketing, some coding, and
a compelling use case that is a common good to stitch
it all together; e.g. A wonderful, usable WikiClient.
(vs. poaching users)
Standards aren't standards until they are both
implemented and implementable by others outside
the original group.
Until then, they are just specifications at best,
or musings at worst.
(*) Similarly, there is no point writing up a
standardization process until you have standards
efforts willing to follow it.
2. Where standards efforts come from
When considering other standardization models, note
first about the initial impetus for standardization.
With the W3C, Tim Berners-Lee needed others to implement
browsers and keep the Web moving forward technologically.
An 'open' standards process encouraged others to invest
their resources in building out the web. HTML was the
'common resource' that forced implementers to co-operate.
For Java, obviously Java is the central resource, and
Sun centralizes control over it.
The central resource does not really have to be central.
It can be a useful client technology. For example, with
blogs, RSS aggregators are the central resource that
forces compliance to an RSS standard. People could only
have the conversation about Atom after enough bloggers
and enough aggregators and enough developers using
aggregators existed to make it compelling. Before that,
Dave Winer pulled it off as he represented all the Manilla
blogs in aggregate. (The common resource was Manilla.)
Wikis don't have a true central resource. They don't
even have many common causes. The one that is most
compelling to me is the common threat of spam, which is
in common with blogs and discussion forums alike.
However, responses don't have to be co-ordinated to
succeed, so we have to build something incredibly
effective to get the attention of others.
One outcome some may worry about is to wait until
WikiMedia and/or some server farms get fed up and pull
a Dave Winer. Be encouraged that wiki folk are generally
very friendly and co-operative. WikiMedia are very kind
people in particular. I don't think many would like to
be much like the Winer. Yet, it's still necessary to
actually *DO WORK* and show *RESULTS* in order to make
a small voice in the market very loud.
Results are compelling. They attract more wiki
developers. Wiki developers make specifications into
standards by implementing them.
Now, while I wasn't part of the SharedAntiSpam group at
WikiMania in Frankfurt, I'm keen to get the anti-spam
response up and running, at least to the point where we
can test if it will work.
So, since WikiMania, I've been quietly in the
background prodding and reminding people to keep things
moving. I feel, though, I should focus more directly on
keeping the conversation between the wiki developers going
to get some results. Otherwise, the initiative will die.
If others have their own initiatives, like interchange,
I recommend doing something similar:
* Find a group of interested wiki developers.
* Brainstorm in some central place.
* Build a *small* prototype. (Or several.)
* Experiment to see what works.
* Adapt the prototype to fix problems.
* Write and update a very informal specification so
others can join in.
* Write test cases to validate conformance to the spec.
* Use concrete and compelling results to attract more
wiki developers to join in.
* Iterate the prototype until it covers enough cases in
the wiki space (from large to small, from community
* Release the specification as a standard once you think
it is stable enough to be adopted without trouble by
everybody on the Internet.
* Release the test cases to validate compliance.
To get this going, someone will have to be the project
manager working to keep the conversation going and the
coding happening; and to co-ordinate amongst developers.
You have to bug people to get things moving.
The point here is to build from small successes that
show results that attract more people that can then
build bigger successes that show more results.
Show results continuously. Rough consensus and running code.
4. Location location location
The first rule of the Internet: Location is irrelevant.
There is no neutral ground, nor should there be. The
developers who are running the effort should be in
charge of their specification so they have the power
to change it as they wish.
I honestly think it's going to cause more problems
if people are forced to use a particular space to get
their work done. That's just creating territorial
conflicts for no reason at all.
Just when it's done, please make the spec CC-BY-SA or
Primarily Public Domain so we can mirror it. That would
be very wiki, and not require a lot of overhead costs
(and therefore membership fees and consequently voting
If we want to simplify people's lives by providing
support services, like mailing lists and a directory
or repository to direct people's attention, that's
fantastic, but no one should be forced to use our
services. Focus on being compelling rather than
I think that if we keep the bureaucratic drag to a
minimum; encourage development in an open, friendly,
Wiki Way; focus primarily on supporting these
efforts rather than controlling them; and generate
working prototypes, we can smooth the conversation
amongst wiki developers and encourage real development.
Appendix I. Laugh
Laugh. Have fun. We were all very cranky in San Diego.
That's no good. If it isn't fun, it isn't worth it.
Q. How many wiki people does it take to change a lightbulb?
A. One, but anyone can change it back.
More information about the wiki-standards