How to convince your manager to start an OSPO

This time around we feature Josep Prat ( @jlprat ) from Aiven on how to convince your manager to start an OSPO at your company.

Recently, I was asked by an ex-colleague to explain how they could convince management to create an OSPO at their company. This is a very interesting question, with several possible answers, that I think deserves a proper write down. Here’s my view on the matter:

One Size Doesn’t Fit All

First of all, you need to find out which kind of Open Source Program Office you want/need. There are several focus areas for OSPOs:

  • Legal compliance
  • Generating OSS projects
  • Contributing to or (financially) supporting existing (external) OSS projects

These are not discrete areas, as OSPOs do several of these at the same time. But more often than not, one of these different areas has more weight than the others in their mission.

A good source of resources on how to set up an OSPO can be found under the guides section in the TODO Group website. If you want to know more about how Aiven’s OSPO does it, tune to Aiven’s blog as I’ll be publishing an article on it real soon.

Open Source At The Forefront

We have reached a point where all companies rely on Open Source Software, and it’s time for them to acknowledge this situation and act accordingly. We are all well aware of the latest security incidents that affected some well known OSS libraries. Incidents and bugs are bound to happen regularly, the important factor is not only to mitigate the impact of those but also how quickly we can react when a new incident or bug is detected. For this we need companies to not just be consumers of OSS, but also contributors of such projects. The more companies giving employees “company time” on OSS projects, the more secure, diverse, and healthy those communities will be.

There is this Internet adage: “What if I train my employees and then they leave? — What if you don’t, and they stay?". This is also true for OS. It’s part of our infrastructure, products, and tooling, for this reason we need to care about them like if they were our own projects. No company will leave crucial parts of their in-house developed tech-stack unmaintained, why are we willing to do so for the ones that are Open Source?

Reasons For Outbound OSPOs

If you have some projects that could be Open Sourced (or already are), and/or like many others depend heavily on OSS, you might want to consider these arguments:

We need a dedicated team to look after non-code aspects of our own OSS projects. Things like:

  • governance
  • project management
  • licensing
  • security
  • community engagement
  • developer education

All these, and many others are crucial for the success of OSS projects.

And with regards to contributing to external OSS projects, we need, as a company, to devote some of our employee’s work time to work on the critical OSS projects in our pipeline in order to:

  • guarantee a fast response in case of incidents
  • keep improving these projects
  • diversify the companies (if any) backing them up
  • remove maintenance burden
  • keep a healthy community