[wiki-standards] pragmatic standardization

[Sunir Shah]

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
space.


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 
interchange format.

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.


3. Results-oriented

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
  to personal).
* 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 
and politics).

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 
controlling.


5. Conclusion

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.

Best,
Sunir