Step 2: Identify the Projects to be Established
Given the reuse options, identify what new projects are necessary and which existing projects need to be transitioned to OTD. In some cases, the “new project” may be a project to extend some existing OTD project and get that extension integrated into the original project. Where possible, split up the project into several smaller projects with clear interfaces. These smaller projects may be divided according to various criteria, including the likelihood of reuse (to maximize the number of participants in at least some of the projects) and the need to limit access (classified or export-controlled modules may need to be separated from other components, e.g., by creating an unclassified “framework” into which controlled “plug-ins” can be placed).
Name each project so that is not easily confused with other projects. It should be pronounceable and easy to find on a web search (ideally, it would be the only result from a search; certainly avoid unsearchable names like “the” or “why”).
Each new project (including any existing project transitioning to OTD) needs a statement of intent that references the OTD software maintenance philosophy. As recommended in [Fogel2009] “the mission statement should be concrete, limiting, and above all, short.” The mission statement should make it clear that the goal is to use open development principles (e.g. avoiding lock-in to a single supplier) and what the resulting products should do. Here’s an example of a good one, fromhttp://www.openoffice.org:
To create, as a community, the leading international office suite that will run on all major platforms and provide access to all functionality and data through open-component based APIs and an XML-based file format.
In a DoD project, the software maintenance philosophy statement might reference DFARS 227.7203-2 (“Acquisition of noncommercial computer software and computer software documentation”), and in particular the text at DFARS 227.7203-2(b)(1) (bold and underlining added):
Data managers or other requirements personnel are responsible for identifying the Government’s minimum needs. In addition to desired software performance, compatibility, or other technical considerations, needs determinations should consider such factors as multiple site or shared use requirements, whether the Government’s software maintenance philosophy will require the right to modify or have third parties modify the software, and any special computer software documentation requirements.
Determine, for each project, whether it must be limited to only DoD or general government access as an OGOTS project. By default, projects should become COTS OSS instead of OGOTS. In some cases (e.g., due to classification or export control) a project must be limited to DoD or U.S. government access. GOTS projects present a higher risk than COTS projects, because by definition there are fewer potential contributors (decreasing competition and potentially increasing cost), and contractors (other than their copyright owners) are disincentivized from using GOTS projects because they cannot reuse those components or knowledge about them in other commercially viable ways. In many cases it is possible to split the project into two projects, one that is OSS (e.g., a “framework”) and one that is OGOTS (e.g., a “plug-in” to the framework).