How Bloomberg works with open source
One expert suggests other companies could emulate Bloomberg’s tactics.
• 4 min read
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.
Bloomberg’s OSPO provides internal community engagement through office hours, discussions, and courses, along with a mentoring program for open-source contributors. Within Bloomberg’s workflows, employees are encouraged to identify open-source technologies that could be a good solution for internal problems. One of these solutions was OpenTelemetry (OTel), which was an open standard and suite of technologies that is intended to standardize how different components of cloud ecosystems communicate telemetry, data, and metrics.
“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.”
Top insights for IT pros
From cybersecurity and big data to cloud computing, IT Brew covers the latest trends shaping business tech in our 4x weekly newsletter, virtual events with industry experts, and digital guides.
By subscribing, you accept our Terms & Privacy Policy.
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.”
About the author
Caroline Nihill
Caroline Nihill is a reporter for IT Brew who primarily covers cybersecurity and the way that IT teams operate within market trends and challenges.
Top insights for IT pros
From cybersecurity and big data to cloud computing, IT Brew covers the latest trends shaping business tech in our 4x weekly newsletter, virtual events with industry experts, and digital guides.
By subscribing, you accept our Terms & Privacy Policy.