Continuously Review Steps 1-7
Steps 1-6 should are the start of a continuous process where projects should constantly be cycling through the search for new components, growing the community, maturing the technologies and seeking to scale the size, heft and maturity of the community. Over time the community should grow, thereby bringing in new people and ideas and leading to an increase in competence and competition for government contracts.
OTD Rules of the Road:
Don’t Fork OSS Solely for Government Use
A common mistake made by government projects that begin to adopt OTD approaches is to start with creating a fork by taking a snapshot of the source code and modifying it for their own needs, in isolation from the community surrounding that code.
This is a mistake because successful OTD projects are constantly evolving and improving. Creating a fork isolates all fork users from the main OTD project, including the improvements it makes. Refreshing OTD components is a very effective way of evolving the baseline for the project. It is important to remain synchronized with latest formal releases of the selected projects for system reliability, technological relevance, and obtaining the maximum benefit of an OTD approach.
In some cases, there is no need to modify the component itself. The component’s application programmer interface (API) or plug-in system may provide the necessary flexibility without changing the component at all.
If a component must be changed, fixes and key enhancements to the baseline should be developed in consultation with original project and then submitted back to the original project. Unique government interfaces and functionality should be segregated through plug-in mechanisms or with APIs at a higher level. Taking this approach allows the government project to painlessly upgrade when new releases are made by the external project. Most useful components are continuously improved, so the ability to perform periodic upgrades must be built into the development and maintenance process.
In some cases, a project must make significant modifications to an OTD component it will depend on. First make sure that this is really the case; sometimes it is not. But if it is the case, discuss with that component’s project the changes that need to be made, and look for ways to submit those changes incrementally to the upstream project. This will increase the likelihood that these changes will be accepted by that component’s project. It is best if there is a contract incentive that changes to external projects be accepted back into those projects, to encourage the contractor to work with those external projects.