WMO Guide to Free and Open Source Software

Autonomy and control: The code is open and licences are flexible, allowing meteorological organizations to perform customization as needed, directly modifying the code to add or remove functional modules to suit unique operational scenarios (for example,regional weather forecasting adjustments). This level of access also allows them to independently identify and fix vulnerabilities, optimize performance for large meteorological data workloads, and control the technical roadmap of core systems. Certain permissive licences (for example,MIT License, Apache License 2.0) even permit using modified code as closed source in commercial products, balancing customization needs with operational requirements.

Cost advantages: No software licence fees or subscription fees are required, making FOSS suitable for national meteorological services as well as deployments in regional forecasting centres. The availability of source code and community documentation reduces costs during adaptation and integration. Meteorological organizations can also choose free community support or affordable third-party services instead of expensive vendor support packages. A 2021 study commissioned by the European Commission estimated a cost-benefit ratio of above 1:4 for OSS investment across the EU public sector, noting that EU companies' € 1 billion investment in OSS in 2018 generated between € 65 and € 95 billion in macroeconomic impact on EU GDP — though these are economy-wide figures and individual organizational returns will vary.^[9] A World Bank case study of institutional investment in open-source geospatial software — a domain closely analogous to NMHS operations — found a conservatively estimated 200% return on investment over seven years.^[10]

Avoiding vendor lock-in: Free from proprietary interfaces and data format dependencies, enabling free choice of deployment environments (for example,private or public clouds). Even if the original project is discontinued, maintenance can be taken over independently or by a third party. Moreover, multiple service providers often support the same open-source software, strengthening the user’s bargaining position.

Cross-platform portability: Most open-source tools run on multiple operating systems (for example,Windows and Linux). Adherence to common technical standards (for example,WMO GRIB data formats) lowers system integration difficulty. Modular design facilitates containerized deployment and cross-cluster migration, adapting to architectural upgrades in meteorological data centres.

Technical capacity development: Community involvement within FOSS projects can foster career growth, professional recognition, networking and collaboration. In turn this can lead to increased technical capacity within Members' NMHSs and other organizations.

Licence compliance risks — users: Members using FOSS internally, without modification or redistribution to third parties, face minimal licence compliance risk in most cases. The principal exception is the Affero GPL (AGPL), which extends copyleft obligations to software used to provide network services even without distribution; NMHSs operating web-based or API services should assess AGPL-licensed components carefully.

Licence compliance risks — contributors and distributors: Members who modify FOSS and distribute it to third parties face broader obligations. Copyleft licences (for example, GPL, LGPL) require that derivative works be made available under the same terms and that original copyright notices be preserved. Where FOSS components with different licences are combined, compatibility between those licences must also be assessed. Violations of applicable licence terms may lead to legal disputes and intellectual property issues.

Security risks: The openness of FOSS source code means that vulnerabilities can be identified — and fixed — by a wide community of developers; this transparency is a significant security advantage over proprietary software where code cannot be independently inspected. However, software from niche or less-established projects may pose security risks where the contributor community is too small to provide adequate review. Additionally, the complexity of FOSS supply chains can create vulnerabilities that could be exploited to implant malicious code. These risks are amplified in meteorological applications, especially when handling sensitive observational data or real-time forecasting models.

Maintenance risks: Fixes for vulnerabilities rely on community responsiveness. If an open-source project is discontinued, known vulnerabilities may remain unaddressed.

Dependency and stack maintenance risks: FOSS solutions typically depend on a broader ecosystem of libraries, frameworks, and runtime components. Keeping the full software stack up to date, including across upstream dependencies, requires continuous effort. Version incompatibilities, breaking changes upstream, and end-of-life releases can create significant operational burden, particularly for small teams managing operational meteorological systems.

Support risks: Most open-source software lacks official support. As a result, timely response and effective resolution of critical operational system failures cannot be guaranteed, potentially leading to interruptions in meteorological operations and data loss.

Technical adaptation and integration costs: Human resources must be allocated for software customization and adaptation, system interface integration, and compatibility testing to ensure the software aligns with existing systems.

Long-term maintenance and version management costs: Dedicated personnel are needed to track version updates, conduct testing, and manage migrations. If a project is discontinued, taking over its maintenance internally entails high technical challenges and added operational complexity.

Talent acquisition and training costs: Recruiting skilled professionals can be expensive, and ongoing in-house training is required to maintain the necessary expertise.

Compliance audit and management costs: It is necessary to maintain an inventory of all open-source components and perform regular compliance audits. Large meteorological organizations may also need to develop dedicated management platforms, with costs increasing as the number of components grows.

