How Bloomberg works with open source

It’s always open (source) season at Bloomberg these days.

That wasn’t always the case, said Phil Vachon, head of infrastructure at Bloomberg’s CTO office. When he started at the financial-services company in 2010, open source was viewed with suspicion, and tech teams focused more on building their own technology solutions.

But over the past decade, Vachon added, there’s been a growing realization that open source could allow engineers to accelerate delivery of higher-quality projects.

“We’ve gone through great lengths, going from a culture that was very difficult to contribute to open source 15 years ago, to today, where the barriers are actually extremely low,” he said. “We almost virtually give people carte blanche to contribute to open-source projects.”

Internally. Having a community within Bloomberg that handles open source is due in part to the Open Source Program Office (OSPO), which manages the training, process, and legal clearances for open-source projects used by engineers and other staff.

Jim Mercer, program VP for software development, DevOps, and DevSecOps at analyst firm IDC, told IT Brew that while the concept of internal offices that handle open-source concerns has been around for some time, enterprises curious about them could follow Bloomberg’s example of open-source consumption and contributions.

“Having an organization or a group within your organization who can help your management and navigate your use and consumption of open source is definitely something good to do,” Mercer said.

“Not only have we engaged with the wider telemetry community, we created an internal community of people, once we identified this as technology we wanted to adopt, who are actually directly using it,” Vachon said. “That investment culminated, not only us starting to contribute features and functionality back to better support Bloomberg use cases…the goal is to ensure that we’re actually bringing something that’s going to value a wider swath of the audience for tools and technologies like that.”

OTel, Vachon said, has helped Bloomberg both engage with the wider community and develop an internal community. The tool allows users to correlate metrics, logs, and more with a shared context to help professionals see a complete picture of an application’s behavior.

Externally. The decision-making behind finding a community or an open-source project at Bloomberg isn’t quite set in stone.

“We do actually have programs where we directly contribute money to certain open-source projects that are of high impact and value to Bloomberg,” Vachon said. “Maybe we don’t have someone who’s a contributor working on it, so we [aren’t] directly putting Bloomberg hours into it, but at least we want to make sure we fund and sponsor it, and these are usually things that are directly related to our business or the tools our engineers use very heavily.”

Finding a way to open source. Mercer said that organizations looking to implement the Bloomberg model for open source should consider a version of the OSPO, especially if they can use it to better understand how their teams are already using open source.

An open-source audit can be achieved by utilizing software composition analysis tools and software bill of materials to catalog what’s in use.

From there, organizations might consider where it could make sense for them to be a good steward of open source and contribute. One way to determine if a tool or project is ready for release to the open-source community, Mercer said, was whether or not a team is using it heavily.

“Are our applications and the way we run our applications dependent upon this project?” Mercer said. “Maybe we have a couple developers that created something pretty interesting internally that might be worth sharing back with the community.”