As more organizations realize the advantages of open source, many are looking for ways to integrate open source technologies and strategies into their own business practices. But they've learned that simply throwing developers into an open source project and hoping for the best isn't enough to really reap those advantages. Increasingly, organizations are also recognizing the need for building centralized open source programs offices (OSPOs) that nurture, guide, and align open source best practices with business strategy.
In fact, that work is so important that even a company like Red Hat, which lives and breathes the open source way, established an OSPO.
So what does an OSPO do?
Why build an OSPO?
Building an OSPO is important in businesses who realize a critical truth about open source: just placing code on a public repository is not an effective open source plan. In many free and open source software communities, people refer to this approach derisively as "throwing code over the wall." If that sounds like a plan guaranteed to lead to negative outcomes, that's because it usually is.
And yet when some organizations attempt to do just this, they are almost universally surprised when there is little to no participation in their project outside of their own organization's employees (and sometimes not even then). This is why it is important for a business to create an actual strategy around their open source implementation.
Such strategies can vary, of course, but an OSPO's role is to align the efforts of all relevant parts of an organization—engineering, sales, marketing, content creation—toward making open source methodologies and outputs successful.
This is the piece some organizations can miss: It's not about implementing open source for the sake of open source. It's also about aligning open source tools and techniques with the needs of the organization.
That is the most important mission for an OSPO: aligning open source best practices with the business strategy of the organization.
What OSPOs do
OSPOs use many tactics to make such alignment happen. Here's a list of just a few—a list that's by no means universal, as some organizations will not need all of these tools to perform their functions successfully.
Maintain open source license compliance reviews and oversight. In any company new to open source methodologies (or one working with proprietary software), an OSPO plays the important role of overseeing license compliance. Open source licensing isn't riskier than any other form of software licensing (despite what some might say), but mitigating potential legal risks around licensing remains important. Typically this work involves conducting active software reviews for all existing and incoming code and content.
Guide the organization to work upstream with open source communities. An aspect of good community citizenship is making sure members of an organization are participating in upstream communities, and doing so well. Participation upstream is simply the best way to gain the collaborative and innovative benefits of open source projects.
Foster an open source culture inside the organization. From engineering to sales to marketing—it's important to consistently and clearly communicate how and why open source is beneficial to the organization. This means creating a solid communications strategy, encouraging the organization to adopt open source tools, and educating the organization's associates on the benefits and best practices of open source.
Facilitate relationships with projects, foundations, and standards bodies. Being a good open source citizen is about more than contributing strong code and content to a project. It's about taking active and collaborative roles within the project's community and governance structure. If there's a related software foundation or standards body associated with the project, then being a member or sponsor of that larger organization is important, too.
Inside Red Hat's OSPO
In many ways, Red Hat's OSPO operates in much the same way as any other organization's OSPO—except there are some aspects that don’t fall within the scope of our specific mission.
Surprisingly to many, we don’t focus on open source licensing and compliance. Red Hat started from open source and had a long head start on the rest of the industry, so our focus is more on providing education and resources to associates, not making licensing choices. This isn't to say that Red Hat blithely ignores legal risk and compliance—it's just not one of our OSPO's core responsibilities. Instead, Red Hat has a legal team who can focus on those open source issues that do crop up.
With regard to community participation, Red Hat's OSPO also operates differently than many other offices with a similar function. Because the health and success of the upstream projects with which we work is so important, our OSPO team spends a lot of effort making sure those projects' communities are working efficiently and well. To that end, we pursue what we refer to as "community building": helping new projects set up vibrant communities and assisting existing projects to keep their communities engaged.
Another key difference in how our OSPO works is that we also help customers and partners with their open source journey, especially if they are getting started and just entering the open source ecosystem. We also work with them to advocate open source licenses and corporate stewardship and contribution. For our OSPO, distinguishing ourselves as thoughtful stewards with a stake in a healthy open ecosystem is critical, and speaks to our position as an industry leader in community and within of Red Hat’s Office of the CTO, of which we are a part.
Eyes on the goal
All OSPOs need not look or function alike. But they all have one thing in common: helping to keep the goals of the business and its open source implementation complementary and aligned. By keeping their eye on that important mission, they will certainly benefit the organizations of which they are a part.
About the author
Brian Proffitt is a Manager within Red Hat's Open Source Program Office, focusing on content generation, community metrics, and special projects. Brian's experience with community management includes knowledge of community onboarding, community health, and business alignment. Prior to joining Red Hat in 2014, he was a technology journalist with a focus on Linux and open source, and the author of 22 consumer technology books.