An open source strategy for WHO

[smbuthia]

The WHO has been making steady progress toward formalizing open source use and development. Documenting an open source strategy is a key step in formalizing an organization's approach to adopting and developing open source. This might include things like:

• WHO's approach to open source and support of its use,
• strategies on the consumption of open source,
• WHO's contribution to open source projects,
• guidance for licenses, policies, and procurement templates,
• usage policy and trademark, etc.

What content would you like to see in such a document, and how would it help you?

[DinaRaus]

Integration policy for developing systems that speak to each other rather then stand alone solutions, allowing the ability to build packages.

[smbuthia]

Open source solutions are indeed enablers of interoperability due to the transparency and open availability of these systems, particularly in public health. Availability of API endpoints and adoption of interoperability standards are good considerations to have within the strategy.

[umu-mo]

First, great work advancing open source use at WHO. This effort is already warming up more digital health participants and FOSS-digital tools enthusiasts into finding out more about being active contributors. Personally, curious to further learn about your OSS effort via Github. Some content we'd be interested to explore on WHO's OS-Strategy doc would be: 1. What ambition does WHO have with its open source strategy and how does it mesh with WHO's mission? 2. How can developers and contributors at large join in WHO's OSPO work to meet its needs? 3. A detailed framework or decision-making guidelines on how WHO will tackle licensing conundrums. 4. What approach will you take in building and engaging a community around WHO's open source tools and systems? . . .There's more we are excited to find out about, for now, let's tinker around Github to find out more about the platform.

[smbuthia]

Thank you so much for your feedback @umu-mo!

What ambition does WHO have with its open source strategy and how does it mesh with WHO's mission?

This is critical. A shared understanding will be instrumental to advancing the use and development of open source solutions. This strategy will be developed jointly with key stakeholders and experts to ensure we appropriately address the needs of the organization and its continued ambitions for collaboration.

How can developers and contributors at large join in WHO's OSPO work to meet its needs and what approach will you take in building and engaging a community around WHO's open source tools and systems?

We welcome insights and ideas in GitHub discussions and comments on GitHub issues. We also continue to develop new guides and improve on existing ones. If you would like to contribute to the guides, you can create a new issue or work on an existing one. We are also working on a list of open source projects that developers can contribute to. This list is growing and we will continue to add on to it in the coming weeks as we put the necessary licenses and guidelines in place for contributor communities.

The open source strategy will cover at a high level how open source projects can build and manage contributor/developer communities. These communities will be devolved to individual projects and the project maintainers will set their own governance structures and contribution guidelines that are informed by the overall strategy and guidance.

A detailed framework or decision-making guidelines on how WHO will tackle licensing conundrums.

This is high on the list of priorities. Uncertainty on what open source license to use is one of the main hurdles to making projects open source. The open source strategy will provide general guidance on open source licensing within WHO. We will also put in place detailed frameworks that will hopefully make it easier for projects to apply open source licenses that are appropriate for them.

We are excited about contributor communities being an integral part of the work that the WHO is doing to respond to health emergencies and look forward to working together with many of you in this great endeavor for the benefit of all.

[NSievers14]

I had similar thoughts. I believe having a shared vision is absolutely paramount for strategy development (otherwise, we might risk producing papers that no one benefits from or even reads). For defining this shared vision, I think it will be key to make it as tangible as possible, especially given the technical depth of OSPO that not many WHO/UN/Govs are familiar with. Best practices and clear assessments of their pros, cons, and operational bottlenecks would be key here, in my view, to stimulate the conversation and drive it to the point where decision-makers get excited, commit and support its implementation in the long run. Also, in defining these best practices, I think putting a clear emphasis on MSs' benefits is crucial - ultimately, our and their outputs should multiply each other to ensure the fulfilment of their sovereign accountabilities.

[DinaRaus]

I agree @Nikinger14 a clear emphasis on MS benefit would be integral for OSPO. Understand the needs of MS and engaging them early will lead to a more sustainable strategy with buy in and application at the country level.

[BonfaceKilz]

A minor addition: Reproducible research/work is a big problem for many people in the research space, and some of these problems [and solutions] are sipping into more mainstream programming (notice the boom in snaps and similar technology). Building something with reproducibility in mind: influences the choice of technology you use, it makes people conservative with what they use; and it makes replication of systems easier.

Personally, should WHO have the above in mind, it will make it easier to package and distribute whatever package/service is created and disburse to other FOSS communities.

Also it'd be nice to weave in progress reports like: https://hpc.guix.info/blog/2022/02/guix-hpc-activity-report-2021/ to encourage ownership of work. These efforts are usually conducted by core devs.

[edited] I removed my suggestion for adding a Coc. It already exists.

[smbuthia]

Thanks for sharing your thoughts on this @BonfaceKilz.

I agree with your sentiments. The reusability of open source components is important to consider when building contributor communities. Developers are more likely to contribute to open source libraries they use for example.

Open source metrics are a key consideration already. From these we could have progress reports that could be shared.

[BonfaceKilz]

Samuel Mbuthia ***@***.***> aliandika:

Thanks for sharing your thoughts on this @BonfaceKilz.

Sure!

I agree with your sentiments. The reusability of open source components is important to consider when building contributor communities. Developers are more likely to contribute to open source libraries they use for example. Open source metrics are a key consideration already. From these we could have progress reports that could be shared.

100%

…

-- (Life is like a pencil that will surely run out, but will leave the beautiful writing of life.) (D4F09EB110177E03C28E2FE1F5BBAE1E0392253F (hkp://keys.openpgp.org))

[nkabiru]

Congratulations on promoting an open-source methodology at WHO! This approach has the potential to benefit the public by increasing access to software tools for developing health solutions. To further enhance your efforts, I recommend addressing the following points in your open source strategy document:

• Establish clear contribution guidelines for WHO's projects
• Determine the platforms to be used for support questions and discussions
• Outline the process for filing bug reports
• Establish a policy for addressing security vulnerabilities.

[smbuthia]

Thank you @nkabiru! Open source digital public goods in health certainly have the potential to increase access to impactful digital health solutions. The points you mention here are really good. The strategy document would also be supported by in-depth guides that would dive deeper into more technical topics like filing bug reports.

I like the idea of having a policy for addressing security vulnerabilities in open source software and will add this to the existing considerations! Thanks again and feel free to share more ideas as they come up.