This is the latest working copy of these Standards, for the official standards please visit here.
Contribute your ideas to the Government of Canada Open Source Standards here.
Developing a Concept Case for Open Source
Prior to any form of development or acquisition, Business Owners should define both a Concept Case and a Business Requirement for any digital project.
A Concept Case identifies the key information on which a potential future digital project should be predicated, and should be completed before the Business Requirement is formed.
A Business Requirement is different from, and larger than, a digital project’s Functional Requirements or Technical Requirements alone. A Functional Requirement defines a particular function of software in order to obtain a result, and addresses a more specific working level need. A Technical Requirement defines a capability or the attributes needed to work with other software, and expresses the larger architectural decision to support the project.
The Business Requirement includes consideration of both the Functional and Technical Requirements, but also other overall elements, in order to address the nature, purpose and needs of the digital project at a high level, As a result, the Business Requirement will dictate the path for software acquisition and development, and Technical and Functional Requirements cannot be used alone as justification for the purposes of an evaluation of the benefits of Open Source Software or Proprietary Software.
The Directive on Policy on the Planning and Management of Investments, Appendix C provides Mandatory Procedures for Concept Cases for Digital Projects. While the Directive only applies to projects over a certain dollar threshold, it is important to note that the vast majority of Agile Project Management Frameworks begin with an artifact that matches a Concept Case such as a Project Vision or Project Objectives.
Expand Evaluating Requirements
Evaluate Requirements
Technical and Functional requirements cannot be used as justification for the purpose of evaluation of Open Source Software to proprietary Software, only Business requirements.
The following are examples of elements that can be taken into consideration in the creation of business requirements, but it's important to remember that procurement rules may require that business requirements permit the bidding of both proprietary and Open Source Software.
The Use of International or Canadian Standards
Business Requirements may dictate that the underlying application should conform to International or Canadian Standards, such as but not limited to requirement that the official languages requiring Software be available in both official languages.
Flexibility of the License
Open Source Software licenses can provide more flexibility than a proprietary license for a digital project’s deliverables.
Where the Business Requirement would benefit from the reuse of Software, the GC may acquire Software such that it may be used in subsequent projects in the GC. A Proprietary Software licensor can grant such right of re-use upon request, but by its nature, all Open Source Software is reusable and therefore compliant with this request by default.
Ability to use for any Purpose
Business Requirements may be set such that Software can be used for any purpose, having no restrictions in how it can be used, or allow others to use the Software. OSS terms are most likely to comply with this requirement.
The Ability to Evaluate the Code
The GC may set its requirements such that the source code be available for audit by a third party to identify quality, functionality and security of the Software.
The Alignment with Open Government
In addition the GC may set its requirements such that the source code be provided to the public to enable greater transparency and align with Open Government principles of the D9.
The Ability to Distribute the Software
Business requirements may be set such that the Software be available for distribution to anyone of its choice to ensure that other Crown institutions do not need to become customers of the original vendor in order to access and use services provided by another agency. For example, the federal Crown may wish to be able to provide the Software at no extra costs to provincial or municipal institutions.