An Introduction to Open Source Program Offices (OSPO): a Community Conversation

Introduction

Earlier this Spring, Rizèl Scarlett, Developer Advocate at GitHub, brought together experts in Open Source Program Offices (OSPOs) for a conversation to explain the what, the why, and the how of OSPOs– including how companies can use OSPOs to bring more Open Source into their organizations.

Joining Rizèl were:

• Ashley Wolf, OSPO Head at GitHub, and a former leader of Yahoo and Verizon OSPOs
• Julia Ferraioli, Co-Founder of Open Source Stories and, hot off the presses, a new Technical Leader of the Cisco Open Source team
• Stephen Augustus, Head of the Cisco Open Source team

Pro tip: Follow Cisco Open Source on Twitter if you want to see an OSPO team with great chemistry and a sense of fun

Hundreds of participants also joined to ask questions.

This piece includes quotes and themes from the discussion (some quotes were synthesized, others edited for clarity), as well as supplemental context.

How this piece is organized

This piece begins by explaining what Open Source Program Offices (OSPOs) do as well as a brief refresher on Open Source generally and its benefits.

Then the piece covers the importance of having an OSPO function — to handle the operational, ethical, and legal responsibilities of Open Source.

The piece offers three tips for expanding the use of OS and OSPOs in your organization, and three tips for OSPOs on how they can be effective.

Finally, it covers two audience questions– common to many people considering Open Source– on maintainability and security risks.

What are OSPOs?

Open Source Program Offices (OSPOs) are responsible for managing, encouraging, and addressing the risks associated with Open Source code.

Open Source code is code that is accessible to everyone, and (almost always) is created and maintained at least in part by members of the public. Its opposite is Private code, where you need specific permission to view or edit it.

Individuals and organizations are involved with Open Source projects. GitHub estimates that 19% of code contributions went to Open Source projects.

An organization can interact with Open Source in two ways:

• By creating or sponsoring Open Source code– serving as the original creator, and having members provide Maintainer (organizing) and/ or Contributor functions. Maintainers code review and organize, and sometimes code; Contributors code, sometimes code review, and sometimes organize. [This is a simplified explanation; there are many other non-coding responsibilities associated with Open Source projects, too.]
• By using Open Source code. Open Source code is incorporated into many other projects. One recent estimate found that 96% of all applications included some Open Source code.

OSPOs cover both of these responsibilities.

Why Open Source?

There are huge benefits for organizations and individuals to be involved with Open Source.

For organizations, creating and sponsoring Open Source code is a tremendous way to give back to the craft of coding and attract talented engineers. Using Open Source code is a cost-effective way to add excellence to your codebase by referencing great work built by others, instead of “reinventing the wheel.”

Pro tip: Open Source is an incredible community to connect with for personal growth and connections, too.

Almost every topic under the sun is included, and being involved with Open Source connects you with a global community of people and ideas. Julia got introduced to Open Source while at a Maryland, USA, educational institution working on a Machine Learning and found her way to a suitable open source project in New Zealand.

As Julia said: “We were able to modify the existing implementations of algorithms. It blew my mind— you can download code from SourceForge, run it on your computer, learn from it, make modifications to it, and I don’t have to pay for it?* That’s wild. So I think from there on out, I was sold on open source. Oh and the research project was a success, too”

* See caveats above…

As Ashley said: “I came to OSPOs because I was always passionate about developers and community and I didn’t know how to put the two of those together in a job. I was also really into intellectual property and nonprofit digital rights groups. And then I researched the work of Gil Yehuda and Heather Meeker.

“Companies were giving code away for free and my mind was blown that there were programs or a team at companies that they were working to help people to be able to build community around code and be good corporate citizens. And I was drawn to this. I thought that’s pretty much it for me. It would be the perfect mix of all the things that I’m interested in. So shortly after that, I joined Yahoo as a product manager and I was then able to transfer and work in the Open Source and standards team and really dive into that world. And I guess the rest is history.”

And Stephen pointed out a great benefit to individuals by creating a public resume of your work and networking:

“What’s really cool about the Open Source work is the visibility — you can build a public resume. You run into a lot of instances where you see someone, say, their GitHub profile, and you’re looking at the pretty green tiles to see what they’ve been up to. You can’t see the work from their private repositories but you can about open source. It helps you build this massive public resume that is really undeniable. … I have this job that I couldn’t have imagined I would have had otherwise without my contributions to open source.”

Pro tip: new to Open Source? You may want to read a piece on a recent conversation led by @eddiejaoude of EddieHub, the inclusive Open Source community. It covers the basics of Open Source and other tips and tricks for Contributors and Maintainers. Learning with the EddieHub Community: Mentoring and Supporting in Tech, and Contributing to Open Source

