The Real Power of Nonprofit Technology is the Community

What makes the nonprofit technology community unique is that people are incredibly caring and collaborative. We care deeply about helping each other succeed, so we can all improve our impact on the world and address today’s vital, pressing challenges.

That means joining forces as a community, rather than assuming that we know everything. It means putting collaboration and impact at the heart of how we prioritize our product development. And it means we take an impact-first approach to creating technology. One of the reasons I love working at Salesforce.org is the incredible community spirit, and the good news is that you can join the community, too!

So what’s the real deal with how we build technology by, with, and for nonprofits and education institutions?

The nonprofit technology community at Salesforce.org came together in 2011 with a 12-person NPSP Community Sprint, pictured in this photo:

The second Nonprofit Community Sprint from 2011

The Early Years & Focus

Salesforce for Nonprofits: A brief history

Before we dive in to what makes NPSP different, let’s start with a brief history of Salesforce for nonprofits to provide some context. In 1999, when Salesforce was started, founder Marc Benioff made a commitment to the revolutionary “1-1-1 model.” Salesforce created a foundation to donate 1% of employees’ time (a week of volunteering per year), 1% of profits, and 1% of the product to the nonprofit sector. While Salesforce.org is now a self-sustaining social enterprise, not a foundation, the 1% pledge manifested in a generous donation of enterprise licenses to the new and rapidly evolving CRM. While some early adopters immediately saw the value, it was clear that nonprofits wanted a CRM customized for their needs.

Fortunately, Salesforce is a flexible platform, so the community started creating templates that took the best of this incredible new CRM and transformed its core into something much more familiar to nonprofits. With that change, adoption began to grow.

Fitting the Data Model to the Community and the Platform

By 2008, it was clear that a phenomenon was at hand, and the technology that Salesforce provided for its app ecosystem was maturing to the point where it was possible to build a concrete nonprofit data model with the existing CRM infrastructure. With that, the genesis of the Nonprofit Starter Pack, the precursor to the Nonprofit Success Pack, was begun. NPSP was a response to a problem: How does a small group of dedicated individuals scale the impact of the platform in a way that is easily understandable and accessible to the communities we’re desiring to serve?

While Salesforce.org has grown since that time, the scrappy 18-person organization that started 10 years ago (in 2008) needed a way to democratize the impact of NPSP. Thus, the NPSP open-source data model and community-driven design and development process were born.

Nonprofit employees from many organizations volunteered their time, energy, and genius to the formation of NPSP. From 2008-2013, an intrepid blend of ecosystem partners, nonprofit staff, and Salesforce employees worked together to harness the power of the Salesforce platform and applied it to the causes and issues most important to their lives. Additionally, since 2017, higher education institutions have collaborated at sprints on HEDA, the Higher Education Data Architecture, but that’s another story. (More on recent HEDA news.)

How the Data Model and Platform Evolved in an Agile Way

Those early years were marked by a time of great transition and evolution. The Force.com platform was less than a decade old, the AppExchange was even younger, and as the platform evolved, the NPSP application and nonprofit data model evolved with it. Mistakes were made, successes celebrated, and we learned constantly. The model and overall application architecture were tempered and hardened in the fire of real-life experience and the hard-won wisdom that can only come with actual usage. Packages came and went, objects were deprecated or repurposed, and the underlying platform matured beneath us.

As the maturation continued, we listened. Our community of users grew from zero to 1,000 organizations, seemingly overnight. Our users – at nonprofits like yours – taught us nearly everything we needed to know. Transactional models were based on real-world implementations of NPSP. The modeling of donor relationships, crediting, householding, and more were evolved based on the concrete problems we were being asked to solve on a daily basis. We developed a focus on practical implementations and things that “just worked.” We came to understand the underlying platform mattered too! If we were building ultra-high-volume real-time transaction processing, storing web or marketing analytics, or tracking basically any non-ACID-required data, we realized we didn’t want to be restricted to a pure relational data structure. Since we know CRM, we listened to community needs and identified where relational models are best (and where to use other techniques) to co-create a solution tailored to fit the application and environment nonprofits work in.

A diagram of the NPSP data model

The Maturation of the NPSP Data Model

The coexistence of model rigidity & flexibility

By 2013, our model was fairly mature, and at its core looks similar to what you have today within NPSP. This presented a conundrum: What happens when you want to evolve your data models, but have thousands of nonprofits already using what you have today?

First, you start with trust. We talk about it so much in our values, it has almost become cliché. But trust is a real, meaningful, and vital piece of what makes Salesforce special. Salesforce founder Marc Benioff talks about it a lot, and it can take on different meaning depending on the circumstance. For us, it was a belief that first and foremost as a technology organization we should strive to do no harm. We’re here to help the organizations we serve first; everything else comes second. In practice, that meant there wasn’t going to be an “evolution of the model” without bringing our customers and ecosystem with us. When we made the transition from NPSP2 to NPSP3 in 2014, we spent months building, testing, releasing, and evolving tools to make the transition for our customers as seamless as possible. We worked with a wide variety of customers and partners to ensure we had considered every possible way to implement NPSP. Unlike some companies that make it difficult for customers on older models to use their technology, we strive for backwards compatibility as a part of our mission.

