How to be a good codebase contributor as a public organization

Increasingly, as public organizations mature in their digitization efforts, they tend to adopt policies of preferentually contributing to existing open source codebases rather than creating yet another codebase from scratch. A while back, we even got a question about what a public organization needs to think about as a contributor to existing open source codebases. That made us pause for a bit, as previously we had mostly been asked to help public organizations make their own codebases open or ready for collaboration.

The Standard for Public Code does not cover the aspect of being a contributor explicitly. Instead, it focuses on the existing community and how they can welcome more contributors. We realized there might be a knowledge gap to fill.

There are many contribution guides out there, and the FreeCodeCamp has collected a fairly comprehensive list of them. This is a good start for anyone that wants to be a helpful contributor. You’ll see there are a lot on the list, but the one-line descriptions will help select the ones of interest.

Additionally, we find these to be particularly useful if you’re contributing on behalf of a larger organization:

• Participating in Open Source Communities from the TODO Group - shines a light on how to be a good corporate citizen, which is quite similar to what being a good contributor as a public organization involves.
• Guidelines for creating sustainable open source communities by the Open Source Observatory at the European Commission - helps you understand, and interact with, existing codebase communities.
• Engaging Enterprise consumers of OSS - Enterprise contribution, participation, and support of OSS by Jacob Redding at FOSDEM 2020 - this has poor sound for the first several minutes but also some interesting ideas on how an organization can contribute to a codebase with clarity around its intent.

Together, these guides cover most aspects that any large organization should consider when contributing to an open source project, so we thought that writing one more guide wouldn’t be that helpful. However, for a contributor representing a public organization, it’s even more important to give maintainers the right expectations about the organization’s current and future involvement, including:

• Your organization’s current scale of commitment. What is your headcount or budget?
• What is your organization’s ability to participate in the future maintenance of the contribution?
• How formalized is your involvement? Is there specific support from policy and or management? Or are you in a situation such that if the role of one engaged contributor changes, the involvement may dry up?
• What is the expected duration of your contributors? Are the contributors from your organization short term contractors or embedded experts with long term contracts?
• Will your contributors be paid to gain depth and become reviewers over time?
• What policy objectives, if any, are being addressed by your participation or contributions, for example adding GDPR compliance, or accessibility requirements, or a feature that was a political campaign promise?
• The goals and aspirations of your organization. Do you plan further contributions already, and if so, of what kind? How are you using the codebase, and what is your scale of deployment/implementation?
• How is your orgainzation able to contribute? Code and documentation contributions are great, but many open source communities can also benefit from other forms of support, including community management, financing, help with governance, marketing, endorsements, and so on.

These points may not really fit in to a pull request, so you might want to consider starting a separate discussion in a place where the community is having their discussions (which might be something like a forum, chat or mailing list). Naturally, the importance of being clear about these points increases with the size of your contribution - if you just fix a small bug, then of course this would be excessive.

Healthy open source codebases have a great diversity in their communities and public organizations are likely to be seen as valuable contributors by maintainers, especially as they are uniquely positioned to engage on very long time scales.

Good luck contributing!