 Thank you for tuning in. My name is Gil Yehuda and today we're going to talk about open source program offices. If it's such a good idea, why haven't we been doing it? First, I want to thank the Finnaas organization for inviting me to this talk and I want to thank the Linux foundation for running this event. Whereas we can't all be together in person. We can all be together. The talk is divided into three sections. First, let me give you an introduction. Tell you what we're going to talk about and why. The second will be the actual content of the talk and then at the end we're going to make some connections, lessons learned from the talk and I'll tell you a little bit about myself and ask that you reach out to me so that we could continue to work together to improve the state of open source and financial services. So let's talk about the title. If it's such a good idea, why haven't we been doing it? Well, there are three assumptions that are being made by that title. First, is that there's something that's such a good idea. Second, that we haven't been doing it. And third, that there's a reason why. Well, let's test those assumptions for a moment. The good idea that I'm referring to is managing open source as a strategic part of your technology portfolio management, likely through an open source program office and not just open source, but also inner source, the close first cousin to open source managing. So I'm starting this talk with the assumption that you agree that strategic open source management is a good idea. If you're not there yet, there are other talks at this event and a previous events that have explained why open source is so vital to financial services organizations. But starting with the assumption that you're already there, let's move on to that next assumption that we haven't been doing it. Well, as it turns out, many of you are here and you actually are running open source program offices, which means that we are doing it. So what do I mean? Well, what I mean is that I think that we can be doing more and that we face structural resistance to our success and that I know that I've run into types of resistance in running an open source program at a financial services organization. And I encountered that 20 years ago also. So the question is, what have we been doing over the past 20 years to make it easier? And with that, the talk itself, why? So I'd like to give three reasons or three frictions that I think are very relevant to open source programmatic management and financial services. I want to recognize that we're a regulated industry, we have regulators and the regulators set the tone for how we view technology and risk management. I also want to examine the nature of our organizations in our industry and how our organizations typically differ from organizations that are more tech company focused, where open source really emerged. And then I want to talk about the word open source itself and how we use that word when we convey to people in our organizations what we're looking to do. And let's start with that, the use of the term open source itself. So I want to point you to a blog post that I wrote last year where I explained that there's a formal definition for open source, the open source definition managed by the open source initiative that defines very clearly that something is open source, if source code is open source, if it leverages an open source compliant license. But when people speak about open source, they're often not speaking about an OSI compliant license. They're often speaking about one of many different things. In some cases, they're speaking about available code they can use. For some people, it's actually beneficial code. It's code that was created by a community of people who are doing more than any one vendor could do. Other people look at open source and they say, well, that's code written by somebody else, somebody I don't know. And even though technically I can look at the code, I'm not going to, which means that it's fundamentally something risky, and I probably shouldn't use it. Other people look at open source as something virtuous, like I'm leveraging code from a community. I ought to contribute back. Now, all those are true in some cases and not true in others. There's a definition of open source. And then there's what people hear when they hear the term open source. And if we're not careful, we speak past each other. Now, I found a seventh use of the term open source, a patently wrong definition of open source shareware. And I'll talk about that later in the talk as to where I think that came from and why we find it in financial services. It's odd, but generally speaking, when open source professionals speak about open source, we tend to think that the listener knows what we're talking about. Now, why is there this discrepancy? Why are there so many impressions of what open source is? One of the observations that many have made is that when technology grows, there's an adoption curve. It starts by one person with a great idea, maybe working with a team of other people to enhance that idea. And at some point, there's an inflection. For successful technologies, vendors come in and productize that technology and make it available to the masses. So if you think about the life cycle of technology, there's the pre-production or pre-product phase where the technology is growing and where communities or people are invited to grow and enhance the technology to have it become what it will ultimately become. And then there's the post-product stage where vendors bring that product to their enterprises, to their customers, and support it, integrate it, leverage it. The growth of the technology is stifled a little bit, but the adoption is increased. Tech companies tend to look at technology on the pre-production side. They're tech companies. They're creating the technologies. They don't often need vendors to provide them with support. They're the ones who are creating the technology themselves. Whereas enterprises and financial services in general tend to look at technology in the post-production phase. They're looking at technology they can buy, not necessarily technology they can make themselves. Now, yes, that's a broad generalization, but I mean to generalize and to say that when most people in financial services look at technology, they're looking for a product they can buy, not an idea they can develop. Now, here's the reality. Most open-source projects don't become products. They don't have a vendor that supports them. So sure, Cassandra, Kafka, Hadoop, many of these great projects have technology companies, have vendors that support them. And you can purchase support and additional features, proprietary code, from these vendors. But millions of open-source libraries don't. And when we think about open-source, holistically, we're talking about both the pre-product technology, as well as the post-product technology. And that's where clarity of language comes into play. Now, there's another difference between these organizations, the organizations that look at technologies and the organizations that look at products. And that has to do with the way a company relates to technology itself. Now, often open-source people talk about corporate culture. And we use the term culture loosely, but it does have a definition. And I'd like to point to the definition provided by Ron Westrom, a sociologist who came up with a framework in his analysis of actually the healthcare industry, which he then applied to the military industry and now was applying to technology companies as well. And I ran into this when I read a book about agile. So this is an interesting framework. And it's quite simple. The framework defines three different types of companies. And through that definition, it gives you the ability to figure out, well, what kind of company are you and what does that mean? So his framework defines on one end of the scale a pathological organization. So the pathological organization used that term because it was a medical analysis. We would call it a toxic organization. The toxic organization is an organization that is controlled by power. And that if you were to come and request change, you might get shot down because your improvement may show somebody up. Toxic organizations aren't really great places for open-source to thrive. In fact, they're not even very great places for careers to thrive. Unless, of course, you're the person in power. Now, on the other end of the scale, there's the generative organization. So the generative organization is quite the opposite of toxicity. It's the organization where people welcome change, and they welcome great ideas. And they say, oh, if there's a problem, let's meet and see what we can do to fix it. We are ready to pivot and ready to grow and ready to fix. Now, that sounds kind of mythical, but such these companies do exist. And there are books written about these companies, usually by the CEOs of the company. So like Jim Whitehurst famously wrote the open organization, a book about his experience as the CEO of Red Hat. And Jeff Lawson recently wrote a book called Ask Your Developer, as his experience as the CEO of Twilio. And in both cases, the CEO describes their organizations in these terms of welcoming, welcoming change and welcoming citizenship behaviors, asking their employees to go above and beyond their work so that they can make the company a better place. So quite the opposite of a toxic organization. But in the middle, that huge middle, there's the regular company. And Westrom calls it the bureaucratic organization. Now I'd like to use the word bureaucracy without its necessarily negative connotation, because bureaucracies could be negative, but they can also be normal. When organizations become large and they employ thousands of people who do similar work, bureaucracies provide structure and stability so that there's consistency in those operations. Financial services, especially because we're in regulated environments are often very bureaucratic. Now, this poses an interesting challenge for those of us who are trying to implement open source and inner source. Because open source and inner source were born from generative companies, from tech companies that welcome change and that told their employees it's okay to swim a little bit out of your lane and to go above and beyond your job. We're now in companies where we tell people don't go above and beyond like stay in your lane. There's a separation of duties. We operate on a need to know basis. We don't want you to go too far afield because there's risk. So how does open source and inner source work in those kind of environments? I'll point you to three blog posts that I wrote recently about company culture and inner source, but the concepts translate to open source. And in those blog posts, I suggest that as open source professionals, we should go and try to meet in the middle. And rather than trying to get our organizations to become generative, to change the nature of our companies because it would be easier for us, it's hard to do. I think what we need to do is also change the pitch and change the way we formulate open source and inner source to these organizations. So rather than telling engineers, we want you to contribute back to the projects that you use. Let's say you use an open source project, you made a fix. You can go above and beyond. We give you permission. We will encourage you when reward you for giving the fix back. It's hard to convey that message in a bureaucratic organization because that sure sounds like citizenship behaviors going above and beyond. Why don't we just cast that as work and say fixing a project you depend upon is what engineers are expected to do. That's engineering. It's not above and beyond, it's actually engineering work. And what our policies will do is guide you to perform that work procedurally correct. But not necessarily because we want you to contribute using a term that evokes charitable giving. It's because we want you to fix a project that we depend upon using an engineering term. And by framing it in those bureaucratic terms, we might find better adoption within the structure of our organizations. So lastly, I want to talk about the fact that we're a regulated industry. And the question is how do the regulators see open source and is their view of open source helpful to us? Now, I know I'm speaking to to an event in the UK and I represent a company in the United States. We're in different regulatory environments. There are folks here from other regulatory environments as well in the EU, Canada, Brazil, etc. So what I say here really reflects what I've seen in the United States. And I'm coming to you with a question. Is this your reality in your jurisdiction? If so, share that with me because I think together we can work to improve the regulatory conditions for all of us. And if this is not the same in your environment, still share that with me. I'd love to contrast and understand where our regulators are relative to where your regulators are with respect to technology. So I want to point to one specific case. This exam and publication was just published in July of this year from the FFIEC, which is one of the regulatory bodies that United States banks are subject to. This FFIEC guidance has a section on open source software. And in that section, it says that one of the ways to abate open source risk is to block access to shareware sites. Shareware, as you know, is the very opposite of open source. And shareware, if you remember, isn't really relevant these days. We don't really use shareware. We did maybe 20 years ago. So why would the FFIEC tell us about shareware in relationship to open source? So the guidance itself points to another document. And that document was the FFIEC guidance on open source in 2004. That happens to be the latest guidance that was published by the FFIEC on these technologies. 2004 was a long time ago. Now, the guidance is pretty good, especially in the context of 2004. It talks about case tools and rad technology and all the things that you may remember if you were in the business in 2004. But 2004 was also the year that MySpace was launched. It was the year that BlackBerry came out with a color screen. It was three years before Git was invented. It was the year before Steve Balmer famously said of Google, they're not a real company, they're just a house of cards. It was four years before the CEO of MySpace said that he wasn't afraid of Facebook as a threat to his company. 2004 was a long time ago and technology has evolved. Guidance needs to as well. Now, much of the guidance is generic and timeless. But some of the risk isn't. We now have cloud computing. We have mobile computing. We have a new way of managing software with Git, new, relatively new, to these guidances. And we need to make sure that our regulators recognize that so that they set the tone for open source, not as being shareware, which it once was, but as being the fundamental platform for all technology that we have today. So where does that leave us with a talk? I think that we have structural challenges in financial services that pose frictions to our success. But there are frictions that we can smooth over. When it comes to the use of language, I think we should be clear and test our assumptions with people we speak with. When we say open source, what do they think we mean? Do they think we were talking about a vendor or a community or good code versus bad code? Let's define what that is so that we're speaking about the same thing. When it comes to our organizations, are we asking our bureaucratic organizations to be something they aren't? And if so, are there ways maybe we can cast what we're trying to do in a framework that would work better within our organizations? If so, let's try doing that. And when it comes to the regulators, let's work together to make sure that we're on the same page with respect to the technologies that we're using and how we're using it. And together, I think we'll be better at managing open sources in industry. So with that, let's make some connections. My name is Gil Yehuda, and I'd love to meet you. I'm the head of open source at US Bank. I've been running open source programs for many years. Prior to this, I was the head of open source at Yahoo, which was then acquired by Verizon, so I was the head of open source of Verizon Media. I've been doing open source for a while, and in fact, I first encountered it when I was in an enterprise architecture role at Fidelity Investments 20 years ago. This is my passion. I'm an active member of the FinNOS Slack Group and an active member of the Todo Group Slack Group as well, both FinNOS and Todo being members of the Linux Foundation. And I'm on LinkedIn, and I'm on Twitter. And I think that the concepts that we've discussed today are concepts that may be relevant to you and relevant to us as a community. And finally, we're hiring. US Bank is hiring, and if you happen to be looking for a job and you're an awesome open source person, please check out our careers because we might want to hire you and bring you on to help us in our modernization and use of open source in our environment. But even if not, let's still work together. I want to thank you again for your time and for your attention, and have a wonderful rest of the conference, and stay safe and healthy. Thank you.