Chaos. Anthropomorphically speaking, it wants to go everywhere.

Order. It wants to be everywhere too, and is willing to fight chaos to do it.

Michael Moorcock used to write lots of fundamentally depressing books about this very idea, and you can see it everywhere today ­ politically speaking, in the U.S. You have order being imposed as much as is possible on a culture that tends to thrive on chaos; more relevant to this magazine, you have industry standards trying to make sure that everyone marches in straight lines, while rogue coders (so to speak!) spend time writing marvelous, new code underground.

Both sides are good; innovative solutions tend to come initially from the chaotic underground, and tested solutions tend to grow out of the orderly standards bodies taking the new solution and rigorously smacking it about until it's able to handle real load. The concept comes from beneath, and the validity of the concept nearly always comes from the office.

Unfortunately, both sides tend to view the other with suspicion. The ones who chant "standards! standards!" are corporate stooges, to the bazaar-based bunch; likewise, the madding crowd is viewed as a set of subversive, rogue elements by those wearing ties. Neither group trusts the other, and often both groups insist that the opposition isn't necessary.

It's important for us to remember that chaos exists within the framework of order, or else we can't recognize what it is ­ likewise, order stifles creativity and we need creativity right now.

This can be applied by using software and participating in the process. For us, that means that people who understand the standards would benefit from using open software and modifying it to comply with what the industry requires. The open software authors likewise need to understand that standards exist for a reason, that there's a benefit to them. That's already somewhat in place ­ remember when there used to be shouting matches over where to place brackets? You still have that every now and then, but there's a common standard that's dominating now, so the fights over code format are sporadic and short. That sort of scenario can play itself out in how code works, too, just like it has played out in how code is formatted.

Of course, if everyone decides to only play by the rules, then creativity is stifled. I'd rather this not happen, obviously. It's important to see new ways of doing things, even if only so they can be rejected. Consider object databases, which are excellent solutions for some vertical applications; when your domain is limited to those applications and your assumptions can be applied, they're great! (Look at Prevayler and its claims of incredible speed.) However, the assumptions can be nasty; object databases can be crippling if you need to process the data from a language that doesn't represent objects the same way. (Consider a COBOL program trying to modify a Prevayler dataset. It can be done, to be sureSbut let's just say that most people would rather gnaw off their own neck first.)

Yet, it's still important to have these tools. You'll certainly find solutions that are vertical enough to use these products well and provide a reason for their existence. Who knows, maybe their authors or users will find a way to bridge the conceptual divide and make the products more generically useful and take over, but the "generically useful" aspect will almost always come from larger, organized bodies imposing a structure over what the products do and how.