 Yeah, welcome everyone This is amazing for me. I guess the biggest always ever speak to I'm quite nervous. I wish I was that relaxed as a previous speaker weren't this topic I'm usually I'm talking about technical stuff and About hypervisor designs and things like this But this is about giving you a broader overview What we are doing in our now a domain in our company and and how we are Integrating open source in industrial environment and the challenges around this So first of all about our company Siemens Just briefly and so we have a history of 170 years of innovations in various fields We are currently about 350,000 colleagues And yeah, the revenue just to give you in that year is about 80 billion last year and the products and solutions that we provide are in the area of power generation of Generation and distribution of industrial building and and rail automation Railway vehicles, maybe you have written one here Medical technologies Product life cycle management software security solutions and this list can probably be prolonged The company is constantly changing That means that if you may have a smart fridge which is Siemens branded I cannot lonely tell you if it's Linux running inside Things are changing a little bit over the time But we do use open source and free software in our products quite a lot already That doesn't mean that it's only open source there by far not But this is a constant trend over the past ten years. I was looking at this There was a constant rise in open-source usage in our bedded products and In fact, although not everyone not every product which considers for example Linux to be embedded Picked it in the end But all of those who did this and who migrated over I'm not aware of any case where someone migrated back to a proprietary platform That means although we are Munich based we had no Linux case in our product so far And I hope it's not going to be changed And in fact, this is something I found out while doing some research for this talk Desktop actually is quite successful with Linux At least for our customers So a lot of our PLM software and and IDs that we provide is also provided for those distributions So there is probably a business case behind this But let's make a bit more concrete What kind of trading technologies we are using here in this thing So this is of course a little bit focused and biased and there's technology like like pre-empty in our devices embedded Linux and Debbie and Linux We have a safety certified Linux running There is a series of product of about 30 or 40 devices All based on a Yachto Linux We also have one product where we provide an own Yachto layer for Linux We do real-time control with Xenomai on various things including very big machines for medical imaging and We have KVM running on arm in our product So it's quite interesting things to work with all these Why is it like that? Well This is of course a management slide, but it gives a good idea about how things are changing over the time And we are still writing a lot of software probably we're writing way more software than we used to do in the past But the overall amount of software in our product we have to integrate if you want to integrate is exploding formally So it's no longer feasible to build this pyramid all on our own I guess no company in the world has the knowledge and the experience to build all these kind of things only on their own anymore So really have to collaborate on this kind of things Another very important aspect for our business and is the long life of our products So many of the devices that we ship live at least for ten years some even longer they integrated in In a lot of facilities which have a lifetime of maybe 50 years or more So and unlike a smartphone for example you don't replace an embedded device in a Magnetic resonance imaging system or in a high-speed train or in a production plan every two to four years you keep it very much longer and Furthermore if you replace it our customer expect is going to be compatible what we put into this Actually, this is the key element in many of our businesses and Open source enables this it helps a lot in this regard It's a major foundation for our products and it's comes with a high assurance that we can still Embedded in the same form in a couple of years ahead The availability of this software makes it really interesting for us and It also comes when chosen wisely without vendor log-ins That of course sometimes also raised interesting question when colleagues come around say oh can we use this kind of software say? System D or let's say docker in our products already. Is it ready to be used already and be used in the same way in ten years from now? These kinds of fashion have to be answered them And of course a very important and painful point if you have to maintain software for that a long time is When things move in different direction Oops, oh I'm ahead of my time Okay. Yeah, actually very important. This actually is The updating of this software we can no longer afford to run the systems unmodified in the field as it used to be former times these were boxes closed locked down and in some In some cupboards and no one actually can access them and no one wants to change them anymore These times are definitely over but now they are standards and regulation that enforce us to update the systems continuously in the field But how to patch such a system? Always the latest and greatest version that you can get from the community, which all the nice fixes included Yeah, the point is actually Developing such kind of devices can take a very long time You have to qualify and and test them to hell and that can easily take a couple of years to finish the product and Then if you're out in the field and you update the system and this update changes more than it actually has to change That means that you may have to redo a lot of this work and that was obviously a no-go So even if these changes that we apply to the system come from a high quality source and they are correct and They don't change the temporal and functional behavior of this component in a way that hasn't been specified like that You have a software stack on top that may have certain expectation on the underlying system implicit explicit expectations and Even if you get that thing in a major form We also have open platforms where our custom integrate software owned software third-party software So it also has to be stable in the end and that's a challenge actually And that's the reason why this domain not only our company is very conservative regarding changes in the system And that takes me to the next point if you have to do changes to the system have to maintain the system You are dealing of course with forks of open source First of all if you did it internally so self-inflicted, but also if you got a lot of things from your suppliers So when we started off with open source and it was pretty easy for People to change things in a way that wasn't really upstream get upstream able and that happened that went into products Of course, that's the first curve so to say of open source development But this is not just while you trip it for a couple of years And then you're done with it you learned about it that easily can take you a decade to get these things sorted out again And also if you're if you're under product pressure have to deliver something and you develop another set of nice fixes and enhancements of the open source component It's not easy to get them in time in the upstream project So they end up with a local stack of patches that it hasn't been upstream when the product is already out in the market Or the changes haven't been developed to be directly integratable in the upstream So we as an embedded team we try to lift this all over the place with our Customers internally and we also keep to reminding the developers to think upstream first When they are changing open source when they integrating open source and the product We also keep on reminding our suppliers to lift this And so because it's really not affordable for us to maintain tens dozens hundreds or even thousands of Non-upstream supplier provided patches for our Linux systems or other components over such a long phase so it's all about Upstream first so this is the message to our suppliers But it should also be a message to other companies in this domain to their suppliers Which are probably the same one that we have We know it's contributing to open source. It's not just about being a good open source citizen It's also about extending your corporate knowledge How to integrate all these open source component properly in your products? It's furthermore about motivating and keeping the talents in your company loyal to you in these times where Moving around becomes pretty flexible for the people By now, it's actually also a way for us to communicate with our suppliers It's way easier if you have an open source software to show them and say look these are the problems We have could you fix that or? Even collect requirements from your customers like we are doing with one of our products But how to get there after well decades inside the cathedral? That's not easy. So just one example a couple of years ago a colleague approached me Look, I have a buck here in GCC This is description. He has a test case to reproduce it. Can you help me and I said I'm not really a GCC expert Open a ticket upstream and and Reported that's probably the way to go and he said yeah But I'm not allowed to publish a single line of source code even that test case falls on that So, okay, I did it. We at CT had the proper processes in place at that time The good news is by now the very same unit is a well-recognized contributor to Corbwood and The products they are making the board support is maintained upstream in Corbwood The times are changing not in all parts at the same pace, but we are moving forward So just one source check our GitHub planning page for Siemens. There are a lot of interesting project around there Maybe you find something useful The next logical step and you may have heard about this in the past days before in the presentation is creating a cross industry collaboration project of your own and We are happy to achieve this last year together with with a touchy with fushy bar code seeing a platform not to Forget about the reason joining of renaissance to this project So the civil infrastructure platform project newest foundation collaboration project is in a natural a community of companies That want to build an industrial great long-living base system for these kind of devices That we are building It's a collaborative effort where we don't want to replicate existing efforts. We rather want to collaborate Augment and fill gaps where they are and and make the whole thing better work better in the long run So we are working together with the current community, of course with Debian It's all with other collaboration project automotive great Linux and more And then you may have seen some branding changes recently of a well-known company mentor graphics So mentor is now a part of Siemens business and we are very held come very happy to welcome a lot of new colleagues on board It's a great chance to augment our experience and capabilities and embedded operated embedded or open source software services and solutions so over the past months the Linux oriented groups of both companies came together and We tried to identify where we have common grounds where we have also things to benefit from each other technologies Experiences and developments going on in different ways So we are looking forward to deepen this over the first upcoming months and one of the results already is members Mentor is participating now in the CIP project So stay tuned for more a last but not least License compliance and probably quite a few of my colleagues with no run screaming out of the room of because of this topic But this is a very important one. So first of all, we are now an open source software producer and We were we understand the importance of license compliance from our own perspective So for example, we chose a copy left license for our JLOS hypervisor and we published it But primarily we are an open source consumer and we are an open source redistributor and That means and we have to take license compliance seriously. I mean very seriously in the day of some first copyright make troll is no longer the time to take a sloppily and For us, it's very important to invest in this topic to make it Simpler for us as his user but also for the others to be compliant So we are investing for example in these tools physiology as an tool to do a license analysis on software and SW 360 which is a tool to do a license a software software library Basically a bill of material for your software based product We are supporting this project. We actually maintaining some of them The colleagues of them around here And we would like to foster this in industry. We also participating in the open-chain activity We are supporting the OZ idle license OSS license compliance checklist SPDX format we are supporting as well and We like to see more collaboration on this between the users sharing the analysis results that quite a few of you probably also generating exchanging the findings coming to a common conclusion on the results and Specifically reporting this results back to the source of it and that's the other open source project distributions because eventually we really want to rely on these results being accurate for us to reflect the whole license situation and Be machine readable that we can automatically generate basically the obligation that we have to fulfill That's the vision behind it and that would help a lot of us to make things easier So with this I would like to close my talk Thank you a lot for your attention. If you have further questions visit us at our CIP booth on the top level Talk to my colleagues. Talk to me. I'm so around for the whole week and yeah, enjoy Let us a dirt now Hold on one second. I want to ask you So I loved your talk because upstream first taking license compliance very very seriously creating your own projects You know At the Linux Foundation the number one thing we see that inhibits the growth of more Developers more commercial investment more reinvestment in open source is companies don't know how to do what your company has learned to do So it's just amazing to see it. We recently published a open source in the enterprise guide on the Linux Foundation website a Lot of the practices that you just described are in those. So I just incredibly well done. Thank you so much for that great lot