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. Joe Gregorio and Mark Nottingham 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. The Wiki was turned into a unavigable swamp of a discussion forum for the drafts edited by other people. It’s less than clear how to be a real part 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 appears so at first glance: Sam running the show from behind the scenes, putting friends in charge of the specs (although that isn’t what actually happened). The lack of a dispute-resolution process only makes things worse: when there’s no clear guide on how to make decisions or contributions, it’s far from obvious how to challenge a decision Sam has made.
There’s no question that the group takes contributions from outsiders but they need to make it 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 to have fallen into a rut. I want to help them get out of it.
posted August 20, 2003 10:39 AM (Technology) #