Embedded Files
January 26, 2026
Prior posts here have explored the area of software dependencies, vendors and support, and collaboration in open source software (OSS). But the reality is that most of the time most of us are passive consumers of existing OSS. What does it mean to begin more active, sustaining participation in OSS?
People > Process > Code
People > Process > Code
Strong software development organizations know the hierarchy of “people > process > code.” Who we have doing work is a first order matter. How we specify the work is an ongoing concern. These two combine in quality team outputs – the “what”.
While this is not new, we tend to get it completely out of order with OSS. The first thing we commonly do is download some code and start using it. Maybe if we find a problem or need a new feature there’s some thought given to who’s maintaining the component. And depending on how our interactions with those people go, we might start to have opinions on their processes.
Who sails the OSS ship?
Who sails the OSS ship?
In the Tavole Amalfitane’s ancient rules of maritime commerce, first in the value hierarchy is people – the sailors of the ships. In OSS, this means the maintainers and core contributors of a project.
How to Support OSS Maintainers
How to Support OSS Maintainers
One seemingly simple, obvious path to valuing your OSS ship’s sailors: Hire maintainers and core contributors! If your business has a deep, significant reliance on a critical OSS dependency, perhaps you should be employing its maintainers and contributors just as your business manages its other deliverables through in-house staffing. This is a great approach and places a direct, concrete value on your business dependency.
Often though, paying individuals in a project is out of reach, especially for a smaller business which depends on OSS.
Further, for many reasons maintainers may not be interested in an employment offer. A maintainer may already be well employed, they may command a wage beyond your business’ ability, they may provide their OSS as-is with no interest in commercialization, or they may simply be focused on a different business and different outcomes than you.
There are many additional paths to supporting OSS communities. As mentioned in prior posts, support may take the form of an intermediary vendor. You give monetarily to aggregating vendors which provide support services for OSS. The quality OSS vendors employ upstream OSS maintainers and experienced contributors. That vendor staff, with specialized domain knowledge, can collaborate effectively upstream on your behalf.
Peering
Peering
Like the vendor model, another scalable approach is directly hiring those who “simply” know how to work with OSS maintainers and communities. The first seeds of sustaining contribution can be sown by such OSS generalists and collaboratively minded individuals, with an appropriate amount of work time dedicated to upstream sustaining, and with business performance goals tied to and measuring upstream impact. This could be as easy initially as establishing a light weight, internal peer-review process through which your OSS-adjacent staff collaborate across your organization to improve the quality of interactions with upstream communities. Establish a culture of peers humbly asking peers “am I missing anything”, “how can I make this code better before submission”, or “how can I improve this bug report before sharing with the community.”
The Open Source Program Office
The Open Source Program Office
One popular model for improved collaboration and reduced risk is the Open Source Program Office (OSPO). OSPOs give a formalized location for business-internal knowledge, process development, and risk management. A tremendous amount of information exists on establishing and running an OSPO.
Reach out for a conversation on your OSPO needs, and stay tuned for a next blog post on how a well run OSPO can be a superpower for your business, enabling and accelerating innovation…
Page updated
Report abuse