 So then welcome, everybody. Thank you for being here last day of the conference. My name is Marcel Kurzman. I'm from Bosch IO. That's a subsidiary to Bosch. I'm also part of the Open Chain governance board. I'm regular participant of the tooling group within the Open Chain. All we have, not this is not the complete list, but just this is kind of where I was grown up in open source, I would say. And today, I also want to show you how we applied really the open source principle also to our own work as the open source office within Bosch IO. I'm not a lawyer, but by the warm our journey here, I became an open source enthusiast, I can tell you. And so from my observation over the last years, this is also the principle that I see that behind that open source. And my colleagues were so nice to have made this little nice picture out of my sketches where I said, OK, and this is very fundamental also for our companies or your organizations is to know, OK, do I differentiate with my business? Because therefore I thought this and this was for, I prepared that for Edinburgh in Scotland. So I put the whiskey in and now I realized, OK, here it also fits very well that you have here so refined products right at the end. So this is really where you differentiate them with your business. But if you look at the raw material coming in, so it's, well, there's no big differentiation potentially. So now with bio or whatever, potentially. But in most cases, well, you all base on the same raw material. And if you know this and if you think about your own business, then you know, OK, well, this is where we differentiate, but we do not differentiate. So we could potentially cooperate. And this is where I think this is a nice picture with these cooperatives, because also cooperatives not only joining forces, but also potentially joining the budget to do things. And it's exactly what we learned also in the last meetings, in the last talks over this week. So where I'm coming from, as I said, Bosch, Iowa is a subsidiary to Bosch. So what was the idea is, yeah, this is our marketing slide, we bring AIO here to life. So you can imagine Bosch when we were founded over 120 years ago, at the 30, I think, even. So no one thought about software or IoT. And so we had also bright brains in our company and said, OK, we need to somehow spark this. And this is the idea of my subsidiary here, Bosch IO, where I work it, so that we are the pioneers to check out how we can do this, how we can bring IoT to life for our customers at Bosch. And yeah, there was also a learning curve, to be honest. And one was also the open source. And that's what I talk about also here a little bit, how we did this. So we, as Bosch IO, we provide Bosch internal services. So I'm also an internal service provider within Bosch. So I'm a consultant. But we also have in our team the metadata curation handling team, like OK, license classifications, component curation, metadata curation. And a big part of it, and I think there you heard also a lot about, is the open source management automation, where we use Oort, for example. And what is the main focus of our services, or where we started with, was our IoT customers, so customers, internal Bosch customers, that pushed this IoT within the company. And that has some special requirements at that point. And also for them, they started to think about it and say, OK, well, IoT is not one company that owns the internet and does everything alone. But this is also something that we need to do together. So we had already this idea, OK, nobody can do IoT alone. So that was our point at that point at that time. And then we said, OK, we also need an open source strategy. And then things came together. And within our internal customer range here, I just listed also, then we started, OK, we need a kind of IoT platform. We learned about cloud and all those things. So that was the beginning. Then we now with autonomous driving, robotics. Also now our new topic, the software-defined vehicle. These are things that we cannot do alone. So we need, really, also to have some partners in the open source community, because it doesn't make sense to only have Bosch in one community, but it's much better to have a diverse community at that point. Then a purchase, Alisa, civil infrastructure platform. This is also where we observe, OK, we see a lot of redundancy, potentially, where we spend a lot of effort in the other organization, other companies. So we also see a big benefit in joining forces at that point, as we saw in the first slides. And all our customers, because we're supporting them, what they have in common, OK, either there was no project yet, so they need to build it up, or they needed to interact with existing ones. That's point one. And then IP, IP, IP. So this is also, well, not a startup company. So we also own a lot of IP. So that's also very important for our company. And this was really, or still is, a balancing that's very challenging, but it's also very interesting. And so therefore, we also happy that we have now a community of here, the OspreyCon D2D group. And as one of these things, and I talked about that before my talk, I will have another talk in the afternoon as a proxy of my dear colleague from Siemens, Oliver Fendt, is unfortunately not able to come to the conference. And here we worked out together this to-do group guide, Outbound Open Source, where we can also go much more in detail what we learned. We put our observation also to share that with the community in case, well, you also want to start it up, and you need some help, or well, you want to inform yourself. And this is exactly where the title came from for my talk. So it's when we observed, OK, well, our poor open source developers, they suffer from everything that we had to establish for the IP checks and things like that. A lot of processes, all this stuff to make that also safe and secure for everyone, not only the company, but also our employees. We thought it might be a good idea if we feel that on our own. And this is exactly what we did. So we also started that as a journey, and you will see some extracts of that. Here, a little list of the communities I'm well actively involved in, they're more to that. Also, I didn't put the links here, so if you go to the slides later, I put all the links at the end of my slides. I tried it out in SCAT this morning, so it seems to work. And here you just have the numbers. So as I said, grown up with Open Chain and the Toland Group, but now also Todo Group, FSF Legal Network. So this is where we thought, OK, this is really a lot of assets where we can profit on, but also there's a community that we can have much more benefit also in the collaboration than just using or contributing assets. And also, I thought, OK, I will put it at the list, because you see also the software 360 antenna, where we see, OK, now in a journey, there's also one sometime an end of a life cycle. And it's also nice now that we know, OK, yeah, we did it at least once, because we are not only starting up things, but yeah, we unfortunately have to achieve that one. But yeah, there's also some potential in a new start. And with Oort, I think we are on the right track there. And this is exactly the, if you look at the upper right, if you remember this cooperative, so where you say, OK, here we are differentiating, here we're not differentiating. So I guess most of our company's organizations, we, our customers, here internal customers, they work on cloud services, applications, embedded systems. So this is where we want to be best in class as Bosch and with our products. But on the left side, this is kind of the input. So we use dependencies from open source and so on. And I liked this quote yesterday, the tide lifts all the boats, right? It's really everyone profits from having a good and cleared open source material. And that's exactly the idea then to join forces at that point, because we said, OK, it doesn't make sense that, well, this company, this company, we all do reinvent the wheel more or less. So let's join forces and do that together. And there also, that's where I became the open source enthusiasts. Really, this is really true for us, right? Sharing really creates value. And I do not talk only about the assets that you could get only by consuming. So also, you can consume. You're invited. You're welcome to consume the material. But I can tell you, and I try to transport this also here, by this experience, eating my own dog food, say, OK, there's also value in this collaboration. And I really, really appreciate it. And that you understand a little bit how we then set up our services here internally. We really put open source at the core of our services. So here we have the three teams I mentioned, so about consulting, where I'm in the metadata curation. And, well, also the automation team, I just put it as IT. And here I just make some collections of where we started here, and then saw, ah, here we have a need, and so on. So where you see, I try to put that also in different areas. And I guess most of you that started in finding out, ah, what's there, what not. This is also something where I see a big benefit in having an open source community, because there's not a lack of solutions. It's just a huge ocean of solutions. And you need to know, OK, what's the right one? So even here, this is also worth sharing. And that's what we also try to do here in the to-do group, that we say, OK, if you come in as a newbie, or even if you already know the stuff that we maintain this together, because I think it was yesterday or some days ago, we said, OK, well, there's material, but this is already outdated. So then new people coming in seeing outdated material. This is also, yeah, you iterate and say, really, and this is also a value to have a community that maintains those materials. So if we go a little bit more down, I thought, OK, we'll also put that picture in here. It's a little bit small, but you can also see it in the slides, that you also need to have an idea about your life cycle, of your processes, where to put that in. And I think here we still have, oh, it's automatically forwarding. This is where you need to know, OK, where can I also use then the assets, right? So because I know I have an asset, but when it's the right place to use it. And here this is done for the infrastructure, one of our main components, this OSS review toolkit. My pitch is rather, that's for us, as we are coming from, as I said, IoT. We have this strong requirement to have this continuous integration, continuous deployment. So we need that automation heavily. So that might be different for others. But so here it's also important to know, OK, who has more or less the same problem space? And this is also in the beginning of the journey, what you will see later. And as I said, it's just the peak of the iceberg here where we started. And if you go down, especially if you go to automation, you see a lot of tooling standards, et cetera. So this is really a huge ocean of solutions. And we need, well then, to share in also what's the best reference. And therefore, we try to establish this also as a reference implementation. So you can use it if you want, but potentially you need to adapt it to your specific environment. And here, some examples where it's not a huge list, but I just wanted to show you, by mere consumption of open source, you can already have a lot of benefits. For example, what I appreciate very much is the open chain curriculum, for example. Because there was really a valuable material in the open chain with multi-language support, especially for Asia, that was very, very helpful. And imagine if you compare this with, I set up my own training material in my company. Well, this is very hard, I can't tell you, starting it up, but maintenance is nightmare, right? And then if you still have to translate that in several languages, and this is, I think, a very, very good example where the community does much, much better than any single company can do. And then also, my favorite, so it's not known very, very, very much, I guess, but I always try to place it everywhere, but this first thought event is so cool, such a cool idea, because of Corona, we didn't have much events, but I really invite everyone to go there and also share their events. Because potentially, some of you had the same experience, okay, end of November, oh, again, we missed the paper dates, the CFP date, for to foster them, because you're not, yeah, you're aware that, well, there's the foster in February, but you're not aware of the CFP dates, and this is also very helpful to plan, and also your schedule for the next year, where are the events, and so on. And also here, I think, sharing is a very high value. And now, yeah, this was some advertising about open source in general, I think I don't need to evangelize anyone here, but I want to say, okay, what's now our experience or why are we also into contribution in collaboration? And this is, well, it's potentially an ugly picture, but I hope it will show the differences. On the left side, you see the close approach. I think that's done, so if you do that internally and, well, maintain your own stuff, that's another story, but if you use, merely use open source, then I called it the open loop, it's you copy something, you copy, for example, this material from the open chain training material, and then you have to adapt it within your organization. That would be the lower right side, right? Because, well, yeah, you need to add this and that, and this and that, company specific, you change, you modify that stuff, so you branch it. And the point is, if then this version one that you copied and you modified, and then the community, because the community is very fast sometimes, and also it's very accurate, because it's several stakeholders that work on that, then they create a next version, this version two, and then you have to merge all your changes with this new version. So if you have a very slow developing community, well, then that might make it, but if potentially you have the experience also from your communities, that might happen very, very fast. And especially also in the training material, you prepare everything, and then you can start from scratch and then merge again and merge again. And this is exactly, I think, a very good example for eat your own dog food, because we heard about this in the beginning when we started the open source office and so on. Ah, okay, somehow the developers, they complain about something, right? But now if you use the material and also are into embrace open chain, embrace open source, you use that material. Now we really understood what they are talking about, right? So because you have all this merge efforts. And therefore, that's what I meant with upstream orientation. So we try to, and that's very important. It's a journey, we're still in this. We try to really switch also to this upstream orientation so that we really try to contribute back ideally most of the material that we use. So only as I said in beginning, you need to be aware one is differentiating or not, but that we really here always linked with this closed loop. So if we have changes, we can't build them back and can directly use from upstream. And that's holds already true for ORT. So here with ORT we really have, we always take the latest also internally, and for the to-do material and so on. So we are still on our journey. And here, this is, as I said, sharing creates value. Some examples where I see, okay, we do not only profit from consuming, but here you have additional benefits. And here I have with the FOSS events, as I already mentioned, one non-code example, because if you share your events, then by FOSS.events and then potentially you didn't think about, and then there are some changes for the event timing or it switches from on-site to online, et cetera. And someone else from the community knows this and he will share, he or she will share that, then you directly profit then also from the updates. And this is, I think you don't need to be a coder for this, right? You just put an issue and say, hey, they have a change and everyone in the community will know, and that's such a brilliant thing. Second, that is, as I said, also one code example that we had, I love to have that, so I'm grateful for Porsche to do this because they made a contribution. So we had teams that also use Cocoa Pots, but it was not the mainstream, to be honest, but they suffered from not having this analyzer for Cocoa Pots and Porsche, they had some more stakes in that, so they contributed and we profited from this contribution. So now we have an extension to the auto analyzer and also our teams profiting from this because this is also, we could have done everyone on its own close, but this is a real, real benefit for everyone, same, we now will contribute to the Python part, so everyone will profit from that. And some general benefits, I would say, is that, and that's what I really, as I said, I became now an open source enthusiast, also to have these meetings like this, but also our work team meetings, so you're really at the most current edge of information, right? Sometimes I really have, once I looked at the mailing list, I saw some news in the mailing list that was only in the news, in the real news, a week later, so it's really, I was so astonished that I'm now in a community that has that up-to-date information and this could also be a good advantage compared to someone sitting in his desk, in his back office, not communicating the outside, so you might have really a information gap of one week because, or more, because you just do not know what's going on outside. And a community, I think that's the best place where you get the freshest and already kind of curated or pre-filtered information because they will not inform about anything, but this is your community, your domain, so they will keep you up-to-date and you keep them up-to-date, right? And so this closed loop, as I called it, so you see it has direct benefits but also indirect benefits, and so also about collaborative maintenance, so I invite really everyone to be part of the loop. But as I said, eat your own dog food. There are also challenges, so I will not hide that from you and here I collected some of them because I also put that in the description of my talk, so what we learned. And now I have just collected some challenges and one challenge is this content formats, right? So for the coders, well, that's clear. They have their programming language, but we do not have a, well, Ospo language yet. And even worse than also the formats, like the one using Office, the other one using this and that and this and that. So also we do a lot in our wiki and then, well, how do you share this, right? And how do you close this loop because you might consume it and transfer it into your wiki, into your Office documents, but then if you have changes, so it's always a bigger burden to contribute that back. And here possible countermeasures, I also try to add some ideas, okay? And here we already have in Open Chain also a initiative to switch to markdown in order to be interchangeable. Or if you, well, if you're also love coding and you're spare time, also if we have then potentially little tools that do this transformation or rendering. So, but then please also share that because we will all profit from that. Then the second point is processes. That's really something we had in the code as well in the code portion, but also here I think in the non-code part is okay. Now I know my internal task list and then I have the issue list in the open source community and how to sync this. So for example, yeah, now our new feature is blocked by something in the community and this is also sometimes a nightmare to keep this tracking. And so this is also a possible countermeasure so that, but you will not change that from one day to another, I guess. So, but something you need to think about. So if I decide for issue tracker, can I use one that also interacts with the open source communities much more convenient. Then that is my real pain and as I said, I will have this other talk in the afternoon as a proxy from Oliver. You will see in the guide, I'm not an author there. You might ask also why he's presenting. So I was very involved in this, but I thought this was also very nice to, as an example, well, the colleagues were much faster than I was, full stop, right? So when I was ready with my organization, now I'm really ready to contribute to that repository, they're more or less done with the document. And so this is something where I think is also a good, a good point and a good motivation for also for the guide itself, right? So to prepare everyone. And I think there's a parallel to this agile thing. So where you try to be always potential shippable here, I would just extend that to be always potentially able to contribute. It's not that you have to contribute it back, but if you adapt your work to a mode that you would always be able to potentially contribute, I think then you did it. And this is where we try to be at. Then I think this is also into a little bit hiding into the direction with this format. If in the left side you have something ASCII in the right side binaries, right? So office documents, so at least I'm not a coder, I'm working with office documents as well. So that's really hard to track your changes, right? With the TIFFs, yeah, you could do that, potentially work, et cetera. But for interaction, the left side, so I'm always envy than our coders because that's so nice also having them get and pull requests, three views. So this is a big benefit in my point of view to copy as much as possible from their methodology. Then one challenge is also the culture because you also need to change your mindset a little bit. If you're used to from your work and I'm working now 25 years at Bosch, I, to be honest, 20 years ago, I didn't think about sharing things. So your mindset is okay, I have to do something, I have to document. But if you change that mindset, okay, to say, okay, I do not have to invent it from scratch, perhaps already someone else did this, right? So that you're first, and I'm an engineer, so I always want to solve that problem. So this is my first reflex. And now I really had hard time to change that reflex to, okay, I need to search community where there's potentially someone with the same problem and potentially these already solved that problem so that I do not have to implement my own one but can rather invest the time better in collaborating there. But here again, also this is the balance that you need to have because you need also in your organization, the awareness for the people, okay, what's differentiating and what not, right? Because everything that's not differentiating, there shouldn't be an issue. But yeah, you need to know this and you need also have to have in your organization good processes also to ensure this, also to secure your company, organization and to ensure your developers and your employees. Okay, and yeah, that's the last challenge and that's therefore we're here, I guess. The community doesn't work or it doesn't work anymore. So what happens then is while the material gets outdated to all no one cares anymore and this starts this visual cycle of say, hmm, okay, yeah, then I don't go there anymore and this is what's happening. I heard that in some of the talks it's like this consumer mentality that we have in some places and that's what I think need to change so that we also, even if it's, you don't need to share everything but if you already review and feedback that might already be helpful to keep that awake also to show some appreciation to the community that and they know they get the feedback, okay, there's someone using my assets that could already do the thing. And this is the, I think the idea between behind open source but then you also need to check and therefore I wrote focus and invest so you cannot be everywhere, right? And that was learning for us in the beginning so we had really these hundreds of projects kind of communities where we just didn't know where to go and then nearly every day there's another community meeting. So this might also be a problem. So therefore, I would say, if you know where you're differentiating, we're not then find your community and then focus and invest there to really have a vivid community that helps you and where you can profit from. Then the third point and therefore I added this in the life cycle, one day there will be potentially also the end of a project. So, and then please also make a clean archiving so not leave your projects there forever and then you create a lot of, yeah, kind of noise in the material and everyone has to iterate again and see, ah, okay, no, it's outdated. And as I said, there's an ocean of solutions and of information that makes it even harder to filter what's really relevant or not. Okay, and the last point I just added yesterday evening when I said, okay, that's really, I think as I said, embrace open source, make that not an extra point because when I think back to years ago, it was really, okay, now I do my work and now after my work, I do the community stuff. But if you can change your mode of working to say, okay, well, this shouldn't be extra, but the community work should be part of my work, right? I think then you also did it. And here I just collected that for ABCDEF. So what would be my ideal setup? So I think you don't have to really, you can check it later in the slides, but if I would have that really in the office, I come to the office in the morning, I have my infrastructure that's already linked to the community, I get all the news, all the stuff. And so that's really where we tried to reach that. And as I said, this is a journey. And then to, as I said yesterday, I thought about this again, okay, what did I do earlier and what did I do now? And this is just a selection of what I stopped or we stopped doing or still trying to stop is for example, as I already said, directly starting implementing. So that's potentially not the best way, but having really a community. And there's something where you potentially, even if you're very nicely involved, that comes for free, more or less, because you already get this information on and then you do not need to search, but you have the information present. Then the second point is this with also the formatting, where we currently try to really switch also to markdown or I already started now for our processes to use this BPM and Business Progressive Modeling Nutation as also standard, everything standard and be ready to contribute there. Then one very concrete example here in the Osprey column is actually these license IDs. So I still remember, okay, we had this ISPDX license list and then we had licenses that we detected. Oh, that's a pity, they're not on the list, but what do we do now? So we invented our own IDs, like potentially the other one also did. And now we really have now with the ScanCode license database a standardized way to provide then also identifiers for non-SPDX licenses. Then also what we did in the past is really we missed this CFP date. So we said, okay, yeah, yeah, we want to go to this conference. Yeah, it would be nice then also to start this and that topic. And then we looked at this, oh, yeah, it's too late, sorry. And that's sometimes that if you plan and you visit so that you also plan not from the, when does it happen, but you plan from the perspective, okay, when is the last date where I can put my papers proposals. And yeah, what I really, really appreciate as this copied from the developers is this pull request reviews. So in the past, it's really okay, we had kind of ad hoc reviews or no review at all. So you just well found that sometimes. And now with having this material in this always potential contributeable way so to contribute it to the external. So we kind of adapt this also internally so that we have this git based approach where we provide create new material. And then I review, for example, for my colleague, my colleague reviews my pull request in git. And that's so nice. I can really tell you it's worth making this switch. It's much more comfortable. Okay, so just as a summary, I would say my learning, it's really a journey. It's as we're not at the end of the journey, but we learned a lot over the years and became open source enthusiasts. And eating this own dog food is also something that I think you understand your customers even if that's only internal customer from our perspective, much, much better where we see, okay, what they are talking about. And then now we know, okay, yeah, okay, they have to maintain internal patch branches. They have, they want to merely make a small bug fix, but then we tell them, yeah, well, then you have to wait for several months and years until we check the contracts for the CLA's and so on. So, but that went in both directions as we then now understood, okay, what is their problem? So we could also find out, okay, what do we need to tell them and put in the trainings? And the, I would say the outcome of this over the years is what we can talk about later than in the late afternoon in the second session in this open source guide, outbound open source guide. Okay, as I said here, if you want, here are also the links to the reference that I used and also the last page I made the title inspirations. So because here where you will not see that we are already actively involved, so we were rather on the consumer side, but we were thinking about and doing this journey and becoming also here in those cases, always potentially, potentially, contributable, right, at that point. So I thank you very much and I think I made it in time and we still have some time left for questions, if you want. So there would be other situations or where would be the threshold where you would say, we can do with the community where we have to basically from PPE, do it on our own from scratch for this very part of the project of the community. Okay, I tried to summarize the question. So the question was, where is the threshold where I would say, okay, I have to do it on my own instead of going the community way. It's a very good question because, and that's a learning I didn't have on the slides, is that we started heavily also with open chain on IP license compliance, et cetera, et cetera. And this, what we are currently also working out is, okay, now in order to answer that question, we need to be more in the business, right? So our main target groups currently or in the past were the developers. We tried to do the translator between developer and lawyer and so on, but now in order to really see, okay, where is our differentiation? Where does it make sense? Then you need a business strategy first in your company and then you can derive an open source strategy. And this is something that is also, I think, not naturally born in the organizations. So that's something that we need to really work on and potentially that might be one topic that we could tackle as a community as well. We had already good start yesterday at the to do group meeting. Yes? Okay, so the question was, it's quite an important part of the company decides to look into the open source world. They always look into this aspect. So how do you work in terms of customizing, contributing to open source, but at the same time, those open source contributors should be able to work and bring it back to the right place after it. So how do you, how do you do it in your organization? Okay, so the question was how we manage the IP in not only using it, but then also contributing back. I guess the question is, okay, patents, not only license, but patents, things like that. So this is exactly what makes this whole workflow a little bit, yeah, slow. Or it feels very slow, but, and this is why I love, oh, sorry, it's the last question, why I love our Output Open Source Guide. So this is something I think we can talk about if you have the time in the other session, is that yeah, you need to do checks and this is what we compiled in this guide. So we can check this there. So thank you very much, that was the last question. And for those who want and are still there, you're welcome at 1650, I think it's the time for the next, my next talk. Thank you very much.