Who should have OSPOs?

The short answer is, everyone.

The slightly longer answer is, almost every organization needs to have the core functions of an OSPO carried out, whether it is a separate team or a responsibility assigned to member(s) of the team.

As Ashley put it: “If you’re using any software, you need an OSPO. if you have anything to do with software, you’re likely using open source, and so you should care about what comes along with that. The risks that you’re taking, the opportunity to contribute back to projects and be a part of a community all make an OSPO important.”

Julia added on to talk about OSPO Communities of Practice: “If you are a smaller company and only consuming it, you might want an Open Source community of practice. This would include people who, um, understand Open Source or are willing to learn and have them function as your “mini hospital,” to take care of any compliance issues. The earlier you have the awareness of the risks and benefits, the better shape you’ll be in down the road.”

Let’s talk more about why.

Back to the definitions above: when an organization is creating or sponsoring Open Source code, an OSPO makes sure that the experience for non-organization Contributors and Maintainers.

When an organization is using Open Source code– and, as mentioned above, almost every organization does — an OSPO makes sure that the use of Open Source code follows proper guidance and controls.

Let’s say more about that guidance and controls.

It is technically possible to reference or use Open Source code in another project, whether it’s Open Source or private.

However, there are operational, legal, and ethical obligations when organizations (and individuals!) use Open Source code.

• Operational: it is substantially safer, more efficient, and just better for Engineers to use open source code (package) managers, where the Open Source code is referenced, as opposed to directly referenced or included in the code. Using Open Source management software prevents tech debt, saves a lot of headaches, and potentially avoids security and legal risk.
• Legal: All Open Source code comes with a license, which lays out how you are allowed to that code. Private code has licenses too. These licenses vary substantially by levels of permissiveness. If an organization uses Open Source code incorrectly based on the license, it opens itself up to potential lawsuits and is especially a risk during Mergers and Acquisitions.
• Ethical: Open Source users, whether individuals or teams, have an obligation to give back to the communities who’ve created the code.

Stephen spoke to the obligations of Open Source users: “It’s not enough to be a consumer of Open Source. For anyone consuming projects, you do have to consider, if I care about the sustainability of this project, how am I going to help impact it?”

The OSPO can help in each of these areas:

• Operational: by making sure that the Open Source code is organized via a package manager, and that there is a regular review process for security and updates
• Legal: by reviewing the use of the Open Source code to make sure the organization is following the license correctly, and it not, remediating
• Ethical: by making sure that the organization as a whole gives back to the Open Source code its members use, and to role model & encourage the right behavior towards maintainers, including kindness.

Pro Tip: nearly 100% of organizations use at least some Open Source outside of a package manager, even if they also have a manager. That means that the OSPO function may want to conduct a code scan to find all of the Open Source code to organize it.

Pro Tip: some people are not kind to maintainers. Don’t be Some People.

Bringing Open Source to your Organization

The panelists shared three tips on how to increase the use of Open Source in your organization.

Go through existing channels.

If there is an existing OSPO or another formal process to use OS, work through that process. You’ll win friends and make things less complicated– and it’s a big lift to the OSPO team members who are working hard to make Open Source available and accessible to the organization.

Make the case = share the benefits of using and sponsoring OS.

If there isn’t a formal mechanism, start by organizing the benefits of OS.

As Ashley said:

“Build a case around the benefits for doing open source in a way that will benefit your organization: You’ll get help from that go beyond your immediate team– ideas and feedback and contributions from people all over the world. By putting your code out there and building community around it, you’ll be building relationships externally with communities, with teams, with projects, with other companies. You’ll have more influence that way. It will help with attracting talent: Open Source is very hot right now for hiring developers.”

As Stephen mentioned, by articulating the case of OS, you become an advocate for it in your organization.

Point out the risks.

This might sound counterintuitive, but stick with us.

As mentioned above, it is almost certainly the case that the organization is already using OS, whether or not they are formally managing it.

Bringing attention to the risks of using Open Source code — such as the Log4j exploit — can be a way to bring attention to the need for managing open source properly. This applies both to security and intellectual property management risks.

Tips for a Great OSPO

The panelists also shared three tips on creating a strong OSPO function.

Offer multiple pathways into helping the OSPO.

One participant passionately articulated a desire to join an OSPO and shared a concern that many OSPOs require mid or senior levels of experience to participate.

When you consider the benefits to contributors who are eager to boost their “public coding resume,” OSPOs that make it easier for individuals at all levels of experience to participate can unlock a huge source of talent and

How to do that? Clear documentation, providing multiple roles, sharing multiple communication methods (e.g. public or private Slack channels).

