 So we are not that many people so we can definitely Well, thank you first of all, thank you all for coming at 5 p.m. Today. It's you know, it's late There are I think there is another talk now after this one. So, yeah, thank you for that the speakers world So quickly here, I think this is the only talk that is Specifically mentioned the keyword inner source in the title which is quite surprising So then I assume that you're interested in the topic because we are talking about inner source. So It would be good to get to know each other You know to say hello afterwards and so on Yeah, thank you again for for coming a bit about me I'm saying all of this I'm part of the inner source commons foundation. So if you have any extra interest on, you know, the community The kind of things we do I'll go over it on you know, not much detail in the next minutes But happy to discuss with you. There are some other people from the foundation all running around active member Tom. So Of course, I Martin there has been an active member not lately, but one of the original, you know People moving all of this. So it's great Well, yeah Founder founder as well of the third job to develop analytics in a source consultancy as for consultancy as well Has been in the business for 11 years now. We are starting in 2012 in part of the Chaos community as well that we have Nicole back in the room But we can we are happy as well to discuss about metrics and open source metrics and community health We are catch boys around so we are you know friendly community Happy to have you on board and brought father of a lovely 11 months. Oh boy Okay, so when when I started thinking about this I realized that the title was definitely too long Sorry about that Then so then I started to remove some words and then I realized that we can cover these four topics in certain way So definitely this is about inner source metrics. It's about the engineering culture It's about open source style collaboration, right and it's about you know making decisions based on on data So first of all, let's discuss about the inner source So what is inner source really quick definition of this is well, it's about applying the best open source practices out there That we can think of into internal corporations. So that means that we are bringing concepts as transparency or collaboration to the way a bank may work right or to a way a Certain corporations or enterprises are working nowadays And that means certain things certain changes and specifically we are discussing about the cultural change But we need to make process and we need tools to enable all of this, right? So we are we are moving from a scenarios, you know Where there is a strong ownership perhaps in the code with budget discussions, but the restrictions And we need to put all of those people to collaborate, you know between them and so on Inner source is not about producing open source inner source is about producing proprietary software but the discussion for today is about how inner source and learning all of this way of doing You know software in a more open source way is enabling developers to at least understand how this works outside Because what we have now in large corporations is that people Don't really know what open source is they don't care because they are a company there They that is asking them to produce over in a certain way So they they do that they do the job right and they are producing really high quality software the point is that We cannot ignore open source anymore So then and then large corporations are using and consuming open source once and again So there is now this this knowledge gap that people are trying to fill Corporations enterprises are trying to fill an inner source is one of those tools that we can use to Enable enable basically to have a massive amount of people Understanding how to behave in the open and how to do open source in the medium term because we need to you know We need to start a small internally in the company You know do experiments try with the with the with the technology try with the processes because we need to put processes to work You know create your own your first inner source program office Which might be the parallel discussion for for an Ospo and sort for an office that I assume you're aware of the term And the discussion is why is this so because corporations or surprises look like this So they are silo-based right so what we have nowadays is that if you are all across the globe You are producing once and again similar pieces of software and Perhaps from the micro level perspective if you are working in agile way You are really effective and agile and you are producing software according to deadlines budget Quality standards, etc. Etc. But then you realize at the macro level perspective You know all around the world that if you are producing once and again similar pieces of software in different, you know Geographical regions it happens that the macro level is not this is not efficient So then how can we take them the best of both worlds basically the regional way of working? regional requirements localization needs and deal with you know or match this with a Global set of requirements that we can work together So there are some good examples here and there we go through some of them later But going more into the metaphor of the of the silos what happens typically is when two teams are trying to collaborate Right what happens is that well first? They don't know how to do it, but they are forced to work to collaborate in somehow So at the end what happens is what what we call a dinner source commons the cheese interface Which is okay? Well, you know you need to go through the path of the holes in the cheese to reach the top level Which is that you know those aisles that you can see on the top and then this is where basically communication happens So we need to go to the top of the hierarchy after discussion And then it goes down to the hierarchy and then suddenly both teams Did something typically what happens is that they don't they didn't know how to collaborate, right? They didn't know how to make software together. It just happened that they were forced to do that So, okay the question here for the audiences who else out there is producing high quality software in a distributed way all around the world The answer or one of the answers is open source So we can think about how the new kernel is being developed. It's all around the world developers producing code together I know open a stack is another great successful piece of software same, right? So there are many many open source projects that we know, you know, all the CNCF ecosystem might be one of them, of course That is being developed in Following a certain methodology in a collaborative way in a transparent way And then all of those developers and geographically distributed and even more we are having competitors, you know companies that are working together Producing their own business value to their customers, but they are building something together. So what if we try this internally? It might in my company, right? So this is inner source and this is this is the rationale because of we have we have inner source Okay In the first line we have inner source metrics, right? So we have this idea that without data. You're just another person with an opinion and That's true. So we need data, you know to to do in somehow decide where to go I really love this cartoon because this is you know, you have certain perception about how things are working But suddenly you realize that when gathering data somewhere you were absolutely wrong on your perceptions. So basically data says no And that's important to have this data and not having data or metrics You know as a goal is just as another tool that you need to well make decisions and having that visibility on whatever is happening in your development software cycle is is key for the success of the Many development cycle Okay Moving forward engineering culture. I have this hypothesis Basically is the software produced or the quality of the silver a representation of the culture and processes of a company So probably you are aware of the concept of Conway's law that both the architect or of the system is Reflection or a mirror of the different teams or departments or companies that are producing that piece of software but if if the the quality of the software is Is not that good is that What does it mean from a process perspective is our process is broken It's basically the cultural approach to how developers are working the engineering culture is not a healthy Culture within the corporation. So my hypothesis is that it's somehow related. So basically There is a certainly low engagement according. I think it's a study from IDC or for us they claim that 70 something percent of the Employees in that corporations were disengaged, right? So what is your motivation as a developer to produce software in your company? So do you have enough agency? Do you have enough room to innovate? Do you have enough space to try things to collaborate with others? Do you have enough room to try? You know new stuff or new cool technologies And then what if even we go into the scheme hour or you know Destructor that we have a lot of outsourced development. So what happens there? You are you know by contract you are forced to work in a project a certain amount of hours by a certain price So that's something really hard and you as a developer We can I can say that perhaps developments is still somehow creative work, right? It's it's it's either engineering. We can discuss about that We can apply engineering practices and so on we can discuss about this later if you want But definitely this is still a creative work and developers like to solve problems So what if we give some more space to those developers, right? So what if we improve? You know the cultural approach or the processes on so then we have a more engaged developers in all of this year So in our source isn't somehow all about this And this is a path so we are not inventing let's say anything new so we are at dinner source commons We are based in part of the This course let's say on on on existing open source communities out there one way of looking at this might be the patchy way, right? so and this is by the patches over foundation and What think of what happens in your company or in any any company if you simply open the communication channels, right? by the way, this is this is a slide that is Inspired by by the work of Jean Jack by from the ASF but what happens if You open your communication channels So what happens when you open your communication channels and just start doing things in the open, right? You will see what others are simply talking about so let's assume I'm maybe you are using slack or maybe you're using some I know maybe or any other tool matter most any of the Microsoft teams whatever you are using But you have access to whatever others are writing down. So that is bringing a certain level of transparency, right? Because there is transparency in place and we are human beings. We are opinionated people, right? So we all have our own way of thinking about how to solve a problem and so on Suddenly what you have or you may have is basically collaboration because there might be people that are not part of the project But they may have a suggestion about how to do things or a question maybe about how to improve that, right? So then what it's happening here is that suddenly you will have two people from different places Perhaps from different geographical regions talking together So they are collaborating right and then at some point over the months, perhaps Then we have or we bring to the table the concept of community. So suddenly there are three four people that you know are really Interested in new JavaScript framework to develop software So then they go there and then they know each other and if there's at some time a retreat somewhere with all the company They will go together and see each other and have coffee or a beer and that's great So that's the sense of community. That's about how can we enhance that way of working internally in companies, right? And this is open source. This is so we are here because we like to talk to each other. We like to You know to have some food together and have some great discussions and and this is open source open source is about the people So inner source is about the people as well and enabling discussions and that work and so on and of course the concept of meritocracy You know, they'll there will be a peer of course technical leaders or people that are more Skilled into communication or marketing or design or development. So those are, you know They will have certain merits within the company that will raise Here and people will follow that that person so on so forth. So there is there is a process, right? There are certain principles that we can discuss on inner source Okay, open source style collaboration. So what is open source open source is this If you if you check these charts here all of the dots that you can see around Well, you don't see the dots but you can see some somehow a dot here and then some blue squares around So basically each of the dots are developers There is a connection between that developer and any of the blue squares that you can see so basically you can see kind of a stars Right around here around here around here around here So there is a connection if that person committed a Piece of code to that repository. Okay Then it happens that we may have developers that are participating in more more than one repository, right? So then what we can see here right now is basically people that are participating in Different repositories or different projects across, you know, the the general organizations And this is open source because all of these data is coming from From open source projects out there Specifically any of the following are okay So this is let's say the shape and size of the Wikimedia foundation This is the shape and size of the opening for a foundation, right? This is the on f open and working foundation chaos community open sith or the Johns Hopkins University that we've been collaborating with their with the Rospo, so You can see that basically in the open source world. It's certainly Natural to collaborate with others to try right and then we will identify people that are, you know More expert in certain technology that are kind of key in the sense of bridging different communities and so on so forth So this is open source What happens nowadays in corporations is that what the let's say the representation of this would be isolated the stars So teams are working in an isolated way not contributing with any any of the other teams, right? Moving forward so now we go to the discussion of metrics evidence driven decisions. Let me check the time Okay, we're good So the first question that I have on the table is basically what are your business goals or what are your cultural goals, right? depending where where we want to go but Because if we think about metrics what we've seen over the years is that people have metrics because it's For the pleasure of having metrics, right because they have the technical skills. So then oh, we can measure now this thing here We've seen even up to the point that people are using certain metrics to you know to be Rewarded or to be part of their objectives, but then When you check those metrics with the real business, you know kind of goals or objectives. There is not a match So then what is what? What's the sense of having certain metrics, you know that are not related to business goals? Right So then the first question probably that we need to discuss here in terms of you know a bit of metric strategies What are your business goals because if we we have that clear then we can start, you know Having certain discussion following a goal question metric approach that we are Discussing as I mentioned before in the chaos community. That's a method coming from the 80s So nothing new on the table, right? But there is a methodology that we we can follow and with this we are sure that we will have The right metrics for the business goals that we have nowadays Maybe we don't have the metrics. I mean we don't have the Option to calculate the metrics to gather the data or so, but at least we have identified The metrics that are needed to answer to the business goals and of course if we are in a department the business unit in a regional Part of our company Then we will have metrics to say okay This is this is what we have advanced according to the business goal, right? Maybe perhaps you are using OCR or maybe any other way of measuring Your success or your advances, but this is this is a really good way based on our experience to discover and And match to this matching between goals and metrics in a company Doesn't matter probably if you are measuring open source or if you are trying to measure success in inner source But this is this is one of the options on the table Okay, so why do we need metrics that's probably part of the next discussion So the first of all and what we've seen is that people don't know Who they are so And the very first thing that we need to know is okay. How do I look like it's basically? This is my mirror. This is me from an engineering perspective This is me from a software development lifecycle perspective. This is me from a delivery perspective and then of course might be You know worse than expected or better than expected But we need to know who we are where we are in the map, right? Because first we need to understand where we are so then we can move from point a to point B Right so metrics then are kind of a good guidance to lead the change because we can say okay perhaps we are you know in our delivery delivery process we are it's taking Three days to have the artifact ready to go and but we need to know that this is three days So then we can decrease this down to a couple of days And then we need to know that this is couple of days So then we can decrease this again to one day But then according to this you need to discuss about you know, maybe stability of the software production chain Maybe you need to discuss about having code review in process unit testing Well, there are many things but you need metrics, you know to have in control of all of these So metrics are like flux that are telling you or you are going into the right direction or you are going into in the wrong direction Right, but be sure that you are choosing the right metric according to the business goals that you are trying to achieve and then in the case of inner source I Would say that metrics are quite interesting to motivate people to do certain things. So inner source Going back to the definition of inner source inner source is a A lot about moving people to not out of their comfort zone sometimes because inner source is a lot about Working in the open and not everyone feels comfortable about working in the open and in a transparent way So the point here is that if someone that is not used to produce software that everyone else in the corporation will see The very first thing will be like No way. So I why why is this happening, right? They there will be a certain pushback. So how do you do this? So well metrics might be Certainly a good way to to move into You know have that discussion because maybe you can have certain rewarding system in place. You may use metrics To simply have a on a table with that person a one-to-one discussion like okay, so You don't have to track that person But you need to say okay What is what you think it's good for the project in terms of delivery time in terms of code review processes in terms of activity in terms Of you know from different regions and so on so what is what it's good for the project And if you get to you know the buying for the from the other person that means that you are describing or defining the metrics From both parts so both parts are having kind of ownership on that decision So then it's you know much easier, right? So then it's not about having You know pointing with a finger like you did this at this time this day No, no, no, it's about saying okay. We as a team You know can grow together metrics are good indicators to tell us the right path to go Okay, let's think about now for the whole solver development lifecycle We can think in the first place. Well, probably we need to have all the product owners discussing, right? I want to bring this discussion here because then we'll discuss about some metrics and some of the metrics are you know part of different different Processes in this timeline. So well, let's assume we have our our product owners discussion from different regions And so they are they are working together. So suddenly you have a new feature request So then you write down the user story, right? Then at some point you will have probably a child teams with a squad So then you will you will develop something there might be I know pull request Maybe you are using another way of working as a kid flow. So then you have a develop branch Well, whatever you're using that's happening. Of course, you have a lot of unit testing I hope you have a lot of unit testing, please and then Ideally with inner source will you have certain code review process? Suddenly at some point after all of this iteration you will have a merge So much happened or maybe that process that pull request. I'm using it have terminology here simply It's abandoned, but there is a ping-pong match right between both people We work then you may have a certain CICD process Suddenly a new feature is available. So then that depends if you are using open source or you are using Inner source but well you have some stakeholder of that tool. So then This is you know, then you have the users of of that new feature. Maybe it's an API Maybe it's an artifact. I know an exact file or something else It happens that Walter is a process, you know from the beginning till the end where and it takes certain time So we can see here certain certain aspects of this for instance How long is taking the code review process? So well, maybe we need to we need to go around this these four steps here and see okay Well, we have the PR is sent then is testing code review, etc, etc But then we may have part of the discussion which is okay. How long does it take from idea? Till this is released to customers So then we are looking at the whole life cycle from the very beginning the future request till this is delivered to To to the customer at the very end in a mobile app perhaps right? Maybe you are interested in understanding the stability of the software So then you are focusing more on this area CICD if the artifact, you know You have a lot of failures when building the software. So there are many many areas Probably up to that line is software engineering on the left So then that means that is mainly about applying Those good practices that in the open source board are happening, you know code review unit testing Have that discussion in the open in a transparent way collaborative way because the center source remember and then We moving forward then we have engineering processes that are mainly the pipeline Pipelines are once they are there it works. So that's engineering. I agree with you the previous per step I don't know if this is still engineering But it's part of a creative work with chat GPT and others Well, I don't know what will be but so far is is being this following this process and so on and then we have the Outer world which is but the rest of the consumers of of my software good So then we go to some examples or you know metrics that might be applicable to the inner source discussion So first of all what we've seen when Working with you know at the inner source commons and talking to people and so on is that There is certain lack of visibility about what the teams are producing Basically, typically what happens is that the management level or chief level. They don't have a clue about what's going on Underneath basically at the development level who is doing what when and where they don't know and the problem here is that if there is there are You know bottlenecks here or there if there are Issues in you know in the development velocity of some of the teams if there are you know all of these Those are not clear because people tend to use for instance, you know, that's what's but there's something else There's life beyond you know, right if you're a manager you should we should go and the data is there about the git repositories So go there and check what's going on all the pull request interactions, right? So it's about all of these all of this process another business goal might be about fostering collaboration across business units Remember that we have silos and we are producing once and again the same piece of software What if we break down so it's about how can we foster collaboration across these different business units? Because ideally we want to have one core of the that is served all across the different regions So then everyone is working there and then perhaps you have localizations original part of your software Of course, but what happens is that well we need to foster collaboration Perhaps you want to increase stability of the software perhaps you would like to have a predictable software delivery process But there are many questions that we can answer from a more You know chief level perhaps about being faster to market. So there are many things that we can discuss So I choose some of those so then we can enter into you know a certain discussion And then I can show you some some ideas or some numbers Numbers are based on open source projects. So of course, I cannot expose internal data or so But this is based on on existing contributions from in the open source world So as I remember this is a kid lap or open FB back in time a couple of years ago So the first thing is who is who so what is the how are my teams contributing? Okay, so we have let's assume that we don't have organizations here We have I you know department one department two department three department for and then we have certain metrics that might be part of this discussion I know commits authors number of touch files edit lines project repositories, etc. Good So we go here suddenly we realize that there are certain departments or companies that are producing really Fatty commits right. So why is this is is it a good the software engineering practice to have a commit of in average of 1000 lines That's something that no one can review. So why is this happening, right? So something is happening there. We don't know the reason for this but something is happening there So at least we have a pointer now with metrics telling us okay here from a software engineering perspective This is about practice. So why is this happening? Let's go and talk to them, right? So now we know that there is a company whoever it is that is producing these fatty commits, okay? That's good So at least we know that this is happening and in the same way that we can go for this level of You know detail we can go at the same time for other processes remember that this is now When the commit is merged in the main branch, right? So now this is information coming coming directly from the git repository if we go a step back Let's say when basically the merge request in this case it was using git lab So that's that's why the is not pull request is much request But instead of instead of going directly to the comet we go a step back and say okay Let's go to the review process. So then why are these companies here or entities taking that long? So we have a difference of even three levels of magnitude. I mean, that's a lot So why is this difference between this team and this team? Well, we don't know right and it's not about saying this is good or this is bad But at least you have the outliers, right? You have probably an average in terms of you know closing time or review time or so But then you have the outliers So let's talk to the outliers. Why is this happening? Right and then probably in with time you will decide Okay, this is it's better to move everyone to the left or to the right. So then sure Let's do that. So then you start slightly You know put in certain goals in terms of metrics that are will kind of lead that change that we were discussing before More things collaboration. So this is an old chart from the CNC F plus open shift ecosystem Again, remember that we have the dots that are developers and then we have here the the project So this is Kubernetes for instance. This is open shift. This is fluent. This is quite old 34 years maybe but What we can see here is that we have developers this bunch of developers here that are collaborating here in Kubernetes And here in offensive, right? This mess here is collaboration. This is the beauty of open source all these chaos is beauty And this is what in inner source We would like to see we would like to see chaos in you know this network diagram because that means that people are Simply contributing everywhere. Okay, this is this is a use case for CNC that we were doing with with red hat back in time But but this is a really great illustration for basically what collaboration means So this is what we are looking with inner source collaboration More things you can think of maintainability right here, right? So then what is how much is Is your team basically closing effectively versus new issues coming to the project, right? So then there is An old metrics, which is called backlog management index in Maintenance in software engineering in maintenance field that is basically telling you a simple formula. Which is okay. Give me the How many issues or mercy quest or so you your community or your people are able to close versus in the new things coming So then basically this is a percentage. So whatever is under 1% you can see this in this chart this green line here that we follow here. This is time x axis This is the this is this backlog management index or review efficiency index that we call this when there is a pull request in place And when this is this is under one which is around this area This means that basically this 15% 10% 5% of the issues or the reviews are simply left there Open right so basically the community or the team is not able to close things as fast as new issues are coming to the Project that's a maintenance issue on the other hand if you're you we can see the other pigs So basically that means that they were closing things or reviewing things really fast So whatever is our over one that means that they are being more efficient And again, this is something that typically teams even engineering teams We've seen that they are not even Tracking so from a project perspective And if I were an engineer, I would like to know this because if we are consistently Living as open tickets or open, you know change request a lot of things We have we have a problem in the development process because there are a lot of issues that are coming So our backlog keeps growing and this basically there is a lot of noise and it's like a continuous running process, right? So doesn't doesn't make sense okay Yes, so Are I is stands for review efficiency index, which is at the same coming from this backlog management index So review efficiency index is it tries to represent how efficient the team is when dealing with merge requests Or pull requests within review process basically Okay So the technology will we go we can go later for the discussion, but the technology is grimoire lab And then it happens that yes, v3rdia is commercializing Grimoire lab as a project. So these specifically were produced by v3rdia because that was open FB customer of v3rdia Well more stability and so I'll go faster because we are running out of time There are some about the stability So if you are interested in learning more about the inner source or technology and so on so Inner source commons dot or a g so we have a great set of books that are you know open to everyone You can go there learn about use cases that opting inner source contains several use cases there Patterns are at least of proven solutions to existing problems in the inner source journey. Let's say Managing inner source project is about metrics and discussion on infrastructure and so on Understanding the inner source checklist is literally a checklist that you can follow to the things on inner source And getting started with inner source is the very first book that was released by thanks to people and O'Reilly Yep, that was that was it so inner source commons dot org slash learn slash books feel free to join there There are more Materials that you can consume learning path is another great place to start short videos short articles You can you can learn you can consume videos and you can go for for instance through the What we call the trusted committer, which is the key central piece for the success of the inner source initiative Which is like the let's say the committers in open source world So it's about extrapolating this and bringing this to the inner source world The contributor the product owner what there are there are many of them So I really recommend you go through them a bit about a bit more about the inner source commons So there are more than 2,000 people Nowadays in Slack channel more than 600 organizations here and there that have claimed that they are doing inner source There is this list that you can go for with links to when a company said hey, we are doing inner source So you can go there inner source commons dot org slash stories So yeah, we are very happy to have you on board if you're interested There is like channel that you can join Community is very friendly There is one rule by the way that is to rule all the inner source commons, which is the chatham house rule that means that you can Go to the community talk to the people But basically no company likes but press right even good press sometimes So basically you can use the information out of outside of the community You cannot say who said what or the affiliation of that person. That's all okay So then you can say things like oh, I learned of the inner source commons So there are companies that are having this issue and they have sold that issue following this this and that okay Um chaos community It's Linux foundation project. We have we've had we had indeed on Tuesday The chaos gone scrape the good people there Well, we were discussing about metrics community health project health the tool that I was Using to illustrate some of the concepts and metrics is Grimoire lab, which is part of this 100% open source and then what you mentioned the question to you was okay Yes, we are taking this tool and and and producing the building the software on top of this A bit more in case you are interested in a more academic background of all of this a couple of papers that might be of interest Related to inner source metrics on the one hand my name self or repositories Last year and then the other one is peer to computer science journal where It's this one is open asset access No, the other one where you can have a really detailed view of what Grimoire lab is in terms of the components the actions The porpoise the mission and etc. Etc. And then perhaps the last thought for Well, not the last thought but the previous one Inner source is So we've been discussing about inner source and we've been discussing about metrics and about open source, right? And the thing is that we are in an open source conference And we said that inner source is basically about building proprietary software. That's true But suddenly if we are able To teach to train people to show the value of working in a transparent way and collaborative way within the corporation or the enterprise Suddenly you have a massive amount of developers that know how to behave in the open because they they feel comfortable about Producing software and being reviewed or review other software or contribute to other teams or talk to people directly Or even public speaking because then you will have more engagement across the different team members, right? So if you are using a note in France, for instance github Literally you are one button one click to say and now this is open source because basically All the way of working is already done all the processes all the code review all the unit testing all the good practices are done You are doing in a short, right? So you are literally one click to say and now I do this open source And that's the beauty of inner source. It's a great path to enable Contributors to be open source contributors and I really believe that this is a Good opportunity for open source to basically grow Massive amount of developers to become open source developers or at least to understand what that means right to behave in that in that way Okay Last but not least probably okay So we said that to be at the beginning that without data you are another person with an opinion but data is cheap nowadays So Have an opinion. Okay, that's all Okay, and this is all well. Thank you for your time and I know questions Comments. Yeah, thank you Yep, I can give you this Yeah, so with generative AI the prediction is that there's going to be a flood of code generated potentially code committed or put into the stream in terms of Pull requests and commits and the like Do the metrics sort of cease to have value with that onslaught that's predicted or is that something That you think the metrics can filter out for That's a that's a good point Yeah, so we are talking about predicting things. That's good Of course, I might but I will stay here. I might be wrong but My feeling is Well first technology is still not there So that's one thing and I would say that technology will help people to become more productive At the same time we saw that in the pandemic, right? So we saw like a huge increase of noise on the internet massive increase of noise people basically move everyone To there and now basically the levels of that noise is kind of you know Stable has no decrease and with these generative AI in not only with code, but you know documentation or Post or you know thoughts on several things. It's kind of my expectation that it's gonna grow So can we filter out this? Might be but but but I think that we'll need people not to build that much of the blocks or the bricks but To be sure that what is being produced has reached certain Expectations and quality so What I would like to see is that human beings will talk more to human beings What they think is becoming is more machines talking to machines Yeah, I don't know I didn't have maybe others have other opinions here of thoughts No, it's definitely hard to say Okay Okay So one of the things about metrics is if if I tell you how I will measure you Then that is usually a good predictor of how you will behave Yes, because obviously you will try to rig the metrics in a way that it sheds a good light on you Okay, and we have experienced this because we implemented some inner-source metrics. We were trying to measure how many Inner-source projects we have per department, right? So We had yeah every department how many how many repositories do you have that are open for inner-source and these metrics were reported to executive management and then What happened was that? Departments just opened up their their repositories for inner-source without actually Intending to do inner-source with these repositories But so it would have a nice number and then when When a project was going on in two or three departments, you know They would fight about which department gets the number for this project and so forth and so forth, right? So we that didn't really help at all and we abandoned these these metrics So my question is any thoughts how you could kind of prevent this? Well, I would say if I were in a company where people are fighting to open the repositories and fighting to say this is mine That's good, but at least for a few weeks Right, so then I think metrics are useful to you know to to drive a change and then when this is done It's close that chose go for another place. That's that's one of the that's one of the Suggestions I will do the other one is if you are Tracking people for a certain purpose Then probably you need to bring those people on the table to have that discussion So then is what you say this if I'm using a metric to track you Then you'll you'll change your behavior, but the discussion here is a Wolfgang you and me we have a problem How do we track this so then it's now you and me discussing about that problem there So then it's about taking both ownership of whatever we discussed and then it's and maybe we were wrong And we need to change slightly the metric, but then it's it's again a conversation. So that would be the other way I've seen it works. Yeah, but I think that's good I mean it wasn't actually used to you know, you get a bonus if you have more more Inner-source repositories, but it was interpreted that way Yeah, and it's like oh, we just need to satisfy and then you know look good and so forth That was not the intention Intention was just to see if it's working at all to have people do inner-source and okay. Good. Thank you I had a question on your smile slide when you're talking about motivation and getting people to adopt into this idea Within certain teams you have a lot of diverse backgrounds And in my personal experience, I had a lot of difficulty actually clicking commit like someone else clicked it for me for my first 10 so I'm wondering if that would be a good Location to insert some mentorship or apprenticeships or practice once you are starting to use inner-source Or if that would just kind of add complexity to the whole So that that's a very good point So the The role so we haven't discussed a lot about trusted committer The trusted committer is a person that is trusted by management that person can you know talk the lingo of management and can talk the Lingo of the people of the technical people, but that person is in the same way that in open-source communities We have trusted committer that are Mentoring and helping others to grow into the project This is this is basically the ex we can copy the rule basically so ideally Yes, we would have trusted committers that are people that are willing to help others because The goal of the trusted committer is not to review everything the goal if I were a trusted committer I would expect to have all the trusted committer to do my job So my my my my medium-term goal is to grow others So then we can be you know more people basically doing that job. So Yes mentorship would be one of the key You know responsibilities of the trusted committer I would say Okay with so that depends if we want to go for something really accurate in terms of data Not always so for instance we've done we've done mentorship analysis for that was Yeah, I'll treat you and Google summer of code a few years ago on the Linux kernel So basically we had all the data about the all the processes reviews that And then what we were looking for was as the list of people were public We were looking for them. We were the question we had on the table was are people that were mentored Initially as engagement Retained for a longer time the answer was initially yes, although we didn't Did that in a more scientific let's say perspective, but We knew that because there was a list of people that were listed that these are mentors in this project So it was a matter of looking for them Internally in a company if you're using github or others you may have certain labels So taking you as mentoring you can work around, you know or infer if that person is a mentor by you know Going to okay first contributor. We know that when the first contribution happened So then we can look for the person that basically review this And then we can say is this a mentorship process Well, you either go there and rate or you assume that the answer is yes And see about you know cycles discussions and so on Thank you, I don't know how much time Okay, I think we are out of time might be okay, but thank you for your time