Summary As proposed, the Cloud and AI Development Act (CADA) does not rely on vague policy statements to gauge open source success; it establishes a concrete, data-driven framework for measurement. Progress is quantified through two specific Key Performance Indicators (KPIs) tied to the EU Open Source Solutions Catalogue: the "number of public sector solutions released as open source in the repository" and "their downloads by third parties." These metrics, defined in the proposal's Legislative Financial and Digital Statement under Specific Objective No 4, transform open source from a voluntary aspiration into a measurable component of the EU's digital sovereignty strategy. For public bodies, this means that releasing code is no longer just an internal decision; it must be published via connected repositories to be counted, tracked, and used to demonstrate the reduction of duplication and vendor lock-in.

Detail

The measurement of open source progress under the proposed CADA is deeply integrated into the regulation's demand-side measures, specifically within Title IV, Chapter V (Articles 41–44). The framework represents a strategic shift: rather than merely encouraging the adoption of open source, CADA mandates the infrastructure required to track the entire lifecycle of public sector softwareβ€”from development and release to reuse and impact.

The Centralised Measurement Infrastructure

The cornerstone of this measurement system is the EU Open Source Solutions Catalogue (referred to in Article 43). As proposed, the Commission is obligated to provide and maintain this catalogue as a centralised access point for software made available for reuse by Union entities and public sector bodies. The catalogue is hosted on the Interoperable Europe portal, ensuring that solutions are not only discoverable but also linked to relevant training and interoperability information.

Crucially, Article 42 establishes the mandatory connectivity required for measurement. It stipulates that when a Union entity or public sector body makes software available for reuse under an open-source licence, it must do so using a catalogue or repository that is connected to, and made accessible through, the EU OSS Catalogue.

This technical requirement is the foundation of the metric. Progress cannot be accurately measured if software remains in isolated, disconnected internal repositories (e.g., private GitLab instances or unconnected public GitHub repos). By forcing connectivity to the central catalogue, CADA creates a unified dataset where the Commission can aggregate and track:

  1. Volume of Release: The precise number of distinct software components, applications, or solutions published by public bodies across the Union.
  2. Discoverability and Accessibility: The metadata quality and ease of access, as the catalogue is designed to be a "one-stop-shop" for open-source resources.

Key Performance Indicators (KPIs) for Objective 4

While the enacting articles of CADA establish the legal obligations to release and connect software, the specific quantitative metrics for evaluating the regulation's success are explicitly outlined in the accompanying Legislative Financial and Digital Statement.

Under Specific Objective No 4β€”which aims to "contribute to the protection of public order by enhancing the resilience of supply of cloud computing services, in particular in the public sector"β€”the proposal lists the following indicators of performance:

  • "Number of public sector solutions released as open source in the repository"
  • "Their downloads by third parties"

These two metrics form the core of the "open source KPI metrics" under CADA. They are designed to move beyond simple compliance (i.e., having an open-source policy) to measuring actual economic and technical impact.

  • Supply Metric: The "number of solutions released" tracks the willingness and capacity of public bodies to share their investments.
  • Demand Metric: The "downloads by third parties" tracks the actual uptake and reuse of these solutions.

High download numbers indicate that public sector developers are successfully leveraging existing solutions rather than building from scratch, thereby directly reducing duplication costs and fostering a more competitive, innovative ecosystem.

The Role of the OSPO Network in Measurement

Measurement under CADA is not solely an automated data exercise; it also relies on human governance and standardisation. Article 44 establishes a network of Open Source Programme Offices (OSPOs). While the primary tasks of the OSPO Network include facilitating the exchange of information, best practices, and contributing to guidance on licensing and security, they play a critical role in the qualitative reliability of the measurement.

By standardising how public bodies handle open sourceβ€”ensuring that software is properly licensed, documented, and prepared for reuseβ€”the OSPO Network helps ensure that the data fed into the EU OSS Catalogue is consistent and high-quality. This standardisation is essential for the KPIs to be meaningful; without it, a "release" might be an unusable code dump, rendering the "download" metric misleading. The network thus acts as a quality assurance layer for the measurement infrastructure.

