What the Heck Is an Open Source Program Office Anyway?

Building an Open Source Program Office — A Light-Hearted Guide

Introduction

A lot of pixels have been scattered and ink spilled about the importance of building an Open Source Program Office (from here on in, OSPO) in your software company. If you’re the one the job has landed on, congratulations!

Right now, I am that person. I’ve been wading through documents and videos to find out exactly what the heck all of this is about. And now I’m summarizing it so you don’t have to. Strap in bucko, we’re gonna cover:

• What the heck an OSPO is
• Why even bother?
• What it does
• A step by step guide to get started
• The people you need to build an open source office

This is one in a series of posts that aim to take the mystery out of the OSPO thing. I’m a fellow traveler on this journey — just as clueless as you may be (and possibly even cluelesser!)

I’m a Total Open Source Geek. I Should Know This…Right?

I’m a dyed-in-the-wool geek. I’ve contributed to open source projects, built my own projects, and worked for years to popularize the idea of open source and how to apply it to more than just software, like aerospace and sustainable technologies.

I use Vim, damnit. So you think I’d totally know what an open source program office is, right? Wrong.

This is me. Except I code in Python and have a much cooler color scheme obviously

I know what an open source office program is. Just not an open source program office.

And everything I’ve read about it is pretty dry.

So I’m trying to fix that here.

I’m not providing a comprehensive how-to guide. If you want that, check out the awesome TODO Group and their guides for building an OSPO. This article is more of a semi-organized braindump, addressing what I’ve learned, what works, what doesn’t work, and the confusion, headaches, frustration, and love we’re facing along the way.

Thanks to…

First up, thanks to the TODO Group! I may rant about stuff being difficult to read sometimes, but without all of you there’d be few resources for me to work with at all. You all rock! (Whereas I, trying to make it more accessible, pop-rock)

So, What Is an OSPO?

TL;DR: The bit of the company responsible for supporting open source stuff

In the words of the TODO Group:

A central open source program office is a designated place where open source is supported, nurtured, shared, explained, and grown inside a company. With such an office in place, businesses can establish and execute on their open source strategies in clear terms, giving their leaders, developers, marketers, and other staff the tools they need to make open source a success within their operations.

Sounds good so far. Jina is already an open-source company after all. But what does it mean to support, nurture, share, explain and grow open source?

That Sounds Like Work. Why Bother?

Open source is everywhere. But open source is weird for big companies who aren’t used to working in an open source way. The open source program office acts as a nexus to make open source work in a company’s long-term business plans.

So, What Do I Have to Do?

Big Picture Stuff

This is a summary of How to Create an Open Source Program:

• Make sure new developers know how to get onboard and have clear understanding of the what’s, why’s and how’s of open source.
• Train developers in using our products
• Engage with developer communities and other open source projects
• Talk lots about what we’re doing and cheerlead open source
• Build an open source culture.
• Make sure code is good and release it often
• Make sure we’re not breaking the law with any of the above

Let’s Make it Concrete

Enough buzzword bingo. All of the above are lofty goals, but what can us grunts in the trenches do?

Onboarding Developers with Open Source

We’re an open-source company trying to attract open-source developers. They already have a pretty decent idea of what open source is before they work with our tech. How can we improve upon that?

Training Developers

• Create tutorials, reference docs, general docs, etc for devs
• Series of training videos

Community Engagement

• Create and maintain channels to communicate with devs, internally, externally and cross-ternally (I’m making up words now. Deal with it)
• Events — hackathons, drinks nights, etc
• Reach out via social media to developers and start/maintain conversations
• Reach out to KOLs, build rapport, and ask for support (only when needed for big things)

Talk about Open Source and What We Do

• Blog about our product, open source, etc
• Share what we do on social media
• Work with external partners do get the word out — social accounts, podcasts, blogs
• Regular release notes, pre-release notes, roadmap updates

Foster an Open Source Culture

• Ensure all team members know and understand open source concepts, whether they’re in engineering or not
• Walk the walk. We talk a big game about open source and open governance. But what about opening up this blog post to the public and letting them know our thoughts and feelings about setting up an open source office?
• Smash all the Macbooks and replace with Thinkpads running Debian. Coders of the world unite! You have nothing to lose but your shiny GUIs!

Release Code

• We have milestones and roadmaps for this
• Released on multiple channels — GitHub, Docker Hub, Pypi, etc

Legal Stuff

• I’m not sure what this would cover since we’re a totally open-source company. Since everything we release is open, it’s not like we’re accidentally putting GPL code in closed-source software
• Could we get a license lawyer for this kind of stuff?

Wait…Most of That Looks Familiar

You may already be doing a lot of this in your company now. Congratulations on the time you’ve wasted reading this blog post then! On the other hand, you could’ve read the much longer and dryer thing I’m summarizing…

Step by Step

Find a Leader

Our ideal candidate

Someone who:

• Understands how open source works
• Has experience in coding existing open projects
• Understands the company’s business to help with strategy and planning across business units
• Sociable so they can talk their way into getting things done
• Is able to talk about the deep technology but doesn’t get bogged down in the weeds

Decide Operations

• Budget
• Staffing
• Tools and systems
• Create policies and processes
• Streamline and automate operations

Get Feedback and Buy-in

Talk to everyone, from C-level to devs. In our case this idea came from the top, and our devs are all into open source anyway.

Where Should We Put the OSPO?

In our case, we’re putting our Open Source Program Office in our Developer Relations department. They’re directly responsible for building relationships with developers, a core part of the Open Source Program Office’s remit.

Roles

• Program manager: should be executive-level position with direct oversight and hands-on management for open source activities
• Legal and compliance: I’m lumping them together here. I don’t think they’re so important since we’re not juggling both open and closed software (yet)
• Developer relations, advocates, evangelists: speak at conferences, spread the good word
• Others: tool administrators, training managers, etc — I think our company is too small to have all these roles yet

What’s Next?

Next up will be lots of discussion with stakeholders about how “open” is “open”, and soon a blog post on open governance for you all to look forward to!

Acknowledgements

• Cover photo by Richard Balog on Unsplash