 Good morning everyone. I hope you're not expecting too much of a technical presentation here. The reason why I came up with the presentation before I start is actually twofold. I didn't ask me anything in one of those virtual open source summits and it immediately turned to the history. And yes, as you can see, I'm an old timer here. Oh, can I move around? So as the slide says, I have more than 30 years of experience with open source. And people started asking about, how did we come here? And then I did like a podcast about specific topics. And again, we drifted up to the history and I figured maybe it's of interest, especially when you're new to the open source world, fairly new, to learn a little bit about what happened prior. I do not agree with Corey, by the way, if you saw his keynote, that the past is always better. Every new generation has their own ways. And I think mostly their own ways are better than what we did. There's a reason for that. But it makes sense to know what was before, so you can find the right ways. So how do I, oops, bring intro. The dates you see here is when I started developing actively on these pieces of software. I used free software as it was called back then before I started developing it. And I'm still active. I stopped working on the Linux kernel, but I'm still an active Debian maintainer, no, developer is the name, and the Postgres, I'm actually a committer in Postgres. So as much as my time permits, I still do that. Oh, sorry. That is the other one. My history, as you can see, if you compare the dates, I did quite a bit of my free software development while I was working on my PhD, classical way. But then got into business, ran my own company for 23 years, actually, and then merged with Instacluster, who were then acquired by NetApp. So right now I'm with NetApp. That's for marketing. There's no more marketing in this slide deck. No worries. So how did it start? You can see the picture here. It's actually from the thought of Postgres. If you can see the starting point, it's Berkeley. The ending point is something the software put into Silicon Valley. I think it's Mountain View, not exactly sure. No idea why. It might be a data center, but it might be something else. It's what the software decided. But the thing is, it started in academia. Quite a lot of the work started at universities. Universities were used to sharing information, collaborating. So it was a fairly normal thing for them to do. Again, back then it was called free software, open source. Well, the history is not clear more about that later, but the open source term wasn't used. Maybe it wasn't even coined back then. It also was a completely different way of collaborating. Keep in mind, we're talking about the time where we didn't have the World Wide Web. Yes, we had an internet. We could send emails, but that's about it. We had news groups. That's it. We had FTP servers for exchanging data. There wasn't much about distributed software development. Literally, there was nothing. But people got into it mostly because it was the hobby. They liked what they did, and they did it together. On the business side, in the early years, yeah, there was not much focus on licenses. It wasn't that many companies went into it. There was the odd one that really put a lot of effort into the open source software they used. And there were obviously some companies that focused completely on the topic, like Linux distributions. And some open source projects became the fact of standard. Like Apache was always the major player in the web server space. Yes, a lot of companies back then used Microsoft's web server when the web started, but still Apache had always like 60% and more market share. Interesting side note, at some point during that time frame, doing or creating firewalls using just built-in features in Linux was a major business. Just to give you an idea, people were selling firewalls, literally a single PC with a Linux pre-installed, and then whatever it was called back then, the internal now IP tables back then was a different solution, configuration to make sure the system keeps your network safe. And they were selling those systems for six-digit figures, because nobody else knew anything about it. Most users, most companies didn't believe in open source. I remember having lots of conversation, even with my own boss, where he said, yeah, it's nice you did this firewall for us on Linux-based, but it has to be Microsoft-based. And why? We're not selling firewalls. Yeah, but still, it's what the market wants. Yeah, but it's not in our business anyway. So for a lot of people, it was like some new idea, some crazy idea. They really didn't get into it. And then the turn-free software created issues up to the point, actually back up to like the 2000s, to the point where you get a call as a company serving the market. And people tell you, actually, it was a municipality from like an hour away. Yeah, we got this free software print server here, and it doesn't work. Okay, happens. What do you want me to do? Yeah, you have to send somebody to fix the system. Sure, why not? How do you want to do that? Shall I send you my rate sheet? Or do you want to send back then still a fax with an order or whatever? What do you mean? Yeah, well, it's service. So you have to pay for it, right? Or why it's called free software then? So people really thought it was free as in beer and not in speech. Back to the open source world, the communities were loose. People were working more or less on their own needs. But they were coming together for the greater good. So it's not just about, well, most people went about, let's create something that disrupts the market. It's more about I need this piece of software. And if I want to use that, I can also use these pieces. And somebody else had a big interest in these pieces. So we just put it together. Version control, as I said, distributed version control wasn't really available. Actually a lot of projects went in version control at all. Even packaging, as we know it by now, well actually used to know now we're doing containers. But even before the classical packaging wasn't available. The first Linux distributions worked with tar balls. You get a tar ball, you unpack the tar ball, it overwrites everything you had already. If a file name changed, you still had the old file name in there. You had to redo the configuration and so on. All the packaging that came afterwards was a result of people figuring out there are deficits. And then came the dot com time. Anyone here actually lived through that period and did open source or did software back then? I figured. Again, we renamed it open source. Bruce still claims that he coined the term. His story is not really clear. Bruce Brown said that is. But anyway, they decided to use it more often. Software became a real alternative, the open source software, in some areas. It wasn't that we could use open source software literally for everything. But for some areas it was an alternative. And more companies, especially IT companies, got into it. We saw the first paid developers. Nowadays, it's fairly common that you can make your salary doing open source development. There are a lot of people doing that and a lot of companies paying for it because it's needed. Back then, it was a new idea. And what's what happened is companies were open sourcing their proprietary software. Let's get navigator was, I'd say, the first web browser. Star office back then is still in use more as open office or Libre office, but it's still the same based on that same software. On the business side, again, big step for companies to go that route. We're not talking about companies that were created as a .com company as an offering web services. We are talking about traditional companies that already did proprietary software and then open source it. The rest of the world, not exactly at here, but in general, started with less important systems. Hence the picture of the satellites. The satellite systems were the first that were moved to open source and new developments. Back then, almost nobody trusted their major internal database to an open source product and maybe rightfully so. But with the .com development, business models came up to monetize open source. Originally when the whole movement started, people were like, okay, so this doesn't, it must not be for money. But why not? Why shouldn't you make a living out of selling open source? No problem with that. So startups were built with and around open source. And actually a lot of the new market, the tech market startups, were using open source. Some of those companies were well too early for their own good. A couple years later, they could have been big million dollar companies, but they were too early because the market wasn't there. And sometimes the business model didn't fit the market. I remember talking to a CEO of a big services company that had the strategy to hire each and everyone who knew something about the open source software. And then once he had, obviously raised money before, and once he had these guys on staff, he was looking for contracts so you can use them. Obviously, very risky business proposition didn't work out because there wasn't that big a market available. Nowadays, I think that company would fly, but it didn't survive long enough. But with all the expanding open source area, also the community has to have to change. We had to invent processes that open source didn't have. Originally, when I became a Debian guy, I sent an email to the project lead and said, I would like to work on Debian. And here's a package that in my opinion is missing. And he replied back, non-encrypted email, use your account information, please change the passport. That's it. At the end of the day, this is not enough. We got into a position where too many people got into the internet. Too many people tried to develop open source and got into that topic that you couldn't vet them all. You couldn't check all the software. Yes, enough eyeballs, all the bugs are shallow, I know. But somebody has to be there to check all the contributions. And that wasn't possible. So projects had to start developing processes to check identities, to make sure everything is encrypted, to make sure somebody cannot pose as somebody else and upload some malware and so on. Also, now this might be my personal opinion, the license issue created or the license situation created more processes. When you're in a GPL situation, a GPL project, usually those projects don't have that many processes and that many guidelines because the license already gives you the guidelines. Now, if you're in a permissive license, you need a lot of implementations. Oh, by the way, I forgot saying that in the beginning. If somebody has a command or question, feel free to ask now or during the presentation. I don't mind being interrupted. It's probably easier than if you have to get back to the topic at the end. So what happened at that time and why we had to do it is very simple. The bad people, the black hats also started getting into it. So we had to make sure the software is on a certain level and security had to become an issue. But with open source becoming such a strong movement, proprietary companies had to find a way to compete with it or against it. And I call this the fear uncertainty and doubt years. It's not an official term, but this is what we experience in the market as the standard strategy by some of the bigger players. We saw contributions by companies. Back then, I was running my own open source consultancy. We had in that time frame 10, 20 people. A lot of the work was building awareness. People started to become interested. They saw press articles. They saw, well, didn't have blogs, but websites describing why it's good. So they wanted to do something with it. I had no idea how it works and didn't really understand the whole movement, the background behind it. But also interesting at that point in time, the we take ideas from each other thing became a two-way street. Originally, the open source software kind of implemented features you could see in proprietary software. You look at what do the others do with the market leaders and you develop features in a similar way. In those years, in the early 2000s, mid-2000s, we saw a lot of developing going the other direction. There were actually patents by proprietor or by classical IT companies that quote some open source email or email from open source mailing lists, where somebody proposed this idea as the best way to solve the problem. And then the company snatched it and patented it. Okay. Now we can talk about how patents do not work with open source, but that's a different topic. But it shows that a lot of talent went into open source and a lot of ideas went into there that the traditional IT software companies realized there is something there that we can use. What also happened is the systems became more complex. We're not talking about a single Linux server or Linux system as a firewall anymore. We're talking about complex setup. I used this schema here in the picture as an example. This was one we did in 2003. It's called the open security cluster because we had the German meteorological service. They wanted to make sure they have a system that filters email for viruses and spam. And because they send out their storm warnings and everything via email, they also had to have it filtered for outgoing emails. The one thing I'm really proud of is that system now obviously in its, I don't know, fifth generation, different hardware, different software to the day, 20 years in existence has a downtime of zero. The whole cluster has never been down. They never went without functionality, not even for a second. This is something you can get with open source. Now whether you can get it with proprietary software now, maybe, were you able to do it back then? No way. There was this guy from a proprietary IT company who proudly told me, everyone else in the room, that they were selling their software and guaranteeing uptime of 90%. Like, wait, seriously? And your customers buy that? Yeah, sure. But 90% means you can be out of service for more than a month a year. Yeah, right. But that's what people were accepting back then. Or not. And this shows why people went into open source more. The companies, the traditional proprietary companies saw open source as a threat. They saw their lost customers because of it. And back then, we did a lot of total cost of ownership calculations for different projects we did or quotes we wrote. And in all those years, I've never seen a single return on investment calculation that needed more than a year to return the full investment. So there was a lot of money to be saved by using open source. And at the same time, companies started to realize you get to market quicker, you get better talent, you get a lot, well, a solution that you can handle much easier. What happened on the proprietary side, obviously, is, as I said, fear uncertainty and doubt. They tell you that they put stuff into a format that say incompatibility on purpose. Like, well, the open office developers are just stupid because now that our office does XML, they should be able to have a 100% compatibility. Yeah, right, except that you put all your data into blobs and you don't publish the content of the blobs. So they still have to reverse engineer it. Oh, do we do that? Yes. Oh, I just remember I have to go. It happened again and again and again, classical way of traditional companies to work with something they have no idea about how to compete with. On the other hand, the open source world as a whole had to learn to speak business and to learn what does a business requirement mean. So we had to do a lot of evangelism, again, as open source people. And what happened is, and you see the picture that this is from 2006, it's a developer meeting, a Debian developer meeting. We also had to learn to talk to each other more. So the whole thing of conferences really started to increase. There had to be a communication going on there. As far as the explaining thing goes, what happened? Just another example of fear, uncertainty and doubt. You sit there like in customer meeting, they asked me to come in and tell them what Postgres is and how it's used. Like almost as many people in the room are here now. Everyone was like, oh, that's great, much better. We have to pay this amount of money for informants. For that amount of money, we can just migrate back away to Postgres, except for one person. And he was like, I don't trust this open source stuff. And I said, why? He had just a bunch of freaky students with no time at their hands, too much time at their hands. That's the way. Once they develop a social life, they're all gone. I was like, oh, wait, I got three kids. But that qualifies a social life. And he's like, yeah, it does, but I still don't trust it. At the end of the day, this guy won the conversation. And I later found out he was a contractor to do informants administration. So he just put something in front of the guy with a budget that you cannot really compete with. It's just bullshit, but it worked at least for a while. And then in, well, let's say 15 years ago, roughly, we got to the point where open source became a commodity. We are still working traditional and monolithic systems. Everyone knows those big systems. But I guess everyone still has a big, big system running somewhere. And when I look at the check-in desk at the airport, and just flew in yesterday, when I look at those displays, it looks like, well, I'm tempted to say the 80s or the 70s called them on the softback. So it's really old. It's a huge thing. But it still works, kind of. But we did the same with open source. So there was no different deployment. It was just, we can do big systems in Postgres. So we keep the big software we have. We change the database, for example. What happened is, but what also happened on the open source side is we became a better distributed, well, project or plural projects. Disability development model became successful. So successful that companies tried to get open source methods into their usual development processes. So the term inner sourcing, I'm not sure if anyone still does that with this term. But inner sourcing was a real thing. I mean, people wanted to use those methods because they figured it helps. It does create better software. It helps to create the software faster. I always liked the analogy. But people used back then to develop software was the so-called waterfall model. Probably pretty outdated, but it was still used by a lot of companies. And you all know what happens when you have a big waterfall. You create a lot of mist, right? I still like that thing because my native tongue is drum. And we have the very same word, mist, written into the same letters. But it has a completely different meaning. It means crap. So essentially, this is what the waterfall model software development creates. There is no return of information. It goes from top to bottom, and that's it. The way software development works in open source and what companies realized is we have to make sure people talk to each other. We have to make sure the users can talk to the developers. Maybe not direct because then they have no time to develop. But they need the information from the users. You cannot have enough Q&A people to get everything tested. You need the information from the other side. Functionality, as I said, still mirrors proprietary software. The community building had different approaches, but what really became a strong thing is foundations. Not just the Linux Foundation, obviously we're here because of the Linux Foundation, but also other foundations because that's the way for companies to pool resources together and to create a governing structure around an open source project, something that was needed by then. So back to my route from Berkeley to Silicon Valley, I still have no idea why the software had me go over that bridge instead of going through San Francisco. Maybe there was a big line there. I have no idea. But at that point in time, we had arrived in terms of open source wasn't in the data center. Literally in every data center. There was no company that didn't have open source somewhere. Some claimed they didn't. Some claimed they had like the policy or not allowed to use open source. And usually in those meetings when it came up, somebody around the table would say, that's not exactly true. We have this system over there in the back room, the end of the hallway. They still all had some open source. And also the companies that were founded during the dot com phase had become enterprises and really big ones. And most of the dot com things were based on open source or had a business model that used open source significantly. Just look at the hyperscalers we have now. Yes, Microsoft was already a big company back then. But Google was fairly new as was Amazon. And the hyperscaling side is all mostly open source. And also we got our first inroads into regulated industries. Nowadays, and I just saw you guys come in with discover shirts on nowadays, it's normal. Nobody wonders why a financial industry or whatever has some open source. Back then it was a big topic because of the regulations that you had to work with. And also what really became a thing was training for open source. Don't get me wrong, there was training before. But in that timeframe, it became abundant. Everyone was training. Companies realized there isn't enough talent around. We need to develop our own. We need to train people. And also, not everyone needs an open source developer. You don't need a committer for a project if you want to use it. My personal prime example is the database. I don't need somebody who can write an optimizer or a new index structure. I need somebody to manage the data inside my database. If for whatever reason the query gets low, I need somebody to figure out what's going on. It's a completely different skill set. So you can train that. So a lot of things happened in that training space. And also in certifications, I mean those two go hand in hand. It's nice to have a training, but you need the certificate to show that you did it. Before doing my own company, before going into open source full-time, I have a short history in ISO certifications in IT. And this is a real example. In ISO 9001, you can build life vests. And you get them certified if you build them out of concrete. So somebody would hop the ferry here and use a concrete life vest. I guess nobody would want to do that. But it's easier to get the certification with a concrete life vest. Because you don't have to worry about the return process. If it's used, it's gone. Nobody is going to bring it back and tell you it didn't work. Unfortunately, I mean, this is an extreme point. But unfortunately, we see similar issues or saw similar issues with certifications in the Linux and open source space. So it makes an awful lot of sense to make sure you have something that makes sense. But the demand is increasing. And just by seeing you guys sit here, shows me or tells me that there is a demand of getting into it, learning more about it, and getting into the area. So now to, well, today, cloud and microservice. Now we are in a position where open source is everywhere. And instead of that big monolithic stone, whatever, we saw earlier in the picture, we see a lot of pebbles. These are more or less the microservices. Right now, all the hypervisors use open source, more or less, at least. I mean, at one point, Microsoft was the second largest committed to the Linux server. And I remember talking to, before Azure was released, talking to one of the product managers at an open source think tank in Napa Valley. And he told me that they are well aware that the most open, the most open cloud wins. This is exactly the thing. Nowadays, you have to be open, not just open source, you have to be open. A lot of the stuff everyone uses is open source. I mean, not just probably your fridge has open source, your TV is open source. Everyone runs around with a cell phone that has some or a lot of open source on it. Kind of feels interesting to think about it, that you want to walk around with an Android phone and you think, well, there's a small bit of the software on that phone that I wrote personally. And it doesn't matter who uses the phone, it's always he or she, they are using the phone that I contribute to a little bit. At the same time, the complexity increased quite significantly. So the open source projects became more complex. We needed more complex structures. Again, the point where foundations became more important, somebody has to run things. And we now have communities of companies. We have some open source communities that don't have that personal developer. It's all companies. But we still have those important hobbyist projects. And need I say log4j? It can be an issue. But again, we have people and again, thanks to the learnings foundation to help out with securing those projects. On the business side, we see a lot of different business models. I'm not going to read them all to you. Some of those work better with the new microservice and cloud offering some less. Nowadays, the managed service vendor is probably the rule rather than the exception. There are models that might not easily survive like open core vendors. Some naysayers said the professional service approach wouldn't survive, but the contrary is true. The more we use this kind of software, the more we need help because we cannot have the expertise all in house or where we can. But it takes an awful long time and a lot of effort. Paper use models are now standard. So even the old license or subscription model is kind of dying out. The success, by the way, differs around the globe. Over here, I think everyone is mostly cloud. I come from a country that probably is on the low end because everyone thinks, oh no, cloud is not safe. I want my data in house. But we use the same technology. Those companies use the same technology. They just built their own private cloud system. What we have now is container-based setups. That means requirements for open source communities have changed. It's not just the simple thing of while we build something and throw it over the wall and let other people use it. It's about we have to combine things and make sure they work together. The issue with that setup and obviously the vendor, the container is kind of a vendoring setup anyway. The big issue here is security issues coming from that. Well, maybe not coming from that, but security issues coming up. That's why we invented or somebody invented shared libraries. There's an issue with the library. Yeah, let's update the library. That's it. Now you have that library in, I don't know, 500 out of your 1,000 containers, but you have to find out and you have to change those images. So it's a different set of problems. It's a different approach to solve those problems and both the open source communities and the ecosystem around it need to adapt to those issues. Last slide. I think I'm pretty good on time. What do you want from a vendor nowadays? This is really important. You want to have somebody, you want to work with somebody that plays by the rules. You don't want to see leeches who just use the open source software and don't care about playing with the others. Up to the point where people say, what do you mean with giving back? No, that's our business model. Manga actually told me once, I don't get these open source people. They are stupid. They give us the software that we can then monetize and sure we won't give them something back. And I was like, you should have at least googled me before because I'm one of those stupid guys and I'm never going to do business with you. No way. Really important in this area is you don't need the open source developer. That means for all of you if you're getting into it, if you're building an expertise, it doesn't have to be development in the community. We love to get more people into communities, no doubt about it. But it's also about knowing how to set up a Kubernetes cluster or how to run one. There is a lot of expertise that is needed globally in the market that's not there. And I'll just look at you, Tim, you have to train more people. And that's it for me. So nobody interrupted me, but maybe there's still a question. Yeah, thank you, Michael. We have a little time for Q&A. If anyone has any questions. Hi, so actually I work at Microsoft, as you mentioned Microsoft a lot. So yeah, it's very good talk. Thank you so much. So I have a question which is about, so Microsoft have its own pretty similar to the Kubernetes like this distributed orchestra system called Service Fabric, but they actually open sourced pretty late comparing to Kubernetes. So which actually not quite attracted a lot of attention. So my question is for the company perspective, what is the best timing for them to open source there? Software is as early as possible or specific business marketing kind of like perspective? Thank you so much. Yeah, usually the, let's say history shows that as early as possible is the right way. Just have the world contribute. Have all those beta testers out there. Just throw it over the wall, let people use it, but make sure you still develop it. As you mentioned, they were fairly late and now Kubernetes is the de facto standard. So what happens? I mean, I guess at 10 years from now people will only talk about Kubernetes and this Service Fabric will not be a topic anymore. We've seen it with a lot of other open source projects. It's not just about open sourcing. Yes, it's about doing it at the right time, which is as early as possible. Obviously, if it's not ready, it doesn't really make sense and you don't attract fellow developers, but maybe attracting those developers is not the most important piece. It's just give out the software, have people use it and attract users around it. We have a little bit more time if anyone else has a last minute question. My name is Jonathan. I'm an IT supervisor and I implement open source solutions whenever I can and I am finding as I keep putting out more and more services and it's easy to get things up and running and working, but then I find I could use expertise to secure it properly, to make sure to test these systems. Security is the main thing that I worry about. I try to keep it in house, but sometimes I need to put it into the cloud and are there, where should I go to? It's partly why I'm here. It's like to look for either, because you said you ran an open source consultancy. I'm looking for this. Are there good resources like that out there where I can call someone to call and be like, hey, can you come and look at this? Yes, there definitely are. It depends on what exactly you need and I still run the same team. Now it's part of NetApp, but I still run the same team. This is what we do, but there are other companies out there. Again, I don't want to do some marketing here, but yes, this is exactly my point why those service providers are still needed. You have the expertise of which application you can put to open source. How could you structure the open source pieces so they make the most sense? You know the processes you need, but you don't have to have the expertise about security, for example. That's where you get the external expertise or you hire somebody, but again, with external expertise, the only thing I say is check, like I mean, go back that one slide, check what the companies are offering. Just because somebody says we can do open source doesn't mean they can do what you need. And if they tell you we have five developers on X, Y and Z software that you might use they are unsecurity related. It doesn't mean those five developers have time to solve the issues. Usually these guys are paid to do software development for the project and they're not available as consultants. So it doesn't help you at all. What you should look for is the services company that does exactly what you need in on a day to day base. And there are a lot of companies out there. Thank you. All right. Thank you. Any more questions? If something comes up later, find me around here and feel free to ask me. All right, Michael. Thank you very much. Thank you.