Pro tip: Include a Readme file with clear and realistic guidance on the relationship of contributing to the project and full-time employment. As Community Classrooms Founder Kunal Kushwala recently observed, many engineers are keen to understand if helping a company’s Open Source work increases the chance of employment.

Pro tip: @eddiejaoude’s discussion, Learning with the EddieHub Community: Mentoring and Supporting in Tech, and Contributing to Open Source, included seven tips for Maintainers that are also applicable to OSPOs broadly.

At the same time, potential job applicants should recognize that most OSPO offices are very small and need to bring in team members with existing knowledge and expertise. So planning to enter OSPO work in a full-time paid capacity for junior engineers / DevRels / community leaders is likely to be challenging.

Encourage non-coding contributions also.

There are many non-coding ways for individuals to contribute to Open Source projects, such as writing documentation and answering questions for others.

The larger the project, the more these functions matter.

So an OSPO should facilitate non-code contributions.

Stephen, again: “There are so many really interesting parts of these communities that once it gets to a certain size, they do not function without having program managers and technical writers and folks who can handle community building. Not all open source work is a bunch of engineering work. It’s a lovely ecosystem that cannot be simply derived from just commits. So make sure that you’re building programs to recognize all of those contributions.”

Learn from and contribute to the TODO Group.

TODO — Talk Openly, Develop Openly — is a great resource for OSPO teams and Communities of Practice.

TODO is an open community of practitioners who aim to create and share knowledge, and collaborate on practices, tools, and other ways to run successful and effective Open Source Program Offices or similar Open Source initiatives.

As Ashley describes it: “TODO really emphasizes the openness of the group — because we have shared challenges and pain points and we’re all working at the speed of technology and open source. So it’s amazing to have this hive mind together. Over the years, the group has published a number of amazing resources: there are guides and case studies, annual surveys, training, and it’s all available to anybody to use to establish an OSPO.”

Is it risky to use Open Source code, in general?

One audience member spoke for many potential organizational users of Open Source when he asked about the safety of relying on OS, and the best ways to minimize that risk.

“OS comes with its own challenges. There are compliance requirements, for example. And there’s a risk if the project is not actively supported by a good community. How should we avoid or plan for those risks?”

Ashley explained the Linux Foundation’s CHAOSS project, which is building metrics and a decision-making framework when working with Open Source projects. Julia gave a shout-out to Cauldron.io as a software tool to help. And Duane O’Brien got a shout-out as a leader in this space, someone very much worth following.

Julia and Stephen shared a few specific signals to determine if the Open Source community supporting that codebase is strong before selecting that project:

• Is there good documentation?
• Are issues that are being filed responded to in a reasonable time frame?
• Does the project have hundreds, even tens of outstanding Pull Requests (changes to the code that have not yet been approved)?
• How are security risks handled? (More below).

Stephen structured his answer based on the different roles and contexts of the Open Source user.

“Consider this from the hat of the Contributor, the Maintainer, and the Sponsor.

As your organization becomes larger, it is easier to mitigate these risks through financial support — by writing checks for sponsorship.

“But there’s also the Contribution and Maintainership aspects. If I’m consuming, am I contributing back– through direct contribution coding, direct contribution fixes, testing.

“And if it’s a project that I’m sufficiently interested in, should I become a maintainer?”

An OSPO or Open Source Community of Practice is ideally suited to help navigate these issues.

What about the security risks for Open Source code?

Another audience member asked a follow-up question about the specific security risks coming out of Open Source use: “If a company is using Open Source code, then everyone can see that the company is using that code, including hackers. How can you prevent malicious code from being injected?”

Stephen shared a risk assessment model to help decide:

“An organization has to assess the risks of their various Open Source options. Would it be better for our team to do this ourselves, or to ingest some open source project? Using Open Source code, and having things in the open is actually really good– because there’s a higher level of scrutiny just by it being out in the open.

“Given a sufficiently sustained project and responsible maintainers, they’re going to feel duty-bound to make sure that that project is free of vulnerabilities. In that case, I’m really betting on the Open Source project over the internal project.”

The panelists also highlighted the work of the Open Source Security Foundation as a great resource, and a participant gave a shout-out to the Indian Open Source Foundation.

Conclusion

One of the benefits of Open Source, in general, is the chance to participate in supportive and inclusive communities. That may be even more true in the OSPO community– which, after all, is about encouraging expanded use.

So for technologists who want to get more involved, OSPO can be a particularly welcoming space.

As Stephen eloquently put it:

“One of the things that we run into with tech, in general, is this whole imposter syndrome and fear of being too visible and making mistakes in public. Open Source is riddled with that.

“And it’s okay. It’s good to fail in public and it’s good to have a community of support to pick you up there. I think in a solid, sustained, Open Source community, you really do get that.”

As an objective observer, I can say that that’s especially true for OSPO communities.