Suzanne Daniels, Nick Trogh and I just rebooted our contributing.today meetup. The three of us met back when we were all working at Microsoft. Suzanne has since moved on to become a Developer Relations Lead at Spotify, I now work as a Staff Developer Advocate at Aiven, and Nick is a Senior Content Developer at Microsoft.
The 3 of us started this virtual-first-and-only meetup to share our enthusiasm for open source around big events like Hacktoberfest, and the annual FOSDEM conference in Brussels. We’ve done these meetups weekly at one point, which was bananas.
We’re now kickstarting this thing again, but with a much healthier, monthly cadence. March 9th we talked about Open Source Program Offices.
Do you even OSPO?
Our guests? Josep Prat, Open Source Engineering Manager at Aiven, Per Ploug Krogslund, OSPO Lead at Spotify, and Vicky Brasseur, Open Source & Tech Strategist at Wipro, and the author of “Forge Your Future with Open Source”. Vicky has done OSPOs and open source strategy for companies “for a very long time”.
Amanda Casari, Open Source researcher and DevRel at Google OSPO, unfortunately had to cancel because she wasn’t feeling well.
I was interested in what kind of tasks the OSPO at our guests’ companies own. Open sourcing internal tooling? Contributing to upstream projects? Managing relationships with open source initiatives? Policies and/or programs on FOSS contributions? Internal education? All of the aforementioned? Something different entirely?
The OSPO at Aiven focuses on 3 pillars: contributing open source code and contributing to third-party open source projects like PostgreSQL and Apache Flink, cultivating the open source culture within the organization, and they are also responsible for governance and compliance. Aiven’s OSPO is 10 people strong.
Wipro is not your standard OSPO, rather Wipro consults their customers on how to OSPO. Vicky described it as “more of a think tank OSPO”, focusing on “bigger picture, strategic things”.
Spotify’s OSPO focuses on operational tasks: compliance, legal, enabling how Spotify contributes to open source, and how to release their own. Per: “We drive the conversation of why we engage in open source, and have that be more than because it's the right thing to do”.
Per has just recently joined Spotify, but the OSPO itself is in its second or third iteration. The first iteration was a passion project of a couple of engineers. Over time it grew to something more mature and needed people to work on full time.
“It’s important to establish a strategy, and a shared idea of why we're doing this, from a business perspective, for open source to get the attention, priority, and budget it needs. At this point we have a lot of versions of that shared idea.”
For existing projects, Spotify needed to define how to operate in the open, how to deal with an issue tracker being in the open.
When Josep joined Aiven in the Summer of 2021, that was the start of the company's OSPO.
But the open source culture was already there. Josep: “The four founders contributed to open source. If something could be patched upstream it would.” As the company grew, so did the need for a separate entity to make decisions independent from what Product wants or needs. Aiven hired a dedicated team to help maintain the projects the company relies upon, and to prevent single vendor open source. Josep: “When any engineer needs to fix something upstream, we make sure they can go ahead and do it, without worrying about licenses and CLAs.”
Vicky tells us that the official first OSPO was at Sun Microsystems, back in the ‘90. So the concept has been around for a while, but it hasn't really gained adoption until recently, due to the massive growth in and of FOSS, but more the mindshare of the criticality of free and open source software. “Businesses would say they don’t use open source software, but developers brought it in through the backdoor anyway cause they had to get their work done, and open source was the best way to do it. Now they're letting it in through the front door as well, and they don't even know anymore what they're using.” Today they feel the need for an OSPO to get all their ducks in a row, map the links in their supply chain, and go fix the weak links.
“It is a business need - even if I as an individual have a very free all the things inclination, the business I work for and which have their own needs.” It’s Vicky’s job to help Wipro’s customers meet their goals through FOSS.
OSPOs Stakeholders
Vicky: “OSPOs are cross-functional. Depending on your company's needs, you may be more of an outbound, marketing OSPO, an inbound, compliance OSPO. Or like Aiven, that has an outbound, contributing OSPO.”
The primary stakeholders at Spotify are in the Engineering department, in the platform teams, says Per. “There’s a natural stakeholder in Legal, and in Security, assessing the risk of using open source. But increasingly also HR. How do we look at open source in terms of promotions and career progression? But also: how can teams use their open source work to attract new talent?”
Vicky: “Don’t forget about retention either! It costs a company so much less to keep people happy, than to re-hire when you push away people by not having good policies around open source. More OSPOs should partner with their HR department!”
Josep: “In two companies I worked at previously I tried to work on open source the legal way, and they didn't know what I was asking them - signing a CLA to give away IP rights to a thing I'd build in company time... to another company? Outrageous!”
On dependencies and SBOM
I was interested in whether the OSPO is supposed to “own” the SBOM (Software Bill of Materials). According to Vicky you'll find older OSPOs, that were originally found around compliance, to own the SBOM, but it's not very common. That being said you do “need to make sure your SBOM is not where your software supply chain information goes to die. You can't make an informed decision about what component needs what kind of support unless you are aware of what's in your supply chain!”
At Aiven the SBOM is owned by Security. And Spotify is “interested in the dependency graph for the health aspect, not so much for the security perspective”. Per: “What projects can we support (financially) that are critical for our business.”
Vicky suggests using tools like Bitergia and CHAOSS for monitoring community health metrics. But generally your OSPO is going to be able to look at a project and correctly assess its health and sustainability.
Per: “I'm probably not the only one who spent December dealing with Log4J. To the outside world it looks perfectly healthy and well-maintained. It took a lot of time to figure out where actually we use Log4J and nobody really knew. Like a 3rd party SaaS platform that uses it in their system, even. Ideally you will want to identify where the vulnerabilities are in a timely manner.”
Josep agrees with Per that as an industry we need to define what it means to be fragile. “A project is not fragile (just) because it has bugs in it, but because it's unmaintained, or only maintained by people in their free time.”
Vicky wishes there to be a way to identify weak links - projects like the one in the famous XKCD comic, maintained by a single person, living in Nebraska - programmatically, automatically. “Harvard recently published data on the most critical open source projects, which hopefully help companies identify what things need their support.”
OSPO well done
OSPOs have almost a facilitating role, how to make sure then that the business recognizes the impact? Josep focuses on three areas at Aiven:
- Working on issues - how many community issues do we collaborate on, support, and help fix?
- Patches, PRs reviewed
- Sharing knowledge through talks, blog posts, mailing lists, …
Timelines in OSS are very different from the business, says Josep. Product teams release several times a day. “In open source you submit a patch on the mailing list, and then you wait. And you wait some more.”
You may have some self-imposed OKRs for this quarter, but nobody else cares about the targets you set for yourself. “How many issues fixed, or PRs merged are terrible measures for success, they're entirely out of scope.”
Per: “It's a bit too early for metrics for the OSPO at Spotify, but my working theory is that we need to establish a culture of ownership of our projects, no stale issues, no stale PRs.”
According to Vicky all is fair, except for vanity metrics like GitHub Stars. “The only metrics that count are the ones that are tied to your business' goals. Throwing money and time away is just business malpractice. If you want to track and present goals to stakeholders, Bitergia and Cauldron do a great job at presenting data, but you need to figure out why you're investing in open source in the first place.”
Want to learn more about how to OSPO? Check out the resources by the TODO Group, part of the Linux Foundation, around corporate open source program offices. OSPO++ is another group, geared towards academics and civic society. OSPO-zone, the OSPO alliance under the Eclipse Foundation, recently released the Good Governance Initiative.
Next month we’ll talk about databases, and we have dates planned to talk about Docs and open source documentation tools, open source business models, and other topics: https://contributing.today
Top comments (2)
// ID Validation
static boolean isValidEmployeeId(Long empId) {
String regex = "^[1-9]\d{5,6}$";
String empIdString = String.valueOf(empId);
return empIdString.matches(regex);
}
Compilation Failedfile.java:98: error: illegal escape character
return empIdStr.matches("\d{6,7}");
^
1 error