Second, you recognize during the ideation and design process that each organization has its own unique wants and needs. Not everything should be in the data model in the first place! While a significant common core of functionality exists across the nonprofit landscape, many organizations choose to implement that common core in different ways to better suit their mission needs or have functions that are modeled outside of that core. Creating a flexible and extensible application and model while still providing a “standard way” allowed organizations of all shapes and sizes to fit their NPSP implementation to their specific needs, or choose a “best practice” if they didn’t have an approach of their own. Additionally, it afforded an opportunity for our community to contribute their own best practice to the cause. An entire universe of tools, applications, mini-apps, code snippets, and more began evolving. These community contributions weren’t about changing the core model (though there were many of those too); they were the evolution and extension of the core. Community contributions took what was already in place, and added to it. You didn’t need to start with how to model a household. Rather, you could focus on the optimal way to visually manage a household.

Striving for flexibility in implementation often meant taking the longer road to a new feature or change. After all, building multiple ways of doing the same thing logically takes longer, but for our growing customer base, that rigid “common core” with flexible implementations and extensibility around it proved to be the secret sauce. The recognition that a canonical “model for everything” was not an achievable or desirable end goal opened the opportunity to do something more: recognize and celebrate the individuality of each and every organization we served.

Ecosystem Impacts of Commonality

Of course, we’re not the only players in our ecosystem. As our common core solidified, the partners who grew with us from the beginning saw the expanding market of nonprofits on an open source core model as an opportunity. Accelerators, implementation services, and applications targeted specifically at the NPSP user base began to slowly pop up, encouraged by the community engagement. Now, any disruption to that core model meant not only impacting our customers, but also the ecosystem of software and implementation providers our customers had grown to count on.

What Widespread Adoption Looks Like

The Lingua Franca of the Community

Today, we are fortunate to power the missions of tens of thousands of nonprofits, and the evolution of NPSP and our incredible community of contributors continues to grow globally. Four times a year, our community of volunteer contributors come together in different cities across the United States and Europe to share their ideas, thoughts, and passion for helping our community, not just in the nonprofit space, but in higher education as well. The dozen attendees of 2011 have now evolved to well over 150 people per Open Source Community Sprint, with both familiar and brand-new faces each time.

A group of Community Sprint attendees in Denver, Colorado, July 2018

As new participants have joined, the need to establish a new language – a common vernacular for conversation, has only grown more important. With the core NPSP application and data model, the community speaks the same language. NPSP allows nonprofits to leverage the tried and true solutions that have been field-tested in the very organizations they work with.

Data Model as API and the Abstraction of Understanding

Somewhat paradoxically, though, as NPSP continues to mature, the underlying data model should continue to matter less and less. Mature APIs can increasingly substitute for direct understanding of the underlying architecture and provide an on-ramp for understanding NPSP without needing to be a database modeler. Integrators and implementors alike can focus on what matters most to the organizations they’re serving: the business processes and impact of their solutions, not foreign key relationships and database-level constraints. That information is still there, open source and available, but a mature NPSP means it’s no longer a prerequisite for participation in the ecosystem as it may have once been. Thanks to the Salesforce platform, we can now even take that a level higher. Salesforce Lightning provides a component-based UX abstraction layer that allows rich customization without the need for architectural definition, and creates a new interaction and customization point for the community as a whole. No longer do we have to discuss the data model; we can now discuss the interaction model and overall user experience as a core part of that. (Though really, if you want to talk data modeling, I’m always game!)

Where We Go From Here

Platform and Responsibilities

Our community has an immense responsibility. Salesforce.org has an immense responsibility. It’s not just a compact with our customers, or users, but with their constituents as well. It’s a relationship with the host of implementation providers and ecosystem app providers that make our rich and vibrant community what it is today. Our young scrappy application has grown up, and for many, NPSP more resembles a platform on a platform then just another app. We take that responsibility to our community and our community’s community very seriously. It’s about our core value of trust, which makes us who we are as an organization. It means:

1. 1. Working closely with our community

 

1. 2. Helping shepherd their work in a safe and non-disruptive way

 

1. 3. Allowing the beautiful chaos of open source innovation to be the driving factor in the evolution of the NPSP platform we’ve all come to rely upon

 

4. Delivering that innovation regularly to our community, without disruption.

Pretty cool, right?

Learn more and get involved with other nonprofit technology leaders here:

• Experience the culture of a sprint: This Is Not a Conference
• Watch an NPSP demo
• Join other Salesforce.org Nonprofit Cloud trailblazers in the Power of Us Hub
• Join the next Community Sprint in Long Beach, CA, from Feb 19-21, 2019: Follow along by joining the Open Source Community Sprint group in the Power of Us Hub
• Read the Salesforce.org Developer Blog

About the Author
Kevin Bromer is VP of Product Delivery at Salesforce.org. He has been at Salesforce since 2010 and has coded, tested, documented, supported and managed NPSP at various points throughout its evolution. Today, he helps run the delivery teams that help make the incredible vision of our communities real across both nonprofit, higher education and K-12. He is based in Baltimore, Maryland along with his wife and four-year-old manager. Follow him on Twitter: @kevinbromer