Understanding open source Part 1
Open source products can't rely on security through obscurity because there is no obscurity. For an open source product to be secure, someone who knows exactly how it works in every detail still can't break into it. That doesn't mean open source products are infallible. It does mean that breaking into a good open source product is often closer to an exercise in cryptography than a game of hide-and-seek.
If it seems like I'm suggesting open source software is more secure, it's because I am. But it's important to understand that the available data don't agree, and I'm expressing an opinion: The forces governing open source software seem more conducive to security than those governing closed source software. There's nothing to prevent a commercial vendor from being incredibly security-minded, and nothing to prevent an inexperienced developer from producing a completely insecure open source product. In the end, it's important to examine the individual products, their track records and the people who make them.
Open source software has advanced and spread significantly in recent years. In many cases it presents an attractive alternative to its commercial counterparts in both functionality and price. Those who exclude it from their purchasing decisions may be doing themselves a disservice.
At the same time, commercial software has its place and isn't going anywhere, while open source is not a magic phrase that guarantees quality. In the end, you can--and should--evaluate your open source options the same way you'd evaluate any software, and draw your own conclusions.
What isn't open source?
The following are not true of open source software:
It is free in every way. Open source products are governed by numerous open source licenses. The most common are variations on, "Here's some source code, do what you like with it," or, "Here's some source code, but use and redistribute it only under certain conditions." As with any software, it is your responsibility to know the terms governing your use of the product and abide by them.
It is unstable or poorly managed. Most open source projects are centrally coordinated. Often there are two types of release: "experimental" releases, designed for those who don't mind a little instability, and "full" releases that have been thoroughly tested and are at least as stable as their closed source counterparts. Of course, stability varies from product to product and release to release, open or closed source.
It is hard to use. Like other software, open source products run the gamut of usability. The Firefox Web browser is a shining example of a usable open source product, and if you haven't replaced Internet Explorer with it yet, you're missing out (and endangering your online security unnecessarily). On the other hand, server tools (such as the Apache Web server) often expect a certain amount of technical knowledge. It's worth noting, though, that difficult-to-use open source products often have free or inexpensive companion tools that provide a more intuitive user experience. Ultimately, you should evaluate product usability on a case-by-case basis regardless of its license, keeping in mind additional factors (such as companion products) that might affect your evaluation What isn't open source? The following are not true of open source software:
Open source and in-house development
Many corporate IT departments find themselves deciding between a commercial, out-of-the-box product and a custom solution developed in-house. If you're considering in-house development because the commercial offerings provide most--but not all--of what you need, an open source product could save you time and money. If an applicable product exists and if its developers have written well organized, readable source code, you may be able to modify it to meet your needs. You can develop the small number of pieces you still need and take advantage of someone else's work for the rest. What's more, you'll have a product that may be updated with new, needed features in the future without having to add them yourself.
[Editor's note: Part 2 of this article will appear in a future issue of KMWorld.]
David Feldman is principal consultant for InterfaceThis, a software and user interface design firm, e-mail dfeldman@interfacethis.com.