Open, Sesame

Saturday, March 27, 2004 05:12 AM

Over at Falafel land, Steve Teixeira and Charlie Calvert have been bickering (actually, having a stimulating and interesting discussion) about open standards. While I pretty much agree with both of them, I think Steve summed it up best for me when he wrote:

"While Charlie articulated what I'll call the developer's point of view, I would like to present a different point of view on the matter, a point of view that is perhaps a bit more in tune with the economics of software development."

Open standards are indeed a good thing, for a variety of reasons: they allow better commonucation between systems and components, provide the basis for system interoperability, and - in some cases - lower both development and maintenance costs. They are not, however, a silver bullet. Here's a little story:

As Chief Technologist at SintecMedia, I was assigned the task of designing the architecture for their flagship product, OnAir. The system was targeted at the high-end broadcasting market, and I had to design a scalable, robust architecture as well as select tools, development languages and supporting technologies for the project. When considering possible technologies, I had to evaluate not only their technical merit, but also their affect on the company's business process. This included things like maintenance costs, technology lock-ins, and even reputations (when trying to sell a multi-million dollar system, which of these statements sound better: "we're using Oracle because it is designed for the enterprise" or "we're using [obscure database server here] because we've found it to be technically superior?").

I did, however, follow some guidelines in making my decisions, which I'm happy to say paid off really well:

1. Use industry-accepted standards. There's an important distinction here - it doesn't matter if the standard is open or proprietary, as long as it is widely accepted in the industry. For example, Java is a proprietary standard, although many people tend to forget that fact. It is, on the other hand, an industry-accepted standard. (By the way, we actually wrote the system in C++ and Delphi, because they better suited the job.)
2. Get source code. This is critical. No matter whether you're using an open or proprietary tool, make sure you get the source code to any library you include in your project. When there's a bug in your software and thousands of users can't do their job, you need to be able to debug and fix every piece of code in your project. Even if you can't fix external libraries, reading the source code is tremendously helpful in finding workarounds.
3. Get tools that just work. If you find a tool that does what you need, and you're sure it works and is the best tool for the job, hardly anything else matters. For example, we needed a central database server that would carry the huge workload of the application and serve thousands of users, and went with Oracle. Now, Oracle doesn't give you the source code, and uses a proprietary variant of SQL (until version 9, you couldn't even use the standard syntax for joins). But it just works. For the benefits provided by the Oracle database server, we were willing to ignore the previous guidelines.
4. Use technologies that customers can accept. It doesn't matter if you think your system will look better on the Mac, or run better on Linux, if you're developing software for large corporations, chances are your user interface (at least) should run on Windows. The same goes for the servers - at the time, large clients were much more likely to accept Oracle than, say, MySQL (although this have slightly changed recently).
5. Reduce development costs and time-to-market. This may or may not apply to you. We had a limited window of oppurtunity to release a new product. As for development costs, this requirement pretty much applies to everybody. In our case, it meant building a Windows client rather than a web client, and using RAD tools to build it.
6. Test everything. Past experience, good advice and product demostrations are all great, but your final decision should always be based on actual test results. Test every tool, library or technology you're considering. Build test that match your project. Try to break things. You don't want to get halfway through development (or worse, customer installations) and find out you made the wrong choice.

You may still make mistakes following these guidelines, but they won't be as bad as choosing technologies based on arbitrary criteria such as open standards, open source, or tools from big companies.