Let's suppose, for example, you are designing image-capture software for a digital camera. Why write your own format for saving image bits or buy proprietary code when (as we noted in Chapter�5) there is a well-tested, full-featured library for writing PNGs in open source?
The (re)invention of open source has had a significant impact on the standards process as well. Though it is not formally a requirement, the IETF has since around 1997 grown increasingly resistant to standard-tracking RFCs that do not have at least one open-source reference implementation. In the future, it seems likely that conformance to any given standard will increasingly be measured by conformance to (or outright use of!) open-source implementations that have been blessed by the standard's authors.
� | The flip side of this is that often the best way to make something a standard is to distribute a high-quality open-source implementation of it. | � |
-- | � |
Until the late 1990s this advice would have been impractical. The few alternatives to relying on proprietary operating systems and development tools were noble experiments, academic proofs-of-concept, or toys. But the Internet changed everything; in mid-2003 Linux and the other open-source Unixes exist and have proven their mettle as platforms for delivering production-quality software. Developers have a better option now than being dependent on short-term business decisions designed to protect someone else's monopoly. Practice defensive design — build on open source and don't get stranded!