Skip to content

Digital Impact was created by the Digital Civil Society Lab at Stanford PACS and was managed until 2024. It is no longer being updated.

Building a Better BRIDGE: Open Infrastructure for the Social Sector

MFG Archive

Powered by Data's Michael Lenczner explains why open access and interoperability should be hallmarks of the BRIDGE registry for global nonprofits.

I’m surprised to be writing this piece. I’m surprised because a public-interest technology project led by Foundation Center, GlobalGiving, GuideStar, and TechSoup — and supported by luminary funders like the Bill and Melinda Gates Foundation and the William and Flora Hewlett Foundation — doesn’t seem like it should be a source of concern. And yet the BRIDGE project has become precisely that.

BRIDGE is the Basic Registry of Identified Global Entities. In layman’s terms, it’s a system to identify every nonprofit organization in the world. That’s a laudable goal: unique identifiers are a key piece of data infrastructure that can enable all sorts of information sharing and new analysis.

Despite the expertise and good intentions of these organizations, BRIDGE has some serious flaws. As it is currently structured, the project stands at odds with both technical best practices and some of the social sector’s values.

Who owns this BRIDGE?

The core concern with BRIDGE is that it’s proprietary: the system and all of its data belong to the four partner organizations.

This is a topic Powered by Data has written about before. BRIDGE broadly emulates the model of Dun & Bradstreet, a company that operates a similar registry for businesses. They provide unique identifiers, called DUNS numbers, to track companies for things like credit reporting. That model works well for Dun & Bradstreet, since being the gatekeeper is a lucrative business, but we see a few problems with emulating it.

First of all, the “gatekeeper” model doesn’t seem appropriate for the nonprofit sector. We don’t see why a data resource about nonprofits should be closed and privately controlled. Although the project partners have said that “public use” of BRIDGE will eventually be allowed, it’s not clear when that will happen or what level of access other organizations will have. Meanwhile, all access and control reside with the partner organizations.

The proprietary model also doesn’t have a great track record. Gatekeepers tend to make decisions that serve their own interests, which in turn breeds frustration and resentment among users. DUNS, for example, has come under fire from the U.S. Government Accountability Office for its high costs and severe restrictions on data use. It has become the subject of organized pushback, including a #dumpDUNS hashtag on Twitter.

Frustrations with DUNS have even spawned an open alternative called OpenCorporates. In an ironic twist, OpenCorporates is supported by the Omidyar Network, who actually helped incubate the idea for BRIDGE. It seems strange that BRIDGE has chosen to emulate the DUNS model, rather than the OpenCorporates model, for the nonprofit sector.

Who can use the data?

Many of these concerns are related to the licensing of data. That is to say, who is allowed to use the data in the registry? And for what purposes?

Although BRIDGE was first announced to the public three years ago, those questions remain unanswered. We still don’t know if or how data about nonprofits will be licensed to the sector itself.

The best-case scenario would be adoption of the Open Database License for BRIDGE to ensure that there is long-term clarity about how the data can be used. The worst-case scenario would involve BRIDGE emulating the DUNS approach, where the very ID numbers it assigns to organizations are copyrighted information — meaning you must get permission (which often involves making a payment) to use the ID numbers in any context.

That kind of license hinders innovation. Anyone who is creating an app or digital tool for the nonprofit sector could benefit in some way from using ID numbers. But if they have to pay — or even just request permission — every time they want to use those ID numbers, they’re less likely to incorporate them at all. Even if no payment is required, the uncertainty and restrictions that come with a closed license create barriers to interoperability.

Who makes the decisions?

These concerns point to the broader issue of engagement: is BRIDGE doing something with the social sector, or to the sector? There’s nothing wrong with covering your costs and having a business model, but for a social initiative to be credible, there must be some level of consultation and community engagement in key decisions.

From an international perspective, it hasn’t felt that way. BRIDGE may have “global” in its name, but it seems to operate as a closed project of four U.S.-based organizations. I can’t speak for other countries, but BRIDGE didn’t undertake any kind of meaningful consultation with Canadian stakeholders — even though Canada has been recognized as a global leader in charitable sector data.

The project’s FAQ page includes the following question: “I have an idea for how to use BRIDGE for something really cool. Whom do I talk to?” Though it’s a nitpick, I think it’s telling that the answer directs people to a generic “contact us” form, and says “we might work together in the future.” That’s hardly meaningful community engagement, and it leaves one wondering, “Who exactly is BRIDGE?”

Building open infrastructure

Members of the Stanford PACS community have led the way in articulating the need for ethical principles to guide civil society’s use of data. This is why I wanted to start this conversation through Markets for Good, which helped incubate some of the ideas behind the BRIDGE project.

As someone who is passionate about using technology to help the social sector, I’m excited to see us building data infrastructure. I want to see an excellent, open version of BRIDGE. But I don’t want to see us repeat the mistakes of other sectors — and in this case, that means BRIDGE needs significant changes to how it is structured and how its data is licensed.