 Okay. Hello everyone. It's great to be here today. Thanks for attending. Actually, or today, I want to talk a little bit about lessons learned after one year running an OSPO. I think that one year ago at Seattle, I was talking a little bit about which ideas we had for create our open source office. And today, one year after that, I want to talk about the experience that we had, the things that actually we are working on and which lessons learned in this year. I'm Daniel and the open source office IT leader in Vancouver, I'm from Columbia, and it's my Twitter account if you want to follow me. I think that the first step to share this experience is explore where is the open source office in Vancouver. I mean, and Columbia is a company with more than 3,000 people working in technology, and I think that more than 20 or 25,000 people working in general in the bank. Then, where is the best place for create our open source office? I mean, it's near of the legal team. It's better be near to the technical team. We need to report directly to our directive, so which is the best place. In that process, I think that if you are refining your strategy, you can choose one of these one options. You can have a central team that when you have different people depends on the central team, or you can have a distributed team with different business units, and all the people depends on the business units for work in different things. Another option is Hive and Spark, that it's like an enterprise service, an enterprise service, and product one, product two, product three, and below of that the teams that work in different business or in different products. Actually, which is a strategy that is called federal, state, and local, that I want to explain a little bit more. Actually, we want to be a cloud first bank. Then, actually, we are restructuring our teams, which is, as I said previously, federal, state, and local. Actually, we have as a federal teams our cloud business office, our operations cloud office, our cloud security, a cloud leadership team that reports directly to a CIO. Actually, we have a team that is called center of excellence. In the center of excellence, we have one that is called developer experience management. Developer experience management is our center of excellence. Actually, in the developer experience management, we have, I think, more than six teams that I want to explain in more detail. And we have state teams like FinOps, skill development, cloud platform, and ops engineering, and we have local teams in different business units. But what is a developer experience team? Yeah, I think that it's a good question, or a DevEx. A DevEx, it's a team where developers create different tools to increase engineering productivity at Vancouver. I mean, we are developers working for other developers. The developers of the company are our clients. And we want to educate our engineers and managers on developing best practice, tools, automations, and different things. Then, actually, our developer experience management center of excellence have six teams. The first one is DevOps and metrics. We have teams about performance practice, automated testing practice, software development practice, IT security, and the area that we want to explain to you today is our open source program office. This is a team of the developer experience management in the federal teams in Vancouver. Okay. And we are working in different topics in our open source program office. We have four principal topics about we are working on. The first one is migration to open source technologies, that it's about migrate proprietary software to open technology. I mean, it's a bank. A bank has a lot of proprietary software, and actually we want to migrate that technologies to different open source initiatives. In two ways. The first one is how we can modernize our technologies in that migration, because actually we are migrating all our on-premise operations to the cloud, and we want to migrate to the cloud and to the open source technologies. Then the other reason is cost reduction. We want to reduce the cost that actually we pay for different license and for different products. The second topic that actually we are working on, it's about contribution and strategy. It's principally about two topics. The first one, it's about contribute and release open source software. We have, I think, more than eight projects that actually we are creating and releasing as open source. And the second one is create and support communities. We actually create and support communities in different ways. The first one is how we can create local communities for different goals. And the second one is how we can support foundations that actually work in the projects that we need to use in the cloud. The third topic that we are working on is about open source government. Open source government is about how we can define different policies that apply for all the developers that actually we have in the company. And we can establish metrics, tools, and different things for improve the experience of use open source in the company. It's a good place for us to speak a little bit about license, which license we want to use, which license we don't be using. And the last topic, it's about inner source and open source culture. And one important thing to say is that an open source in a company is more than the technical approach. You need to work in cultural things because it's a very big challenge. Then in this topic, actually we are creating our inner source portal. We are defining governance models. And actually we want to work in the open source thinking in the organization. Then I want to explain a little bit more in detail each topic. The first one, migration to open source and which initiatives actually we have in order to achieve these goals. In migration to open source, actually we have five principal migrations. Actually, we are working with our Oracle database for migrate to PostgreSQL database. In that process, actually we are migrating, as I said previously, our applications for non-premise to the cloud and we want to migrate our Oracle database to PostgreSQL in AWS as a service. The second technology that actually we are working is application servers, WebSphere application server. We are migrating that to containers. We are using EKS and we want to migrate that applications that can use open liberty. The third one, it's about .NET and actually we are writing different applications that was or that actually exists in .NET and we are refactoring or writing again in different language. For example, Java and Elixir. Another one, it's Cloudant. We have different applications in IBM and we are migrating our applications to AWS. Actually, these applications use different service in IBM that needs to be replaced in the other cloud. Then actually we are using CoachDB for replace the Cloudant in that applications. The last one about migration is Java. Actually, I think we have more than 27,000 people using Oracle Java in their computers and we want to migrate that to OpenJDK. Actually, we are using correct. That's a scenario that actually we are exploring and we want to replace that run times. How can we work as an open source office? I mean, if we have more than 3,000 people, how a team that I think that has more or less 11 or 12 people, how can support all the teams in the company? I think that there are different tasks that actually we have. We automate and we are working in automation of migration workflows. For example, in the database, we are educating developers in open source adoption. We are supporting open source technologies. I mean, as I said previously, it's a bank. When you say a bank, we want to migrate proprietary software to open source. The first thing that the people think is, and what about the support? What happened with the security? It's important to say that actually we are working with purpose with OpenLogic for this type of open source support. That is very useful for us because we can migrate our proprietary software. Actually, we work with this company for the support tickets that we need. We are using a strategy that is called experience-based acceleration parties. That is, a party, it's like a hackathon. We meet people three days and we define a topic. For example, sports, for example, movies or things like that. These people define an application to migrate in three days to proprietary software to open source, database application servers, write a legacy applications and things like that. Then it was very useful. I recommend to you that implement this strategy. It's very useful for accelerate this side of migrations and it's very useful for us. I want to share one of the architectures that actually we are using for migrate our database. Then we are using different tools for migrate proprietary software, proprietary database, for example, Oracle. We are using a schema conversion tool for migrate all the structures, all the tables, views, index and things like that for PostgreSQL. Then after that, we use AWS database migration service or DMS for migrate the data, for synchronize the data in both database. Then actually, we are using that tools and as an open source program office, we build different cloud formations for be more easy than a migration process. Actually, a schema conversion tool, it's a tool that can generate a report of compatibility. Then you can analyze your current database for Oracle and you can define if it's possible migrate to PostgreSQL or if you need to rewrite a lot of things, then you can analyze the schema, the tables, constraints, index, sequence and things like that and you can define if it's a good application for migrate from Oracle to PostgreSQL. That's a good tool that I think you can use for this side of migration. The second topic then is contribution and strategy, which initiatives actually we have in that topic. Actually, we have a site in GitHub, GitHub.com slash Bank Columbia and we are maintaining eight tools released as open source to increase engineering productivity in Bank Columbia. Actually, we have these projects, scaffold clean architectures, reactive commons, secrets manager, data mask, Java projects, a lecture and TypeScript for different things and I want to explain just one, the principal project that actually we have that it's interesting that you know about it. This is our site, our GitHub site. Actually, we have different projects principally open source because actually we have both repositories, service that we use in the company. I use Azure repos for all the private repositories that we have, but we are using GitHub for all the open source initiatives that actually we have. Then where is scaffold clean architecture is one of the projects that we release as open source that actually is very useful for different developers. It's a great little plugin to create Java and Kotli applications based on clean architectures following our base practice. If you read about clean architecture, I think you know that it's a little bit difficult implement that practice in a real project. Then that's a plugin. This is a plugin for be more easy work with that practice of clean architecture in Java. Then actually we have more than, I mean, I could be 50 people using that project and I want to increase that. Actually, the project has different adapters for different things. For example, we have building adapters for MongoDB, for Redis, for R2DBC, KMS, and things like that, or you can generate just with a command, ResNBC, WebFlux, GraphQL, and things like that. We are accelerating the time to market with these type of initiatives. That's the architecture that actually we implement in this project is like clean architecture layers, domain infrastructures, entry points, gateways, configuration source, and things that if you are reading about clean architecture, you can know more in detail. I want that you review all the projects that actually we have in our GitHub account if you are interested in this project. Another topic that we are working is our Ban Colombia engineering block. It's a medium block when we share more than 60 posts about how we are working in Ban Colombia, which technologies we are using, which platforms we want to use, we are exploring about open source, about blockchain, about different things that you can explore. Then we have a lot of content in Spanish, but we have different posts in English. Another achieve that we have this year is that actually we be part as a silver member of the Cloud Native Computing Foundation and Linux Foundation. We are very excited about it, and actually we are involved in these communities for contribute to Kubernetes, and that's the reason for our subscription. About communities, actually we create two communities in this year. The first one is it's called Open Talks Contribute to the Future, is a community for increase the people in Latin America that is contributing to open source. Then we want to reduce the process for contribute to open source in Latin America, and that's the principal goal of this community. The second community, it's Elixir Colombia, that it's a local community for improve our knowledge in this language that actually is really important for us. We are using Elixir for different things in the company, and that community, it's for increase the knowledge in that. The third one, it's Government. Then in Government, we have different things. Actually, we are implementing a tool that is called ScoreCards Strategy, that it's a proposal of the open source security foundation. Actually, if you see our Github account, you can explore different things about this tool. Just give me a moment for this login, and I want to show you some details. Actually, all our open source projects have a workflow for security. Then we have in the Github folder, we have workflows, and we have a ScoreCard analysis. ScoreCard analysis, it's a task for analyze security in the project. Then with this workflow that it's open source, you can review in detail. You will have a security report about different things in the project. Then you will have code scanning alerts about core review, talking permissions, dependency, and things like that. You can review one of the alerts in detail, and you can see all the description. You can show more details about the remediations and things like that. I think that it's a really useful tool for security in open source projects, and actually, we are implementing that for our initiatives. Actually, we are exploring four features in the Advanced Security Licensing Github, about code scanning, about secret scanning, about dependency review with the Pandabot, and security overview, that there are features that actually we are exploring in order to improve our security ecosystem. Then that's the reason we're exploring that. Another initiative that we implement this year is the chaos metrics. Actually, we have a dashboard in Grafana for shell different metrics of the chaos project. It's about, for example, which are the principal contributors to our projects, or which are the languages that actually more are using, or, for example, whereas the pull request activity in any specific projects, things for analyze the health or the healthy of your community. I think chaos metrics, it's a good option if you want to implement that. Another tool that actually we have in the open source program office is the radar of technology. I don't know anyone here know about Toddworks radar. Actually, this is a fork of the technology radar, powered by Toddworks. Then we fork that project and use and customize for our own technologies. Then we define tools, language, platforms, and techniques that we want to implement. We define this for adopt and you can see the description for this tool. It's very useful, or, for example, things like trial or technologies that you need to hold in different ways in tools, in language and frameworks, in techniques, in platforms. It's a good option if you want to have more government of the technologies that you want to use in your company, recommendations and things that can apply for different things in different business units. Actually, for us, it's very useful. I want that you can explore that project if you have a need for a government in your open source projects. The last one, in the last topic that I want to talk about, it's about inner source and open source culture. Then inner source and open source culture, actually, we implement our inner source portal. This inner source portal, it's a fork of the SAP project about inner source portal. Then thanks SAP for that. Actually, we use and we customize for Bank of Colombia and we have different projects in the inner source strategy. We want to implement, for example, the Colombia design system that is like a bootstrap or like material for our internal projects. We want that the people contribute to this internal project and that we can have different features, not just for one team. It's for all the company. Actually, we are sending to all the company an open source culture newsletter that is an strategy that we are using to show the people in the company what's happening with the open source. What is happening with open source in Bank of Colombia, it's a version we are releasing of the projects that we are maintaining with other projects that we are releasing as open source and things like that. It's a good option for working the culture of the company and it has been useful for us. That's all that I want to talk today. Remember that Dairy Cup, it's my Twitter account if you want to follow me. Thanks for your time. Thanks for attending. Do you have any questions? Thank you. Good presentation. It looks like you're making really great progress in just one year. I'm curious if you can talk about how do you get there a year ago? How do you work with your management to make a decision to form an OSPO? What convinced them? How do you justify that? And then similar to that question, what made you sponsor CNCF? What was the decision making to get management approving that? Sure. So the first question, I think that it's important explain that in numbers. I mean we need a sponsor that invests in our open source program office and the principal topic for that is migration to open source. It's the efficiency that we can make migrating proprietary software to open source. That's the principal reason for our by-presidents for our directives. They are really interesting in our contribution, in government, in inner source, but the principal reason for them is cost reduction. That's the principal reason for us. I mean great to proprietary software to open source in order to reduce the cost that actually we have. And the second question about CNCF, the principal reason is because we want to work directly with the communities. We want to work and contribute to Kubernetes and the other projects that actually the CNCF are graduating. Then we want to support the technologies that actually are really important for us. We are migrating all our operations from on-premise to the cloud and it's really important for us that projects like Kubernetes, Prometheus, Jagger and things like that has the support, the correctly support and that's the reason for us. Thanks for your question. Any other questions? Hey Daniel, thank you very much for your presentation today. Really useful. I'd like to know how do you consolidate decision, technical decision, across other tech teams in your company? I mean, could you please tell us at a really high level how was the process to define the tools that we are going to use to replace the proprietary software? Sure, I think that it's really important explore which are the tools that actually your company is paying more. Which are the proprietary software that you can migrate for an efficient cost reduction? If you migrate an application that technically could be difficult, but if you explain the details in the cost reduction and it's just a little bit, could be not a good option. I mean, it's better if you can define the tools that you want to migrate in order to generate a good efficiency. And technically, it's important work with the teams that is related to that technologies for work in the compatibility, for example, and not just cost reduction decisions. I mean, it's important the cost, but it's important the technical compatibility of that tools. Then I think that it's important to relate both criterias, the cost reduction and the technical compatibility of that tools. Thank you. So what sort of obstacles have you found? Once you got into the place where you had an OSPO, what was the most unexpected thing that was difficult? Sure. I think that, for example, the contribution to open source. Because in the company, actually, the developers explore tools, adopt best practice, but don't dedicate a lot of time in contribute to open source. Then when you create an open source office and you say to people, yeah, we need to use technology, we need to adopt best practice, but we want to contribute to that technologies. It's a different way to see the technology. I think that it's one of the most important. And another one, it's about migration. Because as I say previously, it's a bank. And the people that you need to say, you need to migrate that technology to another one, it's people that work with that technology for 20 years. Then when you say that people, you need to migrate that, it's like, what? I like this technology. And it's a little bit difficult. And I think that it's more a cultural challenge. And we are working on that. And the people actually are doing that, but it's a really difficult challenge. I have a question regarding the team. How many developers you have, are active contributors to any open source project, like maintainers, or like having active roles in the open source projects? Sure. Actually, in the open source office, we have, we are 13 people. But we have other teams in the developer experience management. And this one, developer experience management team, that it's six teams, really, that actually are contributing to open source in different ways. For example, performance, or DevOps, or security practice. Then I think that it's like 13 people, 30 people, something like that. That it's just a little bit in technology, because we have more than 3,000 people working in technology. But I think that it's a first step. And another question? Okay. Thanks for your time.