 Good day everyone. Welcome to open innovation in the financial services sector. My name is Leslie Hawthorne and along with my colleague Joe Giordano we're going to talk to you today about how co-creating open source software is a great benefit to your business. To briefly recap our agenda for today, we're going to of course give you a little bit of more information about us and why we're here to present to you today. We're going to talk about how open source software is ubiquitous across the financial services sector. We're going to talk about the process of moving from being a user and a consumer of open source software to contributing to open source software projects and the benefits of doing so. We'll also make sure to give you some concrete ways to get started contributing to open source software projects. And last but not least, we're going to give you folks some resources so that you can learn more about this topic area after our presentation today. So, a little bit about myself. I was fortunate enough to learn the best way to describe myself a couple of years ago from my manager here at Red Hat, Deborah Bryant. She said, Leslie, you're a super connector. You're one of those people who knows everybody and is always there quietly behind the scenes helping them to collaborate and get good stuff done. So I've been doing that throughout my career in the tech industry a little more than 15 years. I've had roles previously working in open source at Google, at Elastic, and I'm actually on my second stint at Red Hat. I'm what we call a boomerang, someone who loves Red Hat so much they came back to work here a second time. In addition to my professional work with open source, I've also done voluntary work for several open source software nonprofits in board director or advisory roles, including the open source initiative. And I'm a proud contributor to Phoenix's open source readiness working group. How about you, Joe? Hi, thank you, Leslie. So my name is Joe Giudano. I'm a chief architect with the Northeast Office Regional Office of Technology. I've been with Red Hat for over seven years now as a solution architect helping customers get business value out of open source technologies and solutions and helping them with their business in digital transformations. I've worked at a number of different software and media companies over the years and have spent over 20 plus years in technology. I'm happy to talk to you guys today about some of the things I've learned and encourage all of you to start to participate in open source communities so that you can derive a lot of the value and benefits from them. Next slide. Very cool. Okay, so, you know, open source is everywhere in your business and your business can't function without open source today. In fact, you know, we've heard numerous times that open source is software is eating the world, right? So what Red Hat does is every year that we charter a state of the enterprise open source survey and we enlist the third party to do that. So the third party alumnus was asked to poll some of them customers, others not customers of Red Hat across 11 different countries. And these decision makers and IT leaders, you know, we asked them a number of questions around enterprise open source technology. And we asked them how important it was to their strategic vision in their organization. Not surprisingly, 95% said that open source is important to their organization, digging a little bit deeper. We see that, you know, 36% and 39% view it as extremely and very important. And that really makes up the bulk of 75% of the respondents. And that's up 16 from 69% of the previous year survey. So, you know, open source is really the technical side of open innovation in commercial and financial services industries. From open banking to PSD to open source development and standardization on open source is allowing, you know, users and FinTechs and other organizations to take advantage of the data and services that weren't previously available. There's a great, great quote that, you know, is talked a lot about in the open source community. And it's not a question of whether to use open source, but it's really more how do you do it more strategically efficiently and extensively than your competitors. Next slide. So, deriving some of the data out of the state of the open source enterprise open source report. And that, you know, it's really open source is being used across all facets of the IT organization as a field resource for reddit. I've helped numerous organizations implement tools like Ansible for infrastructure and DevOps pipelines, reddit runtimes to modernize their applications and open shift to enable it to deliver modern Kubernetes based container platform for their customers. They've worked extensively with a lot of large financials. One example of that is Deutsche Bank, who is a good reddit customer and has spoken at summit quite a few times. They were able to modernize their past platform from what they previously had and they called Deutsche application platform DAP to a Kubernetes based platform based on open shift, you in which they've named fabric. And they've been able to take advantage of a multi cloud architecture. They've really been on this modernization journey for a while with us, starting with open shift three. And they've implemented the platform, while also redefining their application development strategy and transforming their DevOps and RRE practices. So they've not only successfully implemented the technology, but they've transformed their organization. Some of the benefits that they've publicly highlighted are that they've cut end to end application development from six to nine months to two to three weeks. They've also significantly simplified their DevOps collaboration processes using flexible integration and an agile approach. And they've also optimized the use and cost of data center and cloud capacity by implementing microservices containers and cloud bursting technologies. Next slide. So taking a look at the benefits that enterprises considered to be the top reasons for them, you know, using open source software. I think that, you know, some of these are not necessarily going to be a surprise, for example, lower to lower total cost of ownership. But I, you know, when we look at the other two top benefits listed based on the Illumina survey that Joe referred to, you know, we're looking at higher quality software and better security. So the idea that because there is this community of people coming together to create value in the form of software, because there is that wisdom of the crowds and operation, there is a higher level of quality of software produced. And also this whole concept that is often referred to as Linus's law, right? The idea that with enough eyes, all bugs are shallow. So open source software is able to provide a more secure operating environment for the businesses who are using it. And it's 100 percent, you know, my experience that organizations not only derive these benefits through using open source software, but they derive even deeper benefit by being there to co-create that software because by being there to work alongside the folks who are creating the products that you use, you're able to ensure that your use case is attended to. You're able to find out more about ways in which the security may be vulnerable faster. And you're also able to leverage what has been created that much more effectively because your in-house team has been there each step of the journey to help create it. So hopefully we have convinced you that open source is important to you and let's talk a little bit about how you can move from just using open source software to actually contributing to it and making it better. So I think one thing that's really important to know when we talk about open source software, we're not just talking to you about the software stack you're selecting, right? Open source is 100 percent an innovation model, right? And when you decide that you're going to go in all in on open source software, you're making a statement to your employees about how your organization is going to do its work, how it's going to produce value, how they're going to be engaging with their partners and how your organization is going to meet new challenges that are posed to it, right? Like thinking back to Joe's earlier example of Deutsche Bank and how they've been able to transform their operations and now can deliver value instead of in months, instead in days, right? And when you choose open source software, you're embedding that statement of purpose and how you are going to innovate into the set of tools that you are using that enable or disable certain organizational capabilities, right? You're choosing the tools that are fundamental to the rethinking of how you operate and you generate your value for your end customer. So, you know, I really love this quote from Greg Setel, right? And he says, for the past few decades, agility in the technology sector has largely meant moving faster and faster down to a predetermined path. Over the coming decades, however, agility will take a new meaning, the ability to explore multiple domains at once and combine them into something that produces value. This change will be profound. We need to rethink old notions about how we compete, collaborate and bring new products to market. And the part about, you know, rethinking old notions is really striking, right? It indicates, once again, that the challenges that face most organizations are not really about technology. They're not about problems of finding or acquiring or inventing new tools to do the same work faster or more efficiently. It's really problems that cut to the core of how we operate and how we participate in interconnected webs of innovation and evolution that are happening in places that we may not have considered that may in fact be happening with our competitors. So now that we talked a little bit about that and Leslie, you know, conveyed, you know, that the benefits and started to convey a lot of the benefits. Let's talk a little bit about, you know, the different types of models of engagement with open source technologies, right? Because there's quite a few different models that we're going to talk about today and we want to focus on. So I've broken this out into four different areas and we'll start with the most widespread open source relationship model, which is actually the consumption model. And, you know, I have a very high degree of confidence today that if you're listening to this talk, your organization is using open source in some capacity. Whether it's enterprise open source from a vendor like Red Hat or, you know, open source from straight from the community that a developer downloaded and incorporated or a tool that your operations team is using. And you're seeing obvious benefits from this technology. And there are also some risks that, you know, we'll talk about, especially when implementing completely upstream open source projects in a consumption only model. And again, this drives the benefit of whether the thesis of why we want you to co-create. Next, let's discuss a little bit about open sourcing of specific projects. Now, what we've seen over the past few years is some of the financial services organizations and other companies have decided to fully release specific projects that they've developed into the open source community and try to develop a strong community around it. The code's been vetted internally. The organization has done their legal due diligence and corporate due diligence to make sure there's no proprietary secrets or special sauce in there. They've also, you know, a lot of these communities that have been full fledged open source projects being donated have seen mixed results with some really taking off and taking hold with others not gaining as much traction and we'll touch upon some of the more successful ones in a few slides. Next, you know, I want to highlight a way of contributing to open source, which is a little bit more private. And it's a really good way for organizations to get started with the idea of setting up reusability frameworks and setting up code sharing capabilities and this is called inner source and there's a few companies that are pioneering this. This is where an organization put structures in place that enable the sharing of code between development groups and other application groups. It could be within it or within the lines of business but the organization puts together a framework that makes people comfortable with the sharing. There's a good chance that a lot of the capabilities that developers are working on small functions and capabilities are duplicated throughout the organization. So there's benefits of normalizing this process and reducing the deduplication of efforts. This is probably one of the easier ways for your organization to start getting their code out there internally and it will enable your organization to share and improve and pull from a common repository internally. So lastly, I'll hit on the most mature model which is the participation in open source communities and this is why Leslie and I are here for you today. This is when you participate in a project that's outside of your organization. The level of maturity here is increasing. The risk slightly increases but will help you understand how to reduce that risk and it's still very rare in financial services. This is the model we want to encourage you, our financial services customers to drive towards and we'll talk about this and give you a roadmap. Next slide please. So I want to talk a little bit about differentiating between the consumption model and the co-creation model, right? So we'll talk a little bit about the consumption model and here I want to walk through why there are risks in a consumption-only model. Let's say you're using an open source project extensively throughout your organization and the auditors come to you and say this piece of software requires this type of transaction tracking capability or logging capabilities. And this, you know, you can't just rip and replace this software with something that has this functionality. Now you're, you know, you're a test with three options really to get this functionality into your open source software that you're using. You can ask the community for a request for enhancement, which they may or not be able to accommodate. You might be able to ask a vendor that supports this software or another vendor that's willing to make the change and either carry the patch or get it merged into the project in some reasonable timeframe. You know, obviously there are probably significant costs to this. Or you can make the change yourself and carry the patch privately. So you have to ask yourself, how urgent is this change to your organization? Is it a security-based change? Is there a risk involved? You know, does it go beyond what the community sees, you know, the risk and what they're, you know, working on in their vision? Does this change give you a major business advantage? Do you want to work on this change in private and make it something that you are going to completely keep? Are you going to fork the project internally? Are you willing to maintain that fork for, you know, some timeframe? Or are you going to backport the patches to the original upstream project as it progresses and have to maintain that testing and those capabilities, you know, release over release. And has maintaining this fork or carrying the patches at whichever you choose put your organization in a very risky situation. Are you allocating resources to this methodology or this development capability that if these resources were to leave, you'd be in a severe disadvantage or disabled state? And, you know, does this technical debt that you're accruing grow year over year and compound? I've actually seen this play out in, you know, a few organizations. So as a real world example, there was a open source software project called Open EFS that was based on Open AFS a few years back. And it was a distributed file system created that created namespaces on top of NFS shares or NAS shares. And it helped solve a problem with software distribution that wasn't available at the time. There were a few contributors, but the community was fairly small. And a lot of organizations adopted it and would customize it on their own. The community itself stopped getting contributions about six to eight years ago. This piece of software was still being utilized, you know, extensively throughout financial services firms in Wall Street. So now as technology increased, it was up to the organizations to either keep continuously updating that software without a community and keep those patches and accrue more technical debt, or they needed to, you know, move off that piece of software. And as we all know in the software industry, if something's working, people are reluctant to make that change. And generally, we have a tendency to kick the can down the road and look at it at a later date. So, you know, the lessons learned from, you know, not being able to install this software on later operating systems because the supported libraries were no longer available or security vulnerabilities that weren't being patched because there was no community left. Put a lot of these organizations in a very expensive situation five or six years down the road. And, you know, the thing that I want you to take away from this is, you know, either you're going to maintain the project if the community isn't robust and dies, or you're going to spend a lot of money customizing it and or getting someone to customize it for you. So, isolation, software development, open source software development in isolation can get very expensive. Next slide. So, when we're talking about some of the ways that open source co-creation actually creates business value, I'm just going to go down the list of where we see value created at Red Hat, right? These are the reasons why we co-create open source software and where we've seen open source co-creation creating value for our customers and our colleagues, right? We've already talked about minimizing technical debt. Thank you very much, Joe, for Storytime. I always love Storytime. This whole idea of, you know, innovating to be able to try new things and then customize them, right, which you can't do with proprietary software investments. You can't extend those things. You can't make the software do additional things in order to meet your needs without relying on someone else's release schedule and timeline. And, you know, they may not even think that the feature that you're requesting is particularly important to them. And then there's also this, you know, dovetailing, right, winning with that, right? This idea of failing fast and experimenting in order to create value quickly, right? Being able to quickly spin up a minimum viable product and do some kind of user acceptance testing to understand if that software is actually meeting folks' needs, right? I could go through the list, but obviously, you know, all of you folks can read the slide. Joe, are you seeing the same things in your discussions with customers in terms of why they think that, you know, of our customers who are engaged in the process of co-creating? Are they seeing the same reasons for it adding value to their business, or are they seeing other areas where it's helpful to them? Yeah, absolutely. So, you know, when we were talking about this, the agenda and the talk, I reached out to a number of different customers. And, you know, a few of them who participate in open source communities, you know, they definitely confirm that, you know, these are valuable benefits to their business. I mean, higher quality software, you know, bugs in production are expensive. You know, the innovation, the being able to try things before making a full-fledged financial commitment to them, you know, technology-wise, was really important to this organization. So, you know, again, part of my job, the great part of my job is really interacting with so many different types of customers in the field. And, you know, as talking to one particular open source developer who works in, you know, a financial large bank, he confirmed that all of these are benefits that his organization looks to when developing open source software. Security is a very big one and I'll hone in on that a little bit, but, you know, again, the more eyes that see it, you know, it's open, there's no surprises. They feel that, you know, the risk is much lower with open source software. So what they did is they actually set up an open source program office. The open source program office sets the boundaries and the rules around all the different types of community interaction that this organization and the developers in this organization participate in, along with an approval process for contributing open source software. This allowed them to really take advantage and make it a culture where it's permeated throughout the organization and encourage to contribute to open source software. Once everybody was comfortable in this organization, you know, and open source, you know, participation started to proliferate, they were able to move much faster and deploy different platforms without as large capital investment that they previously had. And then they were able to choose better platforms for their business. They started contributing code, enhancing those projects and really making those projects even more and more beneficial to their organization. So next slide. So, you know, Leslie worked, works with the Phinos organization for quite some time, you know, myself, I've worked with Phinos a little bit throughout the years. But one of the great things about Phinos is it's an incubator where organizations can help or donate open source projects and work with Phinos for their open source strategy. And over the past couple of years, we've seen a few organizations listed here, you know, open, which gave and donated open source projects to Phinos and just outside to the community that, you know, previously we would have never seen before. So organizations like Goldman and JPMC and Capital One and Deutsche Bank have all open sourced, you know, projects that they've felt could benefit not only other people but even themselves for this open innovation and co-creation of software. So, you know, just going through the list at a high level, you know, a great example of the building communities are, you know, just the symphony community and the contributions that it's had over the past couple of years and Capital One's Higia platform, which has really taken hold and has established a really strong community with contributions from a lot of different organizations. So these organizations are starting to really see the benefits of participating, co-creating and open sourcing internal projects that they feel are widely used in the vertical and industry. Next slide. Very cool. So if we have not done a good enough job to convince you that there are many benefits to community participation, you can see several here on screen, but one of the ones that I tend to harp on since I have a long time ago background in human resources is this concept of attracting and retaining better talent. I think it's no secret that it is extremely difficult to come by professionals who have the skill set that we require no matter where we're working in the technology industry. And it's particularly important to realize the degree to which being able to participate in open source software projects has become a requirement of software development professionals now. There's this concept of GitHub is your resume. And for folks who are focused on making sure that they stay at the top of their craft, the latest and greatest developments in software are happening in open source. And people want to have the opportunity to work with technologies like, for example, Kubernetes or the latest and greatest financial JavaScript framework. So the idea that there is a benefit to participating in the community because it can help you to find the talent that you need because they're participating in that community right along with you. Or you're simply able to make sure that your staff remains invested in working at your organization because they're able to work on the cool latest and greatest technologies and not just in maintaining a back office system where the lights need to be kept on, right? So again, this idea that there's so many benefits to participating in a community and we want to spend some time now talking to you a little bit about how you can do that in ways that make sense for your business. So we wanted to start really with easy steps that your organization can take to start co-creating with the open source community, right? We've encouraged you to do it and we wanted to give very clear, very concrete steps that you can take to actually begin participating in ways that make sense for your business. So you can see if you want to take it even further. So step one is this idea of kind of follow along and learn, right? So nominate someone from your organization to do some research on a particular open source project, right? And do that by actively engaging by listening, right? You don't have to contribute code. You don't have to ship a feature. You can just kind of understand what's going on, right? Look at discussion forums. Check out what's going on with the project and social media. See what's going on on the project mailing list. Some projects have weekly or monthly community calls where they talk about all aspects of the project. So the community calls sometimes take place weekly. Sometimes they take place biweekly. Sometimes they take place monthly. There's typically an agenda published in advance. If you attend one of these community calls, you are asked to at least introduce yourself and let folks know what firm you're from. If you don't have anything else to contribute during the community call, that's perfectly fine. It's absolutely acceptable to just listen and learn. And this is an opportunity for someone from your organization to learn more about what's going on in the project in terms of technical direction, in terms of areas to contribute, in terms of upcoming events, which you may want to sponsor or send folks to attend to learn more. So again, it's a very useful way to literally have the opportunity to just reach out and understand what the different participants in the community are doing in a very low barrier to entry way. And that gives you a sense of what is happening in that project community. And that gives you a pretty good, you know, thumbs up thumbs down read on how healthy that project is, which helps you for your future planning and risk mitigation strategies. So step two, this is more the medium sized level of engagement, right? You can you can offer financial support to the open source projects that you utilize and this could come in the form of sponsoring their user conference. This could come in the form of an actual donation to a software foundation in support of the project's development. You know, it's, if the easiest thing for your organization to do is to write a check versus to donate employee time, there are lots of organizations who are in that position. Open source projects absolutely welcome financial support for their efforts. And you can also look at providing in kind donations for open source software projects as well and these can include things that are not readily spring to mind but for example, I know I believe Cisco offers WebEx free WebEx accounts to open source projects and other nonprofits. Some projects are looking for, you know, things like, you know, computing resources or a server space to host their mailing lists. Some organizations are looking at things like, you know, software license seats that may be possible because your company produces that software. So, you know, providing in kind donations is a is a again it's a low cost and low commitment way to support the projects that are making the software that your business depends upon. And where you can, if you have human resources to spare, it's great to donate the time of your employees who are working on, you know, non software development aspects of the project. Every open source project needs help with documentation. Many projects need help with marketing so that more folks are aware of that project and their capabilities. Lots of projects are doing various user events and they're looking for folks who can help them, you know, set up a virtual event or find the right speaker to address their user group, right? Those are all ways in which your organization can contribute to the health and success of an open source software project. But again, has nothing to do with contributing code or opening up your business to any sort of risks that's associated with software development and taking that software outside of your firewall. And then the advanced, the advanced level right is actually asking your software developers to engage directly with the project. And there are any number of ways to do this and it's very useful to make sure that you have an organization within your company such as an open source program office or an institutional review board who makes sure that there are very clear rules of engagement for your organization as you start contributing software to external open source projects. And it's also, you know, it make it very clear how you expect your developers to engage, but at that point, you know, let them go and just do something that might be fun, right? Lots of open source software projects will label issues and their issue tracker with things like newcomer or getting started or, or welcome tasks that are just to get people used to the process of contributing to the project. So they understand, for example, how to properly use the style guide or, you know, what does an appropriate commit message look like for the project? And give your developers the opportunity to go and do a few small fixes, see if they like working in that project community, see if they feel like they're deriving benefit from it. And if everything is going well after you've taken these first few steps, you can start looking at contributing, you know, on a wider basis, maybe an entire new feature, maybe resolving some outstanding issues that are also plaguing your organization and that you fixed internally and you want to contribute that change back upstream, right? So to conclude, we wanted to share some resources with you folks if you wanted to learn more about the subjects that we've been talking about. And just, you know, we wanted to be really clear that these are things we regularly use ourselves. So we hope you will also find great benefit in them. So I cannot say enough good things about the Phinos open source readiness working group. I'm a regular participant whenever my schedule permits. And the Phinos open source working group is a practitioner led group of folks who are all members of Phinos member companies. And they are sharing best practices and tools to help their fellow colleagues in financial services be able to successfully engage on their open source journey. We there's typically a weekly speaker. We've had folks talking about subjects, everything from, you know, open source licensing protocols to open data licensing. We've had discussions about how to create training programs for your employees so that they successfully contribute to open source in a way that isn't keeping with the company's open source program office or institutional review board's rules. So it's really a great opportunity for you to come and either share your wisdom or ask your questions or do both from folks who are also experiencing the same set of challenges and opportunities for success that you are. So if you're able to attend, highly recommend at the very least subscribe to the mailing list so that you understand what sessions are coming up and potentially can watch recordings or later write ups. Another area where I have found great values within the open organization community. This is a global community of individuals who come together again to share best practices and principles around understanding how we can change notions of how we work together. How we manage our teams, how we function as individuals who are leading projects and to move beyond the idea of sort of traditional hierarchical models into doing things more the open source way where there is an openness to new ideas where there is an ability to share wisdom even if it comes from our competitors, right, and to be able to build something that is of mutual benefit and value for all. And this organization, this open organization community focuses on principles of transparency, collaboration, community, inclusivity, adaptability, all of the people processes that we need in order to achieve open innovation, right. It's not just about tools. It's about the individuals who are using those tools and how they're working together to achieve new ways to create value. Last but not least, if you're looking for a quick write up on the business value of open source software for financial services firms, look no further than our fine friends at Phinos who have authored a white paper on that very same topic. This white paper, it runs the gamut of discussing topics that are relevant to financial services firms, everything from how to perform effective risk mitigation when using open source software solutions, risk mitigation when contributing to open source software projects, using your energies in the open source world as a recruiting and retention tool. So it's very useful. It's a quick read and it's basically brought to you again by practitioners within the Phinos member community. Full disclosure, yours truly is one of the authors. So of course I'm going to say that this white paper is great. And then last but not least, I thought really long and hard about including these these resources because they are very much directly from Red Hat. And I cannot stand the number of conference presentations that I've gone to where I have gotten sales pitches because it really annoys me. But I did decide to leave them in because these are all resources that either I have directly participated in or have had the opportunity to to benefit from. So I'm going to share my own experience and hopefully you will also find significant value in what I'm sharing with you. As I said earlier in the presentation, I'm a member of Red Hat's open source program office and we create a huge library of resources on creating and executing a successful open source strategy. We have documents that are available on our website, including like a, you know, how to start get started with a new open source project checklist. And our team has also created a number of presentations to help folks understand how to architect and approach having an open source strategy, including things like, you know, how to participate in an open source community and a beginner's guide to open source. So if you're interested in those kinds of learning sessions, if you are a Red Hat customer, you can reach out to your account manager. If you are not a Red Hat customer, but you're still interested in learning more, please email me, please email Joe. We're always happy to make sure that the right person is able to show up to share this knowledge with your organization because we very much believe in the value of open source. And so we're very happy to educate you whether you're whether you're our customer or not. Another offering that Red Hat provides is through our open innovation labs group. And this is open leadership coaching. This is, this is an opportunity to talk to one of my dear colleagues, Shabnore Shaw, who is an expert in industrial organizational psychology and her mission is to help business executives have like the really hard conversations about how they are working together amongst themselves to create the culture that allows their business to innovate and how to achieve digital transformation from like the perspective of how their people work together. Right. This is an entirely people centric point of view on how to do technological innovation. So if you have the opportunity to talk to Shabnore, please do. I have regular one-on-ones with her and I benefit from the wisdom that she shares with me every day. And then last not least this this ebook that that I have read personally and have read multiple times this transformation takes practice. And this is a guide to understanding the open practice library and the open practice library is a Red Hat curated set of DevOps and product product development practices and principles for learning about the discovery and delivery of software. And this is brought to you by Red Hat's Open Innovation Labs team. I've never actually worked with the Open Innovation Labs team on a project because I am not a software developer, but I did have the opportunity two years ago to attend a training course for folks who might want to participate in a lab session. And I have I have used what I have learned in that one week workshop on a bi-leakly basis ever since then. The Open Practice Library has any number of exercises that your teams can go through to understand how they wish to create shared value, a shared definition of success, how to create, you know, work sprints that are actually effective, how to uncover and discover. What are the the actual requirements for the for what are being built not only for the the team getting together to build it but for for their stakeholders within the organization and of course for the end customer. So I would like to recommend this and I will I will just conclude by saying that I tell everybody that the Red Hat Labs email list is my favorite one to subscribe to and the one that always leaves me smiling. So of course I'm going to say great things about labs. So folks, that's that's all we have for you today. We hope that what we have shared with you is beneficial to you and useful. Joe and I will be in the virtual booths for a couple times over the next couple of days and we also wanted to let you know that there are some folks from our labs team who are hanging on our booth if you're interested in talking more about our labs offering and the really the open practice library which is a freely available resource online and how you might be able to use that to consider your open source software journey and your work in open innovation. Thanks so much. Thank you very much.