Read: 2025 DPG State of the Community Report (SCoRe)

DPG SCoRe 2025 report_Webinar Release.pdf

Google Docs

However, like any other open-source project, long-term sustainability of DPGs is heavily reliant on the presence of healthy, vibrant, and engaged developer communities that can help improve product quality, foster innovation, transparency and help DPGs reach their full potential and achieve widespread adoption.

Long-term sustainability of FOSS projects, and especially DPGs, also relies on a broad and steady stream of funding. Because DPGs are FOSS projects that target Sustainable Development Goals (SDGs), it is a no-brainer for Nation-States, CSR, and granting agencies to allocate funding to such projects.

System Integrators (SIs) are essential multipliers for DPI adoption, leveraged by 74% of DPGs. Majority of respondents principally align with a vendor-neutral approach and encourage a community of SIs for a more localized adoption.

Additionally, a few DPGs rely on for-profit implementation partners ("System Integrators") to "deploy" and maintain the products/services for end users. In such instances, the implementation partners should be expected to contribute back to the DPGs, financially or otherwise.

Drupal formalised a tiered Certified Partner programme that ties vendor visibility to verified contribution credits based on upstream contributions, event sponsorships, etc. Partners achieve 1 of the 6 tiers - Bronze, Silver, Gold, Platinum, Diamond or Top Tier and get benefits related to adopter visibility, events & networking, and access to exclusive programs. It also provides an adoption pathway for institutions that prefer SIs with demonstrated upstream stewardship. Financially, the model diversifies Drupal Association’s revenue through tier-appropriate sponsorship. The model is portable to other DPGs where a foundation can define contribution weights, maintain a public directory of service providers, and separate certification from procurement decisions.

Relying on the free labor of a developer community, no matter how "healthy, vibrant, and engaged", is not a sustainable long-term strategy. Drupal is a great case study for a vibrant and supportive partner ecosystem.

C1. Lack of time is the biggest barrier to open-source contributions, followed by project discovery, lack of financial incentives, and inadequate documentation.

I don't believe that "Lack of time" is an accurate representation of the underlying problem. "Lack of perceived value" might be closer to the underlying truth. You get closer to the real answer when you add "project discovery" being the second "biggest barrier" with "skill development", "career opportunities", and "networking" as key motivators. Let's start by looking at the two prominent pathways by which people end up in FOSS communities.

Most students and early career professionals realize that textbook/classroom learning isn't sufficient in a workplace. Few are able to motivate themselves to build projects, fewer have the consistency and persistence to push beyond a "toy project" stage. Therefore, most people look for existing projects that they can contribute to. Given the popularity of FOSS at the moment, people end up looking to contribute to FOSS projects, projects that might not be relevant to them personally or professionally. "Skill development" and "career opportunities" are the usual motivator for these group of people, and the resulting "networking" thanks to their association with a FOSS community.

Unlike the majority, a small group of hackers and tinkerers end up in the FOSS ecosystem. This is because investigating and participating in a FOSS project that they use is a natural extension of their interest in tinkering. These folks have a natural edge over the majority because they are self-motivated to tinker and they are personally invested in the FOSS project as users. "Skill development", "career opportunities", and "networking" naturally follow because of their participation in a FOSS community but these are not the motivating factors.

Please note that I am not making a value judgement - there is no right or wrong path. But it's important to understand the paths that people to take in order to understand what motivates and sustains them.

For the majority, contributing to FOSS projects is a goal, and not a journey. Once sufficient "skill development" is achieved and "career opportunities" are unlocked, their participation in the FOSS ecosystem will likely wane. With new jobs come new skill interests and time constraints, causing them to drop off. For the hackers and tinkerers on the other hand, contributions to FOSS projects is a journey. The journey has good times and bad times, depending on their life, but their participation in a FOSS community usually spans job or career changes. This fact is demonstrated by an interesting observation in the report

Only 7% of seasoned contributors (> 5 years of Open-Source Experience) switch repositories every 3 months, when compared to 68% of emerging contributors (< 5 years of Open-Source Experience)

This feels like a classic case of survivorship bias - only a fraction of the emerging contributors end up as seasoned contributors, and, in my understanding, seasoned contributors become seasoned contributors because they found a project that they are invested in, irrespective of "skill development" or "career development" possibilities.

Seasoned Contributors are much more likely to report bugs (80%) and answer community questions (70%), indicating their willingness to give back and support in strengthening the product and community further.

The early years of FOSS contributions are hard-skills heavy, i.e., software development concepts and principles, whereas the later years of FOSS contributions are soft-skills heavy, i.e., effective async communication, task prioritization and delegation, mentorship and community building.

362 individual developer respondents participated in the survey. Out of which 30% (110) do not contribute to open source, while 70% (252) contribute to open source. The 70% Contributors to open source were segmented into 2 cohorts: Emerging Contributors (60%), Seasoned Contributors (10%)

Based on the respondents of this survey, for every six emerging contributors, there is one seasoned contributor. In my personal understanding, given the employee turnover at for-profit enterprises, they are underinvesting in mentorship and growth of early career professionals, and this responsibility has been shifted to the overworked and often free labor of FOSS communities.

Please note that I am not advocating for people to pick a FOSS project and stick with it for the rest of their lives. Peoples' interests and priorities naturally change over time. But existing messaging in the broader FOSS ecosystem about the "Skill development", "Career Opportunities", and "Networking" benefits of FOSS contributions are harmful to the long-term sustainability of the FOSS ecosystem, especially when there isn't a long-term emphasis on understanding and internalizing the underlying philosophy of contributing to a Digital Commons.

For Seasoned Contributors, the three main motivators are skill development (84%), recognition (50%) and a sense of community belonging (47%).

There is something innately tribal about contributing to a Digital Commons, leading to "a sense of community belonging". Personally, I believe that religious identity fading in many countries is correlated with an increased interest in wanting to belong to a Digital Commons community.

For Community Champions, faster development (100%) is the top priority, followed by increased sustainability, improved product quality, accelerated adoption, and innovation & fresh ideas.

DPGs need to transition from "building in public" to "driven by the public", i.e., the top priority needs to be "feature definition and prioritization" driven by engagement with the public, which naturally leads to the other priorities listed above because it leads to a leaner product.

Lack of mentorship bandwidth is the common biggest barriers in managing contributions for both Community Champions and Aspiring Builders.

I wonder if this is a meaningful problem that can be delegated to GenerativeAI. For instance, using GenerativeAI to create project/product documentation. Mentorship in FOSS projects usually involves helping a new contributor understand the codebase, understand the scope of an issue, and helping them identify where code changes should be made for particular issues - which a GenerativeAI coding assistant might be able to help with.