Open source program offices (OSPOs) have a life-cycle.
Most companies start out with tasking one employee, part-time, “to take care of open source”. This person will typically try to help product and project teams get license compliance right. As a side-job, this person can’t achieve much and is likely to get quickly overwhelmed by the amount of requests as word gets out about their responsibility.
Next, companies create an open source program office. The initial mandate is usually to create an open source policy for the company and to ensure that nothing goes wrong with its intellectual property. This leads to a focus on open source governance and license compliance. In addition, firm-internal marketing leads to more and structured awareness of open source within the organization, ideally combined with training for personnel.
Then, as the open source program office grows, not only does it have to deal with an increasing volume of requests to approve and manage components for use in products and projects, it also expands its scope. It helps teams review code to be contributed to open source projects. It may even decide to take a small or large leadership role by initiating and leading open source projects. This includes active engagement in organizations like open source foundations.
If the open source program office does its job right, it will create and transfer significant skills to product and project teams. The teams learn how to deal with open source: To use it properly, to know how and when to contribute, and to know how and why to get active in open source foundations and lead open source projects. Over time, these skills become an entrenched capability of every product and project organization.
As a consequence, after a phase of growth, open source program offices shrink as they transfer some of their strategic and tactical responsibilities to the product and project organizations directly affected by open source exposure and engagement. As a central function, the open source program office will retreat to supporting revenue-generating organizational units.
While open source program offices at most companies are still in the early growth stages, we could also already observe how some program offices have shrunk in recent days.
A stable long-term state for open source program offices is hard to predict. There will always be some value to a central provision of tooling and training. It is also something that can be readily outsourced.
To my students, the general advice remains: Try to work in a position where it is clear how you are contributing to revenues. Profit centers are better than cost centers, product units are better than central functions.
Leave a Reply