 Hello, welcome to my talk, leveraging an open source project catalog to select the right project. My name is Marcel Kotzman, and I'm from Germany. I work at Bosch, and they're specifically at Bosch IO. So our motto is we bring IOT to life. And within Bosch IO, I'm working in the IOT open source services. And here I run the open source office. In parallel, I'm also part of Open Chain governing board and try also to support the activities here in the community. Bosch and open source, where's the link? The link is that from Bosch IO, we try to connect all the Bosch things that make sense into the internet. And for this, we run an IOT platform, IOT Suite, and this is totally based on open source. So here we are part of the Eclipse IOT Working Group, also a member of the Eclipse Foundation. And here you see that was a lot of work. So it's not from one to another, but you have some steps that you have to go through, starting with mere usage, climbing up the ladder via contribution. And finally, we are so proud to be able to run some projects as project lead within the Eclipse IOT Working Group. And as this, we had a pleasure from the open source office side to accompany this over the last years. And when we saw, okay, our developers need to go through those processes with us, we had the idea, okay, how can we better fit this to their needs. And so the idea here was like, eat your own dog food. So we also set up our own strategy for open source office also to leverage open source tools and also material, everything and also to share with the public and collaborate with other companies. And that was already started a few years ago. Here my last talk I had in the summit was in 2018, I linked it here. And this is also one thing that went very well. And therefore, also we appreciate now this collaboration with the community. And today I want to give you insight a little bit more into our work in the open source office and giving you some ideas where we could also collaborate more on this. So our view, when we looked at all those topics that we tried to cover in the open source office, we made a little open source management process landscape and there we have those four big blocks in the process landscape. The one is the open source strategy and ecosystem. But this is rather high level, but on a daily work level, we have typically the open source usage and handling we have to care for. And on the other side and also the community involvement and contribution. And this is all done in the background we have this open source management system running where we also a lot of processes that we need to care of. And today my talk is about the experience we had in those processes caring about, especially the contribution. And as some of you might know, Bosch, yeah, we also have some requirements to ourselves. So on the one side, we try to protect our company. Yeah, that's clear. We're the open source office we need to protect them. But on the other hand, we also have then our developers in the field. So we try to also collect, protect our employees. On the other side we try to be a good citizen in the community as we value the community and in parallel we have anyway since the beginning our founder started with those Bosch values. So we have also certain responsibility in society. In this course of working and assessing open source projects for contribution we have those three aspects in our process the one is the employee who we check the other is the finally then the contributed contact but content but today I want to focus on the open source project. As the title is leveraging an open source project catalog for picking the right project to contribute to but also to to use it then. This is my main point I want to focus on today in my talk. And what's behind this so for assessing those projects we use three inputs as roughly so the one is the content so what is the content is done in the open source project is it in line with our business. The second is the context of the project where we observe from our open source office view. How do they handle licenses copyrights. What is the maturity of their open source management so therefore I took also this tomato picture are immature enough so if they are read and we can pick it. If they are still too green and we need to think about it and the third part is the contract so some projects already provide some contracts like CLA CAA whatever some use DCO or whatever you have different kinds of contract situations, none or as I said, and all this together is the input to our assessments that we need with that we do with the projects and at the end. This is typically not a go or no go, but it's it's assessment of the maturity level so this is what we try to do with our process. That we say okay, we collect the data that we have and then finally try to create a maturity level for that. And if the maturity levels okay, then we're ready to contribute. But if the maturity level is not okay. This is not not a blockers or something but then we need to think about okay how can we can we help the project or what can we do to raise maturity to a level that we would expect. Well, here in this specific case with the focus on open source management. Then how did this work in the past so this was also you will see I talk a little bit about the journey that we had now in the open source office until we came to this idea of this project catalog. So in the past, we got this request, we want to contribute to that project so we needed to collect some data, then we analyze that data, then we collect more data and more data and then reviewed, etc, etc. So it piled up really as shown here pile of information for each project, just to have the input to judge the maturity of that project. On the other side, it was not well distinct family project but it was really ranging from small libraries to frameworks that we need to assess on the one hand side. On the other side, it was the different domains as we are iot we will really connect everything so the one side might be a demotive and the other side industry whatever so we do not really have standardization and neither in the range and the size or whatever so we need to cover all projects that are that are there. And our observation when we looked at this is, as we had to process already now some of nice number of projects that there's a very heterogeneous situation on the one side is the availability of data so sometimes we try to find out okay what's the situation and specific projects, and then the question is, didn't we find it or isn't it there. So, and sometimes it's the data is just not there. On the other hand, we also observe, we have different structures and representation of that data. So sometimes you find a CLA there or there or the, yeah, how to contribute is written there or there or in different, in different ways. On the other hand, we try to also to leverage available sources like open hub, for example, but this is your rather the data that is provided there is not really talking about stuff that we need it for example where you can direct to check out there they have a CLA or DC or whatever. On the other hand, it's, yeah, it's black duck in the background and it's also, it's not complete so same with the projects lists and directories from the foundations there have a much better structure and in itself, it's rather standardized but it's also incomplete as they only care typically about their own projects. And the third part was that we were in contact with some of the people from the European side that they had an idea about the FOSC catalog. European FOSC catalog so this is still open. So that might be an idea. And here we open for discussion and later. And this was also the idea to form a new community about about this meta data that we collect here. Finally, what happened in our journey is that because we had to work on it. We needed to handle that different situation because we needed the standard virtual we had all the developers that waited for the answers and then finally, we created a standardized structure to to collect that data. And the initial structure to be honest that was nice to watch. But it was huge. It was complex and it was really you needed a special training to fill it out because it was so huge. And then also the question, well, is this really necessary to collect that data? What do we need it for? And then we came up with the need. Okay, we just potentially only need a landing page where we can start. And if we need more information, that's, that's enough because the information is there you only need to know where it is. Then the solution also for the complexity was that we try to make it go a little bit simpler where we said, okay, let's split it up in sections. Because the one who initiates that only needs a few information does not need to provide everything. But the next step as you have seen earlier, we had to process that and then we needed an every step different, different data. And this could be processed by different parties. And finally, as we always as the open source office we try to release to get them to take as much burden from the development teams as possible so that they can really concentrate on their work. And the same here so that we try to release them and providing too much data and spill time with searching for that because this is sometimes really necessary to search, search, search. This is the first step. So we reduced the basic information that we need from the initiator typically a developer developer development team. So what do they provide to us to start this workflow so and really try to reduce that to this basic setup. Data set. And this is the project name than the URL and typically as we said okay the developer he anyway he uses it and and is on the web page anyway or has some more information. So everything that was trivial to and just additionally so also we put in this basic checklist, but the mandatory fields on the name and the URL, and that helped us okay to do the next step then in the following in the following steps in the workflow. And then once we got this request, then we enrich this with additional data and when we did this. We saw okay. There's another thing where we saw it okay. What do we do here we primarily just collect the publicly available data and just put it in a different format. On the other hand we had a lot of information that we need internally like as I said if we handle CLA is we need to know okay or is it there already or not it was assigned. On the other hand, okay who might be a good contact person to get more information about this. So this is things that we mainly need for internal reasons but all this other data. Publicly available so this is potential community data and there's a high potential to share as well and this also brought me to this talk here. But more about this initial idea so with this starting request from a developer typically. What do you need to do he will he provides us a project name here I made a picture here in this case except talk that he provides a project URL. And this is also as it is already available on the homepage also the link to the repository and get so that's trivial and by the way, we also have the description. So this is a question of some some minutes. If at all to provide us, but typically developer also same for you and me potentially if you need to switch your media you're not really happy about this. And so as the get is typically used by the developers and the developers would be the main target group who provides us with those requests. We thought okay it would be nice to use then also get to to process this and then the question okay would form it and here we try to use this markdown. Because on the one side, it might be electronically possessed on the other side it is also nicely rendered and most of the UIs from from the get repositories and even search is possible. So I was astonished I for the preparation I checked it. So I have a lot of functionality already from scratch without even having an extra media or nor UI that I needed to create extra and just as some experience. From the beginning when we try to do this with our wiki and Excel files whatever it was a huge initial effort on the one side. So you don't want to do this again. And second, the question was, okay, how can we send it. And there the use of get also was well accepted by most of the developers because this is lower hurdle they already know get they know how to use it. On the other hand for all those office users like us. We also have now nice wiki marker that renders also this rapport content in our wiki. So both sides were happy with this. And it was really easy to handle. The other thing is that with this get systematic in the background. We can also use this and do the increments because it starts with this basic information. Then we add more and more data. On the other hand, as the projects change and potentially mature over time we also need those updated data. And this will quite perfect to use get for this. And finally, this is what we currently think about is also to you, because at the moment we still use our issue tracker for doing this. Yeah, kind of approval in assessment workflow. So that we potentially might also use the pro request and review methodology. That's already pretty well known from the software element also for this internally that we can also feedback to the developer. Okay, now we got your pull request we recommend and then you get your result and everything is then locked into the system. So it's an idea we didn't implement yet, but I think there's a lot of potential so in this in this setup. But most important, as we have all this data now get we're technically ready for collaboration. And so as I said, the data that most of the data is is publicly available so we just invested the time to collect it selected together and compile it in one in one's file. And there, the open question that I had, because I looked at SS had in all those project directories and open up and things like that. So, where could we share this because the existing system. I wasn't really sure if that's the right way to do this. And also, perhaps we should also first talk about is this the right material so do we need additional data fields, things like that with which community we could, we could have those discussions. And second, as this was in the in the beginning, mainly focused on the project itself. The question is how could we also do the link them to the components because we have on the other side and a lot of component databases. And so typically open source project has an out as an output has the component. So that would be nice to also have that link so if I go to the components see okay what is the mother the mother project of this or or in the other way around so what components are produced by that project to have that in such a dialogue. And the other thing is, then also what's the future so is the structure sufficient or would we need some more structure. I tell you this now and here also feedback is welcome perhaps after my talk, or if you approach us also in the communities like in the tooling group or whatever from open chain is that okay if we come to the point where I would be good idea and but please add this and this in this field. We should rather start this discussion now than later because if we collect that once I told you, I don't want to repeat this and if we can already identify fields that make sense for the future. Then we can directly collect this information right away now without the need of doing too many adaptations later. So, feedback is welcome and this is also all the main idea of my talk to really invite you to come into this discussion, potentially also will having birds of the sessions in one of our community meetings as I said open chain. By weekly meeting here from the tooling group and also in open chain on the on the mailing list. And what about potential because as you might imagine I had already a few talks and two people and if you dream around then there might be other potential places to do this. So, potentially, there might be and this is also potentially one idea than in this European foster catalog that you really have a catalog, not only for the reason that I need because in the open source office this is really my daily work but there might be other people that try to get an overview of available projects open source projects about governance, funding, things like that, addressing the the rears perspective at that point. The other thing is, I search for a specific product here. This is then domain specific potentially already available. So there are some directories where you can search for this and that and this and that, but this might be a side effect of this if I search for something. And I can see, okay, there's already an open source project. And same for the next points, either community or market analysis, we said, okay, we do not need to start a new one, because we have potential contribution. Do we need to build up our own project or is there a project in the same domain or with the same focus so that we could build a new community around it and to connect to each other. And then, yeah, potentially there also put could be possible to have additional fields like, okay, comments and likes things like that. I don't know I fool around here but this could be something would be really cool. Also for us. We get more input for our maturity assessment if you see okay. This is a well accepted project and yeah, there are a lot of likes and whatever. That could be also a potential new input to our assessment is it and will adopt it and so on. Okay, so I added then also some in my backup I can show you later for discussion also some examples would go in here, like here I have it also using my other talk so that's what how it would look like it's the raw data. Just that you can see that's possible here on the left side. We have those basic information about okay name. You are all short description and on the right side and more deeper information about okay where can I find contribution process is there a CLA yes or no. And all this communication channels. Who can I contact is the mailing list. Things like that. So I will add that to as the backup slides for your information later. So that once the slides are shared, then you're welcome to browse it through and also feedback to me if you have what do you what do you think about it and if you have any suggestions to improve and I would be happy if we could come together to form a new birth of feather even find a community to talk about details more deeply. I thank you very much. My name is Marshall Chris man here my contact details, but you can reach me ideally then also in the open chain reference tooling group. We have discussions like that and there you welcome and also welcome your your your contributions. Thank you very much.