Measuring Reuse Uptake

The proposal explicitly emphasizes that the ultimate goal is not just publication, but reuse. Article 41 mandates that the Union and Member States take measures to "encourage and facilitate the reuse of open standards and components released under an open source licence."

The effectiveness of this encouragement is directly measured by the "downloads by third parties" metric. This metric serves as a proxy for:

  • Reduction of Vendor Lock-in: High reuse suggests that public bodies are not dependent on a single proprietary vendor for specific functionalities.
  • Cost Efficiency: Reusing existing solutions avoids the costs of re-development.
  • Interoperability: Solutions that are downloaded and reused across borders demonstrate successful interoperability, a key goal of the Digital Decade.

Furthermore, Article 32 on Union added value in public procurement requires contracting authorities to include non-price award criteria evaluating the tenderer's contribution to the European cloud and AI ecosystem. While not a direct "open source" metric, this criterion often aligns with open-source adoption, as the use of open standards and components is a primary way to demonstrate such contribution.

What this means for you

For public-sector procurement officers, IT directors, and software architects, CADA introduces a new layer of accountability regarding how you manage, release, and report on open-source software.

  1. Connect Your Repositories Immediately: If your authority develops or commissions software that you intend to reuse, you cannot simply host it on an internal GitHub or GitLab instance that is invisible to the wider public sector. Article 42 mandates that you must ensure your repository is connected to the EU OSS Catalogue. This may require technical integration efforts to ensure metadata is harvested correctly and that the software is accessible via the central portal.
  2. Monitor Your Impact: You are no longer just a publisher of code; you are a contributor to a shared ecosystem. You should actively monitor the download metrics of your released solutions. High reuse rates demonstrate the value of your investment in open source and contribute directly to the EU's strategic autonomy goals. These metrics will be aggregated at the EU level to assess progress against Specific Objective No 4.
  3. Align Procurement with Reuse: When procuring new cloud or AI services, you are expected to include non-price award criteria that evaluate the tenderer's contribution to the European ecosystem (Article 32). This includes evaluating the use of software or hardware designed or manufactured in the Union. While not a direct "open source" metric, this criterion often aligns with open-source adoption, as open standards facilitate interoperability and reduce dependency on single proprietary vendors.
  4. Prepare for Reporting: Be prepared for reporting requirements. Member States must monitor their procurement of innovation in cloud and AI and report on SME participation and other metrics (Article 33). While open-source reuse is tracked via the catalogue, your internal processes for identifying which software qualifies for release and how it is licensed must be robust to support this broader reporting framework.

Common misconceptions

  • Misconception 1: "Open source progress is measured only by the number of lines of code released."
    • Correction: CADA focuses on solutions and reuse. The key metrics are the number of public sector solutions released and their downloads by third parties. The volume of code is irrelevant if the software is not discoverable, usable, or actually downloaded by others.
  • Misconception 2: "I can release software on any public platform and it will count toward CADA metrics."
    • Correction: Article 42 specifically requires that software be made available through a catalogue or repository connected to the EU OSS Catalogue. Isolated public repositories (e.g., a standalone GitHub repo not linked to the central catalogue) do not feed into the centralised measurement system established by the Commission and will not count toward the official KPIs.
  • Misconception 3: "CADA mandates that all public sector software must be open source."
    • Correction: Article 41 states that the Union and Member States shall take measures to encourage and facilitate the reuse of open standards and components. It does not impose a blanket mandatory open-source requirement for all software development. However, it creates a strong incentive structure through procurement criteria and reuse mandates for software that is developed with public funds and intended for reuse.
  • Misconception 4: "The OSPO Network will set the technical standards for my code."
    • Correction: The OSPO Network (Article 44) facilitates cooperation and exchanges best practices. It contributes to guidance on licensing and security, but it does not dictate the technical architecture of your software. Its role is organizational and strategic, helping to ensure that the metrics collected are meaningful and that barriers to reuse are identified and removed.

Official sources

Related

This is general information about a draft EU regulation, not legal advice.