Marc's Pursuing Perfection Weblog : Developing knowledge management for Pursuing Perfection in healthcare.


Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.


Stop Energy, by Dave Winer

RFC: What is Stop Energy?

Thu, Apr 25, 2002; by Dave Winer.

This is one of those terms I've been using casually, it's time to try to write a definition.

Suppose someone, call him Mr. A, has an idea that he believes is ready to deploy, or is requesting comments as he is getting ready to deploy. So he posts an RFC, usually on a mail list or a website, in the hope that people will spot a problem and help him figure out a solution; or find no problems and co-develop an implementation, or develop a compatible implementation. In theory, the Internet is a collegial environment, with lots of people who want to do new stuff, where one should expect to get this kind of help.

In this scenario, A is a proponent of Forward Motion. In all likelihood, instead of getting help, A will encounter Stop Energy, reasons why he can't or shouldn't be allowed to do what he proposes.

Stop Energy is not reasoned, it never takes into account the big picture, it is the mirror image of Forward Motion. In the Stop Energy model, everyone, no matter how small their stake in a technology, has the power to veto. Nothing ever gets done, and people who want to move forward are frustrated in every attempt to move. Unfortunately, Stop Energy is the rule, not the exception.

In my experience, FM only happens when no one else is interested enough to mount a SE campaign; or if the proponent of FM simply ignores the SE. And Stop Energy can be applied retroactively. I heard at a working group meeting that things like SOAP can only happen when no one is paying attention. I pointed out that XML-RPC happened exactly that way and suggested that they use it. The point went without response. Stop Energy trumps Forward Motion every time, it seems.

I've been suckered into debates with Stop Energy proponents too many times, these days I don't propose open protocols or formats unless there is a clear advantage to being open; because I want to move and I'm tired of pointless debates.

Just for fun I decided to make this an RFC.

© Copyright 2002 Marcus Pierson, MD.
Last update: 5/5/2002; 3:42:38 PM.

Click here to visit the Radio UserLand website.