Chaos. Anthropomorphically speaking, it wants to go everywhere.
Order. It wants to be everywhere too, and is willing to fight chaos to
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.
About The Author
Joseph Ottinger is a consultant with Fusion Alliance (www.fusionalliance.com) and is a frequent contributor to open source projects in a number of capacities. Joe is also the acting chairman of the JDJ Editorial Advisory Board.