Open Standards
Use open standards. For purposes of this paper, an “open standard” is a specification that at least meets the European Union’s definition as adopted in the European Interoperability Framework:
- The standard is adopted and will be maintained by a not-for-profit organization, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.).
- The standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee.
- The intellectual property – i.e. patents possibly present – of (parts of) the standard is made irrevocably available on a royalty-free basis.
- There are no constraints on the re-use of the standard.
Sometimes extensions are needed, but they should only be used with consideration as it can be easy to become accidentally locked into a proprietary extension. Being locked into a proprietary extension can be a problem, particularly if it is only implemented by a proprietary program (since this effectively eliminates competition, raising costs long-term). Consider requiring tests (as part of the contract) with an alternative implementation of a standard to increase the likelihood of staying within standard. Where appropriate, create or work to extend open standards.
Continuous Delivery
Development should be a continuous evolution through relatively small tracked changes. That way, others can effectively review these changes. These changes should not prevent a system from building or running. In some cases, a change will not have a user-visible effect, e.g., it may be an architectural change to prepare for future functionality. Daily builds followed by automated regression tests are highly recommended; these make problems immediately apparent.
Managing Intellectual Rights
Ensure that each contribution includes the necessary intellectual rights (including “data rights”) that enable the project developers and users to continue in their use, modification, and redistribution as appropriate. In particular, examine copyright markings on contributions, and look for the insertion of new dependencies on proprietary tools and components. Incorrect markings are often copied to other material, so incorrect markings can “spread” to other projects.
An OSS project must reject any contribution that does not meet the OSS project’s chosen license(s). Similarly, an OGOTS project must reject contributions that do not permit OTD development. In particular, an OGOTS project should reject contributions with only “restricted rights” as defined in DFARS 252.227-7014(a)(14) as these do not provide the government and contractors with sufficient rights to reuse the software in arbitrary government circumstances.
Leave a Comment
You must be logged in to post a comment.