In early 2020, several longstanding NTEN members and community leaders created the first iteration of the NTEN Equity Guide for Nonprofit Technology. I was privileged to be a part of the endeavor, and it felt both like a capstone experience in my long association with NTEN, as well as the launch point of a new perspective on what it means to serve nonprofits with technology.
At its heart, the Equity Guide makes requests of two audiences: nonprofits that are engaging with technology at the staff, leadership, and application development levels; and the commercial technology industry that serves nonprofits with products, services, and solutions. These requests are rooted in transparency, inclusion, efficiency, and leveling longstanding power and privilege dynamics.
A very clear point that the data use section of the guide makes involves data for nonprofits — ownership, control, location, privacy, and accessibility. This section calls to attention that nonprofits, as an ecosystem, require broad agency over their data to best serve their constituents. Nothing is more critical to nonprofits than their data, composed of donors, constituents, and operations information. Maximizing data availability for nonprofits maximizes nonprofits’ ability to serve their constituents.
Globally, nonprofits store their data inside software applications and platforms, small and large. These technology tools frequently create ecosystems of users and businesses that either implement them or create integrated software tools. While technology for nonprofits is a win for nonprofits, a question exists about what shapes this technology’s development. Is it actually nonprofit customer needs, or is it other factors in the market?
Factors like a platform’s business partnership programs for implementation and integration companies, software platform sales goals, API availability, software development roadmaps, and revenue models behind these platforms all contribute to how much choice nonprofit customers actually have, and even how much of a monoculture of influential business partners and integrated applications exist around a software platform. Many of these factors are beyond nonprofits’ ability and the global impact economy to influence.
Maybe this is OK. Maybe it’s enough, but it’s important to note a trade-off here. Large data platforms, especially those that make donations of products and services, are putting high-powered software into nonprofits’ hands at a fraction of the cost that would ordinarily reflect on commercial customers. This is genuinely a good thing. The downside is that if nonprofits can’t always influence the sales models and goals, development roadmaps, business partner incentives, API and integration availability, and so forth, how do we ensure that these commercial tools aren’t permanently creating large ecosystems of users without direct priority in software development that ultimately hinders the global nonprofit ecosystem’s ability to define its own priorities and equitable data access?
Given the high costs to nonprofits of data migration between platforms, organizational change, technology management, and crossing the digital divide; let alone factors such as nonprofit staff turnover and funding sources for technology in the first place, are we just repeating the same system of transactions that drove nonprofits from paper to computers, computers to servers and networks, and servers to cloud software? The Equity Guide is written with an aspirational outcome that the nonprofit sector can adapt, innovate, employ technology at scale, retain ownership of its data, and allow for ad hoc and planned innovation.
“Innovation” is a heady word. It’s used here to mean the global impact economy’s ability to exercise even greater agency in its use of existing and emerging data tools, platforms, and applications as seamlessly and economically efficient as possible. The authors of the Equity Guide, myself included, believe that nonprofits are always empowered by broader software choices. This choice in the market can run counter to the relationships between nonprofits and large software companies and their ecosystems. What if a competitor’s tool is simply better? Should an organization leave one platform ecosystem for another to take advantage of it? What if a nonprofit’s data is contained in several applications and services from competing ecosystems? Should an organization invest in expensive middleware, integrations, or business intelligence tools to get the data-driven outcomes it needs to meet its mission?
This goes well beyond looking at the difference between, say, applications that run on Android and iOS. While these are different platforms, software developers have accepted that their applications run on either must create ease of moving customer data. Otherwise, I could never see or use the notes I create in Evernote on my iPhone anywhere else but there. But this is what large software platforms do with nonprofit data. They keep it in structures that serve each platform and compel software developers to build integrations and connections (or not) so that their independent companies can sell in multiple markets. It’s inefficient, costly, and it means that nonprofits will always need to evaluate, at some point or another, when to leave one large platform ecosystem behind for another.
This doesn’t serve nonprofits at scale, given all the potential platform ecosystems nonprofits could use globally. When massive, global challenges compel them to work together in new ways, the first hurdle nonprofits face is the discussion regarding the interoperability of data, data migration, data integration, and data middleware. Suppose we’re solving the sustainable development goals and the journey to 2030, or even a crisis like COVID-19, by first having to solve inefficiencies between the software platforms that nonprofits are using. In that case, we’re literally holding back the impact that mission-driven work can deliver.
Think of how we communicate every day: text messages are global standards regardless of carriers; the transmission of email is a global standard irrespective of whether or not it arrives in Gmail, Outlook, or some other service. Imagine our lives if getting a new mobile phone required leaving behind our friends on Verizon who couldn’t text us when we switched cellular carriers to T-Mobile. Remember what it was like when jumping from CompuServe to AOL, leaving behind entire groups of people because these services were once unable to talk to each other? That is the world nonprofits using large data platforms exist within, and it’s taking up needless time, money, and effort to maintain.
So, we arrive at an impasse. The nonprofit market is a billion-dollar business, and corporations know this. But there is an argument to be made that treating the nonprofit market with the equivalency of other corporate market verticals, despite the proliferation of corporate donation and discounting programs, is ultimately insufficient. Why?
It begins with the bottom line of the impact economy: achieving nonprofits’ missions. While much discussion has been held regarding how closely nonprofits should run their operations to commercial tenants, the shareholder return for nonprofits isn’t profit but mission impact, however that is defined. The bottom line of the shareholder economy is maximizing profit on monetary investment. This priority, while not wholly incompatible with servicing the nonprofit ecosystem, is different than the priorities of nonprofits that are maximizing the output of services, not gross profit for its own sake. To be abundantly clear, I am not saying that nonprofits should receive all software for free or that a free market economy’s ordinary operations are a bad thing. But the systems of software development and implementation prioritizations and the needs between shareholder and mission-driven economies are different.
The standard corporate assumption of motivation in nonprofit organizations, especially as a high-growth market for sales and service, is skewed. It is missing a translation layer, which is why even the largest, most well-funded organizations struggle with technology. What gets lost in translation is the nuance of the promises that every organization makes to the constituency it serves, all of which are not defined merely by common ecosystem business processes such as fundraising but instead shared investments in mission delivery. The translation of nonprofit priorities to corporate technology takes the hard job of technology implementation and makes it harder because nonprofit staff already have multiple jobs, and a technology project is adding another that pulls them away from mission impact. Further, while it is expected that corporate software standards will frequently meet nonprofit requirements, especially around technological features and functions, where they fall down is precisely the difference between a shareholder-driven and a mission-driven economy: collaboration and coordination.
It would cost executive jobs if competitors in the same industry, such as soda, shared formulas, manufacturing methods, and research to improve soda products’ quality across all companies. But this is what nonprofits do: share research, community standards, methods of service, and more, to elevate the needs of shared constituencies. Imagine a world where a service agency worked only with community members who agreed to access it alone and wouldn’t refer them to other organizations to meet additional needs. What is ordinary in the corporate world is heretical in the nonprofit world.
The inherent collaboration of nonprofit organizations globally drives the need for structures that facilitate exchanging nonprofit data. The solution isn’t a series of large software platforms that don’t participate in a common ground. This premise goes beyond simple commitments to interoperability and API access and towards mitigating the cost of adoption of tools, creating best of breed software choices, and promoting global data portability so that the price of innovation (and data migration) for individual nonprofits is mitigated, unlocking the opportunity of global collaboration.