 Okay, thank you all for joining. I'm here to talk about building the open source program office at Goldman Sachs. Just before we start, I have a small exercise. Could everyone put their hand up? I have a strange accent and when I get excited I talk quickly. If you want me to slow down, do this. Okay, practice everybody. Yep, and that will make me slow down. If I say something and you don't understand me and you want me to repeat it, do this. Yeah, so one, two, say it twice. Okay, and if you want me to shut up, do this. Thank you. So let me start with some introductions. Let me move the mouse on the right page and then start with some introductions. So Goldman Sachs, I'm not going to read this. Goldman Sachs is a large financial institution. I'm assuming everyone knows who Goldman Sachs is or you wouldn't have turned up at this class. Maybe you went and googled them before you turned up. But this is Goldman Sachs. We do a lot of things to do with money. Note, it doesn't say anywhere there that we are a technology company. We have a lot of engineers, but we're not a technology company. We're also very old, so Goldman Sachs is over 150 years old. Note that that is older than computers and older than most of the programming languages any of us have ever used. And so it predates a lot of tech. A lot of things that Goldman Sachs do, they have been doing from before we've had computers. Obviously, a lot of things have changed and we use software for many of the things that we used to use non-software things for. So we have grown with the times, but we are old. We've also been in Japan for 40 years, well more than 40 years. I say we. Goldman Sachs, like many large organizations, is not just a single company. So in Japan, these are some of the companies we have in Japan. I work for Goldman Sachs Japan Service, and there's a bunch of others. That's not all of them. That is the ones I could find easily, including two that are sort of in Japan, but sort of not. Outside Japan, we have loads of other companies. I didn't put the list down. It would be a very small font. So we have lots of large organizations. These are individual entities of some sort, or hodging in Japanese. And this will become important, possibly later. The other thing I wanted to mention at this point is, in Japan, some of these entities are regulated. And in other countries, they're regulated by different organizations. So in Japan, they're regulated by the Bank of Japan and the SESC. That means that in addition to the normal laws that we have to obey, that are the same as any other individual or corporation, there are additional laws that finance companies have to follow. And some of those are relevant when we talk about open source, because they make people a little bit more risk averse, and a little bit more reluctant to do things that maybe in a kind of modern tech company, there would be less problems doing. So again, briefly mention that later. Now me. I'm Marty Bolle. I'm not 150 years old. I hope to make that someday. So in Goldman Sachs, they call me a technology fellow. That means I'm good at technology, and I'm not very good at managing people. So they have colleagues in the room, can they start? Yeah, that's the key. My current team is Secrets and Encryption Services. That sounds really good. I think that's why I joined. I'm a bit of a developer, a bit of a kind of system administrator type person. I've done both throughout my career. I've been 16 years in Goldman Sachs in Japan. When I applied, the job that I applied for had five words in the advertisement. It just said, Linux, Perl, Tokyo, Geeks, welcome. That was it. So notice that it does not mention anywhere in that job ad Goldman Sachs. That's all it said. When I called up the guy to talk about the job, he told me about this wonderful job involving Linux and everything cool. And I said, that sounds great. I want that job. He said, oh, by the way, it's for Goldman Sachs. And I went, huh? Is that the bank? And it turned out it was. So in my head, I didn't think that a bank and an interesting open source job would be the same. But it turns out it was. So I'm very happy. I've also been in Japan for 16 years, but we'll leave it there. I can't answer that. Maybe. So I also want to thank one of my colleagues who couldn't be here. So originally I'll be co-presenting this talk with Vicky. Vicky actually is one of our open source program officers. And she was planning to be here and arranged all of this for me to do. And unfortunately, she couldn't make it. But big thanks to Vicky because if she hadn't done this, I would not have been here talking to you guys. So thank you. Vicky's probably watching. So after that introduction, just a little bit more of a background. Goldman Sachs is the bank. As I said, I wasn't expecting these things to link up, but Goldman Sachs runs on open source. A lot of the things that have changed over the 150 years involve software and a lot of places to get good software are open source. So we obviously, like any sensible company, we consume a lot of open source. Oops, too fast. We also participate in open source working groups, various steering committees, we'll see those in a minute. We have engineers who work and as part of their work, they contribute to open source. Outside their work, they also do that. We also have blog posts and they can speak at conferences. So we do try to participate a lot in open source. I'm going to scroll down the notes. So I want to quickly show you some more evidence of this. Again, this is not strictly speaking the introduction, but just we have a few open source projects that I want to dimension. We split them into the three categories. We have some on the left here that GS created an open source. Some of those relatively recently. The ones in the middle open source, but give them across the foundations, so that we are not managing the project. I'll probably explain why later. And then we also have some other projects that we're interested in, so we contribute to them or we want to contribute to them or we want to do something with them. There are many more than this list. This is the list that has been talked about recently. As I mentioned, there are many thousands or tens of thousands of other projects that we consume, because again, not being a technology company, we use a lot of different technologies to fill all of the different needs we have. So there is no way I could list even a small fraction of the stuff that we use. And then I mentioned foundations. Here are some of the foundations that we support. Well, the Linux Foundation, we all know who they are. The Cloud Native Computing Foundation, I believe we're here too. So the level of interaction we have or involvement we have varies per foundation. Obviously the Eclipse Foundation over there, they were mentioned indirectly on the previous slide. They were the recipients of one of the projects we open sourced. So now to the meat of the conversation. The open source program office. Back in 2021, which is a long time ago, almost a year and a half. So not very long ago at all, we decided we wanted to have an open source program office. Now this was not the first time we thought of this, but it was the first time it got beyond the thinking stage. It took a few months to set up, but then just over one year ago, we set up an open source program office. So all of the things I've just told you about the amount of open source that we use and the involvement that we have, it might feel a little bit strange that we only did this one year ago, but I will explain that to you. We have some goals which are listed here. In no particular order, but this was the order that kind of made sense to me. So we want to promote and support open source, both the consumption and the contribution inside the firm. And by contribution, there's two aspects to that. Again, there's contribution of the firm contributing and there's contribution of an individual contributing. Just because, again, it might be important later. When the distinction is quite important, even if it's the same human who is typing the code, because sometimes the code that they type will not belong to them because they are an employee. And sometimes it will belong to them because they're working outside the scope of their employment. This is not something that a company invents or open source invents. This is an inherent part of copyright legislation, but it does mean that there are those two legally defined avenues for contribution. And it also makes sense from the firm's perspective if I'm writing some software and it's useful in the financial industry, it makes sense that Goldman Sachs would contribute that to wherever it's going. Whereas if I'm writing software that's doing something like, I don't know, cataloging all of the DVDs I have sitting under my floor, then that might be something that Goldman Sachs is not interested in and it would be more appropriate that I would do that. Both cases we want to support. The second one sounds similar. We want to position open source consumption and contribution to attract and retain talent. So again, it's for the developers, but it's for the ones who haven't joined us yet. And that's important. We want to expand GS's capabilities to generate insights, sounds cool, about open source at the firm and across the industry and in the wider technology ecosystem. We want to be a leader in open source because all big companies want to lead in something and we want to do that. Is that why? Maybe? We also want to increase our visibility in open source. So for these five things, I've kind of hinted at some reasons, but can anyone think of why these would be our goals? Okay, I'm going to tell you. If you were after, there was a talk this morning. So Ana Jimenez, Santa Maria San gave a talk this morning covering creating open source program offices and doing a survey. And it was quite interesting for me because a lot of the things that she said this morning kind of made sense with the reasons I'm about to give. If you've heard that talk, none of these reasons are going to be surprising. So for number one, we're doing it because it's good for our developers. It makes them happy and happy developers write lots of code. That works. But it's good for the developers. The developers who are already involved with open source, they want to stay involved and they want to work somewhere that they can feel included. This is part of them and they want to be included, so it's important. It also makes the work life easier, right? It does. But we're thinking so the developers definitely want to use it because they have this nice developer trait of being lazy, as I call it. And we want the tools. The company does it because they know that, again, the developers will give their best work if this is the case. So it's developer driven. We have to keep the developers happy. In the second case, it's similar. We want, when we're talking to people, trying to get people to join Goldman Sachs, we want to make sure that they're going to ask us, can I contribute to open source? I know when I was interviewing, that's what I asked. And by coincidence, the second day I was in Japan, I had to ask my boss for an emergency day off to attend an open source convention. That was unexpected. And he said yes. But developers ask and we need, if we want to bring talent into the firm, we know a lot of the talent is going to be in open source. So again, this is not, there are company beneficial reasons for doing this. We can get good developers by making sure they can contribute to open source. Because if we don't let them, someone else will. Third point, we want to generate insights. So this is very kind of, I said I wasn't a manager. This is kind of management speak generate insights. In SRE terms, this is, you can't manage something unless you can measure it. So we want to measure something so that we can manage it. So again, SRE principle. It was also a large bank principle 150 years ago. So it's not something that the firm is new at doing. They want to measure something. If it happens to be how open source is used and worked on in the firm, that's what they want to measure. Fourth point, becoming a leader capable of setting direction. This again is a bit like your point. It's going to be better for the firm if the open source they bring in works exactly as they want it when they bring it in rather than having to fork it and maintain it internally. And it's the whole benefit we're all having as individuals and corporations from open source. Getting involved helps society in general and as a member of that society or community, we each benefit from those contributions. I remember many years ago before GS in a small company, we were planning a feature and costing the feature and it was a risk for us because we were a small company and it was going to be expensive. And just as we were about to execute and pay someone to develop a feature, we got an email from a guy in Japan when we were in Europe saying, hey, this was really interesting. So I implemented this feature that I wanted and he just spent six weeks building the thing that we thought we were going to have to pay for. So again, no one here needs to be convinced of how useful it is to have open source community. GS wants to be part of that and help set the direction. And then the last step, external visibility. So some of that they've mentioned across the financial services industry. So I did mention earlier that Goldman Sachs is a regulated entity like a lot of other, like all other banks. And this part about amongst the financial services part is important because our regulators also need to be comfortable with open source. So if Goldman Sachs were the only bank doing this, then we would be the weird bank and we would get extra attention from all of the regulators saying, why are you doing this when nobody else is? So a lot of the big banks are doing this because everyone knows it's the right thing to do. And they also know that if only one person does it, they will look strange and the regulators will ask them questions and that can be painful. So they want to make sure that the industry as a whole is comfortable with open source and the regulators are comfortable with open source. So that's why we want to do this. Another reason is so that the next time they offer someone like me a job, I don't say, is that the bank? And instead, oh right, those are the guys I saw at the conference and I've used their product. So it has an education for people like I was 16 years ago. So any questions? Oh, sorry. Are they scared of me? I was like, oh my God, did something happen? Is the building on fire? Anyways, lost my train of thought. Something about, oh, being that it's a bank and from the optics perspective of like you in the beginning and you being jarred and shocked like the bank has asked me to work in open source like what? I'm curious from a consumer perspective and being that it's a highly regulated space, anything to do with financial or banks, highly, highly regulation, red flags everywhere. I'm wondering how in a space that is completely open and of course there's rules like any for any operating body, the rules may not always coincide with a highly regulated space. So always curious of how in developing something like this from scratch, what are some of the limitations that a body needs to take in consideration to have those coalesce while building from the ground up? Okay. Yeah, any variation of that? I'm going to put you on the spot. So we're actually going to cover some of that in the talk. So the question basically is given the big difference between the regulated industry and the very open non-regulated industry, how do we go about doing this? So the next slide I think is what happened before then. I'm going to hit some problems and I'll cover those. So hopefully the next two slides will answer your question. So before we formed the open source program office in 2021, this is what happened. We had, we were using a lot of open source with no problems just because that's the easy part. We attended conferences like this one we've been coming here since it was called the Japan Linux Symposium in some long time ago. We built a lot of things with open source components. So, but this is where the problem started to come in. We were a little bit nervous about copy left licenses. Lots of organizations are nervous about copy left. And some of that's unfair and historical from bizarre or weird reasons. And some of it is justified. There are reasons to give copyright license, copy left licenses extra care and attention. So we also had staff, we were allowed, as a joint, we were allowed to contribute to open source as personal projects. But the problem there is this wasn't made clear. My boss who hired me, he was trying to attract people from the open source community. So he made it very clear, yes, you can do this. A lot of other managers weren't really sure themselves and a lot of staff have joined and they weren't really sure. And when they got in, they asked people, how can I get approval to do this? And that was one of the things, you need approval. So to do any outside activity, you need some kind of approval. And there was some kind of approval required for this. But depending on who you asked, you got a different answer. So that was one problem. And it wasn't just for writing software. The bigger problem is software wasn't explicitly listed. You want to write a book or give a pay talk at a conference or get involved in politics or run another company or do lots of these other things. You have to get approval. So it looked like open source was in that bucket as well. And the inconsistent answers were one of the biggest problems. It was also extremely difficult to contribute to open source as an employee on a work project. So that's to the point I mentioned earlier. You have two roles as a human. You as yourself, as an individual, but as an employee copyright legislation means your work does not belong to you. It belongs to your employer. And that made it difficult for to contribute. If you wanted to send something back, it may not belong to you. And that means the firm would have to do it. And that's a lot of effort and expense. We were able to release entire projects as open source, but it was expensive. It required a lot of people to do a lot of things. It wasn't just upload to GitHub. Although that's how it appeared, but it was very expensive. These were the problems. We made some progress before we had the open source program office. Our restrictions on communicating with the outside world. So regulated industries aren't allowed to communicate using whatever applications they want. All of the communication has to be recorded. And that meant even simple things like submitting a bug report could be tricky because we would have to submit it with our company emails so that it was recorded. Thankfully, not just because of open source, but because the world adopted social media and social media became really important for work. So people in work are using LinkedIn and Facebook and some other things. The banking industry needed a social media policy. So the social networking services policy or social media policy or social communications policy. Also happens to cover things like submitting merge requests and reporting bugs and using public forums to communicate about open source. Not because they mention open source in particular, but because it falls under the definition of, hey, this is some kind of social media that we're using here. So that ticked off that box, made that easy. Outside activities, we clarified that open source, if you're not getting paid for it and it is done as an individual and not as an employee, it doesn't need approval. So that was easy. So don't pay me any money is basically the thing. You're not allowed to pay me. Then again, some of the things that Anna-san mentioned today that an OSPO would do, we did a little bit before that. We produced a lot of training about open source. It was a bit difficult to understand. It had to be a bit difficult to understand because it's difficult material. But we produced material. We built a system to track contributions in GitHub. So again, we knew what people were doing. And we know that GitHub is not the only way to work on open source, but it was a nice balance with, it was very popular and it was easy to track. So we have this system called GSOS. And then we built another system that would safely allow us to have code that the firm owns make its way out. It has to go through various reviews, but it could go out on the GitHub. So again, to your question, these were things that we had to build to make sure we could comply with our own policies. Also, because one of the risks is something that's owned by GS, getting outside GS, one way to give our developers freedom without causing extra risks is give them an environment to work in that's outside. So by default, all of our developers get a development environment inside GS. As an option, you can get a public cloud account as well. And GS gives you a budget and you can go and do whatever you want in the cloud, including spin up your own little dev environment and write whatever you want. And because you're writing it outside the firm, it's not on the firm's equipment. It's not on the firm you write it from your own device on the cloud. It avoids the risk of this should be inside GS. And then we released this large library called GS Collections as open source. One of the smart things we did is we realized when we released that that we were making progress, but we still weren't good enough. We could release open source software, but we were not good enough to manage open source software or manage a project. So we donated the project to the Eclipse Foundation, so it's called Eclipse Collections. If you're a Java user, check it out. If you're not a Java user, trust me, Java users think it's good. I'm not a Java user, so I don't know why I think that, but Java users tell me. Java users, I trust, tell me that this is a good thing. So we had to do more. Does that kind of cover? So we had some additional problems even after that, and I'll keep track of me one time. Software developers have a problem because they want to write code. They may not check the license. And if they do check the license, they may not understand it because they're not lawyers. And actually, open source licenses are particularly tricky because sometimes they're also written by developers who are not lawyers. So a lot of open source licenses don't actually make any sense. And a lot of the revisions you will see in license, if you look back at the differences between version 1 and version 2 of certain licenses, it's a correction. It's, oh, we should never have written this because that was crazy. So we now have a lawyer looking at it, and they fixed it. So this is this problem. We need lawyers. The problem with lawyers is they need to be paid, like developers. But it's a problem if you're a developer and you don't have the money to pay a lawyer. Someone has to pay the lawyer. Smiley face because I think it's good that they get paid. It was a problem when we wanted something done. Where do we get the money to pay a lawyer because we're not the legal department? Problem with open source, and this is why the developers get confused. It's not about code. It's about a copyright license, which is a piece of law. So as developers, we tend to think it's about code and freedom because that's what we wanted to be about. But when it started before it was called open source, when it was called free software, the point was they wanted to give us freedom, and they used copyright licenses to do that because that was the tool that was available. So in order to get the freedom, we were using licenses, but copyright is the problem. And it's the thing that the lawyers understand. Most developers unfortunately do not. Even when it comes to lawyers, common concepts in open source are not actually defined by law. So copyright defines copying. So it also means things that you may not think. It means taking us, like, burning at the CD. That is a copy. Loading it into memory is also a copy because you have now two copies of the binary. One on disk, one in memory. If you happen to have a backup, that's a copy. Those are covered by copyright legislation. Terms that we use in common licenses like convey and distribute, they're not copyright terms. And they're invented by the people who wrote those licenses. And we think they make sense when we talk about individual people. If I were to take my USB key and give it to you and walk away, you might think, that's conveying software. But if, like Goldman Sachs, you are 375 different companies and you're talking to your colleague in Hong Kong and you happen to give him some code, is that distributing? Because there's two individual people in two completely different legal entities in two completely different countries. So does that count? Does it not count? And the problem is it's not defined. And the problem with large corporations is what I've just hit on. They're large, lots of individual things, stuck together. Again, I think something Anna mentioned this morning. If something does not have a place in the organisational structure, eventually it will disappear. And unfortunately, that is what happened to some of the things that we had done before we had an open source project of us. So for example, this system we built, DSOS, it was written by a guy called Moe. Moe left. Nobody owns DSOS anymore. So that was a bit of a problem. So now we have the open source programme office. The best thing that they did was exist. So we had a lot of the problems we had before getting inconsistent answers to questions, not having anyone who was responsible for the systems. They solved this by existing. They said, okay, we will take over. We exist now. Look, we have a department code which is important in a large organisation. They have a department code. They have a manager. And their manager has a manager. And that guy has a lot of money. So again, it sounds simple, but these are the basic problems that you have to overcome. And you might think Goldman Sachs, they're a bank. They have loads of money. They do. It's somewhere else. So you need to have this guy who can have his bucket of money and give it to the open source programme office so that they can pay developers and lawyers to run the systems and answer questions. So that's what they've done. And again, it's a massive win. I've been in GS 15 years before that. And in the last year, there's been so much improvement simply because they exist. Now we know if there's a question, you can ask these guys. They did a lot of other things as well. I mean, they employed people to do things like improve the training. And training isn't much use if people don't do it. So the second thing they did is they made sure people took the training. So when you join the firm, you get training. They got into that pile and I said, well, do our training as well. So now people have to do open source training when they come in. That's massive. Again, in my opinion, they also simplified some of the documentation because it's not always easy to understand things, but a lot of times the developers want to do something fairly simple. So simple documentation. They clearly explained some of the care needed for some popular licenses, which I'll kind of mention in my trillion couple of minutes. I've got six minutes left. And they produced guidelines for personal projects. Again, simplified guidelines because the common question was, can I do this outside? Yes, you can. Here's what you should do. And we want to protect the individuals as well. It's not all about protecting the firm. As an individual contributing to open source, there are risks that you need to be aware of. So you do the training as well. It's not Goldman Sachs open source training. It's open source training. So it's beneficial for personal projects too. They took over the tool that was abandoned and they improved it. It now has regular releases and it's getting better every couple of months. They have a budget to pay lawyers and they meet with them regularly. This also links up to my story. This is really great feature because that was a huge problem before. They're connecting with other large companies who are trying to solve the same problems. Again, with the goal to try to make sure that the industry moves forward, we're trying to reach out to other companies. We're helping developers manage contributor license agreements. Does everybody know what a contributor license agreement is? Yeah, good. It turns out that I see about 10% of hands going up. Unfortunately, that's approximately the percentage that we see internally as well at 90%. Don't know. So we're helping with that and answering questions. A very quick story about these two points. Popular licenses needing special care and talking to lawyers. So as I mentioned earlier, large organizations typically have concerns over some copy left licenses. There are different levels but we've been using GPL for a long time. The concerns were there but everybody was familiar with what they were. Does everyone know what Grafana is? Grafana is a really cool open source project. If anybody here works for Grafana, thank you very much. Grafana changed their license after version 7 and before version 8. Before version 8, it was Apache, I think. After that, it became the Afero GPL. The difference between the GPL and the Afero GPL is the conditions for the Afero GPL kick in when someone uses the product. That was not something that we really had to deal with before and manage. So being risk averse, no one really wanted to do anything with it. But it was leaving us in this unfortunate position where we were using Grafana version 7. We didn't want to do that. So before the open source program office, if this had happened then, unfortunately, I'm not sure what we would have done. But because they existed and they had a budget to meet with lawyers and they cared about these licenses, we were able to contact them and say, hey guys, we would really like to use a version of Grafana that is not ancient and we have this plan where we can safely use this inside the firm. Can we talk to the lawyers? And very quickly, we were on a phone call with the lawyers and we told them our plan and the lawyer said, that seems sensible. And the great thing about lawyers is nobody argues with them. So even though lots of other people were still concerned and thinking, oh, I don't know about this, when the lawyers came back and said, that seems sensible, we got it. So we have a plan as approved by the lawyers so that we can do something. If we had not have got the lawyers, had not got the open source program office, we wouldn't have been able to do any of that. We would have been stuck, progress stuck, but now we can move forward safely while protecting the employees, the firm and Grafana with this. So that's basically why I'm here. That one story has made me a huge supporter of the open source program office inside Goldman Sachs. At that point, I will shut up and say thank you. If anybody wants to ask questions, we might have 60, 70 seconds. Yes. Oh, sorry, you'll have to let me talk into the mic. This program now applied is for like a smaller company in the group or like the one you're working for or some wider already? So this particular program is just inside Goldman Sachs, but I was also referring to a talk this morning that Ana Jimenez Santa Maria gave. She was explaining the difference, well, explaining when she was doing surveys of many different companies of many different sizes that these programs will vary depending on the size of the company. I'm sorry, I mean, in Goldman Sachs, this program, I mean, Goldman Sachs is a group of companies. It's very big. So the program implemented one year ago is for which part? Oh, all gazillion thousands companies. So although it's separate companies, like a lot of large companies, those are there for various legal reasons. It's like the companies themselves are like a community. When something's decided, the community moves together. So the entire community of companies, they do this. So they exist in the same way that we're all in this room listening to the same talk. At the start, everybody put your hand up. Everybody put their hand up. So you're all the various companies like someone in GSM. Everybody put your hand up and they'll put their hand up. Thank you very much. I think of minus 15 seconds. Let me ask a simple question about the statistics. Sorry, about the what? About statistics in Goldman Sachs. How many engineers do you have? How many engineers do we have? It's somewhere more than 8,000 and less than 20,000. Next question. How many people, how many OSPU staffs do you have? Including the lawyers? No, no, no, no. Okay, that's going to be tricky. I'm going to give you a range more than three and less than 15. Okay, thank you. That's the great thing about statistics. You have a margin. I should also mention just on the staff, I'm not OSPO staff, but I'm here. So in addition to the ones who are actually in that little department, there are some other, I don't know, OSPO allies like me who get involved and help out with some of the things, but we're not actually, somebody else pays me, the OSPO, so again, like a community, there are people who are doing it and it's not quite their main job. I think I should shut up now. If anyone wants to talk to me, I will be standing outside somewhere. Thank you very much.