 Hello and welcome to our presentation on inner source, a step on the path to becoming an open source organization. We're delighted to be here with you today at the open source summit in Japan. My name is Claire Dylan, I'm the executive director of inner source commons, most of the co founder of open Ireland network and an organizer of the Ospo plus plus network. Hi everyone, this is Danielis Kierdo, I'm one of the founders and CEO of Vitergia, your smallest startup in Spain focused on providing analytics and open source and inner source projects as well as providing Ospo and ESPO services. I'm board member at the inner source commons foundation and I'm part of the governing board at the chaos community that stands for community health analytics for open source software. And we're here today to talk about how inner source as a practice can help people on a path to open source culture change, because working in the open is a challenge. It requires total transparency, and there are often reputational risks associated when organizations are trying to move from a more traditional way of developing software to move into developing software in the open. There are cultural expectations in terms of engaging with open source communities, and teams often want to learn how to do that in a safe environment. And this is what inner source gives you inner source is the practice of using open source methods and practices, but within an organization's organizational boundaries. So they can do that in a safe environment and get you ready to then contribute to the open source community. So let's start by understanding a little bit more about what inner source is. Okay, so this is the short definition Claire already mentioned this, right? So let's let's say this again inner source takes the lessons learned from developing open source software and applies them to the way companies develop software internally. So this is about developing arbitrary software. This is not about creating open source software. You have more information at the inner source commons.org and why inner source. So inner source aims at removing silos of development. If we use an analogy here of how large corporations are, if we think about business units, department, geographical regions, all of them look like this. So there are silos of development that are silos of knowledge. So probably you've faced the problem in your in your company where you are developing or you realize that other departments are doing a similar piece of code. It doesn't matter the code itself it matters that you are producing once and again the same or pretty similar pieces of work. So what if we are able to remove all of these silos right next slide. If we're if we are able to remove all of these silos then we can think of a much more engaged way of developing software altogether from different areas of the company. If we think about this, what we'll see is that the more the points of the different point of view when attacking a problem, the higher the innovation within this organization, the more eyes looking at the source code if this is totally transparent if this is totally collaborative. The higher the quality of the software probably the higher time to market it because you are creating more stable pieces of software, you go about a specific code review processes about the pull request process we'll see about it later. And what we've seen at the inner source commons and in other corporations is that that there is a higher engagement from employees. From the perspective. What we are doing here is we are empowering developers so we are empowering developers to make decisions to solve problems they are engineers right and because they are engineers they like solve solving problems. And by opening this door what we are doing again is we are allowing innovation so we are we are giving room to developers to to meet their managers to everyone in the corporation to try things to try and fail and that's really important this this failing thing because this is where we are So what we are doing in reality is we are creating this let's say more dynamic environments. And at the very end what we are creating is we are speeding up developers into self skills soft and hard skills at the same time because we are allowing developers to talk to each other, if you remember about the silos that we saw before the photo. So what happens in the usual hierarchy in large corporations is if there is an issue between one developer development team and the other. This needs to be escalated so this need to go through the you know the hierarchy what we call at the inner source commons the cheese interface. So what if we break all of these so we are allowing developers to work to each other so we need to set up specific rules clear rules development rules as those rules you can see in the open as in open source. So we are bringing those lessons learn again into into the proprietary software that we are producing. So, next slide. And all of these all of these discourse is not based on just the specific steps or random ones so this is based on on principles. These ones are, it's a way of looking at them this is based on the patchy way by the patchy server foundation which is what we are using at the inner source commons as you know way of getting inspired. If we want to make this cultural change because this is mainly about the cultural change we are we are moving into from a scenarios where we are hiding things and we have certain power into scenarios where we are sharing we are totally transparent right remember that we want to move into this open way or open by default open way of producing open source software at the very end in our journey to open source. We need to change our minds into this way. So these principles that we can see here, communication transparency collaboration community and meritocracy are part of this journey. Let's think for a while in how open source communities work and how we are applying this internally so if we think about communication, what if we start having all of the communications open all of the discussions technical technical discussions specifically open. So what we are creating is certain certain layer of transparency right and we all have an opinion. And if we allow having opinions in the company what we are creating is certain collaboration because someone will communicate certain technical decisions and because this is transparent. Then others may bring their own point of view bringing other point of view what we are bringing here is innovation remember and then at the same time we are creating certain concept of community so we are allowing people across the different silos in the photo that we saw before about, you know bringing together and having a technical discussion all together and then of course we may see in the near future certain meritocracy as technical leaders or people with with certain skills that will will raise their voice they might be, you know, reference as those technical leaders within the community internally in the corporation. So this is this is what we can call meritocracy. Okay. So let's let's try to go back again to the definition of inner source of what is inner source. So this is a longer definition right so we've learned a bit about the principle with learn about the reasons by inner source and how large corporations behave nowadays so going to through all of them basically. So we want to use those open source principles and practices to produce a proprietary software. And this is done through empowering individual engineers to contribute code. This is done focused on cultural approach process approach and tooling then we'll see we'll see more details So my idea is to be able to enable people to produce software if they are interested for any reason to basically load the barriers to contribution to other projects that are not perhaps part of their business unit. And then this is done through a certain process this is done through a specifically Apple request, which is it have terminology let's say there are much request if we focus on get a lot for instance. The idea is that we allow different business units people cramming coming from different silos to contribute to other silos. So for this of course we need to have clear rules explicit processes and etc. The idea is that we are kind of democratizing development and control over the direction of the project by, you know, pushing developers and courage in pull request over our future request. So this is the longer definition of inner source. I'm going to have a little talk about what are the inner source benefits, because we've talked already about how inner source can be a step on the path to open source. And certainly the founders of inner source Commons or for the founders of inner source Commons this was one of the primary motivations for when they started looking at inner source. There are great documented case studies from PayPal, where some of our founders came from where where they were looking at how do you actually, you know, get that culture change happening within inside an organization to be ready to actually do open source collaborations outside the organization. So some of the folks in inner source Commons have actually taken this to another step, whereby, for example in Comcast, they have an open source program office, which is also responsible for the rollout of their inner source programs. And Comcast have actually decided that for any organizations who want to open source their project, they have to go to through a step of inner sourcing at first, so that they can prove that they can do the necessary community management. And to generate the community around their project so that when they actually bring that to the open, they know they have the skills required to actually make that successful in the open. So this idea of inner source being a path, a step on the path to open source is a very well documented one. But it's not the only reason why people are actually turning to inner source, because we're seeing that many organizations are turning to inner source, just to increase the efficiency and code reuse. They're even on a step of their own digital transformation. There's a great presentation by Matt Cobby from National Australia Bank, where he has shared with us on one of our community calls exactly how that's happening in National Australia Bank. And many organizations are actually doing that in order to make that code reuse happen across the various different silos. So that instead of, as Daniel described before, instead of having multiple implementations of the same project or process across all those silos, you could have one and all those silos would be contributing into that one instance of a commonly used piece of technology. And indeed, there's actually evidence out there to suggest that inner source or the use of open source methods and practices can increase developer productivity. So not just in terms of the idea of reusing code that in itself is an efficiency and increase in productivity, but actually the practices of open source can increase productivity. And we learned about this McKinsey report through a Microsoft blog where Scott Guthrie pointed folks to this report, where it talked about this idea of open source culture and methods and practices proving or being closely correlated with increased developer velocity and productivity. And we have seen that this actually does work in terms of breaking down silos. This is a great graphic which comes from Bosch. And what they did was they tracked how many contributions were being made from one business unit into another business units code. And when they showed this to management, this deep mesh of collaboration from all the business units were collaborating across the organization into different business units code. It demonstrated to them the real return on investment for inner source for the company because it actually showed how you could actually generate innovation and how you could unlock innovation between business units using processes like inner source. And there is more to learn from folks like 10 cent who again shared in one of our summits how they use this cross departmental collaboration to unlock innovation within their organization. And indeed, we've seen a lot of organizations come to inner source or start experimenting with inner source when they are being mandated to do cross departmental projects. So for example, DevOps can often involve working with teams across a number of different business units. When you're implementing something like DevOps, people have turned to inner source to do that in a way that involves and democratizes that process across those business units. So we're seeing a lot of people come to inner source commons and try inner source for the first time when they've been embarking on projects like DevOps or any other kind of cross departmental platforms that people might be trying to implement. A great example of this is Capital One, whose journey to inner source started in this DevOps arena and has grown and scaled from there quite significantly. I definitely recommend you check out this presentation from the Phinos organization where Capital One described their journey. The link is in the slides. But it's not only that because we see that a lot of folks are actually turning to inner source because it's simply a way in which developers are happier developing. And particularly for the younger generation where people are much more used to having agency and developing in that open way, inner source can definitely appeal to them much more than more traditional development processes that organizations have had in the past. So it can definitely help with your people strategy and skills building. And it's not just about recruiting folks from the outside into your organization. It's about keeping them happier when they're there, when you people have collaborations across team. And we're also seeing it where organizations are thinking about career path development within organizations so that instead of people looking over across the development silos and saying I'd love to work over there. So in this way they can actually start doing that before they actually leave their jobs and they can get experience in different organizations code so that they can demonstrate the value that they could bring to that department, even before they move jobs. So folks are using that in that way. So for, as for example in Morgan Stanley, and where else but shared with us at the last summit at inner source Commons that Morgan Stanley have been using inner source to actually build up experiences, build up experience, cross departmental experience in their legacy code and helping revitalize that code for use in the future. So it can also be done to future proof your development teams and older projects against making sure that there's enough folk who knows what's going on in that project to actually sustain that development. So as you can see there are loads of benefits that people can have from using inner source. So let's have a look now and Daniel take through the steps that people take to get started with inner source or what kind of journey they go on. Thank you Claire. So this is this is experience based on the inner source commons part of the use cases that Claire mentioned during the benefits section. And the idea is, well, this is all of this discussion about inner source and how to become a good open source citizen is really good. And then you've discussed or we've discussed about this cultural approach, then we need to focus on process and then finally on tools, etc. But the question is, okay, where can I start that? Remember that we started the conversation today about well inner sources about doing open source but in a controlled environment. The inner source is not open source but inner source is about using those best practices from open source. So basically we are, you know, scaling up our, our managers and developers into this way of working in the open so we can deal better, you know, with the risk associated and so on. What we've seen at the inner source commons is that large corporations typically start with with an experiment. So it's about trying things. And the idea is, well, there are already cases within the corporation where we can see different departments or business units trying to do something together. And given the constraints of the same of the very same corporation, it happens that it's perhaps really hard to access other business units code. Then there is, there are discussions around budget, etc, etc. But the thing is about, okay, let's try to create this bubble of inner source. Let's try to kickstart this experiment and then try to apply it directly from scratch. All of the principles of inner source. Remember, we are discussing, we are talking about transparency, collaboration, community, right? So we need to allow to give room to make this happen. Then there are, we can think of two different approaches, top down or bottom down. And that if we go for the top down approach, then we need like heavy support from the chief level, like they really believe that this is the right way of proceeding, and then you need like specifically financial support because this way of working is about bringing people to deal with this concept of inner source, either starting as an experiment or perhaps starting like really big from scratch. The thing is that the usual way of proceeding that we've seen initially more successful perhaps, or at least more often, is about creating the grassroots within the corporation. And this movement, even when you need air cover and ground cover to deal with inner source, it's about developers trying to behave as developers. So this means you have to remove all of the bureaucracy, all of the hierarchy, all of the management, etc. And then it's about developers working with each other because remember that the inner source is about empowering developers. Remember that open source is about letting developers to work in the open, so they need to know how to behave, they need to be good open source citizens. And because of this, the way we've seen to create, to have this effort within the company is about growing the community from the very bottom. And then there are some good examples, as Claire mentioned before, that we can go through them later, or you have the links to the YouTube or the presentation, so please join us at the discussions there. Okay, we started as an experiment, we are kind of growing the community, there are developers interested in the discussion, there are ambassadors, what we call them sometimes, we need to scale. Right, so then this is the time where you need to have certain, let's say inner source entity, you need to move into how, how, okay, this has been successful as experiments, so how are we scaling to the rest of the organization. This is where we can bring this concept of ISPO, Inner Source Pro and Office, or OSPO, Open Source Pro and Office, depending if you are doing Inner Source or Open Source. But the thing is that you need this office to achieve, let's say company-wide scale of Inner Source and Open Source. So we are seeing now later in the next slides about this ISPO discussion and OSPO discussion, so Claire or yours. Thank you, Daniel. So yes, now let's look at the idea of how do you scale Inner Source. So as Daniel mentioned, this can often be done through an organizational construct like either an open source program office or an inner source program office, which is a relatively new term that's being used in industry. The idea of an open source program office is very, very well established, and often time inner source initiatives can be managed out of those open source program offices. So when we think about the path to open source, we can think about it as the kinds of topics that an open source program office might look at, and the kind of topics that an inner source initiative might look at. And oftentimes there is quite a large overlap. So for example, in the areas of open source culture, in terms of how do you set up effective collaboration, in terms of the processes you use, the tools you use, how you communicate about what's happening and what the decision-making practices are, all of those types of behaviors and methods and processes are the responsibility of both the open source program office and inner source program office or an inner source initiative. But there are also topics that are particular to both initiatives that may not have an overlap. So for example, in the open source community, there'd be a lot more emphasis on things like the compliance to open source licenses, managing reputation, how do you actually collaborate even with, for example, the open source foundations, and for example, perhaps looking at competitive scenarios or competitors in the marketplace. So it's a lot more external focused. From an inner source perspective, people want to look at different types of license agreements, perhaps even license agreements between different business units to help establish correct and proper ways of working together. They want to be looking at things like how do you scale your teams internally. There may be some concerns about taxes if you're doing cross national boundary collaborations, and you're basically looking at the effectiveness of those collaborations within your organization. So there are topics that are particular to inner source. So looking at that in a little bit more detail, we've listed here some of the common responsibilities of both an open source program office or an inner source program office or an inner source initiative within an open source program office. And to look at the differences between them. So again, to go through that in just a little bit more detail. Both are concerned with internal policies and processes, but then inner source initiative is often more looking at the contributor agreement between teams and looking at how that can be managed. Looking at reward policies, how do you incentivize that kind of collaboration those kind of processes. Everything happens within the inner source initiative. There may also be responsible for the supporting infrastructure to support inner source. So for example, looking at discoverability of projects across the organizational, perhaps developing an inner source portal. That's often a common first step for organizations looking at inner source, and also looking at the tools that the organization uses for collaboration and communication, and where and how that can be standardized across the organization. Sometimes it's not often across the entire organization, but different tools may be required for different requirements, and depending on the needs of the business unit at hand. Both organizations, both the open source program office and the inner source program office are also looking at the measurements and the metrics required to track the success of both initiatives, but they may be different depending on the context. And specifically, excuse me, depending on the actual priorities of the organization evolved. Both are also involved in advocacy and communications. In particular, this is an incredibly important step on a path to inner source where you share the success stories where you amplify communications where you even look for opportunities for collaboration across business units so that you can ensure that that great benefit can actually extend beyond a given business unit across the organization. They're often involved in education and events. Again, from an inner source perspective, that's often a very important step in terms of helping people understand what exactly is happening, where are the opportunities for collaboration, and understanding the ways in which the the organization's culture is evolving. And often the inner source program office or the folks responsible for inner source are also responsible for representation at external events, because it's a very important part of an inner sources and inner source initiative is often to share what's happening so that you can learn with other organizations that would be similar. So for example, presenting at an inner source commons event is something that an awful lot of folks that are in his post often do so that they can share their own experiences and challenges and get feedback on on learnings from other organizations. And lastly, the idea of managing relationships for an Ospo it's a pretty well established idea that that the Ospo is responsible for managing relationships with for example open source foundations in an inner source world. There may not be foundations to manage well except of course inner source commons because we'd love to have you over there, but you do want to think about how do you actually manage vendor relationships and in the context of inner source so for example some of our, the folks that work in the community are looking at how do you actually create agreements with vendors so that you can have them involved in an effective way within your inner source collaboration. So these are just some of the ways to think about how an inner source program office or an inner source initiative within an open source program office, what are the kinds of responsibilities and activities that they do on a day to day basis. So next we'll actually have a look at dig a little deeper on that idea of measuring success so I'll hand you back to Daniel to talk about measuring success and throw away. Thank you Claire. So we've, we've learned about certain things about the benefits within more or less the differences between Ospo and Espo and etc. So, the thing is, how do I know if we are moving into the right direction right if we are working the right inner source path, even open source path and so on. So this is about this this discussion so measuring success. Next slide please. So, there are two questions here first one, how, how can we measure this inner source success open source success moving into the Ospo moving to into into the Espo ecosystem. And perhaps how are we making this process objective. So this is why we have metrics this is why we'd like to move forward with with metrics and and be able in somehow to, you know to analyze to to understand to measure our our inner source readiness or open source readiness so for this is like about wearing you know, inner source or open source special glasses and then we look at our organization so are you working in a collaborative way are you working in a transparent way. Are you having communication across silos or business units. So this is about this next slide please. Thank you. So, the question probably I have for all of you is, what is the most important metric for you. Probably as many people we are in this talk between speakers and attendees will will will put on the table, those number of metric because, depending on our expertise experience and so on, probably our, our way of measuring success is different from the developer maybe this is about, you know functionality or quality of the of the product or engagement with other with other peers, but maybe from a marketing perspective is about creating an inner source ecosystem or so maybe from achieve and we're talking about discussing return of investment and so on so there are different different roles will bring different metrics so in reality the discussion is not that much about metrics themselves will see some examples later, but it's about the business goals for the industry that you are trying to achieve when moving into the open when or when moving into the inner sources in between the steps so we can think of. Excuse me different different goals so are you interested in reducing code are you interested in bringing innovation productivity time to market effectiveness. So different business goals that we can think of the idea or perhaps the two main points or the key discussions we should have before even talking about metrics is about the methodology that you are following and the strategy that we are putting on the table. So then we can structure all of the metrics needs that we have so then we can properly advance and everyone can follow the same path. So, next slide please. This is probably about the methodology for this one of the proposals or experiences that we've seen once and again is the goal question metric approach. Probably this sounds familiar for those that are building hardware or goods but in the case of software. This is about using a similar approach so if our goal or better said if the first thing or the first step is about understanding the business goals the previous slide what we discussed right so what are we trying to achieve maybe reusing code or having a higher engage from developers or so and then based on this goal what we are doing is we are we are dividing this into different questions so we are, let's say using this approach of divide and conquer were for a given goal we are splitting into different questions and then it's much easier let's say to reach out to the metrics. If we start from the metrics we've seen certain pitfalls let's say about okay we have these metrics and these are the important metrics but what happens in reality is that these are the metrics that you are gathering because you can because you are able from a technical perspective and then you are kind of forcing you know the use of those metrics into how you are defining the goals for your organization so that's why it's so important to start from the perspective and then you'll define a set of metrics probably and perhaps you are not even able to gather some of them and that's totally okay but the thing is that you have those metrics specified and and at least with respect to the others you are choosing you are having the right this is an iterative process so whatever you are defining as business goal or cultural goals for this year maybe for 2022 or for 2023 those will be different in the following year so in the same way that business goals evolve questions and metrics will evolve probably so next slide and how do we bring all of these slides into the daily decision process so probably you are following certain strategy on how you are defining you know process or so if we think about automotive industry maybe you are following the cut improvement cycle for instance so the thing is about how are you embedding the metrics discussion into those cut out definitely work with metrics as well but in this case it's about you know this might be another way of looking at this strategy which is basically well first define the policies and plan those policies and specifically have a section on how you are measuring success within those policies maybe you are trying to foster new contributions from newcomers from other business units that's good so how are you measuring success here maybe about the number of newcomers producing a first comment in other business units that are not theirs so you have the policy and then you have how you are measuring success here so in reality what we have here again is an iterative process where you have the plan and the policies you are you know doing them putting those in place and then you are checking if those are actually working because you have metrics now right so you can check if those are according to your expectations if they are according to your expectations you are acting accordingly if they are not working under expectations then probably you are in any case acting accordingly so defining or tuning the plan and the policies so this is about remember strategy and method so next slide please and let's go with some sample metrics I choose like these two business goals code review and then activity characterization so basically the business goals that we can see here are well we are interested in creating more reliable artifacts or improve the knowledge sharing right or maybe we'd like to have a more homogeneous way of working across the organization or even go faster to market so those are part of the code review process that we'll see some examples later but these four scenarios are well specific business goals that we can discuss about on the right what we can see is specific business goals related to the activity characterization so again we might be interested in understanding how we are creating you know more reliable artifacts if people are collaborating so as you can see we have exactly the same text here but what happens is depending if we are using the code review approach or the activity characterization approach the metrics will be different and we'll see later some examples here so that's why we we wanted to have this on purpose and well maybe we are interested in understanding to having certain engineering teams visibility or maybe bottlenecks that are happening here are there because we'd like to move through sources into those areas to improve so let's go to the next slide let's start with the with the first one maybe with this concept of activity characterization so let's focus now on the chart the chart each of the pink dots are developers and then you can see that those are around you know kind of creating a stars right or circles so each of them are projects this is the analysis of the CNCF ecosystem and each of the dots are developers and then there is an edge a link between the developer and the center of one of those stars if that developer contributed at least one commit okay so then basically we can see on the left the big one which is Kubernetes then at the bottom we can see that there we have open ship which is a distribution of Kubernetes and then we have some other projects here and there of course if there is a developer that have participated in more than one project basically in two then we start seeing this analysis for this group of developers for instance between Kubernetes and open ship on the bottom left on the chart and this means that those developers that are between both groups are developers participating in Kubernetes and open ship from the same at the same time so this is collaboration again some of the questions if we move to the left some of the questions that we can think of is well we have all of these people collaborating in my organization remember this might be open source for internal collaboration so the question I have is where are my teams contributing at or how are my business units collaborating or even what is the expertise of my team so do we have developers participating in certain technologies as Kubernetes other technologies internal technologies maybe even you can go to the programming language so how many developers do we have that are experts in JavaScript or in certain frameworks or maybe in Python or Java I don't know so there are there are different ways of looking and producing this kind of charts what we can get here from here is about how people are collaborating across business units so basically we are breaking silos let's think for a moment how this how would this chart look like if we start from scratch working in a silo way so basically each of the starts we will be or would be absolutely isolated so we would have silo a silo B silo C silo D and there wouldn't be any kind of collaboration there by the way if you are interested in understanding a bit more about this chart and or the analysis that we run you have here on the on the right specific links to the to the IEEE software paper. So next slide please. And all of this mess that we can see here in the middle is is collaboration so this is the beauty of open source this is probably what each large organization would like to be would like to look like after several months or years of iteration into the inner source so it's about breaking the silos of development and it's about allowing developers to collaborate in different projects across different business units producing basically innovation and failing at the same time so this is it this is collaboration next slide. Some other examples and this is specifically about code review activity. We may have other questions for for instance. Now we are working in a in a new way. Are we are we, you know, going faster to market because remember some of the benefits is about higher engagement of developers being faster in the development process producing more stable pieces of code, you know, final artifacts and so on. The question is, are we improving so from a code review perspective, we may have different questions so if we are improving in this efficiency, how fast are we attending code reviews maybe for those coming from different business units, the resolution time or even the code review furnace across different teams, because don't forget that each of the different teams they have different, you know, priorities. So now what we are doing is we have kind of a fight of priorities here. And then there are there are different charts that we can look at, for instance at the bottom you can see like a summary of those. So we can think of different KPIs so the more much request probably the better. This is like a request in this case this is these are examples coming right directly from from GitLab analysis which is the open source analysis of GitLab in this case, then there are certain number of submitters reviewer. We don't have certain indicators as the median time open days that are remember we are following this call question metric approach so this case we would have this goal of, you know, we need to improve efficiency. Okay, so then we may split this into these four questions that then we have and then finally we have the metrics, and then the metrics are different ways of looking at this. Anyway, this analysis is based on, you know, we are using the tools of Grimoire Lab, which is part of the chaos community. This is all open source just in case you are interested in learning about them as you can see here on on the right. Yep, next slide please. So this is about Grimoire Lab in case you'd like to try it. So this is on the top you have the architecture where you are ingesting data sources basically you are transforming the data in somehow and then on the right part, you are browsing that data so you can you can let's say Grimoire Lab as a black box somehow. And all of the charts that we saw here where we're gathered using V30 Analytics Grimoire Lab so there are some some links on the on the bottom right in case you are you are interested. So next slide. Yeah, now we go into the summary and next steps. So what we've covered today, just as a quick summary. First, we've had a quick introduction about well how inner source can be this step on the path to open source culture we see that there are certain intersection but those are not exactly the same right so then we went into the definition of inner source the short definition and the longer definition the benefits of inner source. There are different ways of adopting inner source, you know top down approach button up, or, or at the same time this discussion about the scale inner source through the ESPO or OSPO so the open source one office or the inner software an office. And then we've discussed at the very end about measuring inner source access. Next slide. So, remember that you are not alone. We'll discuss a bit more about the inner source common so how you know you can be part of the community and learn about how to move into the open through an inner source initiative. Because no one is alone in this journey and we're all learning more about this every step of the way. And so now I'll give a brief introduction to inner source Commons as Daniel mentioned it's the community for inner source practice practitioners it's the largest community worldwide. And we would love if you could come along and join us in the community to help grow the community. At a glance, right now we have over 1300 individuals who've been involved with over 500 organizations who have been involved in inner source Commons on their journey. It is a place a safe place to come and share your questions and challenges. We operate a lot under Chatham house rules, which means that folks can come along without any fear of their identity, their name, their organization's name being shared beyond the community so people find it a safe space to come along and collaborate around inner source. We have over representatives from over 40 countries who are involved in the inner source Commons and who participate in our events and activities. And we keep a track of those organizations who are speaking publicly about their inner source journey so we have nearly 100 now organizations who have spoken publicly either at inner source Commons or in their own blogs or events about their inner source journey, and we keep a track of those so that we can help other people learn from the community in terms of folks that have gone before. So what is the inner source Commons what kinds of activities do they actually participate in, we have three primary working groups that we organize our activity around. First is the learning path working group, which is responsible for creating training videos and articles to explain and teach the various aspects of inner source. And that content is also being translated by our community into many different languages worldwide so we encourage you to check that out. We also have a patterns working group, which is about curating the best patterns and practices, and also anti patterns from our contributing community, and to help kickstart and scale your inner source practice so that's about gathering the learnings that emerge from our discussions so that we can actually put them down so other folks can have actually see what kind of things might they want, they may want to experiment within their organizations. And lastly and most recently, we now have a marketing and outreach working group, which is about organizing our conferences and events, and but also raising in awareness about inner source externally. So we help to match speakers to conferences and things like that as well. So if you are interested in participating in any of these working groups we would love to hear from you, but there are many ways to actually be part of the inner source Commons community. The first is just to learn from our resources we are grateful for each and every follow like share subscribe on any of our assets on YouTube on our website on LinkedIn on Twitter. So please do come and learn from the community itself that's it that's a great thing to do. But if you would like to join in the conversation and actually share some of your challenges and get some feedback and insights. Come along and join us on the inner source Commons Slack, which is where a lot of our activity happens. And even better sign up for our virtual coffee buddies Slack channel where you actually get to meet one on one with with another member of the community, and who'll be able to share with you their journey we find that those kind of one to one conversations are sometimes the best place to learn about about inner source and inner source Commons. And then if you have some time to actually contribute back to the community, we would love it if you could contribute to one of our working groups. There are many easy ways to onboard into each of the working groups, and we would love to see you there. So there are three ways that you could participate in inner source Commons. But to find out more, we would love you to come along and visit the community. You can meet myself and Daniel and many other lovely people there who are willing to help you on your journey to inner source. Daniel, any final words. I would like to, I would love to see you all at the inner source Commons so you can find us in a Slack or, you know, Twitter and so on so feel free to reach to us and we would be will be very happy to drive you around the inner source Commons and show you about you know the community and how to get engaged so would be great to see you around. And now I think we'll be open for Q&A so we'd be delighted to field your questions so looking forward to talking to you shortly.