 Welcome everybody. If you are in this talk, you probably want to know more about this Extrospective word, and you're in the right place Today I want to share with you three different things about these extra spective ospals. The first one is the obvious one What is extra spective? The second one is at Ivan we have an extra spective ospal. We just turned one year old in May so now slightly slightly over a one-year-old and We did some learnings along the way and we want to share them with all of you in case you want to build an extra spective ospal You will know what we suffered or what were the problems that we encountered along the way and also what worked and Finally, I want to talk to all of you about why these matters and why do we leave that more companies should have Extrospective ospals or at least have a part of it, which focuses on extra spective ospals. So Extrospective ospal and as the picture kind of says Reaching to the outer to the outside to the outer space The formal definition of extra spective which is a word by the way and it's a word that within our team We came up with like to describe what we do So kudos to Ryan Extra spective is examining what is outside yourself? So it's the opposite of introspective so we are used to introspections and introspectiveness But we usually don't use the word extra spective and in ospal's terms is about Working on things that they are outside of your company Extrospective we are usually familiar with this definition of inbound and outbound ospals and we've seen probably a Diagram like that one or maybe something similar to this one This is not about what they do what the ospals do. It's about the focus of the ospals So some ospals focus more on inbound So taking in open source projects and some of them focus more on outbound and some of them focus equally on both Today, I want to talk about a specific subset of these outbound ospals So it's about the production of open source code. It's about the delivery of open source code. So just as a recap In case you don't know probably everyone in the room knows but just in case which are the characteristics of the outbound and usually is all revolving around creating policies for creating open source projects And we want to make sure that the company knows which steps to follow when we want to create a new open source project because we came with a great idea and We decided to open source this great idea Triple thumbs up. So that's the way to go and obviously we have this open source project But we want to have not only that thing available. We want to have Adoption of this open source project. We want to create communities around it And that's also one of the aspects and points of the outbound ospals to create those communities around those open source projects We obviously talk a lot about governance because yeah We need to make sure that everyone in the community understands how the project is governed and how to have an impact on these projects so we talked about those things a lot and obviously in Contraposition from the Inbound ospals, it's a different perspective. So we don't Intake code we produce code and it's about producing code to the rest of the world. I Have a reflection for you now. So given this picture you see here. It's kind of a small diagram like It's a simplification and it's nobody will use this thing, but Imagine we have this shop web server Which then talks to two different services among many other ones pricing service and stock service which in its own turn Talk to a database So please and please stay forward My question to you my reflection to you is would you consider it a risk? If one of those projects like any of those ones doesn't matter which one the pricing service the stock service of the shop web service was Maintained by your developers on the free time You can raise your hands if do that thing But you would consider it a risk. I'm a recording so I will not see if you raise your hands But I am guessing that many people are raising hands sometimes even two hands saying that should never happen We should never leave parts of our critical infrastructure Unmaintained or just left for the developers to be maintained on the free time So my question to you now is why are we accepting it when it comes to open source? So that database might be Postgres the services might use Whatever open source framework and again the web the web server is also an open source web server So why are we leaving the maintenance of those open source projects and components? For the rest of the community to work on whenever they can some of them might be on their free time as well And most of the time is not even by your own developers So why we find it acceptable and that's when the extra spective come into play So that's why what is our focus our focus is Working towards ensuring that the critical infrastructure is actively maintained And obviously we put a focus on the open source projects that belong to our critical infrastructure We want to have projects that do not depend on a single company organization or individual by that one we mean that we want to reduce the bus factor and if we have more companies who contribute to open source projects, we will have more different backup tools and companies backing up those projects and and and they will be more healthy Because they will not just depend on one single company organization or individual. We will increase that bus factor Related to this previous one We want to have a diversity of opinions and by that one We mean that the more people from different backgrounds that they are involved in these projects the more diverse opinions and Visions we will have and again if it's only like just for the sake of having different companies backing them up So affiliation of contributors is more diverse That will already be an improvement because there will be just different points of view for that project And they will be healthier and better discussions And of course we want to relieve the workload of the current maintainers because that's the pain of many open source projects Maintainers are overloaded and they need help and we want to help them The mission of this kind of extra speculative osmosis is as follows Ensure the sustainability and secure the future of the open source software infrastructure used in your company So we want to make sure that the open source software infrastructure is treated equally as any other service or Part of your infrastructure, so it should be actively maintained by your company and we do it through the extra speculative osmos Now I want to share with you what we learned. So as I mentioned before We do have an osmo, which is an extra speculative osmo at Ivan And we just turn one year old and we want to share some of the things we learned along the way So first of all, I want you to introduce you to the Ivan's Osmo So what we do at the Ivan's Osmo is contribute to third-party open source projects You could have guessed that because of the extra speculative that I mentioned before, right? So the projects we contribute to for example are Apache Kafka, Apache Flank, Postgres, OpenSearch, among many others. So basically the big chunk of work we do is mostly on those external projects on those third-party projects And we also do have some open source projects on our own from Ivan So first-party open source projects But the main focus and goal is to contribute to those ones to the ones seen here And as I said more to come like Apache Cassandra, like Redis, like M3 Anything that we use at Ivan and we consider it power of our critical infrastructure Disclaimer, I need to put this thing around and again That happens when you work with extra speculative osmo's The projects we have here that I say here do not belong to Ivan Obviously they belong to their own respective owners Kafka, Flink, would belong to Apache, OpenSearch, WUS and Postgres It's a Postgres thing Some facts about Ivan's osmo We are around 10 people We are organizing chapters and each chapter is Focusing on a open source project or open source project ecosystem So for example, we have one chapter for Kafka and its ecosystem Another one for Flink and its ecosystem Postgres And OpenSearch and so on So every people is in there is in a chapter and we have at least two people in each chapter So people are not alone and they can collaborate and contribute together to open source projects We are distributed. I think that is an obvious fact But we are all around the globe and we have people in US, Canada, Europe And it basically we are not any more bound to a single location And we are in a growing phase. I said that we are around 10 people We want to double and even go bigger Father than double the size of our team for the next these years And as I said before, we turned one year old in May So we're happy The principles we are running with We want to put the community first And that thing is important to understand from within the company and to outside of the company We are not there to push any kind of Ivan's agenda. We are there to help the community We want to look at what are the problems the community is facing at the moment and we want to help that We don't take requests from Ivan and treat them like these are things that needs to be done We read the community needs and we work upon those We want to be recognized, but don't get me wrong. I'm not meaning like we want to be I individually recognize or be heroes in that we want to be part of the community We want to be seen as a net contributor to communities of the open source projects We want to make sure that we have an impact on those communities We want to be transparent and we are transparent meaning that every contribution that we do At work time, it's basically one of the things we do is It's contributed through the Ivan email on the git commit email So we we always make sure that it's clear that we're doing things in our work time And that contribution is sponsored or it's done at work time by Ivan So we don't hide this fact and we are transparent and forward with it And it's more than just production of code Obviously we do a lot of things in production of code. We contribute a lot of code But we also do other things that it's not just only contribution of code We also do pull request reviews, documentation writing Buck reproduction because we sometimes there is a buck report, but the reason is repeat user So that's also some of the things that we do and we need to take care of Some of the oddities or some of the things that Some companies might have a hard time when trying to create an extra speculative ospal So the first one is the obvious one The IP, the intellectual property of the code produced Is not owned by the company So we contribute to third party projects Meaning that the IP is owned by those third parties and not anymore in our case by Ivan So that's something that some companies need to get their head around and understand That's a good thing. It's not a blocker and we should enable those things We have a little to no control over the backlog And by that I mean that Ivan itself doesn't control end-to-end the backlog of those projects as I said before it's posquerous It's Apache Kafka. It's Apache flink. We don't control end-to-end those backlogs We can influence them. We can have our own opinion there, but we don't control the whole thing The same thing comes with timings. We cannot decide when something needs to be merged Or when something needs to be released We can give our own opinion and we can try to convince the community, but again, we don't own the timings And one thing that probably will be a question happening Hopefully only inside the companies, but hopefully people in this room We should not have this discussion or question is But aren't you collaborating with competitors? We should stop this competitor thing and when we work on open source, we are not competitors We are just colleagues. We are collaborating together Building these open source projects. So we should stop having these competitive mindset thing We are collaborating. We are joining efforts people from different backgrounds and different affiliations On a common goal, which is an open source project So hopefully this question only happens within the company. You just need to convince them and that's not happening around us and amongst us So now I want to play a game with you Let's build an extra-spective Ospo so Let's start So what do you need? So We have a company. It has the full support Everyone said yes. Let's sign off. We build the extra-spective Ospo. Let's go for it So the first thing you want to know is Okay, we might need developers, right? So what type of developers do we need? So let's start the first thing We need to find out what's the focus of those developers Developers should probably forget about these quick turnarounds that we are optimizing our life for And by that I mean this thing You code something you really is it you observe You fix what you observed wrong And we release again You observe again you fix whatever it's not working. You release again You observe and that's an end of the cycle And what developers most of the times do now product developers do is optimize this cycle to be as quick as possible That should not be the focus of the developers working on these extra-spective ospos because that's not how open-source project works We need to have different focus. We need to focus on how can I have this feature? How can I convince enough people that that's a good feature to have in the project? And how can I write code that it's easy to maintain in the future by people who is not me? Me Another crucial aspect of the developers so another developer trait that we are looking for is autonomy and you might say Yeah We always look for this one You're right But probably we want to look for even more autonomy in this particular case So we want the developers to be self-driven and why? Because as I said before you might organize them in chapters Each of them focusing on a community and they will be the experts on those communities So they need to be quite autonomous in deciding what they work on next They should know how to prioritize their own work They need to see I can work on abc and d Right now d is the most important thing that it should be working right now And hence I work on that one and that's something that they need to be have a good sense of grasping Another trait that is interesting awareness They need to be able to understand the community needs so in order to be autonomous on the as we said before You need to be able to read what the community needs at each point in time And what would be the best Place to put my time that would get a bigger benefit for the community So return of time invested on community gains And that's what they need to do. They need to understand the community needs And one of the most important aspects of these type of developers that we're looking for is resiliency I guess everyone in the room contributed to open source at least once and maybe some of you only once because of that and resiliency Many changes that we propose will be rejected and not always because of clinical reasons sometimes because of political reasons Also, not all communities are the most welcoming communities But we might want to change those so we might need to be in for a ride Before we can change them So that's why we might need some people with some resiliency to be able to change things from within or to endure the process of trying to push a complicated feature and convincing lots of people around in the community to have something done And that's something that it's a different trait we need to look for So these were the four main things that we identified that we when we need to look for a developer So now we know what type of developer are we looking for? Now let's start hiring. So we talked to our talent acquisition people and we say look that's the kind of person I'm looking for that's the type of developer I'm looking for Let's get them So the first consideration that we need to have when creating a team is that the team composition is crucial Again, you might say Joseph that's quite an obvious thing Yes, but let me explain what I mean Having existing community members speeds up onboarding newcomers When you have a newcomer to a community to an open source community It might take quite some time until they realize and understand the written and and written rules of the communities So having somebody who is already an member an existing member of those communities helps a lot And that's something we learned There is a problem though those existing members of the community usually If I ask you what could be an ideal candidate for you given those That they need to be an Extrospective hospital developer So they need to contribute to other projects what you would say probably you would say I want a commuter, right? But then the question is how many commuters are there? Given a project you probably have I don't know 20 commuters 30 commuters maybe 40 if it's a really really big project So from those commuters maybe I don't know five six seven They left the project all together Some of them they maybe moved to another stage in their careers So we are left maybe with 20 people in the world Who fit our ideal label? So as you can see that's not quite scalable and we might need to not search for this ideal candidate And we might need to look for more Easy areas to get people which is existing contributing members They might or might not be committed But they if it's good, it's good if they would have already some knowledge of the community So regular contributors Are a good place to place these ones, but again having the commuters is a really really tough one Again, it's kind of obvious Around the globe we said the pool is small And if we still if we on top of that say no you can only be in this particular location Kind of forget about it, right? So you we need to hire the talent where they are and that means Hello multiple time zones. You might have people all around the globe And that's a challenge as well because if you want to have a team Cohesion and feeling of a team You need to work against those time zones differences sometimes So you need to be mindful as well when you create the team On the time zones where the people are and what's your plan on having people on different time zones And if you will have only one person on one specific time zone That's something you need to look really carefully and make sure that that person is not feeling isolated. So These are the restrictions that we're having on on hiring So one of the things that we obviously think about is okay, maybe we can grow some talent Because it's not only about hiring sometimes. It's about growing your own talent, right? so One of the things that every company can do is promoting Programs to promote open source contributions internally at Ivan. We have something called plankton program as we Have a crop many of the names that we use are kind of C creatures or environment things in this sea so plankton program Is crucial for the open source ecosystem We think that that's a nice way to contribute back to the open source ecosystem And basically it means that every Ivan or every person at Ivan who contributes to open source on the free time They will get compensated with money. They will get paid for those contributions So how it works is that each person who wants to contribute to open source projects at the end of the month They report how many hours they contributed to and they will get paid by the end of the month so That's only when they do contributions outside of work and that's not restricted to developers. It's also valid for graphic artists for project managers For typewriters copywriters anything like that any contribution to open source is welcome and qualifies for this work on top of that Every time that a developer or project manager or graphic artist Hits a problem on an open source project or a need on open source project during the work time they can also they are also encouraged to work on those open source projects and We want that thing to happen We want to create a culture that contributing to upstream is not just a anomaly or a really strange thing to do It's common. You find a problem upstream. You contribute it back to it And that's the philosophy you want to have and growing having that one It's easy to grow talent to be able to contribute to those environments So now we have developers And probably want to have some management around it We want to make sure that these people are enabled and that they know exactly what to do and make The better out of them Learnings we made along the way A new tool set probably You need a new type of tools The areas of impact that you might be used to are limited and Timing and responsibilities are not anymore Only on your responsibility tool They are usually external so that means that For example when a team is struggling and they don't manage to release as often or they don't manage to finish Issues that often or solve problems that often Sometimes you say it's because they don't have an end-to-end responsibility chain Or because they are they were working to isolate it and they do neither didn't pair or didn't collaborate on solving those problems So you might want to shake the teams up change the Responsibility of the teams, but that's suddenly something you cannot do on extra-spective hospitals The community owns every all these things that you want to change so you cannot change them Another thing is you need to be more of a coach. You need to be an enabler You need to ask the right questions. You need to help people become diverse versions of themselves And it's about being like a coach like Not being the at the front Foremost and trying to be the all the spotlights on me The spot the spotlight is on the developers and as a manager you need to make sure that They are on the right place doing the right thing at any point in time Related to the previous one you need to be a different leader And you will be lots of the times you will realize that you're not the expert in broom The people that you manage the people in your team Are the experts on those communities that they are working on and you need to rely on them To know what makes sense to do next and you need to enable them so they can do the best On their work, but suddenly you are not relying on your technical expertise You are not leaving from that technical expertise You lead from another place from a more coaching side You need to enable them and make sure that they are the best Developers they can be So we have the managers we have developers And now the question comes when when I was Uh interviewing for Ivan I asked This question and how do we measure success? The answer at the point in time it was That's something we want to discover together And that was one of the reasons why I joined and that's what we came up with So we I will share with what we came up with but first let me show what are the Things we learned that we can't not do So the main question is what do we measure? So we don't control a substantial part of the process Releases mergers when people do co-reviews all those things depend on the community So if you want to define a Like fixed timeline to say okay, I want to measure How good are we doing? We need to be really careful what we can measure because there is a lot of things that we will be measuring that have Lot of the impact is depending on externalities So we will not be measuring our team, but maybe we will be measuring the community instead of the team itself so Time is an illusion That means that if I'm giving myself this three month time window Like I want to measure every three months. I want to see how People are performing. I want to see how they are working and evolving and having these three month checkpoints Nobody else in the world cares about these three months that I'm saying that I'm setting that nobody else in the community Nobody cares about these three months Nobody even knows about those three months So anything about these three months Is to be ignored So probably we need to move away from those timescales So a proposal so what we came up with and that's what I was really excited when I joined I said, okay, then let's Try something. Let's build something some of the things Might be slightly fluffy or like soft But that's what we could do. That's what makes sense. That's what makes sense and what we Think that is working for this whole year. Again, that's measuring performance on individual level and then for a team level There is another picture So what we want to measure one of the KPIs that we want to measure is number of issues worked on And it means work on not merged not reviewed It's basically what we spend time trying to fix So we want to have impact on issues that the community is facing So working on those ones is something we want to count and we want to optimize for The more community issues we work on the better Another thing we want to count a measure is the number of patches reviewed And that's something depends solely on us. We can always go to the bull request Tap on github if we are in github check that And review those PRs. We can also go to the mailing list if that's how the project contributes patches to And review those patches that are there give your opinion on code that it's given by others Because that's one of the bigger bottlenecks on open source projects We want to have community engagement That's another thing we want to measure and we want to increase And by community engagement, we mean blog posts mailing list collaboration or like writing on mailing list answering questions that give talks back reports or Reproduces of back reports that they don't have any reproducer Anything that is engaging with the community and making the community more vibrant That's something we can measure and we can just try to make an impact on that one Those three things rely solely on us and we can have an impact And that's an individual Then as a team we can measure over time like when time is infinite time doesn't matter And then we can just basically say on the long run on Not giving any time frames how many of the tasks of the issues we worked on are merged How many of them are not merged? What are the reasons why they're not merged? And that's the way to measure the team's performance, but individually for each Person in the extra-spective OSPO That's what we do to measure the performance So now we are all set and we can just start our Extra-spective OSPO and do hard work and hopefully we will see the results In some time. There is another big thing. Do not expect results immediately. That's a marathon not a sprint Now i'm entering the last part of my talk which is Why does it matter? Why do we believe or and I believe as well That we should be doing more extra-spective OSPOS or OSPOS should have a extra-spective part So the first one is because it's more than just money more than money Monetary donations solve massive problems in open source projects and they are great And we should continue doing monetary donations and we should have Funds created and we should find better ways on how we can donate money to bodies That they can make sure they reach the right places That's needed absolutely And we need something more We also need people The maintenance burden it's only reduced with more people If we have two people no matter no matter how many how much money more they have it's still only these two people And we rely solely on these two people. So probably what we want is Not to have only two people on that project But maybe four maybe six maybe 10 people 20 people On that project who know this project and can maintain this project that's a more sustainable way And maintenance will be the maintenance burden will be reduced when we can share it among different people And the more people the better And we believe that's a scalable solution Because the more extra-spective OSPOS we have the more open source development mass we will have so Join this journey and we will have more developers contributing to open source projects And the more of us that there will be the more will be scattered around different open source projects and the more mass Of developers contributing to those open source projects will be on the critical path of open source projects and If we have more developers That means that those ones will be more secure the projects So the developers will contribute to projects and those projects will be more secure By that I don't mean that we will prevent incidents They will happen The only thing is that when they happen because they will happen We will react faster And the more people we have the faster will be we will be able to react But it's not about Avoiding those ones or preventing those ones. We will prevent some of those But it's not about reducing them to zero And that's a nice nice line that Should everyone have one so should everyone have an extra-spective OSPOS and My answer to this answer to this question is no And you might be wondering Joseph You had a talk Explaining us why we should have one and now you tell me that We don't need one That's not exactly what I mean. What I mean is that every company who could Afford we should have one And having an extra-spective OSPOS is not cheap. It costs money So we should be we want to have extra-spective OSPOS who are there for the long run And for that reason it would be great if companies who have already a way of Leaving a business model that it's useful. Sorry that is working And sustainable those companies should be Doing to these external parties to this third party open source projects. So they should have Maybe not a full like a independent extra-spective OSPOS, but at least an extra-spective part on their OSPOS Because you should have an OSPOS. Well so If you can't afford it, you should have one And I have one call to action for all of you right now Which is Let's build shared open source projects together If you want to read more about all these things that I talked today There is a blog post about Ivan's OSPOS one year later and you can read that thing. That's the link And don't worry. You will have a QR code leading to those slides in a moment. There is a video recording of a meet-up Slash podcast video podcast From contributing today, which is called do you even OSPOS with members of ypro and A spotify and Ivan as well. So myself wasn't that How to convince your manager to start an OSPOS? That's a bit piece that I wrote on the to-do a blog post and if you want to know more about Ivan, that's the link about Ivan Thank you very much for attending this talk. That's a QR code that will bring you to these slides This is a website. You can just Watch it every time you want and scroll through the slides. My name is Joseph Pratt my Twitter handle is the one you see below that and if you tweet something, please I would love to see this thing trending, you know, some way Extrospective OSPOS. That's the word that I'm trying to coin as maybe you can have guests and Thank you very much for attending my talk and let's have more extra speculative OSPOS. Thank you