Skip to Content

Contributing to the Nonprofit Success Pack

We actively welcome the participation of our Nonprofit Success Pack (NPSP) community. In fact, community members (developers, administrators and partners) have contributed and shared code and features, documentation, videos and more. NPSP is distributed as open source software under the BSD-3 license. That means that you can view and export every single line of code to understand exactly how it works and even make a copy (fork) of it for your own use. It’s all on our Github repository. Go ahead, poke around. It’s okay. We don’t mind. Even better than just viewing and understanding the source code of NPSP, you can get involved and contribute so our entire community can benefit. Share your knowledge and passion for helping nonprofits by improving on the most popular app for nonprofits in the Salesforce ecosystem. Do you have questions about contributing to NPSP? That’s great, because we have some answers:

How is the Nonprofit Success Pack released? [Back to Menu]

NPSP is six separate managed packages (Contacts & Organizations, Households, Recurring Donations, Affiliations, Relationships and Nonprofit Success Pack) that together form the entire Nonprofit Success Pack suite. In earlier versions, each package could function and operate independently. However, that came with limitations. In our most recent version (version 3 and above), we've taken all of that logic and glued those packages together by making them depend on each other. This means all six packages of the Nonprofit Success Pack are required to make your instance function properly. Updates to NPSP are pushed to production instances automatically every 2 weeks. New features need to be enabled by administrators before they’re visible to end users. That gives organizations the flexibility to incorporate new functionality on their own timeline. This is different than the standard Salesforce platform release cycle of every 4 months (3 times a year). We release this frequently so we can provide organizations with new features and enhancements quickly (in addition to fixing bugs). With smaller updates, it’s easier for administrators to manage and incorporate changes than if the releases were much larger. We release first to sandbox, then a week later to production instances. Typically, of the six packages that comprise Nonprofit Success Pack, only the package named ‘Nonprofit Success Pack’ is updated. You can review all the release notes for NPSP 3 here. also posts to the Broadcast-only NPSP New Releases Group on each release.

I think I found a bug in Nonprofit Success Pack. How can I tell you about it? [Back to Menu]

Bugs happen, and telling us about ones you find is one of the best ways you can contribute to NPSP. Thank you! Since your Salesforce instance consists of many different pieces of functionality, some from the Salesforce platform, some from the NPSP, and even some from other applications, it can be difficult to tell where a bug or unexpected behavior might be coming from. Here’s how you can report issues to the development team.

I can’t write any code. What else can I do to help? [Back to Menu]

You’re not alone. In fact, the majority of our most active contributors are neither Apex nor Visualforce developers. They’re administrators or consultants who have deep experience with Nonprofit Success Pack and a desire to help enrich the community of nonprofits who are meeting their mission with Salesforce. Here are some other ways you can contribute:

How can I help with Nonprofit Success Pack Documentation? [Back to Menu]

If you browse the NPSP Documentation, you can see that many articles have been submitted by community members. If you have a suggestion for an area of Salesforce functionality that should be added to the NPSP documentation, we’d love to hear about it. In addition, if you feel like an existing document could be improved or re-written due to new functionality in Salesforce or NPSP, please let us know. Tell us about yourself and your writing background and submit your idea here and a member of our technical writing team will be in touch to discuss next steps. We also have a list of some areas that we want to document, but just haven't been able to get to yet. And we'll even provide Guidelines to help you get started! Reach out and we’ll share it with you.

I heard that hosts open source Community Sprints. Tell me more! [Back to Menu]

What’s an open source community sprint? It’s a way that everyone, from accidental techies to advanced developers, can work together in person to contribute to an open source project. Oh, and have fun while you’re at it! You decide what you want to work on over the course of the 2 day event, and work in small groups to make it happen. It could be code, documentation, reports, videos and more. It’s a great way to meet your fellow community members, learn something new and come away energized by the power of the community. Since 2018, we've combined the NGO and EDU vertices to form an incredible cross-experience event. We hope to see you there! To learn more about what it's like to attend an Open Source Sprint, check out these articles: Recent AMER Sprints in 2018 have been held in Orlando, FL, Denver, CO, and Portland, OR. We aim to host 3 Community Sprint events in North America per year. We've also recently held two Community Day Sprints in EMEA, in London, UK and Paris, France. Future Community Sprint dates and locations will be announced in the Power of Us Hub Group! You can also follow the #NPSPSprint hashtag on Twitter for pictures and news.

