How to do open development work, Rules 1 & 2

  Last night, at a NYC dinner party, a reader suggested I write a Ten Commandments of open development work.
  Even though it reeks of hubris, it's probably a good idea.
  I've been involved in a lot of open development work over the last 30 years, and some of it has worked, but most of it fails. When it fails it's almost always because some group of people violated what I will call Rule 1.
  Rule 1: All meetings must be open to anyone who wants to participate.
  This is important because it means that any control anyone is exerting is visible to anyone who wants to see it. And that visibility tends to limit the control.
  As soon as you have an invite-only meeting, someone is going to have to take your word that the process is fair. And the process isn't fair. So, if you say it is, you're lying. And lies are a terrible foundation to build on.
  I think SOAP died when it became clear that Microsoft and IBM were having private meetings.
    SOAP makes an interesting case study for both rules.
    XML-RPC would have made a much better foundation for interop than the spec that emerged from the SOAP process.
    You could completely implement XML-RPC in a few days. That meant that as long as another toolkit conformed to the spec, you would interop.
    SOAP, on the other hand, was so open-ended that you could never completely implement it. Someone could be completely compliant with the spec, yet interop with no one. That meant that interop could be negotiated privately, for a price, off-list. This was a market that the small developers were excluded from, because they didn't have anything to trade that the big companies wanted.
    Of course this all backfired -- in the end no one cared enough to fix it.
  It's why so many of the supposedly "open" formats that Google is promoting have no chance of working in the market. I can't read minds, so I can't tell you why they do it. But it never works. A lie is a lie, even if you work for the largest company in the universe.
  Rule 1 is the mechanism whereby small developers, even the ones who aren't blessed with invitations, have a chance to compete in a world ruled by the large companies. (And by the way if you get an invite it doesn't mean they like or respect you. You're probably the fig leaf they'll use the "prove" the process was open, even when it wasn't.)
  But a pragmatist might say -- if we made the meeting open to all, and announced it publicly, 1000 people would show up and we'd get no work done. True. I've been in those meetings. And listened to one boring speech after another, and during all that boredom I figured out Rule 2.
  Rule 2: If you have a choice, ratify defacto standards instead of reinventing them.
  When it came my turn to speak in the 1000-person meeting, I said we could all leave the room this day with a standard if we just ratified RSS instead of trying to create something new that does exactly what RSS does. Even though what I said was true, no one could refute it, we didn't do it. And here we are eight years later and the defacto standard still rules.
  The great thing about both these rules is that even if you break them, they still rule.
  If you have an invite-only meeting then your work is for nil, and the people who aren't at your meeting will route around you, and if there's value in an open standard, it will be created in the haphazard way that open formats come about, naturally.
  If you choose to reinvent a defacto standard, you will still have to support the defacto standard, and it will grow while people may implement your competing format, but lots of people will wonder why they should bother, and won't.