OSPO 3.0 – InApps 2022

In the previous two articles in this series (part 1 and part 2), we covered how some companies have created winning technology platforms by driving operational efficiency for developers. We talked about how making your platforms boring and pushing the innovation to the edges can yield distinct advantages for developers, and we covered some processes that can help engineering teams engage more productively in open source supply chain management. In short, we’ve talked about process and technology.

Now we’re going to talk about people. An Open Source Program Office (OSPO) is all about integrating more people into the open source conversation. In this article, I will discuss how these adaptations are leading us to what I call an OSPO 3.0, which I’ll define for you.

People: the Center of your Open Source Framework

As good leaders know, engineers are not fungible resources you can merely plug into a given workstream and expect immediate results. Engineers are people, as are risk managers, security experts, IT support staff, legal counsel, marketers, HR managers, and yes, even upper management. All of these people are stakeholders in your OSPO. Yet for many companies building OSPOs, the people corner of the people-process-technology triangle is often the most ignored because it is, frankly, the most difficult to address. Integrating non-technical people into your OSPO might feel like a daunting task, but it is the key piece in operationalizing the enterprise developer, as it brings tech and non-tech teams together to discuss how open source affects the entire company.

With open source playing a larger role in so many companies today, you can no longer just wing it. Capital One first created an OSPO in 2015 as part of a company-wide digital transformation that focused on empowering developers. Since then, our OSPO has evolved to meet new challenges, as have those at other enterprises across the industry.

A Brief History of OSPOs

The OSPO 1.0 era started when companies like Sun, Intel and IBM created engineering departments that made open source code readily available for insertion into products, internal and external.

The OSPO 2.0 model emerged when companies like Google added community marketing and outreach, to reach the goals of their open source platforms and increase the growth of open source adoption globally. TODO Group even created a guide to creating an open source program.

But new times present new challenges. We no longer need to evangelize open source collaboration globally. It has already won. What we need now is security, sustainability and training for engineers in collaborative best practices. Because while open source development has won around the world, making it successful internally remains a challenge.

OSPO 3.0: Fostering a Culture of Collaboration

In addition to the responsibilities of first and second generations of open source program offices, an OSPO 3.0 empowers developers to contribute to public open source projects. That requires the involvement of legal, risk, HR, marketing and other non-technical teams to ensure that all contributions are not just compliant, but benefit the overall business. Remember: It’s not about the number of contributions you make in a given amount of time, but rather the quality of those contributions and business value delivered, both for those upstream projects as well as your downstream use cases. The World Bank recently wrote a blog post about how their open source projects delivered higher return on investment and engaged developers more deeply once they incorporated product managers, tech writers and training teams into the fold.

The first step in any OSPO 3.0 process is to support developers in making the right contributions through the right technology and process frameworks while also ensuring that stakeholders are involved in the process. The goal is for every line of code contributed back into the open source community to also drive value for the organization.

How do we do that? You should ensure that engineering and product teams work closely with developers to create public code that also supports internal key applications and processes. This is an upstream-first framework where you work on code in public upstream communities, before pulling it downstream to address internal use cases. Measuring the value could also mean the marketing team sponsors a hackathon or coding project to raise awareness of the company as a champion of open source software, with a dual goal of showing that the company is a great place for developers to work. It could mean that legal teams work with developers to ensure any code that’s created is not only compliant with company regulations, but also meets legal frameworks for wider partnerships with vendors, public clouds or other partners.

The responsibilities of an OSPO 3.0 doesn’t stop at a company’s borders, but also involves external stakeholders and building community engagement that benefits the organization strategically. An example would be building foundational packages for the company’s needs, like OpenSSL or Python Software Foundation. It could mean that the head of customer success meets regularly with the OSPO to provide feedback on specific features customers keep asking for, to see if they could feasibly be developed in open source.

At Capital One, we’re beginning to build out OSPO 3.0, working closely with many different teams to find out how a culture of developer-driven open source could help them do their jobs more effectively and serve our customers better. We’re bringing non-technical teams up to speed on our open source initiatives and, conversely, educating developers about the role they play in the wider organization. We also need to continuously work with our risk partners to improve processes to help our developers contribute in a more structured and automated way to public open source projects. There is no one way to build an OSPO 3.0, but the most important facet is to focus on bringing people from across the organization into the fold.

The 3×3 Model

Open source return stops collaboration with

To delve a bit further into the nitty-gritty of building an OSPO 3.0, it might be helpful to think of it as a 3×3 model. A typical OSPO manages three main components of an open source framework: usage, contributions and community building. For each of these three areas, you should address three key aspects: technology, process, and people. Ask yourself these key questions:

• For the usage (or contribution, or community building) part of my OSPO, which technology is needed to facilitate the task?
• What processes need to be put in place?
• Which people should be included in the discussion?

That last part can be a difficult exercise. Does your company reward cross-team collaboration? Is breaking down silos an activity your engineers relish or something they fear?

Take for example, the usage part of an OSPO. You will need to purchase technology to manage how open source is used to build applications within your company. This could be developer tools, enterprise open source products and/or legal or compliance software. You will then need to put processes in place to manage how developers use open source within the company. Lastly, you will need to involve several people in the usage discussion, including managers from IT, security, engineering, product development and customer success, as well as external stakeholders such as enterprise open source vendors and public clouds. It may sound easy, but several groups in your enterprise may have a preference for a particular platform or set of tools. Do you have a reliable means for driving consolidation? How do you arrange stakeholders to facilitate that kind of exercise?

Complete the same 3×3 structuring process for the next two legs of the OSPO stool: contribution and community building. After your technologies and processes are in place for contribution and community building, then you can think of the people component. For the contribution part, that’s where you’ll involve people from the legal, risk and cybersecurity teams, as well as the same technical folks you involved in the usage conversation. For the community-building aspect, you can start to engage marketing, branding, technical writers, HR, event planning teams and others. In both cases, you’ll have to take steps to ensure stakeholders are aligned as to which communities should receive the highest priority. Do you feel comfortable setting the stage for one effort to take priority over another? If not, you’ll need to think about which stakeholders participate and how you facilitate agreement and alignment on topics that can be prickly for any tech organization.

Open source may seem like the most “techie” thing in the world, but in fact it’s the perfect framework to start a much larger conversation about company-wide collaboration. An OSPO 3.0 could sit at the very center of your organization, driving collaboration in a way that puts your company on a path of success in today’s developer-driven world.

Lead image via Pixabay.