 Yeah, I usually do that because it's easier for me to do it myself. Hi everyone. So my name you already got. I've been doing open source for quite a bit. Started with some tools and then Linux, Debian and Postgres. And those years are all when I really started doing work as a developer, not started using it. But nowadays most of the time I spent working for a company that does only open source. That's where we are here. And that's why I'm so eager to point out that the Windows desktop isn't mine. Everything is open source here in the company. As you can see, we do all the services for all of open source and we have offices in the US, in Europe and in India looking to expand further east as well. So that's it for the marketing for now. Let's go to the real topic. So a while back I looked up some numbers of where and how is open source used in corporate IT. You can see on the left side it's MTAs, message transport agents. Right side is IMAP servers. And you can easily see almost everything is open source. So here the green one is Microsoft and there the which one is it? The yellow one is Microsoft. Always the first proprietary software in terms of size. You see easily three fourths of the whole market is open source. And then in databases, no that's a web server. Database comes next. Web server the same thing. We don't really know what Google has. Anyone here from Google? Who could tell us? No. But we have to assume it's based on some open source thing. So again the Microsoft thing in green is the first one and we can have more than three fourths. And yeah that's the database side. It's slightly different. But still you can see all the MySQL side, the orange one is open source. You have with Oregon and Microsoft SQL server you have two big tools that are close source proprietary. But still Postgres and MySQL and SQLite have a lot of market share. Interesting enough SQLite has more than sidebase and Informix isn't even showing anymore. Anyway so we could say yes we arrived. That's it. Open source is there and we could actually make the whole story short and I could send you over so you can start the next presentation. Actually I did that. I added this slide or added this way of presenting it after I was on the presentation where everyone was late. They were running really over and my presentation was the last one before lunch and my guy organizing the session said so the best thing you can do is get on stage and tell everyone to have a nice lunch. So I figured it might make sense to have a point where I can stop. Okay so let's have a look at why and how it works out. What happens is or happened is companies have realized that there are bigger advantages to open source than just licenses. Way back when everyone was talking about the open source license and the license fee on the proprietary side as the big difference. But nowadays it's not the big topic anymore. There's a study going around like once a year called the future of open source survey. And these are the top three points that came out of it as the question was what's the business reason? What's your reason for using open source software? And you can see yeah people like flexibility more than that they like the freedom from vendor lock in and most of it like the quality of the software which has gone up from fifth place in 2011. So essentially it means open source software got better. Let's have a quick look at all three of these. Let's start with the flexibility. Anyone here old enough to know this thing? Except me. Yeah I solved mine way back. Anyway just for the younger forks to explain this bread box is a Commodore 64. It was a revolution back then because it had 64 kilobytes of main memory. The prior model had 3.5. I mean that's a huge difference right? But just as compared to modern or PC hardware everything was solidly soldered. Just compare for create a picture in your mind that the CPU is your P system. The memory is the database. Let's say the audio is the web server and the graphics is your eShop system. Now you get into the situation of you want wanting to upgrade something like I am not satisfied with 64 kilobytes. I want 128. You cannot simply just exchange the RAM or you have to pick out the soldering iron and create more on it. It's a big hassle. And the same happens on the software side. There are a lot of situations where especially in the proprietary side where you have interdependencies so you cannot upgrade as easily as you would like. On the open source side though that would never happen. Never. Because worst case you can just recompile the software in a way you want it to be. So you can always get what's the best for your environment out of the open source. And at the same time, well this is a modern system right? And it's your choice what you prefer. This more or less relates to open source. At the same time you get the advantage of being open. Now everyone might say yeah, open like in open source. We got that. But it's not about the source code alone. It's about the formats, the standards used and so on. And as I already mentioned before in one of my other presentations, there are already files out there that nobody can read anymore. Not that long ago, I mean 20, 25 years ago, let's say the company went bust, the format was lost from the company that created it and nobody can read them anymore. Now assume you have the legal obligation to store your files for 50 years. You cannot do it. You don't know what will happen in 50 years. Not even for big companies. So the only option is everything has to be open. You have to be able to create new software to read it. As for the quality, so I guess everyone who was in computer science has seen these before, the standard software development model called the waterfall model. Frankly, I hate it because it's a one-way street. And what happens is, let's have a look at a real waterfall. For those who don't know, that's Niagara Falls, which is quite a bit of a famous waterfall. And you see what the waterfall produces. It's all the mist there, right? And the interesting thing is mist in English is this. The German language, my native tongue, has also the same word, mist, written exactly the same. But it means something else. It means crap. So essentially the waterfall, me, produces crap. And that holds for software because there is no way to go back. There's no way for the user to feed back to the system architect or the developer. Yes, you can report a bug. I mean, you're lucky. They put it into the ticket system. And that's different in open source. You can always talk to us as in communities. You can work with us on changes, on features, and so on. Collaboration is the key point there. Next topic, well, last topic in that slide was security. It used to be a liability in a lot of people's minds. Now it's become number two on the decision maker's list before costly. Because people realize, and there are studies that prove it, that open source, it might not be inherently more safe or safer and more secure, but it's at least in the open. You can see how good it is and how safe and secure it is. And you can even work on the fixes yourself. So if you have to make a decision to deploy some software in a security environment, you can check beforehand, is there a problem with this software? Is there something I have to do? Well, if you buy a software, you ask your vendor, you ask salesperson that comes in and I bet you he will tell you, she will tell you, no, there's no problem with our software, no matter how many problems there are, because these guys want to sell, right? And that doesn't happen in open source. So I'm kind of with a list because of the timing issue we have. I don't want to read the whole list. The two points that, well, the one point that is really important to me here is think of open source as bespoke standard software. It's commodity, but you still can get it to the point where it exactly fits your need because it's so adaptable. And it's still part of the standard. So the next time you do an upgrade, you don't have to worry about your changes. It's a part of the source tree. It's part of the commodity now. And the other one is of course no license course because we had that before, but it's not what you're really looking at. What you're really looking at as a company is total cost of ownership. When you see where the costs come from, you see that reducing the license cost to zero reduces your total cost of ownership by 7%. It's nice, but it's not exactly a great number. And even that is not really true because you still have to buy support somewhere unless you want to do it all by yourself. So you get more savings potential in the training and downtime department, for example, or in the hardware department. Open source tends to run on older hardware or smaller hardware. You might not need that much training because the way it works, you train people up front and then it works better. And it's more reliable. You have more features that you can enable. You can do more with it so you have less downtime. But the huge difference here is obviously staff, people. So there are a lot of things that make it cheaper in the whole situation. And there are a lot of studies that show it makes it cheaper. But I cannot do anything about it. Some people just don't believe that for whatever reason. So let's forget about it. Just believe it. It's cheaper in the long run. But you also have to get there first. So you have to do migration. And for that, you have to go in and invest money, invest time by consulting whatever to get the migration done. And also have to buy training and stuff like this because when you get to complete new software, people need to learn about that new software. The way it's measured is you check the return on investment. So what you want to see is how long does it take me to recover the money I invested on the migration. And we did some studies there by checking migrations we did as a company. So it's not representative. And we made it like, but it's a simplified calculation. Instead of using the license fee as a yearly fee, which is normally is we broke it down to a monthly fee to give you a better idea what happened. And we had a look at a lot of different scenarios and a lot of different software pieces that we migrated. Could be database, could be monitoring, could be other DevOps stuff. We combined them all and created this sheet that on the bottom shows you the amount the migration cost and on the left hand the x-axis shows you the month it took to recover and to get the full return on investment. Meaning no matter which one we looked at, it never took anyone longer than a year to actually make money from the migration. And that to me is a fairly simple calculation. Usually, depending on the size of the company, people are looking at ROIs of two to three years. That's why they make a decision. If it's longer, they probably don't do any investment. But that's so short. You see it in the same fiscal year. It should be fairly easy, but okay. Anyway, back to the migration itself. There are a couple points you should make sure to take care of when you do a migration. This is not very special to open source nor fairness. Most of these points are general points for migrations. Why is the M so small? I don't know. It's not because I wanted to have a small M. It should be a large one. From personal experience, I have to say don't forget the redundancies. They cost additional money, right? But you need it. And the other one is please, pretty please don't create any temporary or isolated solution. When my wife and I moved into the first flat, we were the first renters, actually. So the builders weren't completely ready. The construction was still ongoing. And we got in, and after a day or two in the bathroom, the spring broke, the spring behind the fan, in front of this fan. So it didn't work anymore. So we called them in. They came in, replaced it. Over the weekend, it broke again. So we called them again because it didn't work. And they came in again. There has to be a different problem, right? Because we replaced it last day. Turns out the spring was broken again. And they didn't bring a new one. So the guy took his pen out, took this spring out of the pen, put it into the fan, and said, okay, this is only temporary. We didn't bring a new one. So you use this one, and we come in again this week and replace it with the correct one. Needless to say, I've never seen these guys again. When we moved out of that apartment, like two or three years later, the fan was still working. And the same happens in IT. Whenever you go for a temporary solution, you kind of get stuck, not with all of them, but with some. And eventually, it will come back to bite you because, well, you need to set up a new system that doesn't work the way it's planned because there is that temporary fix somewhere. Open source licensing. Yeah. Sometimes it feels like it's under growth. It's not that easy to get through, but it does make it interesting for lawyers, right? Anyone left here that's a lawyer? Okay. But in general, you have to audit your open source usage and you have to establish corporate policy. That could be in a small company. That could be something like, well, let's talk. It could be something where you need a full department doing it. It depends. But if you don't do anything, you run into situations where you think you have nothing because your policy is not allowed until somebody sues you and proves that you're using this piece and that piece. And you don't care about the licensing because you thought there's nothing in there. It's all your source code. It's not. So there are a lot of open source licenses and the basic incompatibilities are well known. Admittedly, a lot of developers don't care, which even creates problems for open source projects. Like the Postgres project I work on, it's BSD license. We cannot accept any GPL source code or else Postgres would be GPL. But still, people just send patches, use this library instead. No, we cannot. Stuff like that. A very important point, or actually two, if anyone starts doing open source software, please don't try to put it under public domain. Public domain is not a license but a status, meaning nobody owns that software anymore. And in most legal systems, I don't know how it works here, but in most legal systems, there is only one way to put anything under public domain, and that's by dying. And you don't want to do that to get the right license to your software, right? The only exception I know is that US federal government work by definition is public domain, but only inside the US, yeah, right, makes sense. And the most restrictive license you can use is no license at all. So no matter what you do, put something in there and explain to people how they can use it if you want them to use it, because if nothing's in there, they cannot use it at all. And before you think about that, no, the patent is not the solution for protecting your intellectual property right. It may not be a problem for you, but it definitely is a problem when it comes to collaborative workflows within your unit, with other units, with your contractors, with your customers, whatever. Because at the end of the day, open source is more than just code. It's also about work processes. A lot of companies use what they call inner open source or inner source nowadays. They just look what the communities do and figure out, well, that could help us and use it internally, which doesn't work with patents, even internally. Let me see. At one point, maybe early, maybe late, everyone figures out you run into a situation that you cannot handle yourself, so you need help. It could be a classical service because you don't have enough resources. It could be you don't want to dedicate resources deeply enough, whatever. So in the proprietary world, you would go to the vendor and get support, services, consulting, whatever. There is no vendor in open source. No company should own any project, which is not exactly true. For community-backed projects, it's correct, but there is a lot of, well, commercial open source where a company alone handled the software, like in the database space MySQL. I cannot send, well, I can send, but they will never accept a patch if I send one to MySQL. They cannot because of the dual licensing thing. So if you want to go for support, there are two options. You can have free support by communities. Keep in mind, they are not based on SLA. Community will help you when they see fit. And I've been, as a community member, I've been in a situation where somebody sent me an email saying, well, I got this buck here. You have to fix it because it's critical for me. Well, since when do you pay my salary? I make the decision if, what I do, when. And that's the way to not do it. Starting a demanding back report in the open source community won't get your help faster. It probably slows them down. And at the same time, the way you communicate with the community is different. So it's not like contractor or supplier and customer. And the way you have to communicate is different. You cannot say, well, I paid you all that money. You didn't pay for me. You just got it for free. And that's the one thing you have to look for when you are contracting an open source services company, that they have people who speak both languages, your corporate language and also the open source language. So they can kind of liaise between two. Speaking of experts, in most markets, I know there are not enough OSS experts available. So for everyone who's still looking into getting into it or into finding the field they want to get into, open source certainly has a great future. There are enough trainings and university classes available. But be careful with certifications. There are some available that really make sense. And there are some that are pretty crappy. And I got in my own business life, I got a history in ISO 9000 family certifications. This is the classical example you use there to show that this certification doesn't make any sense whatsoever. The left hand is a life vest, right? The right hand could also be a life vest. You can make life vest out of concrete. And it's actually cheaper and easier to do it. Because you don't have to worry about a return process. Once it's used, it's gone. But you get it ISO certified. If your processes are correct, no problem whatsoever. And like that, I think I hit the nail on the head. Any question? Command? Criticism? What about the neutral argument that defines a company and it's a very complex software that says some 3D modeling stuff. So now I have the option to use a commercial software or use Blender. So now if I switch you over to Blender, I have to do all this training and all these things which you mentioned. But now I've done all the trainings and now the Blender community just splits up. It splits up. It gets applied and they're all like throwing the towel and Blender is not existing anymore. What do I do now? So this is, I feel this is the reason why often businesses are not interested in these orders. I don't think the Blender example would work because the community is too big already. And the same problem holds for companies. By a software from a provider company and they could go bust. Yeah, but they sell me lessons. Yeah, but if they don't exist anymore, I've literally, I mean this sounds like a joke, but I've talked to a bank and they bought a system for risk management from a small software company that only had one developer really knew. And that guy wrote this bicycle onto a tree or into a tree. So not nice, but it happened. It took them three years to get an upgrade on the software. So it's not open source specific. And the worst case, you could take that software because it's yours anyway as open source and do the development work yourself. It will not go away, but assume you buy the software, the company, well ends the product and you need to upgrade your operating system, but it doesn't work on the new one. You cannot recompile it yourself. So in my book, the risk on the proprietary side is bigger than on the open source side. Any more questions? But it might not happen anymore. And this bank buys software. It's only written by one for a reason. Because of all the ISO stuff and now all their processes in place and they need to look into it and they might not even give the contract to them. True, but it doesn't change a thing in terms of going bust. It doesn't matter from which big company you buy, they still can go bankrupt. Or they just decide this product doesn't give us enough profit and we don't want to do it anymore. We're shifting the focus of the company. We're not a 3D modeling company anymore. We're now an audio processing company, whatever. And the product just, it doesn't exist anymore. Thanks for the analysis on migration where you showed the RY. So from your study, did you get any insights on which industry domains are in this migration easier, for example, Well actually, those examples are all over the place. So I don't think there's any industry for which it's easier. There are industries who are more willing to give it a try. And there are use cases where people are more willing to give it a try. Just as an example, when you think of a large machinery that has a database server, a lot of database servers, the price tag for that is big. If you have only one that gets connection to hundreds from the outside, the price difference is way smaller. So it's usually price driven. But from the technology, from the technology, there's a difference. So it's different from migrating informants, Postgres or Oracle to Postgres or Windows to Linux or Unix to Linux. Those are differences. But if that Unix server is a bank or an insurance company or an airline, it doesn't make a huge difference. Yeah, that is true. Interestingly enough, most of the time they talk about regulation and so on, it's not really a problem. They bring it up. And yes, they're in the same situation that he just mentioned. They need to tick the box as in it's supported and company has a certain size, blah, blah, blah, all this stuff. So they cannot probably go for the open source and do it all themselves. So they need somebody to help them. True. But that's it. Yes. Right, right. Yeah, but it's mostly for certification and tick the box. It's one of the most critical arguments that I hear against using open source in the companies in enterprises is that we cannot use this because we don't know how to do it. We need someone who does it for us. And we don't even want to touch it because if we do it ourselves, then we also have the liability. Yeah, but that problem is essentially solved. That's what companies like we are for and others. It's not about saying that we are the only ones, but people just need to learn about it. I think I need to go.