During this phase, research the open standards, open data, open source and open innovation environment for
your initiative’s ecosystem. Consider how to use open policies and requirements to achieve your program’s strategic goals given your specific context. Keep in mind that it is not always possible to include all open practices. If you are not able to participate in open practices, be sure to communicate to stakeholders why that decision was made so that you can continue fostering transparency.
- Define what being open means for your program or initiative. Ensure that your organization has an accurate understanding of what it means to be open. Misunderstandings about what open means could lead to fear or resistance. For example, stakeholders may not understand how open data can also adhere to privacy and security standards. The terms encompassed by this Principle are defined as follows:
- Open standards are publicly available standards with proven implementation success. These standards are developed, adopted and maintained by a community to enable interoperability, or connected systems, across groups and to prevent dependence on any single vendor.
- Open data comprise information that can be freely accessed, analyzed and shared, while still maintaining privacy protections. Being open means sharing data with an open license, in a machine-readable format and, preferably, for any purpose (for example, there are no restrictions on the private sector also using the data).
- Open source is software with source code that anyone can view, copy, modify and share. The open source community prioritizes collective ownership.
- Open innovation refers to co-created ideas, concepts and design or to inviting the contribution of ideas (crowdsourcing is one example).
- Identify policies and standards for openness with which your initiative must comply. These policies and standards might include national policies for open government, donor open access policies that require that publications are made freely available or aid transparency standards, such as the International Aid Transparency Initiative (IATI).
- Plan for open licensing. Agree on a set of licenses for any resources developed or produced by the initiative, such as a specific open source license, an Open Data Commons license (e.g., the Open Data Commons Attribution License) or a Creative Commons license (e.g., the Creative Commons Attribution license). In most situations, open sharing is not the default legal position, so an explicit license is required. To share as openly as possible, use the public domain declarations offered by Open Data Commons and Creative Commons.
- Identify open platforms to host your initiative’s resources, such as the repository you will use for your software code. For example, you could share humanitarian data, including data about a humanitarian crisis, the people being affected by it and their needs, and responses to the crisis, through the Humanitarian Data Exchange (HDX), and you could share open geospatial data on OpenStreetMap. Also consider whether your work has outcomes that can be shared on Wikipedia, including a relevant local-language Wikipedia.
- Collaborate with implementers who have done similar work to identify opportunities for making your initiative more open. Collaboration may take the form of working groups or information-sharing meetings, or you may work together to build the technology itself.
- Identify and build on existing application programming interfaces (APIs) and appropriate open standards. If you do not know how to find this information, ask the Principles community to help you connect with communities in your sector, such as the Open Health Information Exchange (OpenHIE).
- Plan for how you will make your initiative open. Include requirements with which you must comply and steps that you will take by choice. Ensure that your plans align with data privacy and security requirements, which can conflict with open requirements and goals.
- Include open source options when evaluating technologies and tools, if possible. This may not always be possible if, for example, a ministry, partner or funder has already selected proprietary software: software that an individual or group owns rights to and in some way restricts its use. If a selection has not been made, consider the long-term costs of your options, the fit to users’ needs, and the benefits and risks of open and proprietary technologies. This evaluation will help to identify a tool to best meet users’ needs and the needs for your context. If there is an open source tool that has been implemented successfully in other countries, you may be able to use it as a starting point.
- Foster open communities. Simply making your software code publicly available is not the same as creating an open source product. Make sure there is a community willing to adopt the code, maintain low barriers to access and contribute to its further development.
- Contribute back to existing open source platforms. When you identify software code that you would like to use or adapt in the planning phase, make sure that any changes you make to the code are communicated back to the communities that share the code. Continue to contribute your modifications and lessons learned to the community, in case someone else has a similar need for the code in the future.
