 All right, well, we may as well go ahead and get started. Welcome, everybody, to our talk today. My name is Brian Warner. I'm presenting with Nick Penston. We are from Fidelity Investments, and it is not at all lost on me that we are one of the last sessions of the day in standing between you and a reception. So thank you for coming here, and thank you for being here with us to talk about what it's like to make open source contributions and to build an open source contribution practice from within a regulated firm. Now just kind of by way of introduction here, the reason that we wanted to present this talk in the first place is that it's very easy to look at the contributions which are coming in from many of the large players in the open source industry and be a little bit intimidated, particularly if you're coming from the type of firm that is traditionally more conservative about working and acting in the public. Fidelity, we are a tech company, and the reason that we're here is that we have successfully built in open source practice. But again, because we're in finance, we've had to make some adjustments that are maybe beyond what you might find in some other industries. So we're not really unique, I think, in being about nervous about open source contribution. Just kind of curious if the folks who are in the audience, how many have worked in a firm that has maybe struggled a little bit with the idea of working in the open? OK, I see at least a few. OK, yeah, I think this is pretty common. So really what we want to accomplish today, what Nick and I would like to accomplish today, is that we've really got three key takeaways. The first one is that building an open source practice, it can be hard for various reasons, and that's OK. The second thing is the specifics of how this actually works for each individual company are going to be somewhat different. And third, it's absolutely possible to do this and to be successful. So just initial disclaimer, we are talking about ourselves. Again, we're with fidelity investments. We are not recommending or endorsing anything. This is a case study that is about ourselves. So please keep that in mind. So up front, I kind of like to anchor this discussion in the fact that we don't need to be convinced about the benefits of open source. It's not that we lack, and not the companies in our situation, lack a desire to participate. It's just that we are potentially more cautious about consequences than other industries. And these consequences, they may or may not be grounded in actual experience. But to some degree, that doesn't matter, because what we need to figure out here is not how do we convince people that this is a good idea, but how do we actually do it in practice? So some of these concerns, they often follow a fairly common pattern, and probably falls into one of these three buckets. They can be fairly abstract and not specific to a contribution or a project or a contributor. But one of them is often security concern. What if the project that we contribute to gives hints about our internal infrastructure? This is a fairly common concern. Second one is reputational. What if we do something embarrassing? This is, again, a fairly common concern. And then the third one is pragmatic. We're all very busy. If we go through this process and discover that our work is rejected, either by our own firm, as we're going through the process of getting the contribution out the door or by the project itself, did we waste our time? So these are fairly common concerns in a lot of cases that the practices that we've put in place at Fidelity and that we're going to talk about very specifically address this. We're not trying to minimize anybody's concerns, but we are attempting to work within them and build approval processes and build encouragement within the firm that helps get around some of these concerns. Now, one of the things that is kind of a common thread through all of this, you'll notice that none of these concerns are really about being afraid of tech. When you look at a financial firm, most of us are highly sophisticated entities. And contribution to open source participation in open source communities is not about the tech. And so what's it about? Well, in financial services, we have a lot of rules. So this is, I joined Fidelity about a year ago. I came in from the open source community. Spent of my 15 years in the industry. About half of that has been in open source foundations. And the other half was with IBM and Samsung, which are very active tech firms. The biggest difference between us and the high tech sector, it's not whether we want to lead the curve, but rather who's looking over our shoulders and checking our work as we're doing it. So this leads to quite a few differences in the way that you approach the question of getting permission to do this work and getting approval to actually make contributions. And these are the things which we're going to talk about. I want to be very clear, and I'm going to say this a few times, the goal here is not to discourage anybody. This is rather demonstrating that there are viable paths forward despite some of the concerns that you may run into as you're working within these processes. So I'm going to talk a little bit about the environment that we work within. And then when I pass it over to Nick, Nick is going to share some really practical advice for what's actually worked in his organization over the past few years. So like I mentioned, I joined the finance industry from high tech about a year ago, and I wanted to share some observations to just kind of ground this conversation. These are some observations that I came across as I came in, and the first shouldn't be a surprise, but I hadn't fully appreciated just how much double and triple checking there would be moving from Linux Foundation from nonprofit into finance. This is very good for work-life balance in the sense that we move a little bit more slowly, but it can be challenging sometimes when you're trying to keep up with a fast-moving community. And then second, the tech adage of move fast and break things really does not apply. One of the things which I've found over the past years, it is never better to beg for forgiveness. The only thing better than a plan is a plan that has been reviewed by multiple parties, has a risk owner, which is tracked in the system of record. So we rarely have the luxury of impulse here, which means we have to be, going back to the title of the talk, steady and deliberate. And finally, when it comes to open source, one of the things that I've found is we don't really dive into community's head first the way that I've seen in prior firms that I worked in, or immediately open up a flurry of poll requests. These are kind of good ways to get a visit from your friends in security and compliance, and they may have some comments about that. Our goal here, again, is to find ways to work within these constraints. So don't get discouraged. This is going to be something which you're going to hear throughout this talk. You really, you have three options when you make a move into a firm that has a more conservative viewpoint on these things. You can either not participate at all and just assume that you're going to go heads down for a few years, and that's obviously not great. That's not the answer that any of us really want to hear. You can find clever workarounds around the rules and regulations, which is really not great. That definitely is not the sort of thing that we want to be encouraging here. Or ideally, you can work within these systems that you have, which that's going to be the point of this talk. Contribution ultimately is a matter of laying social and technical groundwork so that when you go to make a contribution or somebody in your firm goes to make that contribution, they are able to follow a series of specific steps and tasks and follow within those guide rails so that we're not raising red flags for unnecessary reasons. So I'm going to take you through about four things that I've learned from the way that Fidelity created this environment to be able to support work that's coming from teams like Nix. And the first thing is, it is okay if your firm does not have an established practice. It's okay to start on hard mode. Just try not to stay there. You're likely, when you begin an open source practice, you're likely going to start fairly far from where you want to be. And it's very easy to compare yourself against some of the big names in the industry and say, how will we ever get to that point? It feels like it's so far away. But you have to start every journey with a first step. So for example, one of the things that I've learned on my team, I am basically the open source programs officer at Fidelity, I've learned that record keeping is really important. So this is not just keeping contribution metrics but actually having a structured process that uses the same system of record as the rest of the firm. Another aspect of that is that there needs to be somebody who can actually own the risks in a meaningful way, which you may or may not agree with what your firm believes the risks are based upon your prior experience and direct experience in the open source industry, but you still have to work within that framework. It may not feel open sourcey at first, but that's really okay. You have to get started somewhere. And in the process of doing so, you're beginning by building trust that you can actually follow the systems which are in place before you start trying to build around them and trying to augment them into an actual open source contribution practice. The second one is that there's an awful lot of value in finding common cause with people who are not ever going to be contributors. This is something which I hadn't fully appreciated until I started working into a firm that has a fairly sophisticated audit and compliance practice. So you can actually find some help in unusual places and my advice here is to lean into that. So in any organization of decent size, you're going to find people who want the outcomes of open source contribution, but actually don't care about the details. One of the areas of unexpected support was with our internal audit team. So at Fidelity, we have various processes that we have to follow to make sure that software doesn't get too out of date. We call this the technology lifestyle management process. It's about managing end-of-life dates and making sure that we don't have crusty things in our stack. And if internal to Fidelity, if we find a team using outdated dependencies, this actually kicks off a process where the developers get notified, they have to create a plan and then commit to it to be able to fix and remove or remediate these dependencies that are out of date. And this is fine if you are writing an app and you have direct dependencies and you have control over it, but every modern piece of software is built on a stack. And that stack pulls in a lot of transitive dependencies that you don't have direct control over. One of the things which we find is teams will receive yellows and reds on their scorecard if they have outdated transitive dependencies, but they'll say, rightly so, we don't have control over this. What are we going to do about it? One of the places I was able to find support over the past year was with our audit team and saying, well, one of the things you can propose to them is make the change in the upstream community. You're still going to pull in the same pristine package from outside the firm, except now it's going to have updated dependencies and you're going to be off of your red and yellow scorecard. The audit team thought that this is great. It means affording a little bit of extra time for the contribution process to go through, but at the same time, you're fixing the problem for yourself and fixing for others. So I think the point here is that there are going to be reasons to contribute that do fall outside of the normal open source is great talking points. And it's okay if this comes from parts of the organization who had zero interest in open source or open source communities. The key is helping them understand that this kind of work helps solves problems that they care about regardless of the mechanism. The third observation from the past year here is that it is absolutely okay to admit there are challenges. For example, submitting a conference talk about how things are a little bit different in the finance industry when you're contributing to open source. You should also acknowledge that it takes time to fix them. This is biggest piece of advice that I could give to other people who are in new auspose. Don't fake it till you make it. If you're coming into a firm that's been trying to build an open source practice or that has tried in fits and starts, you are probably going to encounter people who are frustrated because they bounced off the restrictions in the past. And one of the things which I've found is it's much better to acknowledge that there are challenges and that you care about the solutions than to pretend that everything's going to be fine. This helps build trust within the people who are going to be using these processes. But it also helps you gain some elbow room and buys you some time to get some work done, time and space to get work done. So as with any engineering, whether it's a software project or anything else, you need to manage your timelines, right? Clever hacks and workarounds, they just aren't valued in our industry the way they may be in others. And it's taken about a year for me to understand our internal processes well enough to actually begin proposing meaningful changes to them. And I don't think this is unusual. So you're really kind of taking a step back. It is totally fine to admit that things will get better in the future and that you're going to need time to fix them. You want that elbow room so you're not trying to make changes in a panic. And then finally, the story that I just gave you was our story. And this is very specific to our Ospo. This story is not going to be the same for everybody, but this actually, this filters down into more levels of nuance. You're not going to win all the battles all at once, but you can win some of them with proper framing. In a regulated firm, we care a lot about risk management. It's really, really important to us. And the most efficient way in general to manage risk is by defining general cases and then fitting as many scenarios into them as possible. But I think anybody in this room would tell you open source isn't well suited to general cases. One of the keys to success here is that you want to choose the right hairs and choose to split them the right way. Nautical projects are the same. Nautical contributions are the same and Nautical contributors are the same. And it is actually useful to treat them differently. Some projects by major of what they do are easier to frame as low risk. So empirically about 95% of Fidelity's open source contributions are from cloud and platform engineering teams. Most of the time they're contributing to infrastructure projects that are generally pretty easy to justify and relatively low risk. So as long as you're not committing internal config files or putting real data in test cases, it's unlikely that you come anywhere near a sensitive situation. You can build up momentum in an open source project or sorry, in an open source process by sticking to the right kinds of projects which that allows you to branch out in the future. So really by drawing these distinctions you can really begin to carve out some safe swim lanes for yourself and build the organizational confidence and competence that are necessary to actually build a successful contribution practice. So with that, those are some learnings here. I'd like to turn it over to Nick who will talk about how this is actually working practice. Nick, go over to you. Thank you, Brian. All right, so I'd like to switch gears a little bit and take what you just heard and how do you put it into practice? How do you implement it when inside your engineering teams? So before we get into that just wanna put a bit of context on where we started from and ultimately it was from zero from a pretty low base. We did do open source contributions but really what we were looking for was to embed open source contribution and its way of working inside our engineering teams to be able to contribute to open source as part of our everyday work. So that was part of the transformation that we wanted to drive and that's the journey I wanna take you on now in the things that we did, the success that we met, the challenges that we met and how we went about it. All right, so first, what we started on first was running a pilot. It was pretty small, it was about three months in length and really what the idea was was to work with Brian's team in relation to how do we understand the friction in relation to those contributions so when inside the firm, what are the things that we need to know as engineers and in engineering teams to be able to make those contributions? To be able to build advocates for open source contribution when inside the engineering community so we can again, as we wanna scale that out to be able to utilize their learnings to help others but ultimately it was to learn. We were coming from a low base in relation to our engagement and we wanted to understand how to engage with the community successfully. So we did that for about three months. We had no restrictions on what we wanted to do outside what Brian and his team were recommending but ultimately it was aimed at learning and being able to really open up the advocacy in relation to open source within site at York. So based on that, we took a step back. So you might say why do we take a step back and start thinking about strategy straight away after a pilot rather than just continuing and scaling the pilot and we did that for a couple of reasons. The first was when we want to advocate it across the organization we needed support from our leadership and be able to articulate that and be able to communicate that to them was really important but also from the engineering side how do you get them excited about the opportunity to contribute to open source in areas where they may not think that we can do it. And that was really the key reason why we took that step back and tried to understand why and how we were going to do it. And what we came up was with a simple tree tier model and we wanted to keep it simple for one reason we wanted to be able to communicate it pretty clearly and pretty easily in relation to our stakeholders and developers but also to give us that guiding light that we can empower our engineers to be able to across the organization to be able to drive the strategy forward without having something complicated to align to. So the first step on it was about enablement and that mirrors what we did in relation to the pilot keep things small it's about learning it's about learning in relation to engaging with the community. The second phase was around building on that initial step and the expertise that we wanted to build so starting to get more complex features start to understand the code bases in which we wanted to work and then finally when you think of the strategic impact we want to have a lot of the projects as you heard were in relation to the platforms in which we were building and we wanted to build expertise in those open source frameworks and platforms and tooling so we could then contribute to them and solve the problems that we had but also give that back to the community. And this is where things really started to begin on our journey and started to scale that and implement it out and I want to take you through the first two the sections just based on time. So first up we start on the nano contributions we call them nano because they were really small in size these are not big impactful changes they are small changes that can be anything from documentation changes to very small bug changes the aim of them is to first time contributor make it simple lower the barrier of entry for engineers and they can spend time on these simple things to understand the process which is inside the organization. We also wanted to keep it to between one and three hours in length so again making sure we could complete them quickly in relation to these small changes again time box is the most really important so again keeping that barrier entry really low. It was aimed at first time contributors we did see as time goes on people who were contributing multiple times we'd see them doing multiple nano contributions on projects that they were interested in but again it was aimed at getting people on that contribution ladder and being able to use it as a tool for learning. We wanted open source not just to drive strategic direction from our perspective and contribute to projects that were strategic but also to be able to use contributions as a learning tool you want to learn go contribute to go based projects you want to learn Python or you want to learn more about Kubernetes or open telemetry you're able now to contribute to those projects and again use them as a learning tool. So what type of things did we do to measure success and this is one of the key areas that we started off pretty early and I'm a huge fan of keeping measurements simple and again being able to use it as a way to communicate to your stakeholders on the direction you're doing. So we used two metrics here at the beginning and they're pretty basic it was how many contributors did we have and how many contributions were we making? As time went on we introduced what we called our lead time and that was how long was it taking in relation to the contribution starting and the open pull request and then working with the OSPO then to reduce that friction. What about the challenges we met? So one of the challenges we had in the nano contribution side was mirrored actually in the pilot was how do you have the momentum for these small changes? So how do you ensure that the developers aren't spending a huge amount of time going looking for these changes? We wanted to keep that steady stream going and understanding the open source community understanding the projects that takes time and that essentially mean that that rhythm of contributions was often difficult to continue to maintain. Some projects are very good at indicating these are good first time contributions others may not have that facility so again navigating that and making sure that we had a good backlog of contributions that developers could pull off to ensure that we kept that friction pretty low. So moving on then around onto our project clusters and this was the area which we focused on driving expertise in the projects we were working and the big difference between the project clusters and the nano was it was more moving us towards a more strategic direction in relation to the projects we wanted to contribute to. So a key area here was as a platform and cloud and platform engineering team we deal with a lot of platform deal frameworks and technologies and we wanted to be able to build out our open source contributions around those key tooling and platforms which we use so we can contribute to them and drive the strategic direction then of our platforms. So these project clusters were a group of engineers that focused on platforms that in Kubernetes, open telemetry various things like that and these projects then focus on building expertise in the core code base within those areas. Again we want to use it as a way of learning and again being able to learn about the code base but also for engineers to be able to learn about the frameworks, how to work with the community bring that back to our engineering teams. So how do we measure success here? We continue to use our contributions and contributors as an indicator of our success around the clusters and introduce what we call our drop rate and our drop rate was how successful are we from going from starting the process to ultimately ending it in a public PR but also how successful are we in getting that PR merged? And the reason why we focused on this metric was to help us guide one was the maturity of our engagement with the community particularly because these changes were geared more towards bug fixes and small features. We wanted to understand where we're engaging properly and being able to get that drop rate ultimately as low as possible as we continued to mature. So you've got your nano contributions up and running. You've got some project clusters around some of the platforms or some of the tooling or frameworks that you're really interested in. How do you kind of keep that momentum going once you get that initial success and essentially that initial excitement about being able to contribute to open source? I'd like to talk about two key areas which were really critical for us and keeping that momentum. The first one was around the use of a steering group. So we created this steering group at the beginning to help essentially guide the strategy forward. It was a group of about five to 10 engineers who were passionate about open source contribution and they were empowered to decide how we were going to implement the strategy which I showed a couple of slides back. The steering group was open to anybody. It wasn't necessarily senior engineering leaders. It was open to those who were advocates of open source and they were empowered again to drive that strategy. So one of the big problems we started to see with the steering group was as we started to scale out this program was the steering group started getting really, really large in relation it went beyond the eight people, the 10 people and what happened was decisions were starting to take longer to be made and obviously different opinions, et cetera based on that strategy and how we were gonna implement it. So we took a step back and revisited how we were looking at steering groups and started to federate the model based on the project clusters. So the model area you see on the screen essentially the steering group continues to be the core driver of the strategy but introducing this concept of a focus group which is focused on the project cluster. It mirrors the steering group in the way it works as in between five to 10 engineers are part of that area they're again passionate but they have the context of that project. So when you think about I'm working in Kubernetes I'm now going to be in that focus group I'm gonna contribute to the main Kubernetes platform, et cetera and we're gonna drive the strategy and how we're gonna drive contribution in that area. With these two groups in mind they're driving the community so not everyone needs to be involved in a steering group or a focus group to be involved in open source and driving the open source for example we wanna drive a community who are engaged in open source contribution outside of these groups and in their squads or in their teams and their engineering teams and again with sharing best practice sharing the challenges with having and feeding back that into the OSPO for example. Another key thing on scale and driving engagement was the introduction on what we call the jam and we run these jams to essentially bring engineers together so it's a real community aspect and it differs between five we've run them up to 30 we've won actually next week up to 50 people and we bring people together to contribute together. So depending on whether it's around the clusters or it's very wide open in relation to the nano side it's about bringing engineers together to share that experience and two when they're in that room or doing it virtually they're able to share hey I'm stuck on this can I get help and being able to really accelerate the contribution process for those engineers getting them moving, getting them the contribution out into the public domain very very quickly and what it does is also is it creates this network of engineers who have then contributed to these projects people that may never have met each other across the globe be able to then create that network and community and then create that sharing aspect of it so it's really successful in driving not just our contribution and bringing those numbers up but also creating the community behind it. So finally you've done all that great stuff for the type of things that you need to consider when you think of your momentum is going to also think about outside of the general process and there's four key areas which definitely resonate with ourselves that have been key to our success. The first one is time. So we were really fortunate in relation to infidelity we have what we call learning dates once a week we have one day dedicated to learning and we were able to use that as a platform to do contribution. Now if you don't have a learning day or you don't have learning time think about how you're gonna open up time for your engineers. You might be able to have open source days or open source periods of time built into your capacity of your teams for example or other different ways to be able to enable your engineers to contribute really important to be able to ensure that your developers have the time to make those first steps on their first contributions particularly. The second one is around rewards and recognition and this is really important not just from the beginning but also as you continue the momentum. How do you recognize those who are leaning in to really drive the process, who are advocates but also those who are contributing continuously who are really driving the contribution particularly the complexity and driving the impact and the expertise in your projects. How do you recognize that range of people and being able to do that to show the behaviors that you want others to do. The third one is around support and that was one of the key areas why we built the strategy at the beginning in the first place was not just at the beginning of the process to have that support from your leadership from your engineers to drive it forward but how do you continue that momentum because often when you start on the nano side it's not really impactful from your firm's perspective because these are small changes and again being able to get the support to be able to crank the wheel at the beginning lay the foundations for your engineering teams to be able to contribute is key and then as you go into the impact stage and being able to contribute bigger contributions that have bigger impact to you as a firm getting that support is critical to continue that momentum. All right, that's hopefully giving you some insight and just to wrap up, you heard from Brian his insights from coming into a firm like Fidelity from the outside, things can look challenging at the beginning but continuing that momentum looking at the longer view is really, really critical thinking about how you start off again, we started off with a pilot it was a great way to test the water, get your support understand what it means to you as your organization and building a strategy to drive that momentum and ensuring that you're bringing everyone along is really, really critical and don't forget the measure really important to measure it's a great way to communicate the tool and also get those early wins to be able to demonstrate the benefit to your organization. Thank you very much. Any questions for myself and Brian? I'd like to know about the community is it the internal community? So question was around the community was the community I mentioned an internal community yes it was an internal community for us it was really critical to be able to bring developers together to share their stories of how they're working in open source the benefit it had to them personally but also the benefit it had to their engineering teams often it would be best practices that they picked up from the open source projects they were engaged in and then sharing that and then amplifying that across the organization and being able to create that network of engineers that were contributing and sharing the challenges and then bringing that back into our process to improve. And then any difficulty to bring up the community develop the community? So the question was was there any difficulty in bringing up the community? We have strong community practices when it fell early already and we use that model in conjunction with the steering group but my advice there is started off small a community doesn't have to be thousands of engineers across your organization it can be as small as five or six people on a video called sharing their experience and then being able to talk out then in relation to it so what we started with we started like that at the beginning we only had a small amount of people and then being able to share those stories and then invite others to hear those stories and then the benefits and then amplify it in that way and we hold those jams which were a great way to be able to bring people together who ultimately demystifying that you can do open source as part of your role inside a financial service company and it's that momentum that starts to build the community but it's all about momentum so we were the steering group and the focus groups a key part of what they do is constantly thinking about how do they put the message out in relation to the success that we're having and telling that story over and over again thank you very much were there any policies or procedures that needed to be addressed or challenged in the course of setting this up particularly in the very beginning and getting started and sometimes particularly in our corporation there's a brick wall there that would have to be you know that the policies would have to be rewritten first before we could even begin to begin the journey or that would be the first step in the journey I can take that one so just by way of context within Fidelity we are a heavy policy driven organization so essentially we have policies which say you have to follow the specific standards of behavior and then those get implemented in various different guidelines now one of the things that we have had in place for the past few years is an open source standard which has been fairly non-specific it covers really four major topics it covers non-code contributions so if you're going to answer a question on a stack overflow or something like that consumption of open source, contribution to open source and then actually hosting open source projects each one of those sections is about a paragraph long so it leaves an awful lot of room for interpretation kind of to that point and the best piece of advice I think that I could give if you're in a situation where the firm is saying we need to rewrite all of the policies would be to start as generic as you can and Fidelity's approach on this a number of years ago was to say we know that people are interested in open source contribution we don't know how many people are interested we don't know what they're interested in doing we don't know what hurdles we're going to face so let's not over optimize this from the beginning we're not going to get it right at the beginning so we created effectively intentionally unoptimized processes for open source contribution now three years later the ball has started rolling and we're beginning to say oh these processes are straining under the weight and it is time to actually make changes to those actual standards and start rewriting them to be very specific to an open source contribution practice however if we hadn't spent a few years working under the heavily manual processes I don't know that we would have had the internal justification to be able to say it's time to optimize these things this this goes back I think probably to the to the beginning of the presentation it's fine if you it's fine to start with you know manual reviews like I review every piece of code that goes outside of the company you know and this is we want to get out of this process of having manual reviews and humans having to look at things for every single contribution but it's enough to at least get us rolling so we can then say okay now we have justification to update these standards because this is getting to be a very heavyweight process I think also when you think from the engineering side is you can also be tempted to scale really quickly and then you know you don't scale because of those challenges start small that's why we started with the pilot to be able to test and learn and just to even understand what are those roadblocks and where are the walls and then be able to work on then reducing that friction and just understanding and being understanding of where the friction is and then being able to work very closely on it it's it's we have the model to scale is to not to scale first right and that was kind of why we did the pilot in the first place any other questions curious whether you focus on lots of little contributions to lots of open source projects or do you focus on main big projects that you wanted to open source and that kind of thing so the question is to do we focus on lots of small lots of small contributions to lots of projects or a subset so at the beginning on the pilot we had a pretty open door policy in relation to what we would contribute obviously in line with what we could contribute to the nano contributions is intended to get your foot on the open source ladder so we don't have any restrictions in relation to hey you know we want you to only these five projects on the nano side the project clusters narrowed the band down because we're more focused on building expertise in frameworks that we utilize inside the organization and with the nano my advice is keep it wide as you can because one you're looking for those small changes and if you have a small subset of projects that can be actually quite difficult to do and particularly scale out so we still use that nano contribution today it's all about enablement so you know the answer to your question is we keep it wide on the nano contribution side as in the enablement side but narrow it as you kind of go up through the strategy when you get to the end there's only a small amount of projects which we focus on to build the impact and influence versus say on the nano side any other questions all right appreciate your time thank you very much thank you everybody