In mjd’s talk “Mailing List Judo” (removed from the Web due to its evil content), he gives several strategies for getting your changes into Perl. The key point is that you only need to convince one person to accept your patch: the patch pumpkin. (The patch pumpkin is the one who folds patches into the official distribution of Perl.) Everyone else can be reasonably ignored.
With many standards projects, the process is reasonably similar. The group’s output takes the form of a set of documents, each of which is controlled by one or two people (the Editors) who fold in changes and maintain the official version. There’s sometimes also a dispute-resolution process (voting, consensus, etc.) if the editor doesn’t know what to put in or the group disagrees with the editor.
The genius of Sam’s wiki was that there was no editor. Thought something was ugly? Change it. Think the text needed clarification? Clarify it. Sometimes disputes spilled out into separate pages but for the most part the process worked amazingly well.
But the process failed when it came to the big unresolved disputes. What should we name it? Should we encode HTML? There were polls but people didn’t trust them. There were discussions but they never came to consensus. And often the loudest or most persistent voice would win by pushing their opponent to exhaustion. Unfortunately the most persistent voice is often the least experienced.
As we’ve begun to write actual specs, things have gotten even worse. Backchannel deals made Joe Gregorio and Mark Nottingham into have become traditional editors of the API and feed format respectively. Sam Ruby and Mark Pilgrim took control of the spec by declaring milestones and updating their validator accordingly.
Many of the comments on the wiki were ignored and the The Wiki was turned into a unavigable swamp of a discussion forum for the drafts edited by other people. Everyone not in the clique has been relegated to an advisory role, pointing out bugs or pleading pet requests. It’s less than clear how to be a real part to of the core group.
It’s not too late to turn things around. Specs could be moved back into the wiki until they’re nearly done. Editors, instead of being gatekeepers, could be helpful moderators. A clear process for making controvertial decisions could be decided on. And the validator could follow consensus instead of leading it. But do the people running the show want this?
Standards bodies tread a fine line between organizations for the public good and shelters for protecting collusion that would be otherwise illegal under antitrust law. For the dominent vendors involved, the goal is to give the illusion of openness while giving themselves full control to enforce their will behind the scenes.
The IETF is a good example of this. Often lauded by the public as a model of openness and and and freedom, the reality is that working group chairs, appointed by a self-elected ruling board, get away with declaring whatever they want (usually an inferior and difficult to implement alternative) as “rough consensus”, routinely ignoring comments from the public and objections from working group members. One working group (in charge of DNS extentsions) went so far as to censor mail from working group members. The dictators running the IETF, when informed, didn’t seem to mind.
Is the same sort of thing at work in the Pie/Echo/Atom Project? It’s got all the signs: a self-elected cabal (the Research Triangle Park Bloggers) who runs It appears so at first glance: Sam running the show from behind the scenes, forcing their agenda (e.g. unquoted HTML) against strong objections from important players, and putting themselves friends in charge of unilaterally declaring what’s in and out of the spec. the specs (although that isn’t what actually happened). The lack of a dispute-resolution process only makes this easier: if things worse: when there’s no clear guide on how to make decisions or contributions, no one complains when the decisions are made for them.it’s far from obvious how to challenge a decision Sam has made.
There’s no question that the group takes contributions from outsiders, and is certainly better for it, outsiders but calling they need to make it open clearer that you can be part of the development process. I think moving specs onto the wiki will reinvigorate work and setting up a dispute resolution process will help us start moving forward, instead of stuck here where no decisions have been “final”. The group seems a stretch. Instead we to have fallen into a rut. I want to help them get the same as everything else: a closed cabal that puts on a show of openness. This may not be the intention, but it is certainly the effect. We have the chance to get more, and we should take advantage out of it.