Proprietary software pricing risks: When assessing the cost implications of FOSS, these should be considered alongside the risks of commercially licensed alternatives, which may include vendor-driven migration to subscription-only licensing models (whether cloud-based or locally deployed software requiring ongoing licence validation), significant price increases, and ratchet mechanisms that progressively erode an organization’s bargaining position and ability to exit the relationship.

"Open by default" procurement rules requiring public institutions to consider FOSS alternatives alongside proprietary solutions when acquiring software. National examples include the United States Federal Source Code Policy,^[12] the Government of Canada Open First approach,^[13] New Zealand’s NZGOAL-SE framework,^[14] India’s Policy on Adoption of Open Source Software,^[15] and Japan’s Open Source Promotion Report.^[16] In some countries, like Romania, when you purchase "on demand" software development services, the source code should be transferred to the customer along with all the IPR associated with the software. Making the source code available under an open-source licence is highly recommended.

Guidelines for software development funded from public budget, encouraging publication of code under approved open-source licences. The "Public Money? Public Code!" campaign, supported by over 200 civil society organizations, advocates that software developed with public funds should be released under open-source licences.^[17]

Policies promoting interoperability and open standards, which naturally align with FOSS implementations within WIS2 and other WMO technical frameworks. In the European Union, the Interoperable Europe Act^[18] (in force from April 2024) requires public sector bodies to conduct interoperability assessments and share open source solutions for cross-border digital services.

Capacity-building programmes that enable staff to acquire skills for maintaining and developing open-source tools, reducing long-term operational dependency on external vendors.

Security and lifecycle requirements to ensure that open-source components used in critical systems follow maintenance, patching, auditing and version management rules.

Establish internal rules for licensing, contribution approval and repository management.

Define procedures for evaluating FOSS components (governance, community health, maintenance model).

Incorporate sustainability planning (including contribution back to upstream projects when fixes or new features are developed internally).

Promote transparency by adopting open repositories for research software and operational tools.

Software evaluation and endorsement: Providing a consistent process for assessing FOSS used in WMO programmes and projects, applying criteria such as those described in the FOSS evaluation rubric (see Annex A). This includes evaluating licence compatibility, security posture, project and community health, openness of governance, and technical fitness for purpose.

Lifecycle oversight: Tracking the status of FOSS components used across WMO programmes, from initial adoption through operational use to end-of-life, ensuring that migration plans are in place when software is no longer maintained.

Standards alignment: Coordinating standards alignment reviews, working with Expert Teams to ensure that FOSS developed or endorsed within WMO implements relevant Technical Regulations and open standards correctly and consistently.

Guidance and advisory support: Providing practical guidance on FOSS best practices — including licensing, contribution workflows, governance models, and release management — to Members, implementing authorities, and project teams, in support of the technical direction set by Expert Teams and Task Teams.

Open Source Program Office (OSPO): Delivers the day-to-day coordination of FOSS activities across programmes and projects, including software evaluation, lifecycle oversight, guidance to implementors, management of external partnerships, and continuity of institutional knowledge across constituent body sessions.

WMO Secretariat: Provides the institutional mandate and home for the OSPO, and ensures FOSS governance is embedded within WMO’s broader programme management and regulatory framework.

Expert Teams and Task Teams: Provide domain-specific expertise in evaluating and developing FOSS relevant to their areas of responsibility. Expert Teams and Task Teams may identify candidate software for endorsement or develop Reference Implementations of WMO standards.

Communities of Practice: Serve as collaborative spaces where Members, developers and stakeholders work together on shared FOSS initiatives. Communities of Practice can play an important role in maintaining and evolving software that supports WMO standards, as demonstrated by the development of Reference Implementations within the WIS2 programme and the OpenCDMS project and initiative.

Members: Contribute expertise, code, testing and operational feedback. Members with mature FOSS programmes can serve as mentors and collaborators for those building capacity.

Concept and prototyping: An initial requirement is identified and ideas are explored. These may often be part of the development of a new standard, such as the WIS2 standards, or in response to an operational need. At this stage, the software may be experimental and maintained by a small number of developers.

Development and pilot use: Following initial prototyping, the software gains maturity and may have additional contributors. The software is tested in pilot environments. Parallel to this, the standards that the software is implementing may also gain maturity and undergo further changes.

Operational use: Software, and standards, are ready for production use in operational environments. There will be established governance processes for the FOSS together with comprehensive documentation and contribution guides. The contributor base will have grown and be sustainable.

End-of-life and migration: When software is no longer actively maintained or has been superseded, clear guidance should exist for migrating to alternative solutions, including data migration. End-of-life planning is particularly important for software that Members depend on for operational services. Retirement planning should include: a data archiving plan to ensure secure storage and traceability of historical data; an assessment of migration costs and a defined transition path to maintain continuity of service; and clear assignment of responsibilities for decommissioning, including procedures to mitigate risks such as data loss or service disruption.

