 Good morning. Hope everyone is in the right presentation. I found it slightly confusing here with zero E1 and zero E2. Anyway, this is the open source on ramp. The idea was for me to present a little bit about where we stand with open source now in the current age and how we got there and what we can learn from it. I mean, we all know the saying that if we don't learn from the past we're bound to repeat it. There's a lot of things that worked out in the past were forgotten or didn't work out at all and were tried again. Let me start with a quick introduction of myself. All the dates listed there are when I started actively developing software. So yes, 93 when it was still called free software. I used it earlier. I guess that makes me kind of an old timer. Anyone here working on free software longer than I do? Okay, I figured that much. Oh, close. Okay, fair enough. Did a couple of bits pieces here and there and then did some work on the Linux kernel actually, but very minor pieces. Became a Debian developer and then a Postgres developer in 98, both of which I still do. That's my professional history, not really important here. Although you might notice some of my first contacts with free software were at the university, which was pretty common back then and maybe still is. The first couple of years in business were like much less free software because free software wasn't that much of a thing back then, but I'm going to talk about that a little bit more in detail. So let's start with the early years of free software. Again, it was called free software back then with a couple, well, there's a reason it's called free software, but there's also a lot of confusion in the term free software and we know this is the open source summit. The new term that was coined in the 90s has a replacement for free software. Well, it's slightly different, but that doesn't matter. The thing is people thought about free software as in free beer again and again and again. Even back into the 2000s, I still remember somebody calling the office telling me some IT manager in the municipality telling me we have a Linux print server and it did stop working. Okay, what do you want me to do? I have to send somebody over immediately. We need to get back to printing. We need to print our documents. Okay, fair enough. It's like an hour right away. How do you want to proceed? Do you want to send me a written order? Should I give you the rates on the phone? Do you want me to fax something? And he was like flabbergasted. How do you mean rates? Literally, I thought it was free software so everything should be free. No, sending a consultant to your office, fixing your problems and going back is not free. And that probably problem was there for each and everyone back in the day. People didn't understand it. I think nowadays we could use free software again because most people do understand. Not all the nuances, but the general concept. It started mostly in academia. Again, I pointed to my own time at university. This is by the way is a path that the software or a route that the software calculated from Berkeley to somewhere in the Silicon Valley. Coming from the idea of creating that slide or that graphic came from the idea of showing how Postgres made it from the halls of Berkeley to the data centers. But that's exactly the point. Postgres was a university, a scientific project. Then the University of California said, okay, we're done with it. It was still free and a group of people came by, took the software, started fixing bugs, using it, improving it and so on. And it became the open source database. I mean, there's nothing comparable to it in terms of features and quality. Also, I mean, this is like, again, the old guy talking. This was before we had web servers and before all the worldwide web was in existence. So we did all this work through email and Usenet. Not sure if anyone still knows Usenet or uses, or I don't, I don't use it anymore. At least we know it. And most of the coders were literal volunteers and hobbyists. There was no real business behind it. Then the businesses started coming up. Mostly starting with Linux discos. But also with some pieces of software that were just needed on the new and developing thing called internet, like email servers. For the vast majority of email servers, as MTP servers on the internet, have always been Linux systems or Linux open source software, let's say. Originally back in the day, it was sent mail. I don't think anyone still uses sent mail. But still, there are a lot of different tools and it has always been that. And then other software came up. As I said, the worldwide web was just getting into existence. So Apache was built, the web server, which was always a major player. I don't think we ever had, except for maybe the first one or two years, we ever had a situation where less than 50% of the worldwide web servers weren't open source. Do you know how many, what percentage Apache itself has? Phil, I'm looking at you. Okay, anyway, I could have looked it up. Nowadays, we have different servers that you might use. But by and large, if somebody's running a website, a lot of it is run in open source software. And also functionality, I put it here, it's functionality to access and build the internet. In the mid 90s, there was a big, big business of building firewalls with Linux, with built-in filter software. I'm not sure what it was called back then, net filter, I don't know, I forgot the naming. I still see people running booth at trade shows selling those firewalls where they literally just configure the Linux kernel accordingly for six digit figures. For a short while, it was a real big business. Again, for a short while, until people understood what they were doing. But at the same time, most of the market didn't understand open source and didn't believe in it. Starting with free software, then we put it into open source. But again, the issue was not just the term, but also the way it works. I haven't been at meeting lots of people in the room. And one of the, it was about replacing the Informix database by Postgres. And one of the guys said, I don't believe in this open source stuff. I said, why don't you believe in it? Yeah, well, once people start developing a social life, they are out of the project and you lose your best coders. But wait, I'm married, I have three children. Don't you consider that a social life? And he's like, yeah, maybe, but I still don't believe it. Turns out he was the external consultant, paid big bucks for working on Informix and he didn't have any idea about Postgres. But at the end of the day, that argument won. So they put a lot of money into new additional licenses because it was a very easy argument. But again, I'm jumping ahead in my slide deck. The community-wise, we had loose communities. There wasn't this big group of people working on it. And most people came into it just by working for what they needed themselves. And then they pulled together for the greater good. Was every software and a version control system back then? Nope, not at all. And the packaging was an issue. That's why the Linux distribution came up, actually. But anyway, we got those figured out and started with the .com years, where open source, at least in some areas, became a real alternative. Back then, a lot of features that were developed in open source were simply re-implementations of what was done in proprietary software. You do your software, it doesn't matter what it is. You look at the proprietary alternative and see they have these neat features. Let's implement those two. But also at that time, we started seeing the first projects that got paid development. Where companies actually figured it makes sense to go into that area. We got software, I mean, Netscape Navigator is probably not the best known software anymore. StarOffice, or then OpenOffice, then LibreOffice now, is still a big, big thing in the open source world. And those companies just open sourced their software because it was the best move for them on the business side. In general, we had this .com market coming up with a lot of startups creating a lot of software. And a lot of those was done by using open source software or by even open sourcing the software. So the new development here is business started to rely on open source. People developed business models that used open source, that were built around open source. Some companies were out of their time though. There was this big, big consultancy firm where the strategy was, first place raised some capital, second higher, everyone you know that knows somebody about the topic of open source software. Third, find some work for these people. Obviously that is not a sustainable business model. They were betting on the market growing exponentially and it didn't, it actually faulted because the market collapsed. But anyway, it showed the word, it can be done. And the next generation actually survived, but not everyone, but most of them. Some of those open source parties were part of the bubble, sure. But some of those newcomers that were built around open source are now big, big, big companies. I mean, when did Google start? When did Facebook start? And also traditional companies started out with using open source, usually from the outside. I mean, this is a satellite picture, this is exactly those systems, not the satellite up there, but the satellite systems in an IT perspective, people started using open source for. Let's use open source for the smaller systems, the ones that are not so important and get some experience. And eventually open source moved into the inner core and replaced, for some companies at least, or for most companies, replaced the most important pieces of proprietary software they had. On the community side, we had to develop processes. The original word of, oh, I just sent an email and be done with it, wouldn't work anymore because more and more people loaded into the ecosystem. And I became a Debian developer, I send an email to the then project lead and said, hey, I would like to contribute, there's this piece of software that I use that is not part of Debian, I would like to package it. And the reply in clear text email is, well, here's your account on our master server, please change the password. That's it. And back then, connecting was something like town net, which means clear text of each and everywhere. Obviously, more people looking into it, more people trying to find vulnerabilities misusing the software, means you cannot stick with that plan. And also more people coming into it means more people with no idea what they're doing. They like to learn, which is fine. But while you're learning, you shouldn't be packaging or creating mission critical software for other people. That's just too big a risk. So open source community had to start with real processes where you prove your expertise, where the identity is checked. So you can trust the software you download from the internet. Again, speaking of my major projects with Debian, because it's such a distributed group of people, it's tricky, but we still do ID checks for new developers. And ideally by somebody meeting with them in person, checking the idea and checking the GPG key and cross-signing and so on. With Postgres it's different because we have that group of committers who are allowed write access to the source code and everyone else has to gain trust by sending patches and fixing bugs and so on. But they cannot write into the source code themselves directly. Also we found that different licenses created different needs and processes. It's fairly easy to say, okay, this is GPL, GPL gives you already a certain set of guidelines, what you can do and what you cannot do. Once you get into permissive licenses, it's more difficult because you're literally allowed to do everything with the software. But you don't want to exploit the community or don't want everyone to exploit you. It's not really nice when you talk to a software vendor that uses your software and they tell you, oh, I don't know what these community jerks want. We take everything they give us to get to market quicker, but we certainly don't give back because that's our advantage. And you're standing there and think, wait, I'm one of those jerks. Could you at least Google me before you tell me that crap? So it's always a difficult situation for some software, for some business needs, permissive licenses, make a lot of sense. For others, they don't. And I know the Linux Foundation by and large promotes permissive licenses. I still believe that the Linux kernel has been that successful because it is GPL, because all the major vendors work together, there is no advantage for any one of them to fork, to take something away because they have to publish anyway, so they can collaborate. Also, in that timeframe, security became a topic. The hackers in the bad sense looked into Linux system, looked into open source systems as alternatives. Mostly not to steal data. Back then, there wasn't much data to be had, but to use the system as a stepping stone, as a jump host to attack somebody else. It's really great when you talk to IT people and they tell you, we have those Linux servers. This is great, we have a firewall, they have a firewall built in, did you know? Oh, yeah, I do. So we don't have to worry about it that much. Okay, can I have a look? Sure, yeah. Okay, it's nice that they have a firewall software integrated, but it should be activated. Wait, it's not? No, it's not. Okay, can we have a check? Sure, so we checked the system and found out it was used as a jump host to attack whomever. We never figured that out. At the end of the day, nothing bad happened for that system, but this is the special case. It was a hospital. Just assumed they had used the server to get medical data from their patient. They could have closed the doors, I mean, that could have been catastrophe. So it became a topic and people started worrying about it, which makes an awful lot of sense. It also resulted in open source software that became more and more competitive to proprietary software. Companies had to decide whether they wanted open source route or the proprietary route. A lot of companies did both to some extent, which makes sense, but also gave back changes they did to the open source software. So people started to play by the rules, started to become part of the ecosystem. There was a competition between open source software and proprietary software, but the difference to the earlier years, it was a two-way street. It wasn't the open source software copying features or feature ideas from the proprietary route. It was also proprietary route copying features from the open source software. Just as an example, there is a patent owned by Microsoft, something about aggregating button or aggregating, when you have certain amount of open windows, they go into one in the same button in the task manager, something like that. But the patent description says the first time the idea came up was on the KDE mailing list. So some guy from the KDE project came up with the idea and Microsoft said, that's a great idea, let's use it. Now we can discuss whether it was a good idea to get a patent for that, but a different story. The thing is, the open source word started developing their own ideas and ideas that were so good that the proprietary route wanted those two. The system became more and more complex. The awareness in user cases was much bigger. As for complex, there's a schema here of a, I'll call it a mail cluster. We did in 2003. That's the first scheme, schema. The idea was to filter all emails going in and going out for spam and viruses. And given that this was the German meteorological service, they need, and they send out their storm warnings through email, they needed to make sure everything's clean and they don't send viruses. The system has been upgraded, obviously. New hardware, new software versions enlarged, and whatever you do in those 20 plus years. But the condition back then, when we won the tender, it was our version of our solution and open source versus some proprietary software. So they went with us with the open source version because of availability that we promised. And up to the day, 20 years and something, the total downtime of that system is zero. It has never failed. Try doing that with some software where you cannot go into those bits and pieces and details to figure out what's going on. Really, really difficult. Also, companies started doing total cost of ownership calculations. Interesting enough, most of those showed easy wins for open source software. Despite that, a lot of decisions went to proprietary software anyway. What happened here is, back then, the proprietary world figured the only way to fight this open source movement that takes away our revenue and margins, is to spread fear and uncertainty and doubt. Up to the point where they put incompatibilities into their software and blame it on the other side. Or where they said, yeah, the office developers are just too not good enough because our office software has XML now, so everything is there. Yes, right, but if you use a binary blob and don't tell anyone what's in the blob, it's reverse engineering and you cannot be 100% perfect. Once you answer that, people left. So that was the literal sales argument by some people trying to sell Microsoft Office back then. A lot has changed, don't get me wrong. But back then, that was the tactics they used. Because even back then, the companies saw open source as a threat to their business. On the community side, we as a community, or a lot of communities, had to understand business requirements. We had to learn to speak business language as well. Originally, it was easy, like I need this feature, I want this feature, I'm going to implement it. But now it's like people saying, we need this feature, would you like to implement it for us? And you have to understand it because that feature is only needed if you run like 100 systems at the same time instead of one, and who has 100 systems at home. So we had to learn to speak business language, but we also had to learn to speak to each other. Yes, there were a couple of conferences and things before where people were able to talk to each other, but developer conferences, and conferences like this, were coming up in that timeframe. This is, by the way, the picture is taking from the 2006, I think, Devin Developer Conference. The original ones, the ones before had a very small group of people, but starting in that timeframe, more and more people were willing to travel to get to those conferences, and talk to each other, plan, work, and stuff like that. And then, let's say, in the last decade, open source has become a commodity. There's literally no data center in the world where you don't find open source software. There's probably no room in the world where people don't use half open source software. Just looking at your, you all have a cell phone in your pocket somewhere, and I assume some of you have an Android phone, so even have a Linux kernel, right? By the way, a very small piece on that soft phone was written by me. Anyway, it doesn't matter where we go. Go to your microwave oven or your refrigerator, your TV, it doesn't matter. You always find open source software somewhere, your car, everywhere. Now, what we also see is a lot of those traditional monolithic systems. Difficult to replace and not exactly up to date anymore. We had to learn how to do a distributed development, how to do distributed development on a large scale. Which open source communities really were good about. That resulted in a lot of companies figuring out, wait, we can use that for our internal development. So the term inner sourcing or inner source was developed using open source methodology for your internal own development. And we built more and more foundations around the open source software because for a change, we needed some organization around it as a community, but we also needed legal representation. It's not just the simple situation, everything is easy and just do it, stuff just happens. There are court cases out there with trademark violations and license violations and so on. And for a while it was even, or actually still is a risk for open source as well. So back to the data center thing as I just said, we are an every data center. The startups that survive the dot-com bubble are enterprises now, well, most of them. Some might have stayed small, but by and large, they are big now. But also traditional companies are using and installing and offering open source. But in that time, I've even got into regulated industries. So we see insurance companies, banks, other financial institutes use open source now. Well, maybe to a certain extent, maybe there is some special software that cannot do it with it. I don't think there's any open source software that can help you do your text work. And I can understand why nobody wants to take the risk to develop that software or follow up on all the changes the government comes up with to create more text revenue. So yes, I get that. But in a lot of areas, open source gives you the alternative, no big issue. Given that this here is the on-ramp track, I'd like to put a couple of words in about how do you build the skills to work in the industry to be part of the open source world and also the open source business world? Training was there for a long time, but it only became abundant during, I don't know, last 15 years. Not every company out there needs committers and developers. Actually, it's quite the opposite. Most companies out there need people who can administrate servers, who can keep systems running, who can set up new systems, who can configure systems, and so on. So there are a lot of skills that the market is desperately looking for that doesn't mean you have to be a coder and nothing but. It's still an argument that some companies use, oh, we are a much better company. You should work with us because we have those developers. Yeah, do you need a developer? No. Do you have people who can, well, take care of our database? Well, yeah, but we have to develop us. Oh, great idea. Anyway, when you look for a job, you will always run into those issues. And since you're being here, I assume you already have some experience with open source. And it's perfectly fine to start developing that skill set at home or during uni or on the side in a job that does something else. We all did that. And it's much easier to do with open source than with biotech software. But there's also the way to go around and get some trainings, get some certifications. I think it's really, really important for us as a community, as an ecosystem, to get more people into the market, to get more people develop the skills needed with and for open source. That training is probably the best way to fill the needs we have. However, training and certifications are a tricky thing. Please, if you go for training with some of the software or even a certificate or both, make sure you really get what you need and not something that just looks nice. It doesn't mean that such a training, such a certification doesn't mean you're on par with some year-long open source experts. Obviously not, but it's a stepping stone, but only if it gives you what you really need. And the example I always use is, I personally have a business history in quality assurance in IT, brief one, but still. And the certification that was really important back then was ISO 9001, which is about the quality of the processes and so on, but not about the quality of the product. So that's what these pictures come from. You can build a life vest out of concrete. Anyone here would like to have a concrete life vest in case the ship goes under? Well, I kind of figure that. But for your ISO certification, the concrete one is easier to get certified because you don't need a return process. Once it's used, it's gone. Nobody is coming back with it and saying, I want to return it because it doesn't work, because it's somewhere down there. So at the end of the day, the certification has to work with what you want to accomplish. And also if you try to build, well, build up your team, if you're responsible for a team, make sure you test people if they really know what they're talking about, and not just get something for clicking a couple multiple choice questions. Like the guy who wanted to have a database admin job and after two questions, but obviously he never did that kind of work. And I literally told him, let's be honest, you never touch a productive database system. And he was like, what do we mean? Sure, I got the Oracle test server running at home. That I would call production. No, it's not. And unfortunately, there are certifications out there. Still are, that bring you into the same situation. So now, modern word. Everyone is moving to microservices or not, or moving back from microservices. Not sure where you guys stand there. The worst thing, if you ask me, is those companies using, still having those big monolithic applications and trying to attach something to it to make it look like a microservice application. I flew in yesterday and every time I'm at the airport and see those big ASCII screens they use there for rental cars at the gate, it's like, okay, so I don't care what the system behind that is. This doesn't look like a modern design. And it actually happened to me that I was standing at the gate, no plane there and asked them about the delay because I got a layover, a short connection. And she's like, yeah, yeah, no worries. It's currently landing. Okay, 15 minutes later, we start boarding. There's still no plane. Oh yeah, it's not here, it's over there. But when I asked her the first time, she didn't even know because the system didn't offer that information. The problem is you have that big monolithic application that does exactly what somebody expected it to do or wanted it to do way back when. And adding stuff is really tricky. Changing this, I was on the round table last week and talked to, interesting enough, somebody who used to work for a company that does software for airlines. And he said, yeah, they all have the same issue. We don't have the people around anymore who know the inner details of that software. So, refactoring the software is almost impossible. And starting from scratch takes, I see you're not in there, you have the same experience. It's an issue, it's a real issue. So, a lot of things happen by just new developments. But honestly, most of the microservice things we see nowadays are open source. All cloud providers use open source. Everything that's, well, Kubernetes-based, everything that's cloud native. I mean, the whole infrastructure below it is open source. There is no proprietary alternative. So in a word, we could say open source rules the world now. Already talked about the phones, same thing. Just that people most of the time don't know. You don't know what your vendor is using in the cloud when you use a software as a service. The open source projects have changed because we get more complexity into it. We get more advanced project structures. So that also means for you and for everyone, we have to learn more about the project before we can actually contribute. And that's where the foundations become more important again. But we also, and that's a very positive thing, you also have a community of companies now. It's not companies versus open source. It's most, for most of the companies, we want to be part of open source. Maybe we don't know how. Maybe there is some explanation, some training to be done for those companies. But a lot of them want to be part of it. Although obviously very important hobbyist projects still exist, somebody run into the Lock4J issue. I guess everyone did. And it's good, I mean, not that we had the issue, but it's good that we still have those small projects that run maybe by one person. We just have to identify those and help them with what might be needed in terms of security testing. But if everything becomes a big project that's only run by companies, we're too far away from the grassroots movement that open source used to be. We need to keep our identity. Otherwise, I don't think we will have the same vibrant ecosystem we have now in, let's say, 10, 20 years. We have different business models in use. I'm not going to read them all. You probably know more than that. The new ground rule seems to be offer everything as a service. And it makes a lot of sense for a lot of people and a lot of companies. Why would you set up your own database if you only want to store a bit of data? Or why would you set up your own system that scales up and down like crazy and pay for hundreds and thousands of systems when you only need the scaling up like once in a year, like Black Friday or whatever? The managed service provider is, again, it's not the rule. For everything you want to do, you have somebody who offers this as a managed service. Some of the other models might not easily survive. I'm personally, I'm not a fan of the open core model because either the core is not enough to give you real functionality, then it's not worth looking into, and then it's just not really open source. Or it gives you enough, then why should you, why shouldn't you go full open source instead of open core that doesn't really hit home with me? Obviously, some business model better adjust to the new world than others. I remember somebody, a product manager from Microsoft before Azure was public, we sat together and he explained the concept Microsoft was going to have with the, and back then 2012, 11, I don't remember when, back then he said, we are already absolutely aware that the most open cloud wins. That's why we want Azure to be as open as possible. And obviously I was running a service company then and somebody else at the table said, oh, sorry for your body because your business is going to go away. Why? Yeah, because Microsoft and the like are going to take over. No, they never did because they give you the infrastructure. They don't help you run the software. None of those service providers, well, none of the big three at least, will go into your database if you have issues with your data. They will make sure that your database is up and running. That's it, that's where they cut the line. And that's where other companies come in who give you the services, but also maybe their own solution where their services included. The success that was obviously around the globe from a country where cloud is seen different than in some other countries. The standard approach in Germany is more my data, my data center. I'm not going to put it onto somebody else's host. Doesn't matter who made up which one owns the host. But there are use cases where it really makes an awful lot of sense. The other thing we get now is there's container based setup, obviously with microservices. By the way, all those containers usually have a build on top of some Linux distro. And most of the ones I know run on top of Debian. So it doesn't matter what your software is you have in your container. It's all run on open source. The requirements have changed, yes. So for the Linux distro or general open source communities, it changed, we don't have to worry about the full server anymore, at least not totally. We can also have to worry about those minimal systems in the container. Other things we have to worry about too. I mean, like security issues coming from rendering. I personally think, well, we invented shut libraries for a reason and then we went to a rendering approach and do exactly the opposite again. Why? You go to systems and scan them and then you figure out they have 347 open CVEs and the only thing you need to do is rebuild the software with the latest version of whatever JavaScript or Node.js library they're using and they're all gone. And actually 347 is gross under estimation. It's probably factor 10. So what are we looking for when we go for software vendors nowadays? Exclusively open source, well, it shouldn't be open core as I just said. If they want you to pay for it and then open source is eventually, for example, it's just another version of vendor control, vendor login. You wanna see people who really know what they're doing. You wanna see experts. It doesn't mean they have to be committers, but you want them to know what they're doing and not just, oh yeah, I know how to install a Linux server. The operations have to run at scale, reliably, securely and performantly. It should be in the cloud and on-prem, depending on what you do when you look at the software as a service solution. And the most important piece for me is there should be community engagement. I put it as influential on the slide. That doesn't mean they have to, well, decide where the project is going and how. But it doesn't mean they have to play a major role, a bigger role in the community, not just leaching the software, but also able and willing to fix bugs that you might encounter. It doesn't matter which software you use, they all have bugs. And if your software provider, your service provider, has those bugs and fixes those, it's exactly what you want and what you need. If they say there's nothing and just wait for the community to fix it, yeah, good luck with that. And that's it. And according to my timer here, I'm exactly on time. So any questions, any comments? Nothing? Thank you all.