Where would I find the Nonprofit Success Pack code documentation? [Back to Menu]

NPSP code documentation is here. We use another open source project, ApexDoc, to automatically generate our technical documentation directly from the code itself. Where can I learn about other projects that support NPSP’s release operations? In addition to NPSP, we maintain a number of other projects related to our release operations. These include: These projects are not exclusive to Nonprofit Success Pack, are free and open source, but were designed specifically to address’s internal managed package build operations. We do not actively support or encourage contributions to these projects as we do for Nonprofit Success Pack, but we will review and consider pull requests.

I have an idea for a new feature for Nonprofit Success Pack. How do I tell you about it? [Back to Menu]

Post your feature suggestion to the Power of Us Ideas tab. Learn more here.

I can fix one of the known bugs in Nonprofit Success Pack. What do I do next? [Back to Menu]

We are so grateful to our developer community who not only help us identify bugs and issues, but can swat them too! When we receive a pull requestthat fixes an existing bug, we can usually have it reviewed by a member of the development team, and merged and released quickly. First, leave a comment on the issue that you’d like to fix to let us know that you’re working on it. If our development team is already working on an open issue, you’ll see that it has been assigned to a Milestone. Then you can either manually set up a development environment following the directions here or you can use our Contributor Tool to submit your pull request.

I am a developer and I’m ready to contribute a new feature. What’s next? [Back to Menu]

First, make sure your contribution is appropriate. NPSP is distributed to thousands of organizations so we’re most interested in feature contributions that will be applicable to organizations of all shapes, sizes and missions. While we welcome all contributions, not all pull requests are accepted. A pull request is how you submit your work to us in Github. There are some core philosophies about NPSP that you should consider when proposing a completely new feature:
  • We favor native Salesforce platform over custom development.
  • Nonprofits come in all sizes, budgets, and technical expertise. The average Nonprofit Success Pack organization is using the standard donated 10 licenses and has a small staff. We strive for functionality that will be as useful to as many as possible, rather than features that are useful exclusively to an organization of a certain size, from a certain country or nonprofit sub-vertical (such as animal rescue organizations, social services agencies, etc). More narrow solutions may be best delivered in extension packages.
  • We live in a big garden – what we build and incorporate through contributions impacts partners and existing customers, and impacts decisions customers have already made. We take contributions very seriously, and need to assess all parts of the picture before we can accept a contribution.
  • We avoid new features that will require organizations to move data around or follow overly complex configuration steps in order to adopt.
  • Do No Harm. We strive for backwards compatibility. For example, a feature that limits access or scope for an existing feature, or does not allow an existing feature's data to be easily ported may be rejected.
  • Nonprofit Success Pack is used by organizations in over 80 countries. Therefore, we avoid implementing features that are strictly limited to a single country’s use cases or best practices.
Here are some additional questions you should ask yourself that will help you determine if your feature idea is right for a core NPSP contribution, or perhaps should be developed as a separate package that is compatible with NPSP. As the overwhelming majority of our contributors, users and implementers of NPSP are part of the nonprofit community, we recommend you start a conversation on the Power of Us Hub describing the feature you have in mind. You may find that others have the same idea or can provide input. For example, here’s the conversation about the Grants Management feature, started by community member Sam Knox, that was eventually accepted and incorporated into core NPSP. When you’re ready to submit, you can either set up your development environment and GIT from scratch, or you can ask us about our Contributor Tool that is currently under development. While the process is more complex in setting up your development environment, that approach allows you to use a single development environment for multiple contributions. If you use the Contributor Tool, you will need to provision a new Developer Edition environment for each contribution.