About NPPatch
What Is NPPatch?
NPPatch consolidates the open-source Nonprofit Success Pack (NPSP) into a single, namespaced, unlocked second-generation package (2GP) that the nonprofit community can install, extend, and maintain independently.
The original NPSP was distributed as five Salesforce-controlled managed packages. NPPatch changes that by giving organizations the ability to install, upgrade, and modify the package on their own terms.
What’s in a Name?
If you’ve spent time in Seattle, you might know what a P-Patch is. If you’ve spent time in the Salesforce nonprofit ecosystem, you almost certainly know what NPSP is. NPPatch lives at the intersection of both — and the name is no accident.
The P-Patch Story
In 1970, a University of Washington student named Darlyn Rundberg had a simple idea: she asked her neighbors, the Picardo family — Italian immigrants who ran a small truck farm in the Wedgwood neighborhood — if she could use a corner of their land for a community garden. They said yes.
That single act of neighborly generosity became the seed of something much larger. By 1973, the City of Seattle had acquired the Picardo farm and established the P-Patch Community Gardening Program, named with a “P” to honor the family who made it all possible. What started as one garden is now a network of over 90 community gardens spanning more than 30 acres across the city, tended by thousands of households.
A P-Patch isn’t a commercial farm. It isn’t owned by any one person. It’s a piece of shared ground where neighbors show up, tend their own plots, share what they grow, and take care of the common spaces together. Gardeners donate tens of thousands of pounds of fresh produce to local food banks every year. New gardeners learn from experienced ones. The soil gets richer over time because people keep showing up to work it.
The P-Patch program has survived budget crises, development pressure, and decades of change in the city around it — not because of any single institution, but because the community that depends on it keeps choosing to sustain it.
The NPSP Story
The Nonprofit Success Pack has a similar origin story, even if the soil is digital.
In 2008, the Salesforce Foundation (later Salesforce.org) partnered with the nonprofit Salesforce community to launch the Nonprofit Starter Pack — an open-source project to make the Salesforce platform actually work the way nonprofits needed it to. It started as five separately installed managed packages that handled the basics: constituent management, household relationships, affiliations, and fundraising.
But what made NPSP remarkable was never just the code. It was the community around it. From the beginning, NPSP was shaped by the people who used it. Nonprofit administrators, consultants, developers, and partners came together at Community Sprints — collaborative working sessions where people contributed code, documentation, reports, best practices, and ideas. You didn’t need to be a developer to make NPSP better. As one Sprint attendee put it, knowing firsthand what’s working, what confuses users, and what features are needed is exactly what the builders need to hear. That knowledge is its own kind of contribution.
Over the years, the community contributed major features like matching gifts, grant management, and campaign-member functionality. Volunteers wrote significant portions of the documentation. A Community Advisory Board helped guide priorities. The Power of Us Hub connected thousands of nonprofit professionals who helped each other solve problems every day. In 2016, the product was renamed the Nonprofit Success Pack to reflect how far it had grown beyond a “starter” kit — it had become the foundation tens of thousands of organizations relied on.
NPSP was always described as open source, and in an important sense it was: the code was publicly available under a BSD-3 license, hosted on GitHub, and open to contributions. But there was a tension at the heart of it. Salesforce controlled the distribution mechanism. The packages were managed packages, which meant Salesforce decided when and how updates shipped. Organizations couldn’t modify the packaged code in their own environments. The openness was real in spirit but limited in practice.
When Salesforce announced the end of active innovation on NPSP in favor of Nonprofit Cloud, that tension came to a head. Thousands of organizations — many of them small nonprofits with limited budgets — were left weighing their options. Some moved to Nonprofit Cloud. But others felt pushed toward a product they weren’t sure was right for them, not because they thought it was better, but because they thought it was their only path forward.
Why NPPatch Exists
NPPatch exists because we don’t think it should be the only path forward.
We’ve taken the open-source NPSP codebase — all five original packages — and consolidated it into a single repository. We’re distributing it as a second-generation, namespaced, unlocked package. That distinction matters: it means organizations can install NPPatch and modify the code in their own environments if they need to. It means the community can continue to fix bugs, build features, and ship updates on its own terms. The namespace preserves a clean upgrade path so that improvements can flow to everyone who wants them, while the unlocked model ensures that no single entity holds the keys to what organizations can do with their own systems.
This isn’t a fork born out of frustration with Salesforce. We’re genuinely excited about much of what’s being built in Nonprofit Cloud. But we believe every organization should choose its path based on what actually fits — what the product does, what it costs to implement and maintain, and what kind of support exists around it. Not based on the fear that the alternative is disappearing.
Communal Growth
The name NPPatch carries all of these threads:
np is for nonprofit — the mission at the center of everything.
patch is for Seattle’s P-Patch program — a model of what happens when a community takes collective ownership of shared ground and keeps showing up to tend it.
patch is also a word that means something specific in software — a fix, an improvement, a way of keeping something running and making it better over time. That’s exactly what this project does for the NPSP codebase.
And if you put NPPatch next to NPSP, the family resemblance is right there. This isn’t a replacement that pretends the original never existed. It’s a continuation, carried forward by the community that always made it what it was.
The Picardo family didn’t plan to start a citywide movement when they said yes to a neighbor’s request in 1970. The early NPSP contributors didn’t know they were building something that would serve tens of thousands of organizations when they gathered for those first Developer Sprints. Both things grew because people kept showing up, kept tending the ground, and kept sharing what they grew.
That’s what we’re inviting you to do with NPPatch. Bring your plot. Grow something. Share what works. The garden is open.
What’s In the Package?
NPPatch includes the full NPSP feature set, consolidated from the original five managed packages into a single codebase:
- Household and Organization Account Management — automatic household creation, account naming, address management
- Recurring Donations — schedule management, change tracking, and forecasting
- Gift Entry and Batch Data Import — form-based gift entry with template support, plus batch import tools
- Customizable Rollups — flexible rollup calculations across Accounts, Contacts, Households, and GAUs
- GAU Allocations — allocation of donations across General Accounting Units for fund accounting
- Relationships and Affiliations — contact-to-contact relationships with reciprocal tracking, plus organizational affiliations
- Engagement Plans — task-based engagement workflows triggered by donor activity
- Payment Management — payment scheduling, tracking, and write-off support
- Levels — automated donor level assignment based on giving history
- Error Logging — centralized error capture and admin notification
Technical Details
| Detail | Value |
|---|---|
| Package Type | Namespaced Unlocked 2GP |
| Namespace | nppatch |
| Salesforce API Version | 63.0 |
| Build Tool | CumulusCI 4.6+ |
| Architecture | Apex Enterprise Patterns (fflib) with TDTM trigger framework |
| License | BSD-3-Clause |
Get Involved
- Documentation: nppatch.readthedocs.io
- Source Code: github.com/Sundae-Shop-Consulting/nppatch
- Beta Program: Sign up as a beta tester
- Contact: admin@nppatch.com