DEV Community 👩‍💻👨‍💻

Cover image for How Postman's Building Their Open Source Program Office (OSPO)
Jan Schenk (he/him) for Postman

Posted on • Updated on

How Postman's Building Their Open Source Program Office (OSPO)

This is not your classic "How We've Done That Thing" post on Dev. It's not a best practice, nor a step-by-step guide to building a Program Office. It's a in-progress documentary of a company's (Postman) and an individual's (me) efforts to create a meaningful structure within a well-developed start-up: A support program for Open Source, or, an Open Source Program Office (OSPO). Although we don't call it that. Yet.

In-progress means, we're still at it. As of November 2022, we've defined an initial structure and responsibilities for our OSPO, or, how we prefer to call it for now, OTPO. OTPO stands for Open Technologies Program Office, and the name is declaratory for its current responsibilities limited to the scope of the Open Technologies department.

Where It Started

We were not starting from scratch, either. When I joined Postman in October 2021, there already was Open Technologies. And Open Technologies did a lot of the things that you'd see an OSPO doing.
I joined in Developer Relations, an adjacent department, that reported directly to Postman's CEO, Abhinav Asthana, and so did Open Technologies. Kin Lane, Chief Evangelist and Open Technologies Lead, together with others already done a good job of inviting maintainers and contributors from API Specifications Open Source projects into Open Technologies, and into joining Postman. That meant that there was already a business priority to support Open Source projects that mattered to Postman today or would do so in the future.
(As a side note and for the sake of completeness: Open Technologies now reports to the CTO, and Developer Relations reports to Open Technologies after the latest re-org.)

Assessing the Status Quo

So there was already a department hosting Open Source projects, but it lacked structure and people willing to cover the organisational matters of running an effective Open Source approach. It lacked a team taking care of the needs of Open Source projects within a company, and taking care of Open Source in general. The highly respected folks in Open Technologies did what they loved most and what they were hired for: maintaining their projects and contributing to the codebase and the community.

Pitching a better concept

I'm coming from Program Management in DevRel organisations. Providing structure to create something more easily, reducing barriers and removing uncertainties, helping people find supporters to create together and thus build their business inside a business is what I did for the last 10 years. And I saw the potential in Open Technologies, the raw beauty, the support from leadership to invest in the company's future. And I saw that it would need three things:

Structure, Business Support and Empowerment

That's when I pitched the concept of a small team inside Open Technologies and the idea of shared resources to Kin Lane end of September. That's what he said:

That's very much on point. Build it.

What is an OSPO

I hadn't had an OSPO blueprint in mind when I pitched the Program Office concept to Kin Lane. Or maybe I had, but underestimated the scope of a full-fledged OSPO. But yeah, after reading more and getting great introductory resources through the TODO Group, I realised that this is exactly what I want to build. Not only for the projects in Open Technologies, but for the whole company. Delusions of Grandeur? Maybe. Or maybe an opportunity to build something that's very much needed in a company that is still growing at a massive speed and benefits from more structure.

This mindmap gives a great overview on responsibilities of an Open Source Program Office.

Proofing the Concept

Nobody's buying a pig in a poke, they say. We are two months into the creation of the OTPO, and nobody asked me for results yet. I'm working my way to showing impact, helping make meaningful connections within the company (e.g. between Product Managers and API Specifications Leads), write and develop guides and how-tos to make it easier and remove barriers for employees to contribute to Open Source projects or opensourcing their own projects that save others tons of work. I'm holding Office Hours twice a week to give people orientation and a safe harbor for their questions. I'm having great discussions. But I realise that at this stage, it will take more than just me to create a Program Office that has an impact. And it was part of the pitch to have a Program Manager, a Community Manager, a Writer and Editor, and Engineers join the efforts. And that's where we are at them moment, we're hiring.

Building the Team

Reach out to me if you are interested in building the OTPO, and paving the path to becoming Postman's OSPO in the next 12 months. We're looking for a diverse team consisting of

  • a Technical Program Manager
  • a Technical Community Manager
  • a Technical Writer / Technical Editor
  • a Developer Relations Engineer

I'll be linking the job descriptions once they are online, but until that, feel free to reach out to me here or on Mastodon, LinkedIn, or even Twitter if you must.

There'll be more parts to this series soon. It's a documentary of what we're building, and it's a long way ahead.

Stay safe.

Top comments (0)

We want your help! Become a Tag Moderator.
Check out this survey and help us moderate our community by becoming a tag moderator here at DEV.