Call for Feedback: Draft Maturity Indicators & Assessment Methods for DPGs

[PelinSmines]

Call for Feedback: Draft Maturity Indicators & Assessment Methods for DPGs

Dear DPG Product Owners, Members, and Contributors,

As part of our joint effort to define a domain-agnostic maturity framework for Digital Public Goods, the Digital Public Goods Alliance—together with partners like UNICEF, FAO, and Digital Square—is co-developing:

1. A standardized set of maturity indicators applicable across DPG types
2. A flexible assessment method (e.g. scoring, readiness statements, or maturity levels) that helps DPGs identify strengths and growth areas

---

1. Indicators

We’d love your input on:

• Are the proposed indicators clear, relevant, and universal across different DPG types and domains?
• Do they strike the right balance between:
  • Technical maturity
  • Community health
  • Governance
  • Impact readiness?
• Are there any indicators that are unclear, or redundant?

👉 _View the draft indicators here:

2. Assessment Method

We also want your thoughts on how to assess maturity:

• Should the framework offer numeric scores, descriptive levels (e.g., “emerging”, “established”), or narrative maturity statements?
• Should it help teams build roadmaps toward maturity over time?
• How can we ensure that assessment feels supportive and collaborative, not evaluative or competitive?

How You Can Contribute

• Comment below with suggestions
• Share feedback on gaps, additions, or examples
• React to other comments to signal agreement or priority
• If you’ve used a similar framework for your DPG, let us know what worked

⏰ Feedback deadline: October 3, 2025

After this, we’ll compile the input and move into drafting the first prototype of the assessment tool. Your contribution will be acknowledged in the final version.

Thanks for helping shape this important tool for our shared ecosystem!

— The DPGA Maturity Framework Team

[csmlo]

I think that the proposed indicators in the draft appear to be generally clear, relevant, and designed with universality in mind, making them applicable across different DPGs and domains. Each indicator is organized under well-defined pillars such as governance, data protection, open standards, product strategy, source code accessibility, total cost of ownership, and composability which are foundational aspects relevant to a wide variety of software projects.

The use of progressive maturity levels, I think allows for nuanced assessment regardless of the DPG’s scale or context. While the descriptions are concise and the indicators touch on universally important themes like transparency, security, interoperability, and sustainability, some indicators could benefit from more detailed definitions or examples to ensure consistent interpretation across diverse sectors. Overall, I believe the structure encourages adaptability and relevance, supporting broad applicability while maintaining clarity for contributors and evaluators alike. Would love to hear opinions from the community as well!

[NilHomedes]

Hi all! Thanks for all this awesome work DPGA team, these indicators are very needed and for us would be very useful 💯
I think most of the indicators are relevant and clear. My two cents to improve it:

Regarding Governance:
It seems we are only measuring the fact of having clear rules. But we are not assessing how democratic a governance model is. For example, a classic Benevolent Dictatorship model would rate "High" if they had clearly documented their model. My question is: Are we going to give the same governance rate level to a Benevolent Dictatorship model than to a democratic model? I would say no, this is not only about how clear rules are within a community, it is about the real power that the community have to participate and define the project evolution.

I feel there is something very important that is missing in the pillars: Measuring the bus factor.
It is not the same having a FLOSS project maintained only by 1 person who have more than the 90% of the total commits, than having a project with a plurality of maintainers. A FLOSS project is more mature as its bus factor is lower. Having a diverse group of maintainers gives a project more resilience to changes.