One of my favorite sci-fi plots starts with a man entering a time machine with the dials set to some year in the ancient past. After the press of a button and loads of special effects, the man emerges in the midst of dinosaurs. Startled, he steps back and accidentally kills a butterfly. As expected, his return to the future reveals a present that's much different from the one he left. Depending on the writer of this script, the result could be better or worse for mankind.
Time travel remains sci-fi fantasy. However, little events can still make a big impact over the long term. For example, the swish of Judge Kollar-Kotell's pen approving a recent Department of Justice settlement enables a major software vendor to police itself. Many say that it's business as usual. We'll need patience or a time machine to find out.
A close look at the past might help, especially when it comes to standards. Take Microsoft's Active Directory for instance. It's an excellent directory service that's based on open standards, like Kerberos and LDAP, or lightweight directory access protocol—sort of.
Microsoft's use of Kerberos includes a proprietary field that prevents most third-party directory systems from working with Active Directory. Is this likely to change? Probably not. That swish sealed the deal since security related application programming interfaces (APIs) and technologies aren't something that Microsoft will have to reveal to the world—unless it wants to, of course.
But who would blame Microsoft for such resolve? The company isn't alone in its pursuit of proprietary extensions of public standards. In fact, some standards, such as XML, push the idea of extensions, proprietary or otherwise. SOAP (or simple object access protocol) is based on XML. While it's an open standard, it also is designed to be extended in the same fashion. The individual, company, or organization holds the responsibility over the extensions. They can reveal them to the world or hide them under a basket.
I prefer standards, de facto or formal, to be open, not hidden. Of course, this bias is because I think that the availability of products and services based on these standards will lead to more, as well as improved, products and services.
One de facto open standard platform that shows promise is Eclipse (www.eclipse.org), the Java-based integrated development environment. It's one of many open-source projects that reveals not just protocols or APIs, but also the source code.
Eclipse has been used to host a variety of languages and is the base for system-development environments from QNX (www.qnx.com) and IBM (www.ibm.com). The environments are often closed and proprietary. But because they don't subvert the standard base, the tools can coexist with other open or proprietary tools.
A good example of the interchange between plug-ins, as they're called, is the source-code management and track systems that can be employed with other tools like editors and debuggers. This would not be possible if a proprietary hook was added to the the base standard.
So what tools are you using these days? Open or proprietary? If the latter, how proprietary are they? Proprietary tools running within a standards-based environment are much preferred over a proprietary environment with tools that must employ a modified standard. The latter locks you in.
A proprietary extension or secret API may sound like a minor thing when there are thousands in a system. Yet even the smallest change can affect the future in a big way.
It's up to you now. Change the future. Step on a butterfly.
Reprints
