 Okay. Hello to everyone. It's great to be here today. Thanks for attending. I'm Daniel and the open source office IT leader at Bank Columbia. Today, I want to share my experience answering the question, what is an open source office doing in a bank? But before I start talking about open source strategy, I want to share with you what is Bank Columbia. Bank Columbia, it's one of the largest bank in Columbia with more than 8 million users in the principal transaction lab with more than 3,000 software engineers, more than 8 million transactions, and something like 883 office. Bank Columbia has present in four countries, and today and this year, we are starting our office in United States. I think that it's important that you know a little bit about our technology journey. It's starting in 1996 with our Colomban First financial service website. Next one in 2006 with the creation of the mobile application of the principal mobile application of banking transactions. Next one in 2016 with our technology, we have all the technology teams working 100 percent in agile using Scrum, Kanban, and things like that. In 2018, we start our journey to the Cloud. We start testing the ATN with robots, we are working with the robots in 100 percent. In 2020, Bank Columbia was selected as the best robots implementation for database, and the most important milestone for this stock, it's 2021 with the open source office creation, and with the start of our strategy that is called 100 percent Cloud migration. Bank Columbia, it's a bank that is migrating all the operations to the Cloud, and this is a year when the open source office creation makes sense. Well, to be all in context, let's talk about what an open source office is. An open source program of its main functions are to advance open source consumption, contribution, creation, inside companies for a strategic advantage. That's the theory definition, but the most important, it's essential that you understand that each company has different motivations for creating open source office. You can create an open source office for economic efficiency, for definition, new architecture values for your new applications, for consume more open source, for contribute, for create community around the projects that you are releasing, but where are the most important motivations for Bank Columbia with the open source office creation? A bank, Bank Columbia, that it's a company that traditionally was interested in proprietary software. I want to talk a little bit more about that. We had the idea of the creation of our open source office was the migration to open source technology principally, because we want to create operational efficiency, we want to have cost reduction by using open source software, but there are other topics that we want to work about open source environment. For example, contribution and strategy, open source compliance, and inner source. The first one that is migration to open source, it's about efficiency, but for example, contribution and strategy has two ways in Bank Columbia. The first one, it's about contribute to external projects, external projects that we are using for our projects, open source software, but the other way is release software as open source. We have more than 10 projects that we are released as open source, and we are creating community around that. Bank Columbia wants to have technology influence on open source projects. We want to enable and lead the contribution, encourage and govern the creation of the open source projects. The third one topic, it's about open source compliance and government. We are working in risk reduction, traceability, government in the open source tools. This is important because migrate to open source technology needs that you are okay with the license management, for example, and the last one is inner source and open source culture. I think that one of the most important challenge that we have for using open source in a bank, it's open source culture. Inner source, our detailed channels have common needs and inner source is the strategy that we are using for these common requirements. We want to recruit and retain the best talent. Let's talk about what specific or which specific initiatives we have in the migration topic. One of the main reasons, as I say, it's to reduce cost. A bank has a lot of property that is suffered and this property suffered can be replaced by using open source project that in many case a both at a better rate that several property software projects. For example, we are migrating the database from Oracle to PostgreSQL. This migration is in the process to the journey to the Cloud. We are migrating our apps from the on-premise to the Cloud and then replacing or modernizing the apps with open source technologies. Migrating the Oracle database to PostgreSQL servers like IBM, Westford, migrated to OpenLeverty, Apache Tomcat. We are migrating capabilities of IBM integration bus to Camel. We are migrating capabilities of IBM MQ and we are using ActiveMQ, RabbitMQ, we are migrating Harvest as a tool for versioning big files and we are enabling GiveLFS. Another one is we are migrating the Java Oracle JDK to OpenJDK. We are migrating capabilities of the Euroband code for our on-premise DevOps process and we are enabling Ansible. We are migrating a lot of .NET traditional apps and we are refactoring for .NET Core Linux environment and we are writing a lot of applications in Java. Many people may wonder about that. Many people wonder about the support. Many people say the support does migration to open source mean loss in support. This is one of the main cultural challenge that we have at the bank because many people think that migrate to open source technologies mean loss in support and of course not. Those are very frequent comments when starting an open source strategy in a bank, but the most important thing that the people need to know is that open source technology has enterprise open source support. Another topic it's about contribution and strategy. Let's talk about contribution and strategy, which initiatives we have in contribution and strategy. For example, the first step for define our contribution strategy was identify our maturity to define our plan. We are using this tool, the open source ladder for identify which level we have. For example, a consumer that only is using open source, a participant that is contributing to open source a little bit, or a contributor that has a lot of open source contribution, releasing open source, or a leader that create communities, lead the future of the open source projects. The milestone of each phase, it's that consumption needs to evaluate using deploying participation. It's about interaction with communities, minimal contributions. The contribution level, it's about increase contribution, major and scale contributions, and the leadership level is about open source organization, start new initiatives. We think that in Mancolombia, we are in the participation level, and we are starting more in-detailing contributions. In Mancolombia, we have an open source ecosystem, we have more than 10 projects that are released as open source. You can visit in this link, Mancolombia.githem.io. You can find useful tools for different needs as a developer. For example, one of the projects that we have is the Scaffold Clean architecture. The Scaffold Clean architecture is a gradual plugin to create Java applications based on clean architecture. If you read the book about clean architecture that writes the Uncle Bob, you can use this plugin for create apps that use these principles of your interest in domain driving design. You can use that for create applications that apply these principles. Another project that we have is Secrets Manager. This is a library that will help you to a couple your application of your Secrets provider. You can use AWS Secrets Manager, you can use Kubernetes Secrets, you can use another providers with the same interface. Another project is the Distributed Performance Analyzer. It's a project for do HTTP benchmarking. It's a benchmarking tool capable of generating significant load for a single node or for a distributed cluster. That's the tool that we use when we want to select the best tool for an app. You can identify when it's useful, use Node.js or Java or something like that. Another project is Bint Stash. It's a library for caching data in memory, making a single-tire catch or using both as two-tire stage catch. Another project is Reactive Commons. It's one of the libraries that we have for create event-driving architectures, for accelerate the process for the developers communicates with different tools for build event-driving architectures. Another one is the Performant Benchmark Stacks. It's a project that allow executing repeatable performance tests in different technical stacks. It's a tool for define different scenarios, and you can do a repeatable performance test. Another one is the Serenity Parallel Execution Plugin. It's a Gradle plugin that enabled parallel execution of automated Serenity Test. It requires a smaller configuration and accelerated process to run that in parallel. Async Dataflow Channel Center, it's another project. This is a distributed Elixir cluster for implement WebSockets, for implement notification channels, for create end-to-end asynchronous communication. It's a project that accelerate that process. Another project is this one, that it's a decoder encoder of Elixir, and we have other projects that we are released as open source that have an initial community. In the open source office, we are creating the open source office central repository. This is a project that contains guides, templates, best practice, checklists for use open source, for contribute to open source. But Columbia, it's a company that has more than 3,000 software engineers, and this is a tool very useful for help the people that wants to use or contribute to open source. For example, contains things like how to choose a good name in an open source project. This is a good tool where you can verify the name that you are thinking, and you want to choose a good name for your open source project. Another one is the high-code quality. You can evaluate the code quality of the project that you want to use, the open source project that you want to integrate to your application. One of the most important things that these repository have is the open source maintainer expectations. Release software as open source requires, or has a lot of responsibilities. We have defined what are our maintainer expectations. We have more than 12 open source projects, and you can contribute on these tools in the github.com slash bank Columbia. Currently, we are defining our open source ecosystem. We are in process to be part of the Clonative Computing Foundation. We are in progress to be part the Linux Foundation to the group. That is, we're in progress. Another topic is open source compliance and government. Open source compliance and government about race reduction. It's important to say that in an Ospo automating, your policies is essential, and much more when you have a team of those and of developers like Bank Columbia. One of the tools that we are using is JFrog X-Ray license management. It's a tool that provides a comprehensive list of open source license. You can create your own license and help a lot in the development cycle for choose the right license that the company wants to use. In government, it's important that you define good criteria for choosing open source software and support your team in making decisions. About choose license, the best license for a project, the vulnerabilities, how to be driving the vulnerabilities in an open source project, how about the regular activity, books reported, documentation, communication channels, and high-code quality. There are many important things that you need to know about support the people in making good decisions. About inner-source and open-source culture, Mancolombia is a company that has different detailed channels, but the different detailed channels has common requirements and the most maintainable way to work with different teams is use inner-source practice in these projects. One thing that should be stress is that an hospital do more than just work with developers. It's really important to know that because, for example, inner-source that is the practice of adopting open-source patterns internally within your organization, it's more a government, it's a tool for define workflows for work with people, not only for a team as a developer. You need to know that it's different inner-source that open-source. Inner-source is the practice of adopting open-source patterns, but an organization that practice inner-source may or may not also maintain open-source software. In Mancolombia, we're interested in inner-source and open-source. We have shared requirements for the different detailed channels, and inner-source is the most maintainable solution. In inner-source, we are working for items, discoverable repositories, templates, files, measure success, and define the workflows for the people. In discoverable repositories, contributors should be able to self-discover internal project that are of interest to them. Exists different people working in different projects, but we want that people from different teams can work in the common repositories or in the common needs. About template files, independent teams require standardized templates for issues, for pull requests, for features. It's a tool for facilitate the communication between different teams. About measure success, you need to define in an inner-source strategy, what interests do you have with the strategy time to market, improve the teamwork. You need to define what is the most interesting things for you. You need to define your workflows. For example, define the maintainer teams, trained people for do the job of a maintainer team, define the workflows for work in an inner-source projects. Open-first, not only open-source, I think that it's an important thing in the company about the culture. I think that open-source can change many things in the company. For example, we are creating this block that it's called Bank Columbia Tech. We have more than 14 publications about how we are using and creating technology. We have more than three posts per month, and I think that it's a good tool for thinking in open. What about the Ospo team? The team of an Ospo is different in each company. It depends on when you have defined in your strategy, and our team, it's like that, it's like this. I have four people that are working in database migration for people that it's working in open architecture, that it's the process of, as I say, we are migrating our operations to Cloud, and then there are many people that it's reviewing these applications for migrate to open-source technologies to people working in infrastructure and operations, and three people working in open-source contribution and compliance. We have a core team, but not a centralized strategy. It's essential. We have a lot of help of the cybersecurity team, risk management, legal team, marketing team, and the corporate culture, then it's not a centralized strategy. Don't forget that it's mainly an open-source program offices. It's mainly a cultural challenge. The open source in a bank is a cultural challenge. It defines the principles that will transform the culture of the organization through code open-first. To finish, here are some sentence that represents goals that we have in the Ospo team. Thinking about open, it's an act of revolution. There are more and more of us. The world is going in that direction and nothing is going to stop it. Open-source is not just a trend. It's a competitive professional skill of the future. It's a way of thinking. It's an incredible way to solve challenge in a collaborative way. The future of humanity, it's being programmed in open source. This can always add up to the business, and that means saving an agility. Let's talk about the future, the way to the cloud, it's open, and that's it. Thank you very much. Do you have any question? What your team is building is being released as open, which I think is generally awesome. Are there people in your company that are pushing back saying that you need to maintain some intellectual property so other competitors still use the same thing you're using? For example, for the projects that we are releasing, the question is about the competitive, about the projects that we are releasing. We are releasing open-source projects, but the most common topic of the projects, it's tools for do something, not about the business of the bank. Then if another bank, if another company wants to use the tools that we are releasing, it's perfect. It's the idea behind the projects that we are releasing, for example, for the architectures that we use in the projects, and something like that, but it's not a problem because the project doesn't contain business things. Do you know what I mean? Yes, that makes sense. Okay. Another question? Okay. The question is about open-first, not only open-source. I think that open-first is the cultural challenge, because in a bank that usually preferred the proprietary software, needs a cultural challenge for think in open-first. When I say open-first, it's about, for example, share the things that we are building, share the way for defining our architectures, the way for, for example, the strategy for defining any tool instead of another. When we use Node.js, when we use Java, which criteria we are using to define which tool it's more useful in which use case, what about our journey to cloud, what we learned in this process? I think that these topics, it's about not only open-source, because it's not code, but it's share experience, share things that can be useful for another companies or another developers. Yeah. Thanks. Another question? Okay. Thank you very much. Thanks for attending. Thanks.