Section 4.7.  Summary

4.7. Summary In this chapter, we set aside the Sarbanes-Oxley discussion for a moment to investigate the entire open source phenomenon and the fundamental differences between it and nonfree software. After an examination of closed source development, we examined the open source methodology in some detail and articulated the tangible and intangible reasons why open source software can save you money and give you freedom of choice. Because of the rapid development cycle and the "release early, release often" mentality, the bar of quality and security is raised owing to massively parallel peer review of the source code. When a bug is identified by an end user, often he or she is a hacker who also supplies the fix, or at least a directed report on how to reliably reproduce the bug for the developer to test. Linux Torvalds' "Given enough eyeballs, all bugs are shallow" theorem essentially states that someone, somewhere, will know the fix to a bug no matter how difficult it may seem to the original developer. We continued by examining the use of open source in your environment. We learned that there are many opportunities for the use of OSS software, even if you are currently on a primarily Windows-based infrastructure, as most prominent open source software runs on diverse architectures, including Windows. This investigation was further refined by discussing the two main ways in which open source software fits into the SOX compliance equation, both as elements of your IT infrastructure and as support systems such as document control, system monitoring, workflow, and approval management. We also discussed some of the items you should consider if your environment is in a state of transition. One must be diligent to document and subject any changes to the same approval and testing mechanisms as those identified for internal controls procedures. When evaluating your IT infrastructure, your internal controls universally fall into the categories of prevention and detection; however, all controls share some common characteristics and constraints. All controls must be testable; a well-defined test must be in place to validate the control. All control tests must be repeatable; the same test should yield the same result every time. All control tests should be sustainable; that is, they should enable you to maintain your controls and certification processes over time. In conclusion, we introduced the sample companies that will be used as case studies for the remainder of the book to illustrate concrete examples of open source software deployment as the subject of certification, and the use of open source software in the compliance process. The sample companies demonstrate two completely different architectures; BuiltRight Construction is a small public company with an infrastructure based entirely on Microsoft Windows and other closed source technologies, and NuStuff Electronics is a medium-sized global organization with a mixed platform environment.