Do You Need to Modify the Source Code?
The major difference between proprietary software and OSS is the ability to view, modify, and distribute the application source code. Code modification may lead to some undesired effects on the life cycle of the system. Modifying the source code would force the program to keep a private copy that is different from the open source project’s repository. That may work without issue for the initial release, but remember, just like proprietary software, OSS periodically releases new versions, patches, and upgrades. Once one breaks off from the primary project, he or she is now responsible for any upgrades and associated testing as the releases may not be compatible with the modified version.
Code modification may not be as easy as one might think. Take the Open Office project mentioned previously. If someone required a code modification and provided the development team with 9 million lines of code, a seemingly trivial modification may turn out to be a daunting task. Unfamiliarity with the application or programming language may cause additional complications. Most OSS uses a modular design so it can be easier to locate the code segment for which the modification is needed; however, the effects on the application may still be unknown.
One possibility is to make the modifications to the source code and submit the update to the OSS project’s committee for review and possible incorporation within the next software release. If accepted, the update would go through the project’s revision, testing, and review process during subsequent releases, and one would no longer need the old version of the software. Similar to most commercial software, the open source community does what is best for the community and not one’s specific program. Therefore, there is no guarantee one’s changes will be included in the next software baseline. As with any software application, when new functionality is added, the project is now responsible for maintenance, testing, and bug fixes for the added piece of functionality.
While modifications provide an added level of complexity, OSS does provide several alternatives over commercial software. One alternative may be deciding there is only a need to use a portion of the source code within the project. If the OSS is modular in design, it may be easy to extract only the functionality needed to incorporate into the application. That may be the best option if only a small piece of the OSS functionality is required. As with proprietary software, there is a point where “too much of a good thing” can turn bad. If one takes several pieces of different systems and includes them in his system, the system may become difficult to maintain, especially when each addition is in a different programming language, contains different interfaces, and may require additional dependencies. This can be exemplified by using a car analogy. Consider buying a Chevy Camaro but realizing that it will require the engine in the Ford Mustang and the electronics of the Audi A4. After integrating the required functionality of the other automobiles, the owner would have a system that met all of his requirements. However, if the vehicle needed maintenance, the owner would no longer be able to take it back to the Chevy dealership because a modification to the electronics system may adversely affect the engine because the components were not initially design to work together. In addition, if Audi releases an electronics upgrade, the owner may be unable to use the new software due to compatibility issues with the nonstandard engine.
Is OSS the Full Solution?
As with most proprietary products, OSS may not provide a solution that will satisfy everyone’s requirements. Users may have to sacrifice functionality for a faster time to field. Gen. David Petraeus, commander of U.S. Central Command, recently said in an interview, “Never underestimate how important speed is.” Additionally, he pointed out that in most cases, the soldiers are willing to accept an 80 percent solution. This is where constant user involvement is imperative in order to help make an informed decision. The user decides if less functionality provided sooner outweighs the time needed to develop the functionality from the ground up.
Conversely, OSS comes with a variety of features and could include many more features than are required by one’s program. This inundation of extra features may require additional training, testing, and/or information assurance assessments to use the software in an operational environment. Removal of those features is also an option, but one must remember the risks mentioned in the modification section.