Key person dependency (bus factor): Over-reliance on a single, or small team, for critical software. When supporting FOSS development and adoption, the WMO should encourage a broad contributor base, shared governance, and pooling of resources for the support and development of critical software.

Lack of long-term support and maintenance: Not all FOSS projects have a sustained commitment to long-term support. Projects may cease active development without formal end-of-life notice, leaving Members dependent on unmaintained software with unaddressed vulnerabilities and no migration path. FOSS maintenance relies on community goodwill, institutional backing, or commercial arrangements with service providers — similarly to proprietary software, where such obligations are contractually defined but not always guaranteed in practice. Members should assess the long-term support model of any FOSS solution prior to operational adoption and have contingency plans in place should maintenance cease.

Security vulnerabilities: Software components must be subject to regular security reviews, including vulnerability testing, with clear disclosure and patching policies. Adequate resources must be in place to ensure any identified vulnerabilities are addressed in a timely fashion.

Dependency risk: Software often depends on a chain of upstream libraries and components. Understanding and monitoring these dependencies is essential for assessing overall project health. This includes changes to upstream licensing conditions.

Funding and institutional support: Whilst FOSS may be free of licensing costs there are still costs associated with the development, maintenance, implementation and operation of FOSS software. These costs are often hidden or neglected but should be taken into account. Capacity development costs — including staff training, upskilling, and the ongoing effort required to build and retain the expertise needed to evaluate, deploy and maintain FOSS — represent a significant and frequently underestimated component of these costs, particularly for Members with limited technical resources.

Technical Regulations and standards: Co-development of Reference Implementations alongside the development and implementation of new regulations and standards; FOSS developed or endorsed should conform with and / or implement WMO standards. The WMO should also promote alignment and interoperability with open standards, such as those developed by the Open Geospatial Consortium (OGC).

Cross-programme and cross-project coordination: FOSS components are often relevant to multiple WMO programmes. Coordination can help avoid duplication, identify opportunities for shared development and ensure that Members benefit from a coherent set of tools rather than competing or overlapping solutions.

Capacity building: Providing training, documentation and technical support to help Members evaluate, deploy and maintain FOSS solutions. This is particularly important for developing countries and small island developing States, where resource constraints may limit the ability to engage with FOSS communities directly.

Knowledge transfer: Facilitating the exchange of experience and expertise between Members, for example through workshops, code sprints and hackathons organized alongside WMO events or in collaboration with partner organizations.

Visibility and discovery: Helping Members identify FOSS that is relevant to their needs by curating recommendations and maintaining awareness of available tools within the WMO community, drawing on existing registries and partner ecosystems.

Formal partnerships: Memoranda of Understanding (MoUs) with organizations such as OSGeo can provide a structured basis for collaboration on project governance, incubation and quality assurance.

Registration as Digital Public Goods: Key WMO FOSS implementations may qualify for registration with the DPGA, increasing their visibility and credibility within the broader international development community. The DPG Standard^[21] provides a structured quality framework covering licence compliance, documentation, privacy, and standards adherence.

Multilateral development partners: The UNDP and ITU, through their joint Open Source Ecosystem Enabler (OSEE) initiative, provide practical support to developing countries in establishing national open source ecosystems and Open Source Program Offices (OSPOs). This initiative represents a direct parallel to the OSPO model described in this guide, and presents an opportunity for WMO to partner with UNDP/ITU in promoting OSPOs across the meteorological and hydrological community. The World Bank maintains its own open source programme and has documented significant returns on institutional FOSS investment in geospatial and environmental data domains directly analogous to NMHS operations.^[22]

Joint events: Code sprints, hackathons and workshops organized in collaboration with partner organizations (such as OGC/OSGeo/ASF joint sprints or FOSS4G conferences) provide valuable opportunities for capacity building, community engagement and collaborative development.

Meteorological sector examples: The European Centre for Medium-Range Weather Forecasts (ECMWF) runs an annual open source innovation programme under the Copernicus Climate Change Service (Code for Earth),^[23] demonstrating how a major operational meteorological institution can embed FOSS practice as a core activity.

Regional digital innovation hubs: Regional digital innovation hubs, established in collaboration with Members, national and international development agencies, and regional organizations, can play an important role in the development and implementation of FOSS solutions, with a focus on meeting the needs of Members within a region. These could be co-located, or hosted, by existing regional centres. By enabling the development of regional communities around shared software solutions, FOSS can also support local service ecosystems, allowing expertise and associated economic value to be retained within the region rather than being dependent on external providers.