Community And Ecosystem
KEY RECOMMENDATION: Note how an open-source community generally follows a 'project archetype.' Communities and ecosystems around open-source projects are not all the same. Project archetypes describe these differences and can help you understand a project's dynamics, health, and sustainability. This is useful when assessing an open-source project for adoption or in creating your own open-source project, as these insights can help you set expections and plan investments.
EXAMPLE: The City of Paris' Lutece, an open-source platform for municipal digital services, largely aligns with the Controlled Ecosystem archetype, in which a 'benevolent dictator' (here, the City of Paris) manages the core platform that supports over 400 customized plugins created by cities and organizations accross the globe. A team considering adopting Lutece and working with a vendor to create several specific extensions wouldn't worry if the vendor hasn't contributed to the main platform but would look for contribution to several existing extensions as a sign of experience and competence.
KEY RECOMMENDATION Look for diverse resource-committing participants, which indicate stability, resilience, and growth potential for most project archetypes. Pay attention to diversity in areas like employers of contributors or of vendors providing support services, such as customization, deployment assistance, maintenance and operations, and training.
EXAMPLE: 55 commerical businesses provide a broad array of supporting services around the financial inclusion DPG Mifos, from custom development and hosting to business consulting and deployment support.
FUTURE WORK: It would be useful to do some more in-depth research on Mifos. Mifos has a lot of partners. On an initial look we didn't find a lot of them showing up in the public repository -- maybe we didn't know the right places to look, though. The development forum mailing list is pretty diverse, however, so on that basis it's fair to say the project has some diversity.
KEY RECOMMENDATION: Encourage commercial participation to improve a DPG's adoption and sustainability, but take care to foster diverse commercial actors and be wary of creating commerical opportunities that could permit unfair advantage.
EXAMPLE: The DPG Mojaloop publishes a list of consultants, systems integrators, training organizations, business operations supporters, and other solution providers, vetted against a published list of criteria. They also host open training, networking, and business development events to connect these commerical participants to new business opportunities.
KEY RECOMMENDATION: Consider how you might approach financial sustainability differently across your DPG's project stages. The sources and types of funding options might change as a project progresses.
EXAMPLE: Your agency might be able to cover seed funding, as was the case with the World Bank's Global Facility for Disaster Reduction and Recovery (GFDDR) with the GeoNode project. Philanthropic funds might help you pilot the project in particular locations, as was the case with the DPG DHIS2, or to scale, as was the case with the DPG OpenSRP. Charging for use might cover ongoing maintenance costs. For example, the DPG ODK is free as a self-hosted solution for offline data collection, but the organization also provides cloud-based hosting at different pricing tiers.
Understanding how to work with, participate in, and foster a successful open-source project is not just a matter of understanding the software at a technical level; it also requires understanding the motivations and interrelationships of the people and organizations who do make up the project. While we touch upon some aspects of finding or nurturing a broader DPG supportive ecosystem at the national level in the Appendix: Resources and Tools, this module provides guidance on understanding project-level open-source communities and ecosystems. The Adoptability module provides even more detailed recommendations for applying this understanding to evaluating open-source projects, including how to map a project's ecosystem. The Appendix: Resources and Tools also provides some insight into creating and nuturing an open-source community, but this is also a topic for future toolkit development.
FUTURE WORK: Are there unique lessons to be learned from community development around DPGs, which often function in more low-resource environments and target vulnerable populations that often can't easily become an engaged base of end-users? Is there a useful development model for DPG ecosystems with government, NGO, academia, and commercial actors?
DPG efforts run on the collective motivations of all of their participants. A healthy project often gathers around itself a diverse ecosystem in which many participants cooperate, each for their own reasons. Those reasons need not be the same. They might even be in tension or in outright competition with each other. open-source processes excel at enabling many parties with divergent interests to cooperate and create shared value.
We can refer to the direct participants in an open project as the project's community. In addition to that close community of cooperating participants, we find that successful projects gather a larger ecosystem around them. This ecosystem is centered on the community, and also includes related open-source efforts, users, integrators, clients, competitors, and stakeholders. Anybody who has an interest in the project's output and operations is part of the ecosystem.
Communities can contain governmental, commercial, or volunteer contributors, though the lines between these categories often blur. "Volunteer" contributors who aren't being paid directly for their work in a project often have a business interest in the output of the project. Similarly, commercial vendors might be participating as part of a government contract. Roles are fluid, and strictly labelling community participants can at times be reductionist.
What everybody in the community has in common is that they gain an advantage to pooling their resources: there's no reason for any one agency or firm to shoulder the entire burden of fixing bugs or developing new features when they all need the same bugs fixed and, for the most part, the same features developed. This common interest, built around a zone of cooperation, is the core of a project's community.
Wider ecosystems can also contain a diversity of participants from many different sectors. Even though most participants in the extended ecosystem of stakeholders do not directly contribute to a project, they help the project realize its value in the world. These stakeholders can include investors, NGOs, funders, end users, and even competing and adjacent efforts. They magnify the value of the investments made by direct participants. And of course, the best place to recruit new community contributors is from that wider ecosystem.
The import of all this value, investment, and mutual reliance is that successful DPG communities are usually built on mutual or collective benefit. Although it is certainly accurate to refer to this collective as a "community" -- it has social relations, cultural norms, status differentiation, informal debt relations, and all the other aspects of human communities -- it is not a community that runs on altruism. Even mission-driven participation is best understood as value-seeking (but not value-capturing) in open communities.
Project Archetypes
One of the most important skills for agencies exploring open source is understanding existing ecosystems and their project's place within them. In order to plan a project that builds on or collaborates with other open-source efforts, agencies must know their own projects and also know what to expect from other community participants. Again, the Adoptability module describes how to map a project's ecosystem.
Open-source projects operate in many different ways. Experienced open-source practitioners build nuanced open-source strategies by pattern-matching against other open-source projects. They use those patterns to understand their own projects as well as other open-source efforts around them. This understanding guides their expectations, decisions, and investments, such as how they approach adopting an existing open-source product or who they plan to recruit as new contributors to their own open-source project. Practitioners with a lot of experience have seen many different types of projects succeed and fail in all kinds of situations. Less experienced practitioners pattern match against a smaller set, which is to say they might have only one or a small handful of open-source approaches and find it difficult to perform nuanced analysis.
Mozilla identified this experience gap as a general problem in open-source and developed a set of open-source project archetypes to give practitioners more patterns to match against.
The purpose of these archetypes is to lead people away from generic open-source thinking and toward considering in more detail the behaviors and dynamics their open-source investment seeks to create. Each archetype tends toward typical strategies, and categorizing projects by archetype can help in predicting behavior. Similarly, where the strategies deviate, we can usually find deviation from the archetype too. The more specific you are about what you want from open source in your particular context, the more you will be able to look for patterns and practices in successful open-source projects that operate in similar contexts.
For example, in evaluating an existing open-source project, you wouldn't expect a "rocket ship" project to invest in supporting new contributors, and you'd want to plan any contribution and participation accordingly, bringing in vendors or your own personnel with some level of open source familiarity. Similarly, if you're planning to create your own multi-vendor infrastructure project, you'd want to invest in good API documentation early on.
A complete discussion of each archetype is available in Mozilla's report. Below are just their names and brief descriptions, from which one might draw some ideas of pattern each one represents. (A quick-reference chart is also available).
A note of caution: a given project won't necessarily fit perfectly into one of these archetypes, and a project might not reflect the same archetype(s) for its entire history -- transitions happen all the time. In some projects, one sees multiple archetypes at work or even different sets of participants pushing the project toward separate archetypal practices.
The project intends large-scale collaboration and is willing to slow down certain aspects of development in order to scale up the number of contributors, increase the diversity of contribution sources, and take more points of view into account. An example would be the Apache HTTP Server project. The DPG Apache Fineract, which provides core financial services functionality for the world's 2 billion underbanked and unbanked, might also fit here, or it could be viewed more as a controlled ecosystem (see below). Again, exact categorization isn't as important as how the exercise gets you thinking about a project's likely dynamics and ecosystem and what this might mean for your efforts.
The project is driven by a small, tightly-focused core team that knows exactly where it's going. If you want to go there too, you can get on board the rocket ship, but right now the project is not looking for (and will not stop for) discussions about alternative roadmaps, unplanned features, or unsolicited goals. This archetype is often found in funded projects that are in their early stages. An example might be the Signal messaging application, along with the DPG AIAgro.
The project is sponsored and largely driven by a commercial organization and is aimed at users who are also commercial organizations. The sponsoring organization may have a direct revenue interest in a product based on the project or may have a strategic interest (for example, undermining a competitor's product). Google's Android operating system is a great example here.
The project's goal is to provide a high-quality solution to a narrow and specific problem. Meaningful participation requires familiarity and expertise with that problem and with the project's solution. The libmp4 software library to handle MP4 files is an example.
When a number of commercial organizations share a common need, it makes sense for them to pool their resources into one open-source project that meets that need, rather than each one developing their own separate but duplicative solution. For example:Kubernetes, an open-source system for automating deployment, scaling, and management of containerized applications. X-Road's distributed data exchange is a DPG example here as well that's now managed by a consortium of government agencies.
An open-source project aimed at very broad user adoption. Mass Market projects often have commercial sponsorship of some kind, and if they are successful they tend to have fairly elaborate mechanisms to help steer potential contributors to the right place -- because even a tiny fraction of the user base trying to file bug reports or send in improvements can be overwhelming if you have millions of users. The LibreOffice open-source office suite is an example here, as is Mozilla's Firefox browser.
A project that serves as a dependency to a wide variety of other projects. Many of the common web-development Javascript libraries fit well into this archetype, for example. Their governance tends to be somewhat informal, perhaps because the variety of projects that depend on them serves as its own kind of constraint on decision-making, thus reducing the need for highly structured governance.
A commercial organization with unique expertise may sometimes maintain an open-source project that simultaneously serves to advertise that expertise, to maintain it, and to provide leads on direct or indirect sources of revenue. Interaction with these projects is sometimes equivalent to interaction with that particular vendor. The Coral web site commenting and community building platform is such an example, with Vox Media supporting the open-source project, using it on their own new web site, and making money through hosting, training and implementation help.
The Osano open-source cookie/consent management platform could be categorized here. It's open to contribution but largely maintained by the B-corp parent company Osano, which also offers a paid hosted version.This is most often seen with highly extensible software: a dominant company maintains the core project (and a corresponding product from which they non-exclusively derive revenue), surrounded by a satellite community of extension providers. Interaction with the core project can be very different from interaction with that extension ecosystem. Although the core development is usually dominated by the founding company, the extensions market place has often served as an incubator for other vendors who provide support, so the presence of the dominant player does not usually imply a monopoly on support availability.
The open-source WordPress web site builder is an example, where WordPress invests the most in developing the core platform but supports a range of indepdendent extension developers and professional services. The City of Paris' Lutece, an open-source platform for municipal digital services, is a controlled ecosystem project that supports over 400 plugins created by cities and organizations accross the globe. Estonia's DPG X-Road (now managed by the Nordic Institute for Interoperability Solutions (NIIS)) fits here, with its support for extensions, as does the DPG Primero.
The multi-faceted DPG Mifos and the DPG Apache Fineract are interesting examples of how a modular technical architecture (see Procurement module) can lend itself to having individual components run as quite different projects. It's also a good example of a thoughtfully phased approach to DPG development that's taken advantage of the existing global open-source ecosystem.
Apache Fineract's back-end core banking functionality and open APIs were originally developed by the non-profit Mifos (Micro Finance Open Source) Initiative to encourage the growth of microfinance institutions. Once Fineract's open-source core platform was stable, Mifos transferred the code to the Apache Software Foundation, a non-profit organization that hosts and fosters open-source products (as noted above, the Apache HTTP server is probably its most well known product). This cooperative division of labor let Apache Fineract develop on its own path - hosted by Apache, which has a track record of sustainable community development of enterprise-grade products -- while Mifos could turn its attention to more market-focused activities to reach the scale needed for global adoption of its 'out of the box' solution that's keenly focused on financial inclusion needs.
To do this, it created its own product built on top of Apache Fineract (a 'distribution' of the Apache Fineract code), called Mifos X, that's a complete 'off-the-shelf' solution, combining a web app (Mifos X Web App, formerly the Mifos Community App), a mobile app for field officers (Mifos Android), a mobile app for clients (Mifos Mobile), open-source Pentaho-based reports and a data import tool. Each of the Mifos extensions are also open-source DPGs. In this way, Mifos X is more of a controlled ecosystem, with extensions and customization around a core platform.See Commercial Participants below for more insight into how Mifos's extensibility helps them engage commercial partners to expand their market and reach. Assessing software extensibility is also covered in the Adoptability module.
A single person started the project, has maintained it all along, and either has not wanted to or has not been able to expand its developer base. (While this kind of open-source project definitely exists, it is perhaps overrepresented in writings and public discussion about open source.)
A project whose source code has been published under an open-source license, but which is now being ignored by its original authors. The code was thrown over the wall, as the saying goes, and it is there for anyone else to pick up if they want.
Identifying Archetypes In Your Community
The most common archetype we observe in the wild is the "Wide Open" project. This is normally what people think of when they imagine an open-source project. Wide Open projects take all comers and try to gather as much developer momentum as they can. They skew toward shared governance models and cultivate a welcoming, inclusive air. This approach is popular for a reason -- it's a pretty good default starting point for a lot of projects, especially government-led open source.
But not all projects fit that mold. Sometimes you want to build an open-source ecosystem and absolutely must retain a strong, controlling position to achieve the policy goals that drive your open-source work. In industry, we see that, for example, with Google's Android work. There, one company makes the majority of the investment and benefits by steering the majority of the mobile market to its products, services, and advertising network.
In Android's case, the additive value of individual additional contributors to the ecosystem is fairly low. It's not worth giving up control to gain those contributions. A Wide Open approach doesn't fit Google's strategic need. Instead, one can classify that project as B2B Open Source, which is a much less inviting model.
In government, we see this type of cautious approach around crucial infrastructure. Election infrastructure projects, for example, have a very high bar for participation and is only useful to government agencies and the vendors who serve them. Such projects might try to be Wide Open but will in practice tend toward a blend of the characteristics of multivendor infrastructure and specialty library.
Archetypes help us identify that Android is not like a stereotypical open-source project. They help us predict the dynamics around open-source election infrastructure. They allow us to see a project's actual behavior rather than the expected or stereotypical behavior. We can use archetypes to reveal something about a project's strategy to help us form credible expectations about how the project will behave in the future. It would be disastrous, for example, to build a product strategy that depends on being able to have any influence on Android's road map or feature set. Anybody who misidentifies Google's strategy on that point (and there have been a few) is defeated before they write a single line of code.
Although government agencies can expect to find the full range of archetypes among the projects it encounters, its own projects will tend to fall into just a few categories. Many government projects lean toward "Wide Open" dynamics, and that archetype is a good default starting point for consideration. Less often one finds "Controlled Ecosystem", "Multi-Vendor Infrastructure", and "Trusted Vendor" archetypes. All of these are candidates for projects led by or originating in government agencies, depending on strategic and policy needs.
There are other cases where archetypes help us understand the open-source world around us. In each case, the archetypes are a rough lens that leads us to clarify our view of a product's position.
The archetypes, though, are just a starting point for consideration. They are a useful start to analysis, but the conversation should never end there. If you view the archetypes as a set of slightly-more-specific generic game plans, you lose most of their value. The archetypes give teams a shared vocabulary for conversations that should eventually move beyond archetypal thinking. The archetypes are also simplifications. After all, a project's success will come in details much finer than a few archetypes could possibly capture. Every successful project grows because it is well-fitted to the particular needs of its contributors and users. As a project grows and adapts to its niche, its strategy and planning can and should move to a uniquely detailed view of its needs.
KEY RECOMMENDATION: Note how communities and ecosystems around open-source projects are not all the same. Their differences matter in setting correct expectations around likely project dynamics, health, and sustainability.
With an ecosystem map as background (see the Adoptability module),consider what project archetype might roughly fit the open-source project you're evaluating or that you plan to launch. Although these maps are inexact approximations that change over time, this is a key level-setting exercise for your team when assessing an open-source project or planning to create your own, and it should be periodically revisited.
Community Diversity
There are many ways to think about the diversity of an open-source project community. Do its contributors come from a wide variety of geographic or cultural origins? Do they represent a wide variety of skill levels? Do they represent a wide variety of usage patterns? Do they represent a variety of organizations and organizational needs? Does the project have diverse paths by which someone can contribute (e.g., coding, testing, documentation, bug ticket management, etc)?
Any of these dimensions of diversity may be relevant for adoption of a DPG, and its useful to think about what dimensions matter as you create your ecosystem map. However, we especially urge consideration of diversity of investment -- i.e., employer diversity among the various contributors, and diversity among vendors offering support services -- simply because these aspects of diversity are so often overlooked and yet are so important to the health and success of a DPG. This diversity is particularly important to projects that aren't speciality software libraries, although even there overreliance on one contributor type can be problematic. Note that it can take some sleuthing to figure out the backgrounds of contributors, who often use non-work related identifiers or even pseudonyms.
In considering diversity, including diversity of investment sources, it is useful to recall that participants tend to exercise control over a project in rough proportion to investment and to a lesser degree to reliance and benefit. Diversifying contributions will usually diversify the voices that dictate a project's direction.
Conversely, projects that over-rely on one provider of resources often find themselves at risk of over-fitting their products to the needs of that resource-dominant participant. This tends to depress contribution, which further concentrates investment. As projects retreat from open collaboration, they become more vulnerable to their one, dominant participant leaving the project or shifting direction.
This tendency for non-diversified projects to further centralize is often a risk for early-stage DPG projects. At the start of most projects, communities are not usually diverse. They haven't attracted enough participants to have diversity. Projects in this situation often find they have to invest in outreach and make special efforts to attract new participants.
FURTHER READING The World Bank's Open Data for Resilience Initiative + GeoNode: A Case Study on Institutional Investments in Open Source presents how the Global Facility for Disaster Reduction and Recovery (GFDRR) invested in a diversified set of partners, in part by using modular contracting (see also Procurement), ultimately creating a successfully self-sustaining open-source project.
KEY RECOMMENDATION Look for diverse resource-committing participants, which indicate stability, resilience, and growth potential for most project archetypes. Pay attention to diversity in areas like employers of contributors or of vendors providing support services, such as customization, deployment assistance, maintenance and operations, and training.
Community Health
The technology industry has been wrangling with how best to measure and understand open-source community health metrics for some time. There are frameworks that consider health from a comprehensive business ecosytem perspective, like the Open Source Ecosystem Health Operationalization (OSEHO) framework, and standardized contributor activity measurements created by the Linux Foundation's Community Health Analytics Open Source Software (CHAOSS) working group. Such contributor activity metrics are useful but can be insufficient to determining health without a deeper knowledge of the project's goals and type. For example, pull request efficiency might not be as important to a multi-vendor infrastructure type project as the rate at which partner contributors pick up high priority issues.
In the big picture, an open-source community's health and sustainability ultimately depends on the presence of a user base that needs the DPG and is willing, directly or indirectly, to invest in it. New contributors come from either those users or from the organizations that service those users; useful feature direction for the project's roadmap comes likewise from those users or their representatives; and bug reports -- the lifeblood of an active open-source project -- come ultimately from those users.
Some of these details can be gleaned from an open-source project's code repository. Unfortunately, the tools for analyzing metrics are complicated for decision-makers without some technical know-how. The CHAOSS working group does provide open-source software for running analytics on GitHub and GitLab, which are among most popular repository management services, as well as on issue tracking systems, but again, these take some know-how to use.
Still, even a novice can gain some useful insights by looking at activity over time in the bug tracker and the record of change, and this is often a fine enough way to roughly assess the health of a project community (and a note here that 'bugs' as referenced here are also known as 'issues').
What is the rate of ticket filings and the approximate number of unique filers? These two factors together are a proxy for the size and level of the user base.
How often do project developers respond in bug tickets? How well do they respond: are they constructive, both with users and with other developers in the discussion? Do the responses result in changes to the product itself?
Is it always the same developer, or small set of developers responding? Or is responsiveness well-distributed throughout the development team? Is there the diversity of developers and commercial participants you'd expect for the project type?
The rate at which bug reports are closed is actually not very important. In a healthy project with an active user base, bug reports are sometimes filed faster than the development team can close them. The important question is not rate of resolution, but how the project responds to and organizes the influx of reports.
A healthy project also has development spread across multiple developers. Exactly how many depends on the size of the project; it's not uncommon for a project to have a few very active developers doing most of the work, and then a "long tail" of other developers doing the rest. But the gentleness of that curve, from the most active developers to the least, tends to correlate with project health.
Moving up to a higher level of consideration, a project community tends to be healthier and more sustainable the greater the number and variety of its commercial participants. Depending on the project archetype, a lack of commercial participants isn't necessarily a sign of a languishing community, but the presence of engaged commercial participants does confirm that a project is creating clear value. There's the added concern of project overreliance on individual unpaid volunteers, who suffer high burnout rates. Of course, commercial participation can bring its own issues as noted below, including the potential to being prone to changing priorities more quickly than non-commercial participants. In fact, at least one open-source stewardship organization has a rule that it will only accept projects as members if there is a sufficient diversity of employers across the project's individual maintainers. Their logic is that if most of the developers in the project are employed by a single company and that company changes priorities, the project will be in immediate danger of folding.
Again, it is difficult to offer absolute numbers or base metrics that indicate whether a project is "healthy" or not. All the data gleaned from a project's bug tracker must be considered in the wider context of the rest of the project. Project metrics, especially as they change over time, are strong signals that add to the understanding of a project. They are not, however, very informative on their own.
There are two other relatively obvious tasks that should complement the quick glance at a project's bug tracker that we describe above. First, a little web surfing can take you to valuable project discussion forums, news releases, and other public information that can help you evaluate if the project has the level of community 'scaffolding' (documentation, clear governance processes, security vulnerability reporting) that you'd expect for such a project type and its maturity. Second, actually speaking to a variety of people involved in the project almost always leads to valuable insights.
RECOMMENDATION: To roughly assess the health of an open-source project, look at the bug tracker to understand the activity 'vibrancy' around the project. The bug tracker, along with other web resources like user forums, should also give you some insight into the diversity of developers and commercial participants. Diversity, the growth rate of adoption, and a well structured ability to respond to input are good markers of health and sustainability. The level of quality community 'scaffolding' around a project, such as documentation, should also fit what you'd expect for that project's type. And lastly, talking to a sample of diverse participants will also give you as sense for how the community is doing.
Community health, as outlined above, matters to DPGs because community health is the key to sustainability. Those who are investing in those DPGs should consider every action they take from a community health perspective. For example, when choosing between vendors, if one of those vendors is already highly dominant in the project community, it could be advantageous (from the project's perspective) for you to choose a different vendor -- assuming that vendor can competently provide the needed services -- in order to help equalize the balance of power between commercial actors in the project. Of course, procurement rules might require choosing the lowest bidder or include other decisive factors that run counter to community health considerations, but we're describing an ideal state here.
Note that many aspects of open-source project community health are also discussed, implicitly and sometimes explicitly, in the Adoptability module.
Non-Commercial Participants
Depending on the open-source project, there may be fewer or more non-commercial participants than commercial ones; it varies from project to project.
A "non-commercial" participant, in this context, can mean one of two things:
1) An organizational participant that is ultimately motivated by something other than profit.
2) An individual developer who contributes to the project but is not directly paid for that work.
Organizational non-commercial participants are usually NGOs (non-profit organizations) or government agencies. They are often motivated by equity concerns -- making sure the product is available and usable in contexts where it might not otherwise be -- or a desire to avoid having public data or public goods monopolized in a proprietary system (with the attendant risks of vendor lock-in, as described in the Adoptability module).
Such participants often act in the project through vendors, and the vendors of course have a commercial interest as well. In these cases, there can occasionally be conflicts between the two parties' motivations. For example, the NGO client may want an API capability that the vendor is reluctant to add because the presence of that capability in the open-source product would reduce the value of some proprietary offering of the vendor's.
There is no general formula for avoiding nor for resolving such conflicts. However, those selecting and deploying DPGs should be aware of the potential for those kinds of conflicts to arise. Mere awareness of the possibility may be enough to aid negotations and motivate early contract clarity.
Individual contributors who are not directly paid for their work are more often called "volunteers", but it is also reasonable to call them non-commercial participants. A volunteer's motivations may be connected to their current job or business interests, but if they are ultimately participating as an individual contributor and their participation is likely to persist across changes of employment, then they have a bond with the project that goes beyond their day job and their motivation can be said to be non-commercial. Every individual in the project usually has at least some non-commercial element to their participation. Even developers who work on the project full-time as their salaried job generally retain their community status in the project if they move from employer to employer.
It is worth noting that some DPG communities might confine themselves to non-commercial participants. Most DPG standard licenses allow commercial as a well as non-commercial use, but not all. While it is rarely useful for governments to create communities with such restrictions, agencies might encounter non-commercial communities in the course of their work.
The most frequent form of non-commercial DPG licenses are creative works publised under a Creative Commons license "NC" license. The "NC" stands for "non-commercial". Not all Creative Commons work is restricted to non-commercial use, so agencies should be sure to look at which Creative Commons license applies to materials they use.
In the case of open-source software, all commonly used licenses allow
commerical use, as noted in the Introduction.
In fact,
most community participants would classify software whose license
disallows commercial use as "not open source". The Open Source
Initiative (OSI) offers what many community participants agree is an
authoritative definition of open source, which excludes
software that discriminates against commercial use. All commonly-used
open-source licenses and most projects align on this point -- including the
DPG Standard.
At the same time, some open-source community members are offering "ethical source" licenses, such as the Hippocratic License. These licenses restrict the use of DPGs when their use might contravene various social values. Regardless of whether or not we call these licenses "open source", people working on DPGs in a government context might well come across DPGs that use these licenses. This is a space to watch, perhaps especially as AI adoption grows. For now, the DPG standard does not include any of these ethical-source license types.
FUTURE WORK: What are the additional ethical considerations specific to machine-learning models and their related data and working with children and vulnerable populations, and how are these best managed?
In considering commercial vs non-commercial communities, agencies should keep in mind that most jurisdictions have defined "commercial" in a clear way as it applies to open licensing. While governmental use would seem to be quite clearly non-commercial, in some jurisdictions, it might be less clear when vendors work on DPGs on behalf of government clients. This is something to clarify early in evaluating an open-source project.
Commercial Participants
All open-source software licenses, by the most common definition, allow commercial as well as non-commercial use of the software, and it is typical for open-source projects to have both commercial and non-commercial participants. Some individuals may even represent both types at different times.
Successful commercial participants tend to take a fairly long-term view of their participation. They are in the project because it enables them to provide some product or service, and that means that their future (for that product or service) is tied to the project -- which means that future is tied to the community, which means that their credibility with and relationships to others in the community have an economic value that goes beyond one day's bugfix or another day's feature request.
This economic value is understood as such quite literally by those participants. For example, when a company that is very active in an important open-source project is the willing target of an acquisition, it works with the acquirer to place a monetary value -- a definite number -- on its relationship to and influence in that project. That number is partly computed by looking at the individual employees at the target company who are active in the project, determining numbers for their participation in the project, and estimating their chances of staying on board after the acquisition.
Interestingly, this does not mean that those employees, who are members of the project community, are viewed with suspicion by other members. Everyone understands that each person is there for a reason, and commercial reasons are not thought of as better or worse than any other reason. As long as people act with care for the project's long-term interest, and their quality of work is high, their motivations might be useful context but are largely their own business.
Some open-source projects go even a step further. As a way to spur further investment by commercial participants, they undertake to create commercial opportunities for participants. Sometimes these opportunities tend to reward more active project participants. So long as these opportunities do not start to create monopolizable advantages, they can be effective ways to promote sustainability for some DPG efforts. (A review of an open-source project's governance documents, if available, can give you some additional sense of how well commercial engagement is steered towards the collective good.) For example, the DPG Mojaloop publishes a directory of consultants, systems integrators, training organizations, business operations supporters and other solution providers, vetted against a published list of criteria. They also host open training, networking, and business development events to connect these commerical participants to new business opportunities. And they have a reasonable, balanced approach to project governance; also see their FAQ and community discussions.
The DPG Mifos initiative knew they not only had to engage existing banking institutions to drive product adoption, but they also had to create opportunities for new, innovative, local companies that could deliver the 'last mile' for financial inclusion. A centralized, proprietary model could never support the innovation and scale needed to make their product useful and trusted across so many locales and domains. Open source made it easy for anyone to deliver a new financial service product simply by developing a new extension, creating a new application or packaged solution on top of the Mifos infrastructure, or by integrating Mifos with their own product. Mifos also invested early in developing local IT partnerships to help with implementating, hosting, and supporting Mifos X. Moreover, they turned users into active agents for innovation and adoption by establishing community chapters. These local volunteer organizations help communities use and shape Mifos to their particular needs, and they provide feedback to the main project (see the Appendix: Resources and Tools for how Mozilla supports a much less centralized set of localized volunteer communities around the Common Voice open data project).
KEY RECOMMENDATION: Encouraging commercial participation can be useful to a DPG's adoption and sustainability, but take care to foster diverse commercial actors and be wary of creating commerical opportunities that could permit unfair advantage.
Community Lifecycle, Longevity, and Sustainability
All DPGs have a lifecycle. That lifecycle may not be knowable in advance, but it will eventually become apparent. As a project matures, its rate of user acquisition slows down, the rate at which new contributors come in likewise slows down, and, in the long run, the rate of new feature development slows as well.
Projects that have an extensible design (see the the Adoptability module) often have a longer lifecycle, though this may be correlation rather than causation: longer-lived projects tend to become extensible, and innovation can continue to happen in the plugin ecosystem even after the software's core has remained stable for a long time. But, perhaps with rare exceptions, most software projects that last long enough eventually reach a stable state: either they address their problem domain so well that no further improvement is needed, or they are overtaken by some newer, nimbler competitor that was able to learn from its predecessors' mistakes and that does not suffer from the burdens of having an old code base that has accumulated technical debt.
An organization adopting a DPG should try to ascertain, to the extent possible, where in its lifecycle that DPG is. It is not necessarily a problem to adopt a DPG that is in the later, more static part of its lifecycle. Maturity has advantages: all the easily encountered bugs have already been fixed, and the tool's features reflect, at least to some degree, the accumulated wisdom of many users' real world usage. But one should not expect the project's community to be eager to add new features or have design discussions about complicated changes. At this point, the project may value stability relatively highly. If the DPG needs further work to be useful for a certain purpose, then that work may have to happen outside the current project community.
In this instance, some community members might decide to make what's known as a 'hard fork' (or 'social fork') of the project. This entails copying the source code and creating a separate open-source project that's able to develop in a new direction -- an action that's entirely impossible under a non-open-source code license. A well known example of a hard fork would be the creation of LibreOffice from the OpenOffice code base, which was a mass market type open-source project sponsored by Sun Microsystems. When Oracle acquired Sun Microsystems in 2010, it was clear to OpenOffice participants that OpenOffice's competitive alternative to Microsoft Office wasn't important to Oracle's business and would thus likely run into problems. So the OpenOffice community created a successful hard fork of OpenOffice and launched a new open-source product and community around it called LibreOffice. Another hard fork is the Mifos X platform described above, although that decision was based on sound business strategy and planning.
However, hard forks aren't always successful. They can be costly in terms of user confusion, potential legal wrangling over trademarks, and in-house and community resources, and they can harm community goodwill too. Forking a project to meet your needs should always be a last resort. However, agencies should be aware that this is an option for open-source projects that are at a stage of maturity in which the community has made it clear that stability is more important than new features. In these instances, if there is no other alternative project that suits an agency's needs, it might be reasonable to consider a hard fork, and you might find the project's community supportive of your new direction.
RECOMMENDATION: A 'hard fork' of a project to meet your needs should always be a last resort. Such an action might be appropriate for a mature open-source product in which there is community understanding of and support for your new direction, but this is a costly and fraught thing to do and would require thorough planning and foresight.
It's notable that content DPGs and software DPGs have different lifecycle dynamics. Software lends itself toward endless improvement. There's always a feature to add, a new library to adopt, or a new platform to move to. Some content sees high rates of reuse and longterm evolution, but a lot of content settles in to a final version and thereafter sees somewhat limited reuse. A Creative Commons-licensed novel, for example, might initially see revisions, a new edition, minor fixes to typos, but eventually the book is done. Somebody might make a translation or undertake a second edition, but the original work is readily identifiable as a "finished" artifact.
For software DPGs, it is also not necessarily a mistake to adopt an open-source product that is still in its early stages, when it is not completely stable and some of its basic feature set may even be in flux. But in that case, one must be ready to make the investment necessary to have one's needs met within a certain period of time -- either directly from one's organization or through a consultant or vendor. This can be a "virtuous circle" in some cases: other entities, on seeing a clear signal of investment, become more willing themselves to invest.
More specific recommendations around lifecycle and maturity in assessing a project's adoptability are covered in the Adoptability module.
A final note on sustainability. As noted, health -- and thus sustainability -- depends on whether a project is genuinely meeting the needs of its stakeholders, if it's thoughtfully set up to be responsive to changing needs, and if a well diversified set of stakeholders is engaged and contributing. In many project types, stakeholders should probably include a varied set of commercial actors.
There's also a related question of how DPGs can attract ongoing financial investments, what novel options are out there, and how these might be applied to the under-resourced area of maintenance.
Again, creating opportunities for private companies to commercially benefit is one option. The World Bank's Global Facility for Disaster Reduction and Recovery (GFDDR) used the power of modular contracting (see the Procurement module) to bring in multiple vendors to develop GeoNode, an open-source geospatial content management system. As adoption of GeoNode grew, many of these companies found new clients for their GeoNode expertise, which gave them an additional incentive to continue contributing to GeoNode and invest in its success (and this infusion of input from an expanded user base made the product better). Depending on local circumstances and regulation, agencies themselves might even be able to offer paid services around a DPG.
With GeoNode, GFDDR was able to stand up the early investment but scale back its commitment once GeoNode's broader comerical and non-commercial ecosystem gained strength. With the product's foundation set, GFDDR instead made incremental investments to resource features and new development it specifically needed. Open source's ability to support such incremental commitments can also be attractive to external funders.
However, fostering commercial engagement doesn't exclude other options. GeoNode also worked with universities, NGOs, and intergovernmental organizations. It's notable how the engagement of just one PhD student helped distribute GeoNode knowledge and expertise as he moved jobs between different agencies and organizations.
Long-term collaborations between government ministries and academic institutions are a possible answer to broad DPG sustainability. DPGs could be developed and maintained by universities -- sources of local talent that can also spin out new businesses -- with their implementation driven by government agencies, which have a "ground game" understanding of their populations and experience working with NGO partners to expand their reach. This is the model followed by District Health Information Software 2 (DHIS2), a DPG that aggregates and layers sector-specific health data. Here, research grants were thoughtfully linked to building the DPG. This model seems particularly promising when considering the problem of DPG discoverability and re-use by others -- instead of more "wheel inventing" -- as academic institutions and governments already have collaborative networks and relationships that can be leveraged together. Philanthropic grant programs fit well here too.
Collaborative financing is also an option, as NORAD helped bring to the Modular Open Source Identity Platform (MOSIP). A university team did directly support MOSIP, but the collaboration was limited, so outside funding from the World Bank's Identification for Development (ID4D) rounded out the financial needs. Collaborative financing can be managed through intergovernmental organizations, like the World Bank, or through an NGO, like the PATH. PATH created the Digital Square effort to coordinate investments from over 40 wide-ranging donor types -- including government agencies, intergovernmental organizations, universities, private foundations, and private companies -- to improve how the global community designs, uses, and pays for digital health tools and approaches.
Pooling financial and personnel resources across agencies to create a DPG is also an option, although it can take a lot of upfront investment to identify internal partners who share your problem and are willing to collaborate to solve it. Each agency might hold tight to a set of features it believes are paramount and not see the value of collaborating to get to an 80% solution that they can then refine. However, solving shared problems while permitting flexibility for differentiation is core to the open-source approach, as well as to modular architectures and extensibility (see Procurement and Adoptability modules). Still, the benefits of inter-agency collaboration is precisely why centralized digital services agencies are often at the forefront of government digital transformation. In some instances, these might be areas for the lower-risk open-source experiments we recommend for building skills and capacity (see the Open Source Readiness module.)
Social impact bonds (also known as development impact bonds) are another method of bringing private capital to the creation and maintenance of public goods. By definition, they seem like they would help bring more funding to the long-term maintenance needs of DPGs. They've received a lot of attention and some uptake, but to our knowledge, this model hasn't been used by a DPG.
Social impact investment funds take varied shapes and can function like venture capital (like the UNICEF Venture Fund), private equity, or a community development financial institution. These can be a great resource for helping to develop local commercial suppliers and talent.
A tax or a precentage of revenue from the sale of public assets, such as from bandwidth allocation, could fund DPGs. This revenue could be distributed with a focus on maintenance of successful DPGs. A tax on private development projects is a similar option, like the "percent for art" programs that require private developers to allocate a certain percentage of the project's budget to creating and maintaining public art. For some countries, creating a new tax on a company's IPO value could ensure capital gains help to pay for existing (and future) public infrastructure that created the conditions for the company's existence.
Direct crowdfunding and sponsorship might also be a viable financing option in some cases. GitHub recently launched GitHub Sponsors to let individuals and companies donate directly to GitHub-hosted open-source projects.
Lastly, charging for use might be an option as well. For example, the DPG ODK is free as a self-hosted solution for offline data collection, but the organization also provides cloud-based hosting at different pricing tiers. Infrastructural components of some DPGs might lend themselves to a revenue-generating model for commercial implementations to support free non-commercial implementations. The DPG Project AEDES, a portal that predicts dengue hotspots from climate, search, and satellite data, plans to create a social enterprise around different prediction services by incorporating other risk frameworks. The new social enterprise would offer subscriptions to the insights.
FUTURE WORK: How could government agencies play a role in enabling innovative financial investments in DPGs to help with sustainability? Are some financing methods -- or collection of methods -- more suitable to particular areas and applications? (e.g. improving health versus monitoring climate change impacts?) What are the pros and cons of these methods? What patterns might we discover when more DPGs are created and deployed?
The most important take-away is to think about your DPG's financial sustainability from a project lifecycle viewpoint. Early design and feasibility work might be funded through research grants to a partner academic institute. Seed funding might be at a low enough threshold for your agency to cover, as it was for the GFDDR with the GeoNode project, or you might complement your investment in an external vendor with funding from a social impact investor. Philanthropic funds might help you pilot the project in particular locations, as was the case with the DPG DHIS2, or for scaling, as was the case with the DPG OpenSRP, or for capacity, as was the case with the Bill and Melinda Gates Foundation funding a community manager for the DPG Mojaloop. The DPG Primero is a collaborative effort across aid organizations and agencies that started with initial seed funding of $1.5 million from the United States Agency for International Development's (USAID) Office of Foreign Disaster Assistance (OFDA) and the United States Center for Disease Control (CDC). Ongoing platform development costs are funded by UNICEF, while countries fund the costs for customizing the platform to their specific requirements. Training and ongoing maintenance costs might be linked with existing investments or new grants to local academic institutions to improve digital skills and build the local workforce.
KEY RECOMMENDATION: Consider how you might approach financial sustainability differently across your DPG's project stages. The sources and types of funding options might change as a project progresses.