Bloomberg has been fostering open solutions for the financial industry for quite some time, so it should come as no surprise that they also have been actively engaged in the open source community, with an eye toward promoting more rapid innovation across all aspects of the organization worldwide. Today, we're talking about open source for good with a Member of the Bloomberg CTO Office, Kevin Fleming. Kevin focuses on Bloomberg’s technology community engagement, including the company's involvement in open source projects and standards. He has been an open-source developer and project manager for nearly three decades and, in today’s episode, he shares what the term ‘open source for good’ means to Bloomberg and how it fits into the company’s strong philanthropic history. Tuning in, you’ll learn about the reciprocal relationship Bloomberg has built with the open-source community, some of the hurdles Kevin has had to overcome in implementing the open-source programs at Bloomberg, and the main benefits of these programs for Bloomberg and other organizations, plus a whole lot more! We hope you’ll join us.
Key Points From This Episode:
Links Mentioned in Today’s Episode:
[00:00:02] ANNOUNCER: Welcome to The OCTOPod, hosted by Alan Clark, and brought to you by the SUSE & Rancher Community. Alan has spent his software career focused on open source advocacy and emerging tech. In The OCTOPod season one, Alan talks with experts across technology about trends and challenges in open source, from building communities, to diversity and inclusion, to keeping the open in open source.
[00:00:36] AC: Hi, everyone. Welcome to The OCTOPod. We're continuing our conversations about open source. Today, we're talking about open source for good. My guest today is Kevin Fleming. Kevin is a member of Bloomberg office of the CTO and focuses on Bloomberg’s technology community engagement, including the company's involvement in open source projects and standards. He's been an open source developer and project manager for nearly three decades. Kevin, it's an honor to have a fellow OCTO join me on today's podcast.
[00:01:12] KF: Thanks, Alan. It's great to be here.
[00:01:14] AC: Kevin, you're from Bloomberg? Yes, that Bloomberg. The technology drives the world's financial markets. You've got, what? 6,500 technologists contributing to systems that fulfill the needs of financial market participants from around the world. Everybody knows Bloomberg, but perhaps less likely familiar with the company's ties to open source.
I'm interested to hear about that, but first, let's set the stage for the short time that we have today. I know that Bloomberg has participated in open source projects like Solar, Hadoop, OpenStack, and others. So, why open source? Why is it that open source is important to Bloomberg?
[00:02:01] KF: Well, since we don't have a couple of days, I'll try to keep this relatively short. Bloomberg is a bit of an unusual player, I guess, in the technology space and we're not a young company, we've been around for a long time, 40 years or so I think, which means our technology stack has incorporated every technology that's been relevant in all of those years, in that entire time. Of course, open source infrastructure is a relatively new player in this world. That means that for many, many years, we either bought technology or we built technology. Those were how we solved problems, like many big companies did, we would either build or buy, that was always the equation; build or buy. Then, open source communities came along and started building really, really amazing technological tools that could solve problems, many of which were problems for which there were never buy solutions before. They were new challenges with new solutions.
As we began looking at those sorts of things, our management team said, “Hey, when we are either replacing an existing piece of technology in our infrastructure, or looking at deploying a new piece of technology in our infrastructure, we need to consider open source solutions as an equal opportunity, just like building or buying, and weigh them against all of those things.” What it turns out, of course, as many people who are listening to a podcast like this know, that very often the open source technology tends to be the winner. It's better in many, many ways. Then, of course, you have the source code, you can participate in the community, and all of those kinds of things.
You mentioned Solar and Hadoop and there are countless other numbers of things of pieces of open source software that we've used, which have displaced. Things that we had built ourselves previously or that we had purchased from proprietary software vendors, which then means we get a better tool, but we also get to participate in the community and our engineers learn new skills and all of the other benefits of participating in open source.
[00:03:57] AC: Yeah, that's one of the things that I wanted to highlight here is my interaction with Bloomberg in these communities has been that they're not just consumers of open source, but they are contributors and participants in these communities as well.
[00:04:12] KF: Yeah, we try very hard to do that. When a team is evaluating potentially using open source software, as I mentioned before, they may find that a particular project exists which solves, let's say, 80, or 90 percent, of the thing that they're trying to do, but doesn't quite do all of it. Then, a part of the discussion is, well, could we just build the rest? If we built the rest, would it be something that would be unique to Bloomberg? Or would it be beneficial to the rest of the community that uses Solar or uses HBase or uses whatever it might be? That becomes a fundamental part of the equation then. If you are looking to buy products and they don’t quite do what you need, well, then of course, you can't improve them. You have to have the vendor do it on your behalf and you don't know when that's going to happen.
If you're going to build it yourself, we have to build the 80 percent. You can't just do the 20 percent part because you have to build the whole thing. That's a great combination. That means that you get to benefit from the work the rest of the community has done, but then also give back things, which, as it turns out surprisingly often, the things that we contribute back are things that people in the community had been wanting, but they never asked for.
No one ever brought it up and said, “Gosh, it would be great if the software worked this way.” But as soon as someone makes that available, they go, “Hey! That's a solution to a problem I've had for years, and I never asked if it could work differently.” So, that's a great feeling for our team members when they get to contribute things like that.
[00:05:37] AC: That's awesome feedback. We're starting to hear the phrase “open source for good.” I think hearing it used in and throughout the open source world. What does open source for good mean at Bloomberg? Why now? Why are we hearing about this now?
[00:05:57] KF: Well, the first part is easier for me to answer. Bloomberg as a company has a very strong philanthropic history. The founder of the company is very much into supporting social good causes all over the world using the resources that he has available to him as a result of the company's success. We have a very active and engaged philanthropy team who I collaborate with on projects fairly often.
A few years after I joined the company, one of the discussions we had was, the philanthropy team was interested in getting more members of our engineering team engaged in volunteer activities. We do lots of volunteer activities all around the world, there's probably half a dozen every week of all forms, but there are certain departments that may not have as high a percentage of engagement as other departments do, and the engineering team happened to be one of those.
We were brainstorming about various ways that you might be able to get more engineering team members engaged in volunteer activities. I said, “Well a lot of the open source software that we use has a home in some sort of nonprofit organization.” Whether that might be the Apache Software Foundation, or Pythons Software Foundation, or Software in the Public Interest, there's a whole bunch of them. Those are charities. I mean, they're a different form of charity than what our philanthropy team usually works with, but they are charities.
We had a discussion with them and they needed to do some learning about what open source software was and how communities work, but once we got past that point, they realized that if we spend time improving software that is – its home is a charity, that's a public good. That benefits everyone in the world who's interested in using that software it has educational aspects, it has many other aspects.
Once we got over that small bump, then I said, “Okay, well, what if I organized events where we got people from our engineering team to gather together for a day or two days?” We chose a project, and said, “Let's go spend time fixing open bugs and writing documentation and improving tests and various other things that that project would like to have done.” If I did something like that, do you think that the time that the people put in could count as volunteer time just as if they had gone to one of our other volunteer activities? They said, “Sure, let's try it. Let's see how it goes.”
We did our first one, having absolutely no idea what response we were going to get. We got 35 people to come in on a Saturday, and work on an open source project just because they wanted to. It was really heartwarming to see that response. We've now done this, I've lost track of how many there are and pandemic obviously has made remembrance somewhat harder, but I would say we've probably done this eight or nine times now, the events have been both in New York and in London, because we have major facilities in both locations. It's expanded beyond just our own team members. We now often have members of the local community of that open source project will just come to participate in the event.
We've also had groups from students from colleges and universities who are nearby who will say, “Wow, yeah, we're really interested in doing data science in Python and Bloomberg is hosting a weekend event to work on Python data science tools. Let’s have some of our students go and also participate.” In the end, it means we build more community, we create more contributors for the project when people come out of this, who may have never contributed that project before, but now have learned how, and maybe in some cases, even got a patch merged while they were there at the event, which is a really great feeling for a brand new contributor.
Then they have staying contributors and obviously that's the best end game here is they stay contributors. So, our philanthropy team is really happy about all of that. They see more people getting engaged. They see this as a philanthropic good, we're doing good for the world by making the software better. That's how we got there.
[00:10:01] AC: So it sounds like those events may have morphed a little bit from the initial writing patches or whatever to also mentoring and particularly, as you mentioned, you've started getting college students and so forth involved. Has the program changed a little bit? You're now doing more mentoring at these events, or how has it changed over time?
[00:10:25] KF: Yeah, when you do something for the first time, and you have absolutely no idea if it's going to be successful or not, you tend to minimize the amount of effort you put in up front, because you don't want to spend weeks and weeks putting together a big complex event and then have it be a flop, but then when it's a success, you have to learn, what went well? What didn't go well? For example, what didn't go well, the first time, as we told people, you're going to have to have a laptop, your laptop is going to have to meet one or two of these sets of criteria. You're going to have to have a certain set of software already installed, so that you can be prepared to write patches and test them and things like that.
Some percentage of people didn't prepare, so a portion of their day had to be spent getting themselves ready to be able to participate. They lost a portion of their time being able to do that. Then, we learned, okay, well, that's going to happen. We should be prepared with a backup plan, which is some virtual machine, probably in the cloud, where everything has already been set up. They can just say, “Oh, your laptop isn't sufficient. Maybe you work on a Chromebook or some other laptop that isn't really suitable for doing heavy duty software development directly on it. Great, we'll give you a virtual machine that's hosted somewhere in the cloud, just log in here, everything's been set up for you."
The second thing we learned was, we originally thought that just having one person from the project that was the beneficiary of the event, one of the core developers, or maintainers, or whatever they happened to call themselves on site to help people along as they struggle, wasn't sufficient. You end up needing probably one of these well trained, well known people, for each group of about six to eight participants, because especially for the first few hours of the first day, everybody's at the same place, they don't know how to get started, they are having trouble building the software.
We have increased the number of people that we bring in from the project to do that hands-on mentoring during the event. That has worked out really well. As I said, then, since those people tend to be the projects maintainers, it's really common at these events now where someone will work through Saturday, get their patch ready, go open a pull request on GitHub, or however submit it however that project wants things submitted. The maintainer who was helping them is right there with their laptop, and they say, “Yep, I see it. As soon as the continuous integration tests are done, and I see a green light, I'm going to merge your patch in, it's going in the next release.” That's just I mean –
[00:13:04] AC: Immediate feedback. That's awesome. Yeah –
[00:13:05] KF: Most of us have never been in for Mac, because we've always done it over email. It's a long cycle, you never see the other person's face, and you don't really know what's going on. We've had mentors who've commented after the event, that they had not had that kind of one-on-one experience with new contributors before either and it made them feel good about doing this. We want everybody to come out of this feeling good and the software is better and everybody wins.
[00:13:30] AC: That's cool. Thank you for sharing what you've learned there, because it raised those kinds of questions in my head. How do you make this effective? I like that immediate feedback. That's awesome. Tell us about Bloomberg’s program, I think you call it tech at Bloomberg. What is that that makes it motivating to those that are participating?
[00:13:52] KF: So, Tech at Bloomberg is a brand that we use for all of our interaction with the technology community, what you might call your innovation communications, so social media, and blogs, and all kinds of contributions and various things along those lines. We built that because, again, going back to the company being around for a while a lot of people don't think of Bloomberg as a technology company.
Maybe they've come across, I don't know, some of our media properties for example, because we're in a bunch of different locations there. Or maybe they've been the beneficiary of one of our teams being really, really good at getting Bloomberg terminals into a movie or a TV show. They see them on the screen and they just happen to know that Bloomberg, but they don't really know anything about the company or what we do or anything like that.
Telling that story of luck, yes, we as you say, we are very fundamentally important to the financial industry around the world. We produce tools that lots of people use to make their investment management decisions every day. That doesn't happen without smart people, building good software, moving data around, and connecting technologies together. So we need to do that, that means we need to tell the story of what those people do.
We have multiple people, myself and many others, who participate in ensuring that we get to tell that story. Part of that is open source contributions. If we succeed in contributing a significant new feature or a performance enhancement or something else to an open source project, we want to let the world know that that happened. In many cases now, the project themselves will blog about it, or mention it in a release note or something like that, or do their own podcast for example, that's happened a couple of times.
We make sure that we can connect all those dots together and that the community who hears about that contribution knows that it was a direct result of Bloomberg engagement with the project. That's what – that's what that brand is really all about is engagement with the technology community.
[00:15:53] AC: Okay, so have those engagements been mostly about code, right? The events we talked about seem like they're very focused on code. Have there been other types of contributions? Have you found those effective as well or less effective? What have you found?
[00:16:09] KF: Yeah, so not to turn this into too long a story, but one of the technology domains that Bloomberg invests a lot of time and energy and resources into is user experience design. We want to make sure that our product, which our users tend to sit in front of for their entire workday. We won't speculate how many hours that is, but they sit in front of it for their entire work day. We want to make sure that they enjoy using it, that it's effective for them, that they can find the things that they need.
We have a moderately good-sized team who that is their job. They're people who are experts in how you build a product to make it comfortable for the user to use, and effective for the user to use, and efficient for the user to use. We've actually applied those skills to open source software as well. Years ago, I can't remember how many now but it's been a number of years, when we began participating in the Project Jupyter community, as we were beginning to incorporate Project Jupyter actually into one of our products. One of the obstacles we ran into was that its user interface, we’ll say, was less than optimal, to put it charitably. Lots of users really didn't like the way the menus were structured, and a number of other things.
At one of these events, where we just had people gathered together in a room to work on code, one of the leaders of our user experience team organized a parallel activity, where they use their user experience design knowledge and expertise to run an event gathering feedback from the people there about how they would like to see it be different, what kinds of problems they ran into using the software every day. Not could they fix the code? Were there bugs? But literally, do you have challenges finding the correct menu item? Or does it do this does this order of menu items make sense to you?
The result of all of that was a report back and a proposal to the Project Jupyter community, saying, “We think your user interface would be better if you structured it this way." You might not be surprised to know that was successful, those changes were made. Now the user interface is more in line with what people expect it to be. That's not the kind of contribution you hear about very often in the open source community –
[00:18:20] AC: No, it’s not but that’s very important –
[00:18:23] KF: But a lot of open source software is end user facing. That wasn't the case 30 years ago. It was mostly behind the scenes infrastructure that you talk to over a network, but a lot of it is user facing now. Users expect certain things. You have to have that skill set available in your community to meet that requirement. That's another area we've been able to contribute.
[00:18:45] AC: Perfect. Thank you. We talked a little bit about when you started how you had to sell the idea within the company to get this started. You've learned at the events that you need different preparations and to handle scenarios. If somebody else is listening to us and going, “This is a great idea. I want to go incorporate this in our company,” what are some of the hurdles that you've had to face, beyond those that we've already talked about, and the hurdles in creating this program? How have you overcome those?
[00:19:24] KF: That's a good question. I guess one way to put it is, people like you and me, who have been in the open source community for a long time, have this impression that the open source community is really big. It is big. It's easily millions of people around the world are actively involved in open source projects. It's not big enough to be something that the general population is even aware of though, right? Most people, if you just grab a random person off the street and even mention open source, they have no idea what you're talking about at all.
That means that your corporate philanthropy team has probably never heard of open source or if they had it was in passing and they never really understood what it meant. Your events teams and possibly your marketing and communications teams, depending on what industry your company is in, may not have any awareness of it either. So, that's going to be the first hurdle, is how do you help them understand what the nature of the open source community is? How it's a global collaborative effort to produce better software, all of these sorts of things. It's almost teaching them about an entirely new kind of science, for example, or a new domain of art or something that they may have just heard of in conversation, but they have no idea what it is.
If you're going to get to the point where they can understand that contributing to it is a benefit to the public, they're going to have to have that level of understanding. You have to help them get there. What I found, I guess, frustrating may not be the right word, but it's the word that comes to mind. There isn't a resource you can go point them at, to get them jumpstarted, right? There's no book you can point them at that says, “open source for non-technologists.” This is how you learn about what open source is, right? You're going to have to learn how to do that, if you're in an organization where you need to help educate those people, then you'll have to learn how to do that.
Once you can get there, though, then they start to see the benefits of participating in all of this. Then, the next part you've got to deal with, we had to deal with this as well. I'm sure most big companies will, is most companies have policies around software publication software being written by their employees and being contributed and all those kinds of things. You'll have to make sure that the events you organize are compatible with your company's policies and all those sorts of things.
Probably not as big a hurdle as it used to be, because more companies are familiar with this kind of thing now and more of their engineering team members are active open source community members, so they've already had to understand how to enable that. But when you're organizing a big event, you're doing it in the company office on a weekend, potentially using company computers and things like that, you’ll find little places where the company's policies don't quite contemplate, “Yeah, this is actually a volunteer event, and we're giving away all the software we write,” and you'll have to help some people become comfortable with that.
[00:22:20] AC: Okay, so to follow on that. If they come up to you and say, “Why are you doing this? Why are we involved in this?” What are the benefits that you tell them that you're getting from this, right?
[00:22:33] KF: I guess it depends on the person who’s asking, and what I know about what their understanding of this might be?
[00:22:38] AC: Yeah, I was going to say your answers probably very different from the lawyer, than it is from the accountant, than it is from the marketeers, right?
[00:22:44] KF: I would say, that one way to approach this is, it is a primary way in which software developers continue to learn and expand their skills now. Let's say you are a person who went to university, got a four or five-year computer science degree, maybe you even went further and spent a couple more years and got a master's degree or something like that. Then, you're in the industry, you're developing software, and part of a product team, and getting things out the door. Five years later, if you haven't continued to engage in the rapid pace of enhancement and innovation in the software development community, then you're falling behind. There's no standing still. You’re either falling behind or you're or you're staying current.
Since so much innovation is happening in open source projects now, if you're not participating in those, you're missing out on learning about that level of innovation and how those new skills are being developed. I can point to a specific example of that where one of the – when we organize these events, we tell people which open source project we're planning to work on, and we tell them what skills they're going to have to personally have. For example, if the software is written in C, well, then they're probably going to have to have some decent amount of C skills, or Java or Python, or whatever it might be.
We had an event that the tool we're working on is written in Java. We had some people who were concerned. They would email me privately and say, “Hey, the last time I worked in Java was when I was in university, and I graduated eight years ago. Do you think I can participate in this event?” I said, “Well, honestly, it may be a little challenging because software being written in the open source community in Java is most likely going to be using the latest and greatest bleeding edge features of the Java language and the Java library.” If you haven't had the opportunity to refresh your own skills, you might find that you open up the source code in an editor and you don't recognize it, because it doesn't look what you remember Java being.
That's one way to approach this is that this is a way now that engineers keep themselves fresh, keep learning about what's going on in the community and all that stuff. A lot of this sort of thing, there is no other avenue. There's no continuing education for software developers that teaches them what's new in software development in 2021, like there is in so many other disciplines. You have to seek it out and figure out how you can do that yourself. Open source projects can be a great way to do that.
[00:25:17] AC: Yeah, I was going to say, what a great way to do that, because you're actually doing something real and contributing to the good.
[00:25:24] KF: Yup.
[00:25:25] AC: So, that's a great example. This has been very enlightening and interesting. I can tell that it's, it's developed into an important aspect for Bloomberg. Are you seeing other companies, other Fortune 500, other financial companies taking on similar programs?
[00:25:45] KF: I have had a lot of conversations with peers at other companies, both in inside and outside the financial space, who – their open source programs may be slightly younger than ours. For example, maybe they haven't had an open source community advocate for nine years, which is how long I've been doing this. Maybe they've only had them for three or four years. So they're at an earlier phase of their development, and they're still dealing with some of the earlier things. But then, as they get further along, and they're starting to think about, how do we encourage more contribution? How do we encourage more engagement with the community? These types of programs start to make more sense for them.
I would say, every few months, someone in the network will mention my name to them and say, “Hey, Kevin did a presentation about this. It may be something you might want to think about.” I don't know that I've seen a lot of events be organized, but honestly it's been like 18 months now, since any of us have really done organized events like this. I'm sure that there were probably some that were in the works and had to be put on hold. I would hope to see much more of this.
It's not particularly hard to do, once you've done it a few times, and you understand the obstacles to get over. It's a recipe you can follow fairly easily. I'm hopeful we'll see more of that.
[00:27:04] AC: Perfect. Thank you. In our conversation here, I'm finding there's a lot of similar ideas with what you're doing there at Bloomberg and what SUSE has done. The thought keeps growing on me, I'm wondering if there's efforts that we could do beyond this, that could grow beyond just our individual companies doing this type of ideas? I don't know what that is, but I want to throw the question out there. Is there something more that we could be doing that could grow this idea amongst other companies and organizations.
[00:27:40] KF: I'm sure there is, absolutely. We all, all of our companies rely on a common set of software to operate our businesses or, in your case, it’s going into your products very directly. There's a lot of overlap in desire to improve these projects and collaborate in these projects. I will say, though, that there probably would be a– I don't know, reluctance maybe isn't the right word. There are some brand building, sort of recruiting type benefits from doing these types of things, too. I've seen in the technology space in the past that can sometimes impede companies collaborating, because they're – we're fighting for the same talent as well, as all these other wonderful things that we're doing.
Sometimes it can be a little challenging to get those two parts of the company to not fight with each other and say, “We're going to go do this good thing, because it's just good. Yes, we know, that means we're going to be in a room with half a dozen companies who are also trying to hire our talent, just we're trying to hire their talent.” So, it could be worked around. I'm sure it could be worked around.
All of us participate in independent organizations and trade associations, other things that can provide us a meeting point, to be able to do these things and not feel like it's SUSE coming to a Bloomberg event or Bloomberg going to a SUSE event, but it's both Bloomberg and SUSE participating in an event organized by SPI or some other independent entity. That's probably a good way to approach doing something that.
[00:30:22] AC: Kevin, it's really great to have you here today. It's interesting how all our conversations in this podcast this season have been intertwined, because open source truly is become everywhere. Thanks for sharing your experience at Bloomberg. I'm inspired and I hope all of our listeners are inspired as well. Thanks for tuning in. We'll see you all soon.
[END OF INTERVIEW]
[00:30:47] ANNOUNCER: Thank you for tuning into this episode of The OCTOPod. Subscribe to the show wherever you listen to podcasts, so you'll never miss an episode. While you're at it, if you found value in the show, we'd appreciate a rating on iTunes or if you simply tell a friend about the show, that help us out too. You can connect with us at SUSE and Rancher Community at community.suse.com.