Moved from a thread on GitHub Discussions
lmeerkatz on Feb 18 Maintainer
I want to have this conversation early, and I want to have it in public.
NPPatch exists because a community built NPSP and that community still has things to contribute. But right now, “community project” mostly means “one person with a GitHub repo.” That’s not sustainable, and I don’t want to pretend it is.
So I’m opening the conversation about governance – how decisions get made, who gets to make them, and what structure makes this thing durable beyond any single person.
Where things stand today
-
The code lives under the Sundae Shop Consulting GitHub org
-
I’m the sole maintainer with commit and release access
-
The project is BSD-3 licensed (same as the original NPSP)
-
Funding is starting to come in through GitHub Sponsors and Buy Me a Coffee, with an Open Collective application pending
-
There is no formal decision-making process, no steering committee, no contributor agreement
What needs to be decided
Here are the big questions I see. I have opinions on some of these, but I genuinely don’t want to decide them alone.
Legal home. Where should NPPatch live legally? Options range from staying under my consulting business (fast but fragile), to fiscal sponsorship under an existing org like Open Source Collective (moderate overhead, quick), to forming a new nonprofit (maximum independence, significant effort). Each has real tradeoffs around liability, tax status, grant eligibility, and how much overhead we want to carry.
Decision-making. How should technical and roadmap decisions get made? A single maintainer model works when the project is small but doesn’t scale. A steering committee adds process but also accountability. Something in between, like a small group of trusted committers, might be the right starting point.
Release authority. Who can push a new package version? This is high stakes in the Salesforce ecosystem — a bad release can break subscriber orgs. Right now it’s just me. That’s a bus factor problem.
Contributor model. What does the path look like from “interested person” to “trusted committer”? Do we need a CLA, or is a lighter-weight Developer Certificate of Origin sufficient given the BSD-3 license?
Financial transparency. How should project funds be managed and reported? Open Collective provides a public ledger by default, which I like. But there are questions about how funds get allocated — who decides what to spend money on?
What I think (but want to pressure-test)
I’m leaning toward fiscal sponsorship through Open Source Collective as the near-term legal home, with an explicit plan to revisit in 6-12 months once we know more about what this project actually needs. I think a small group of committers (2-4 people) with clear roles is better than either a solo maintainer or a large committee at this stage. And I think financial transparency should be a non-negotiable from day one.
But I could be wrong about any of that.
What I’d like from you
-
Does this framing miss anything important?
-
What governance model would make you feel confident recommending NPPatch to a client or installing it in your org?
-
Are you interested in being part of the governance conversation beyond just commenting here? (No wrong answer.)
-
Are there models from other open source projects you think we should look at?
I’m not going to rush this. But I also don’t want to let it drift. The goal is to have a working governance structure - even if it’s a simple one - within the next 90 days.
Thanks for being here. The fact that this conversation is happening at all is the point.
Replies
I think this discussion is probably the most important one to have in order to ensure the long-term viability of this project. Ultimately without a good ownership structure and governance model, this could simply die on the vine if @lmeerkatz inevitably gets pulled into something else and/or decides to finally retire and move to Tahiti 
. To directly answer your questions:
Does this framing miss anything important?
I think this captures the major pieces: who “owns” this, how is it maintained, how do changes get made, and how is money collected/distributed?
What governance model would make you feel confident recommending NPPatch to a client or installing it in your org?
Personally I like the idea of a nonprofit “owner” (either fiscal sponsor and/or separate org) with public board members and finances. That would make me the most comfortable.
Are you interested in being part of the governance conversation beyond just commenting here? (No wrong answer.)
You bet.
Are there models from other open source projects you think we should look at?
sigh This is a big question - as much as I love the idea of @lmeerkatz as the Linus Torvalds of NPPatch, I am not sure that model has been super successful for Linux. I’m going to sidestep Wordpress because they have had their own governance issues recently, and default to the Drupal governance model. Although not perfect, I think it’s a good one to aspire to - details here: Client Challenge.
Boy do I love reading a conversation that starts with people who are clearly smarter and more educated on the topics than I am! I’m going to just drop a quick thought or two for now, with intent to say more after listening more. (Plus I think I’ll probably write something on my blog at some point.)
I think one point that has been missed so far is the question of whether it made sense to just mostly-clone NPSP or whether this would be a moment to consider changes. I know that’s opening a can of worms. But if this is going to grow into something that might actually be installed in real orgs, this might be the time to consider whether we should get rid of Visualforce (the Manage Household Page, for example) in favor of screen flow or LWC, whether some Apex should be replaced with Flow, etc. I also don’t want to imply that I think everything should be on the table. But these are choices that so far @lmeerkatz made and maybe others would have chosen differently.
lmeerkatz on Feb 20 Maintainer | Author
@mkolodner These are really great points, and I’m glad you’re bringing them up – please do share more when you’ve had time to listen and reflect (and I’d love to read that blog post).
You’re right that the question of whether to clone vs. reimagine is worth serious conversation. To clarify my thinking on the choices I made: My goal at this stage was intentionally narrow – remove deprecated features, get a working 2gp build, and establish a shared foundation of utilities and common components. I wanted to make sure we had something functional to actually talk about before we started making bigger decisions collectively. It wasn’t that I think those bigger questions (Visualforce vs. LWC, Apex vs. Flow, etc.) aren’t worth asking – they absolutely are – it’s that I didn’t want to front-load the project with contested architectural decisions before we even had a working base or a governance structure to make them well.
I do think you’ve identified one of the hardest problems here: getting meaningful feedback and alignment on these kinds of choices. I don’t have a great answer yet, but I’m hoping conversations like this one help us figure out what that process looks like. Really appreciate you jumping in.
If you want to offer feedback on what in NPSP is worth preserving and what should change, there’s another discussion here that I’d love your feedback on: #35
microveldton Mar 7
This is a critical conversation. Big up for starting it early and publicly. I think what @lmeerkatz has built is very valuable, and we want to ensure that she’s not rolling the boulder up the hill by herself. We also want to ensure the product can thrive and scale as needed.
I think that we could learn a lot about appropriate governance from the Plone CMS model. I believe that Plone and NPPatch might have similar trajectories, as they are important, well-designed open-source products with a niche yet committed user base. @davisagli might be able to provide good insight here.
In the meantime, I think a nonprofit fiscal sponsorship might be the appropriate initial move.