Is it time to set up an Open Source Program Office?

Google, Microsoft and VMare all have them and their use is spreading as security concerns mount - but what exactly is an OSPO?

Open source software is a showcase of the power of collaboration, developers from different organisations or none at all coming together in a spirit of problem-solving for mutual benefit, even if in other areas they might be in competition. As a development and organisation model, it has proved massively effective at producing high quality code at speed, and in serving niche areas that are of little interest to proprietary vendors.

Open source has many advantages, but ease of management is not one of them. Open source software is commonly constructed from libraries and components from a variety of different developer communities, released under a range of different licences, and subject to continual change. Core developers leave projects and new ones join; security holes emerge and need to be patched, and so on.

The right culture

Organisations that contribute to open source software at scale need structures to manage the fast-moving ecosystem, but more fundamentally, they need the right culture, says Sanja Bonic, head of open source programs office at database company Percona.

"Open source only works if you already have an open source culture or a loose performance process, otherwise in your enterprise the question will always be about, ‘but how do I know if my people are actually working?', which is hard to quantify in general and even harder when you're dependent on someone outside the company approving your members' contributions."

Buy or build?

Another key question is when to adopt an existing project and when to start your own. Is there something already there that can be tweaked to your requirements, or would it be simpler/quicker/cheaper to start afresh?

Frank Reno, principal product manager at data and analytics firm Sumo Logic, has been through that experience. The company started off by building its own deployment tools but shifted to open source alternatives once tools like Terraform became available.

"We are a born in the cloud company and we needed a reliable way to provision our cloud infrastructure with the right abstractions, so we created our own internal tooling to achieve this. Fast-forward ten years and now you have many tools that are the gold standard and we are embracing those."

His colleague, cloud software engineer Marcin Stozek, adds: "If there is an already established project, then make sure you have good reasons for creating a competing software project. You can potentially innovate faster if you control the whole process, but creating and maintaining community is a task one cannot ignore."

Scaling up

Organisations that play a lead role in software projects are likely to find, sooner or later, that they need to scale up the communities supporting those projects. Keeping contributors' motivations aligned as the team grows is easier said than done, according to Dawn Foster, director open source community strategy at VMware.

"Scaling a community is hard work and something that a lot of open source projects struggle to do effectively," she says.

"It's important to have a person - or team for a large project - focused on building community by making it easy to quickly onboard new contributors in a scalable way while also working to build a community culture where people enjoy participating to help your project retain existing contributors."

As teams grow, they can become less cohesive, inclined to split into cliques. So how can project leaders steer the ship and foster the all-important sense of ownership? Don't leave it up to chance, advises Stozek. Developers' passion will ebb and flow and relying on enthusiasm will only get you so far.

"It helps to have a dedicated person inside the company who frequently asks questions, like, ‘Who is the owner of repository A, B and C?'"

Recognise and reward positive contributions in an open way, urges Bonic.

"If people feel like their suggestions and contributions - internal and external - are at least considered, they will have an easier time taking ownership, even for things they weren't assigned to. In a nutshell, if you want to foster a sense of ownership, you have to be transparent, allow for input, and explain how decisions are made - and be consistent."

Dealing with the docs

Just as important as ensuring the core developers remain engaged and that new coding talent flows into the project is keeping up with peripheral support activities such as documentation. Poorly documented code is the root cause of many a software woe, yet documentation has long been seen as a lesser role.

"Docs have been a problem historically in open source communities," says Matt Jarvis, developer relations at Snyk.

However, he goes on, as the importance of open source has grown so has the interest in non-code contributions. After all, not everyone is, or wants to be, a rockstar dev.

"Areas like documentation are actually a great entry point for folks to get involved in a project who may not initially or ever be able to contribute code, and recognising the effort of non-code contributors is seen as extremely valuable in managing the health of communities. Ideas like ‘chopping wood and carrying water' now carry a lot of cultural cache and are highly valued as contributions."

Lorna Mitchell, developer relations at database managed services provider at DBaaS provider Aiven believes that pitching in to help with less popular tasks should be part of the ethos.

"As an organisation with contributors and maintainers on our payroll, Aiven sees it as our responsibility to also lend a hand with the less popular tasks alongside the more mainstream code contributions," she says.

Being able to rely on a sense of personal responsibility for creating clean well documented code is the ideal, says Bonic, but this is unlikely to be sustainable as teams grow: "Management is key here: reward people who do it ‘right' rather than the people who do it ‘fast' but happen to omit tests or documentation."

The open source program office (OSPO)

As the above exchanges show, managing open source projects is surprisingly complex with many moving parts. With organisations increasingly reliant on code they have created jointly with others, many are looking to formalise the arrangements in the shape of an Open Source Program Office (OSPO), taking a lead from tech giants like Google and Microsoft - as well as smaller ones such as Aiven and Percona.

In its guide to creating an OSPO, the Linux Foundation describes it thus: "A central open source program office is a designated place where open source is supported, nurtured, shared, explained and grown inside a company."

The mission of the OSPO is to maximise the organisation's return on investment and reduce the legal and security risks of using and contributing to open source software by managing the messy licensing and legal issues, communicating strategy, engaging with communities and fostering a positive culture. The OSPO can also help with ‘build or buy' decisions, decide when to release code so that outside developers can contribute, handle licensing issues, and so on.

An OSPO can be quite a small team, staffed with programme managers, compliance and legal professions and developer outreach evangelists, but it does need to be able to wield considerable clout and should be headed up by a high-level executive, the Linux Foundation advises.

It's easy to see how this approach could work within, say, Google, where software is their bread and butter, but how widespread is the idea of an OSPO outside of the realm of tech firms?

It's early days at least in the UK and Europe says Amanda Brock, CEO of the not-for-profit group OpenUK, but it's an idea that is gaining traction as it's seen as best practice, particularly at a time when bolstering cyber security is a top priority of governments.

"They are evolving in both the public sector and universities. The European Commission set up an OSPO and is looking to build a network of them across Europe. Biden's Ordnance of May 2021, focusing on software security, also recommends that organisations set up an OSPO."

If your organisation uses and contributes to open source projects and is dependent on what they produce, it might be time to think of setting up an OSPO of your own.