Package Governance #1033
Replies: 2 comments
-
Well said. I agree and I have aired similar ideas in the past. |
Beta Was this translation helpful? Give feedback.
-
It's a couple of years in the future and things haven't exactly slowed down. I searched for the topic because I noticed a pretty large increase of downloads for a couple of utility packages I've written. Between them they are getting close to a million weekly downloads, which is pretty crazy considering the figure in the original post. However, I find myself in the weird position of not really using Zod or my own packages for work anymore, and haven't for over a year now. After a refactor this fall to support ESM (finally) I'm currently only maintaining them on a bare minimum level, fixing the worst bugs as they pop up, but not really making any drastic changes, even if some may be needed to be honest. Not saying that won't ever change, but that's how it stands right now. Zod itself seems to have reached some sort of mature stasis as well. Due to these factors and the rising popularity of the ecosystem at large I would at least consider moving ownership of my repos to a Zod organisation if one existed. I have no idea if Colin has considered creating one and ultimately its of course his decision. Zod is his creation after all and the rest of us are just along for the ride. Just thought I'd throw in my two cents. ¯\(ツ)/¯ |
Beta Was this translation helpful? Give feedback.
-
Disclaimer
Zod
, and this is more a comment on making it easier for new teams doing risk assessments to join us on#teamzod
.Problem
Given the recent high-profile horror stories of individual package maintainers deliberately corrupting packages (eg
RIAEvangelist
,Marak
, etc), I've been personally reviewing all the critical packages in use across all my applications.I'm sure there are better internal stats in terms of how many packages and apps depend on Zod either directly or indirectly, but it's fair to say that:
Suggestions
Zod
package decides it isn't the right time for some or all of the ideas.Move to a
Zod
GitHub Org account.For better or worse, I've noticed a (personal) cognitive bias immediately towards any packages under an individual GitHub account. While I'm sure there are ways to employ trustworthy governance on these packages, the fact remains that some percentage of teams will share the same bias.
Publish and enforce transparent governance.
To make the analysis easier, it would be great to work on a written governance policy backed either by some reliable (third-party or otherwise) enforcement system, or at least a demonstrable track history of compliance with the policy.
Establish a core team within the Org.
From what I can see
Zod
is already well ahead of the curve here, so part of the policy could be describing how the core team can take action in the event the policy fails and a rogue event occurs.Formalize value-add sponsorship options.
There is already a GitHub Sponsors button on the sidebar, which is great and an extension of this could be describing why sponsorship (especially from medium-large organizations with even modest revenues partly attributable to
Zod
) is important for ensuring package health and quality.Assuming that "being a good corporate citizen" is not enough motivation, I've seen some packages with a similar trajectory to
Zod
work out creative ways to add value either by adding priority feature requests or voting, private Discord supporter channels, additional "premium" features only available via a private "premium" repo linked to subscription status, etc, etc.Even if "money isn't really important" for the core team, the visibility or at least perception there is at least some financial support from users can be a decider during risk assessments (which ultimately means more
#teamzod
users 🥳)References
Beta Was this translation helpful? Give feedback.
All reactions