I read Dirk Riehle’s recent post on the OSPO Lifecycle, and it conjured up some thoughts that I’ve had recently and have been meaning to write down. Something has been bothering me about the concept of Open Source Program Offices (OSPOs) within corporations and where they fit in value stream discussions, especially since a few OSPOs suffered waves of layoffs and saw a reduction in scope. As a professional OSPO guy, it certainly turned my head and made me think. In Dirk’s post, he points out that the OSPO provides an important leadership function, mostly at the start. Over time, as the company’s open source involvement matures, the OSPO reaches an inflection point and transitions from a thought leadership role to one of coordination and support. The mature OSPO performs a support function for open source governance and compliance, as well as procedural guidance for the few lucky engineers who get to actively participate in external communities. This makes sense if you think of the OSPO as an atomic entity, riding a 5-year lifecycle from inception to “business as usual”.
But what if OSPOs are not atomic entities? When I think about how OSPOs function, what is often missed is its role in developer productivity. Back when OSPOs were first stood up inside tech vendors, before they were even called OSPOs, a big incentive was vendors wanting to capture value from software produced by collaborative communities. Vendors wanted to be able to reliably use community-produced software embedded within products that they sold. This required a different view of supply chain and product management than had ever existed before, and OSPOs were the chosen vehicle for doing so. Along the way, these vendors discovered that an additional source of value was learning how to collaborate in an open source way. Suddenly, they weren’t just pulling software down from communities, they were actively collaborating with these communities. What OSPOs helped vendors achieve was producing products using the principles of open source collaboration. To me, the enablement of community collaboration and the embrace of open source principles was always the primary value of an OSPO. In that light, to constrain the scope of an OSPO to one of coordination and support is to miss the primary opportunities for value.
What’s in a Name?
I think a maturing OSPO needs a name that reflects its aspirational scope. If the ultimate value of an OSPO is measured in developer productivity, then perhaps what’s holding it back is the name. A “program office” may seem like an interesting place to invest if you’re a tech vendor, but the words “program office” have a very different meaning inside large enterprises, one largely associated with bureaucratic functions.
One of the messages I have incorporated into a lot of my talks since 2013 is that open source communities have been the greatest source of innovation for over two decades, going back to the linux boom of the late 90’s. Any large enterprise would do well to at least attempt to replicate the success of open source communities and instill open source principles into its engineering teams. And if you can expand your “shift left” methodologies to include open source supply chains in your SDLC, then you benefit direclty from the innovation produced by these communities. This is where an OSPO can add the most value, if that value is recognized and invested in. I don’t know that the name necessarily should be, but since accelerated innovation and higher developer productivity are the end goals, then that should be reflected.
I think when OSPOs grow up, they should become Centers of Innovation and Developer Productivity. Let’s face it, the term “open source” doesn’t grab people like it used to. It became what we always thought it would be – a means to an end. A tool. Instead, let’s focus on the outcome we’re looking to drive: Innovation and Developer Productivity.
