 Okay are we good to go? So this presentation won't be that technical. It's more about why open source and what you should do or should not do or how you get, how to get most of it. Let me first start by introducing myself. You see from the year numbers given there that I'm kind of no-timer. All those dates are when I start from when I started really developing open source software. It's not from using a software before. So literally I started doing all this before the term open source was even there. And now, busy running a company, as I said, purely open source. We're completely focusing on open source. We use open source internally only. And the basic idea that we have and I don't want to bore you with details is to offer all the services you expect a software vendor to offer for their own software. We offer all those services for open source on an SLA. Postgres, of course, being one of those, and yeah, we briefly touched the topic of Postgres Committers. I'm another one, so there are two of us in the room right now, right? So, but let's go into media's rates. So, how did open source really, in general, open source, but Postgres in particular, of course, make it into corporate IT? So let's start at the beginning. Yeah, I tried to find the beginning. This is probably a bit too early. No Postgres on these systems. Okay, let's step on further. You know these guys. There are a couple, but most of you are younger, so you probably know him, right? Recognize him? I actually don't know if Richard is still active. I haven't met him in years. I don't know. But he would be mad at me right now because I talk about open source. It's free software, right? I assume that most of you know there are only subtle differences, and for this presentation, I just go in and use both terms as a synonym. Those differences don't really matter here. Okay, so let's start with the real beginning of Postgres. This is Berkeley. For those who have been there, the clock tower of the university, which is where Postgres started and was started by the guy in the upper left. That's Mr. Professor Stonebreaker, who before Postgres did the Ingress project. Anyone ever worked with Ingress? Wow, three. So the open source version that was there briefly, or the one that was commercially distributed? I assume so. So what happened is he created Ingress roughly at the same time when Oracle was started as a science project and then spun off a company first called Ingress, I think, then Relation Technology. I don't have the full history available. But anyway, after that, Stonebreaker decided that he knows enough about relational database, or we'd know enough, and he wanted to go the next step for object relational databases and started Postgres as a Post-Ingress with the query language of Postquel, because Ingress query language was 12, which is essentially the same as SQL, just different words and different syntax. But anyway, so the project ended in 95 with Berkeley creating a SQL interface, and then they gave it out as open source as most of the stuff they did. So the picture up to the right are the first six that came together to take over Postgres as well, the initial team. And last year, three years ago, when I prepared for this slide, I actually checked out commit locks and found out that there was somebody in between those six who was available for a couple of years only and then left, and the first one who got commit rights to the source code after these was me. And now I'm very careful using that because I use it for my university class and told my students about it, and then found out that they spent the whole semester calling me number seven. It could be a worse number, I mean, they could have said 007, maybe, whatever. And this picture, I don't know which developer conference it is, Simon, do you think you're on there? What is that, 2006? I guess it's 2006 or I wasn't there. You were? Yeah. So just to give any comment, this is 10 years old, and this is like the developer community we had back then. So it's grown quite a bit. Just another short slide about the history. I think we already touched that one. So now let's have a look at how it made it into the data centers. I actually tried to find some routing platform to get from Berkeley to somewhere in the Silicon Valley, and I was really surprised because I wouldn't use this. I have to check that. That's Dumbarton Bridge, whatever, because anyone ever been to San Francisco area? Nobody? Well, yeah, you are no. So if you ever do, you're probably to take the road over Bay Bridge and make a brief stop at Treasure Island to see the sights of San Francisco. If you don't have enough time to stay there for longer, at least you want to see it. But it could also be there's a roadblock, whatever. This might be the highway, the best way to get there, but it doesn't mean this is the way you're going to drive. And that is exactly the same thing that happens with open source when it comes into IT, into corporate IT. It doesn't always take the high road, but it arrives, it is arriving, and it has arrived, and a lot, if not all, that is. Let's start with an early adoption. This is a schema from a project we did in 2003, not related to databases at all. It's a, as you can see, security filter, it's called, it's filtering, it's supposed to filter emails and web traffic for spam and viruses. And the first customer that contracted us was really eager to get something that's very stable. It's a German meteorological service, and they send out storm warnings via email, even back then. So the system has to be up and running all the time. And interestingly enough, yeah, they check outgoing emails for spam as well, for whatever reason. So we set that thing up. It's a huge cluster with a lot of different systems, and now 14 years later, the system is still up and running. Obviously new versions of the software, new hardware and everything. But as a system, as a whole solution, the total downtime of this thing is zero. We never had a single second of downtime. And everything, every single piece here is open source. So just grab the pieces of software. This is built on top of Debian, try to choose the solution you want. Grab the software, install all those pieces, and you get exactly the same solution as this one that's running for the German government. And that's the advantage that open source in general gives you. What happened then is we started out with more or less the communication side. I mean, all of the even infrastructure in the internet is essentially open source and has always been. People went to web servers. Through the web servers, they started doing programming on the web with Perl, Python, and some which are open source again. So we finally got to the point where we had open source applications that were customer facing. So essentially moving up the stack and then open source started to move down the stack again. Finally arriving at databases, which we are here for, and maybe even ERP systems. There are open source ERP systems not on the scale of an SAP or Oracle ERP, whatever the name is. Anyway, I think it's fair to say open source has made a big impact. However, it still faces controversies. And I spent some time in a random project meeting in my IT department. I saw quite a few objections being made by people. And inside this presentation, I would like to have a look at those objections and see and discuss whether they are blessings, or causes for us as IT people. And for that, please, if any question or if any comment comes up, feel free to interrupt me. It's not about me telling you and then at the end you come back to a question, just let's do it while we're talking. And let's start with the topic of security. Now, this is probably an open transport system. Whether it's safe and secure, ah, not so much. Years ago, security was considered a liability for open source. Actually, it still is by some. But there are studies among decision makers in IT that show security is the number two reason why they went to open source instead of proprietary software. But still, up to the day, I myself, again and again in conversations with people who are not really in open source, who tell me, well, it cannot be safe because the bad guys can have a look at the source code. So, yeah, that's right. If you have classical proprietary close source software, neither the bad guys nor the good guys see the source code. So, neither one can see the bugs or find the bugs by looking at the source code. The one thing I don't understand is why do people go in and only see the advantage that the bad guys cannot see it, but not the disadvantage that the good guys cannot have a look at it. I don't get it. Yes, we all know they would still find bugs in this close source software. In open source, it's different. Well, this is called Linus's law. With enough eyeballs looking at the software, all bugs are shallow. So, if you have enough people to check every line of code, you will eventually find all the bugs, which sounds great, which in fact is true, but nobody, even all the communities, don't have enough eyeballs. So, we still have vulnerabilities in open source as well as in close source. But we find more vulnerabilities in open source just because we can check. We can see it. Somebody is working on a patch and sees some other things for a better moment. That doesn't make sense. There could be a problem, tries to exploit it, find out, yeah, there is a problem, fix it, that's it. And if something gets found, the bug fix is way faster. And there's a lot of proof on this in studies and all over the internet that open source projects are way faster in releasing vulnerability fixes than close source software providers who may or may not accept or admit that there is a bug first step. While open source communities will talk about it openly and make sure the fix get out ASAP. But does it really make a difference? Is it really something we have to think about? Because we even proprietary software vendors use open source, all of them do, because they don't create the whole finished product themselves. They use open source bits and pieces. And yes, they also acquire software from software vendors, maybe at the other side of the globe. Who knows? And they might have used other open source pieces. So at the end of the day, we still have open source in literally all the products that have software. There are well-known examples of companies that had the policy of no open source at all in our software until they were sued by somebody for a license violation for the open source software they had used. They didn't even know. In general, open source for software vendors is a blessing because it enables them to get to market faster, to develop faster, to be cheaper in the software development side. Why should you reinvent the wheel again and again and again? On the other hand, as I said, there are companies who don't even know what's in there. And actually, I'm pretty sure a lot of companies don't know all the pieces in their software. So it's also a curse. You have to know where the problem is, or if there is a problem, or else you cannot fix it. And that's the other piece of the curse. A lot of software vendors might know what they have, but they don't have a process to fix problems in their open source components. It's easy for them to create a new version of their own software. But just the thing about it, you use a library version two in your software, and when the vulnerability comes up, you're on version five. What will the community do? It will release the version six, which has all the new features and the bug fix. You cannot even easily use version six instead of version two without a lot of testing. So you need a fixed version number two. And most companies I've spoken to so far don't have the processes in place at the moment. In general, as you can see, put some up here. There are definitely advantages for using open source. We use time to market, lower the cost for a couple of things, and safe developments for the unique functions, for unique selling points. You don't need developer resources for developing commodity that's already available. With the licensing, yeah, there might be something like licensing costs in open source as well. And there are also licenses. Even an open source project has to worry about this, especially one like us that is under BSD and wants to use all the freedom that's available that means we cannot rely on stuff like lip-read line and GNU because that's GPL. So we cannot bring that in. Again, there's a blessing of the license situation because it's really effective and gives a lot of people a lot of opportunities. But there's also a curse because you have to worry about legal aspects and so on. Just a brief word. There's another way of protecting your intellectual property and that's the patent. But in general, hopefully nobody really has connections to software patents because open source and software patents don't really mix well. Open source is about collaboration, right? It's about being open with each other and developing stuff together while the patent is the opposite. It's about keeping your ideas for yourself and don't give it to anyone. Don't even tell people about your ideas unless you have them written down and the stamp on it that you get a license fee for it or whatever they call it. That was one too many. But back to the license thing. As I said, open source usually comes without a license fee. Yeah, there might be a subscription fee. There might be a maintenance fee. Depends on where you get it, but you definitely can get it from the community directly and then it comes without any license fee. However, is that really what you want or the main focus you're looking at? I don't know. It's a bit of cost, yes, but this is that much. Most of the other services around it or the other work you need, you still need developers, you still need DVAs and so on. And roughly that will be the same cost. However, what you're looking at is the total cost of ownership. You will save some on the licensing side. You might save some on the hardware side because you need less. So it will be cheaper. However, you have to get there first. Getting there means you have to migrate your existing solution, probably, or you have to set up a parallel environment and start all the new solutions you're working on on a different environment. You have to invest in people learning about it and so on. So this is measured as what they call the return on investment. So the basic idea is how long how long does it take until those benefits I get from moving to open source or any other investment, of course, are higher than the cost I have for making that step. Or in other words, does this migration make any sense financially? Obviously, there's no general answer for that. But I do have some examples that I'd like to show you and I have to admit I use the very simplified calculation for that. So instead of talking about a yearly license fee, I brought it down to a monthly number just so it makes more sense. And I forgot about everything but the license and the migration protocols. The first case, this is the one I'm really unsure about whether to bring it in a presentation or even worse in a customer situation because nobody tends to believe it. But I did the consulting work myself so I was part of the migration myself and it's really true. Should I stop moving around? That customer had a problem with their existing database so they had to do something anyway. They already knew about Postgres. Actually, their DBA was the one saying, couldn't we try Postgres instead? Couldn't we bring a consultant in to help us try out if Postgres works for our situation? They were using a middleware that supported Postgres. They were using only standard data types and standard SQL types and everything. And it turned out that the problem they were facing in their old database wasn't in Postgres. So they had a kind of a performance problem that you couldn't tune away because of the way their optimizer worked. And the Postgres optimizer was able to optimize it in a correct way. So the only thing needed was they had to change a small thing in the parser because of capital letters or not, a lowercase. And then they had to migrate the data over. So except for the work they did themselves, it was one day of consulting and one hour of work for creating the Postgres package that accepts their source. That's it. Obviously, nothing to talk about because if it takes you one day and one hour, the return on investment is immediate. You stop paying the license and that's it. The second case was about a retailer with roughly 600 installations. And they had a database server in each of their shops. So a very small license, they only had to pay like $5,000 per database license for a relational database. It's an older case. It's a very low number. The upfront migration cost their software was self-developed, was all their own software, and they could change it as they saw fit. The migration of the software and the work they had to do on the database side was roughly 150k. And it cost them another 2k per database server to really roll it out. They didn't push it, but every time they went to work on the local installations, they just replaced the local installation from the old database to Postgres. And if you do the math, it's essentially a two month time for the return on investment. It's fairly fast. And then there's another one. This one is even bigger. 1800 database installations. It's a different database system here, but it doesn't really matter. The cost for each installation is fairly cheap, the license cost. And the migration cost, as you can see, is very high. It's one million. However, they were rolling out a lot of new versions or a lot of new databases in a month, and it took them only eight months. And seriously, we did a lot of math on Postgres migrations and other migrations, be it monitoring, be it VPN, whatever, all over the place. We haven't had one single migration with an ROI larger than a year. So there is literally not one that didn't bring in additional money to the company after a year. But it's not only important that the investment pays off. You also want to make sure that you don't have to do the similar investment again in the near future. Like for example, as Simon mentioned, when you invest something into migrating the database to something that again locks you in and you have to invest again to get out of that vendor lock. You don't want to do that, right? That's why open is so important. And this situation is called, in financial terms, it's the security of the investment. All the decisions you make when deciding which software to use should be all the business criteria, but all aspects. And please be fair with it, because I've seen too many where some costs were considered as mal. They're not regarded on the proprietary side as in, well, we do that anyway or whatever. One more word about being open. It's not just the source itself. It's also the format, the standards, and so on. Do you know that there are already files available that nobody can read anymore? Not because they are corrupt, but because nobody knows what the format is. Some old Amiga files company went bust. The documents were lost. So if you still have those files in your backup, gone. And I don't know when the company went bust. Maybe it's 30 years ago. There are countries that have laws that you have to store your data for 50 years or longer. How can you do that if you rely on any proprietary software without having the format? Another thing is with your software itself, when you write SQL code and you stick with a standard, fine, you can move from one database to the other easily. When you go to whatever database it is you're using. That's not post-cost. I bet you're probably using some proprietary add-on to SQL. It's not the standard itself. And that makes it more difficult. That's why we had those migration costs in those projects. So it looks pretty clear, right? Open source is a real blessing because everything is open. You get the document format. You get the standards and everything. But not so quick. There's another problem and that's compatibility. It's nice that the open source formats are open. If nobody else uses them, you're stuck with the open source people. It would be a great situation if all the world was open source. Let's say in the office world if everything was on open document format, great. But that's not the way it is. And it doesn't help you if you have XML, if people put binary blocks in there, for example. So again, it's a two-sided sport. Next thing, the updates. I guess we've all been in a situation where we wanted to update one piece of software, but we had a different piece in the same system that prevented us from the update. Like you have a library and you have two services running on the same system and the one demon needs library version A and the other one needs library version B. It doesn't work. There has been a case a couple of years back when a bank had seven different versions of the same library on the same server because they all came in with some software they acquired. And eventually one of those library versions was used by the wrong software and the old system crashed. It was done for a couple of days and just imagine how much money that means in losses on an investment bank server. So it's a real problem and you have to be really careful in the proprietary world or you cannot upgrade at all, which again is a real problem if there's a security vulnerability that requires the update. In open source, no problem. Worst case, you recompile the software yourself in a way that it allows you to upgrade. So that thing is not there. However, again, it's not just a real blessing. It is a blessing in terms of protecting the your investment. But it also occurs because you need to make more decisions yourself. You need to be informed more and you need to have more resources available. Speaking of which, the resources thing and the special expertise missing argument. That's one thing I heard quite a bit. However, it essentially says we cannot use anything that's new. We have to seek with the same version we have, even if the user interface changes. We cannot use that because we don't have the expertise in the new one. And that's the thing that drives me nuts that people accept they need training for a new version of the software they already have, but they don't accept they need the same amount of training for getting a new software. I don't get it. And frankly, training an Oracle DBA to become a Postgres DBA is easy. Give him three days or maybe five and he's good. That's not a big deal because the concepts are all the same. It's not a huge difference. Unless, of course, you want to go into real deep, really deep into the project and want to start getting involved with the community, then you should know a bit more than just in quotes the DBA stuff. For all, for everyone using open source in general and Postgres in particular, it's good to have you work with the community. As we heard earlier, that should be the goal, right? However, it's not the standard way of acting in a proprietary software world. So you either have to learn how to do it and liaise with communities. And that takes a while. That's not a three day training course. It takes a long time to get to learn all those processes and behavior and so on. Or you have to hire people like Simon or like us to do that for you to be that DBA sort. And you can use people like us to even create new features. It's not just about helping you run the software. It's also about you have the influence. You can work with developers directly or companies or service providers to work on the software side and help developing features or test new versions. The big difference on service and support side in the proprietary world, you can always go for the vendor as a last measure or whatever. The vendor is always there for supporting your software. In the open source world, you cannot go to a vendor because there is none. But you also need not go to a vendor because there are different options. So you can go to one company, have them support your installation. And if they don't do what they claim, if they're not satisfied, well, you go to the other for the third one or the fourth one. It's really, really important that Postgres is a real community and that there are more than one or two companies supporting it. So you get the freedom of choice. It's not like a lot of the newer open source projects that are driven by one company or that other so-called database system in the open source world that's driven by one company. You don't have the choice there. It's still open source. But there are not that many providers available. And also, please check with company you work with. I've seen over the years and in different countries, I've seen a lot of companies who claim to know a lot about open source and don't. So it's fairly easy to talk the talk, but check first if they are able to walk the walk. The other advantage is once you get into working with communities, you get to know these people. And yes, wait a moment, did I skip? No. So for us as a company, being involved with all those communities is a great hiring tool because we know these people already. Speaking of knowing people or open source developers, the open source world has, well, they say open source developers are freaks. Most of us are considered, well, not exactly your standard John Doe. However, we don't differ from the closed source world. Software developers are a special breed. It's very interesting because it seems we all are software people here. I did this same slide on a conference like a year or two ago where a lot of people brought their spouses. And you could immediately tell which one of those were working in the software industry and which one were the spouses because when I said that, half of the room was like, yes. Yeah, but I think it's not about that open source people are so special. It's about computer people are different than some others, whatever. But, and that's the last and most important piece to that. They are pros. They are professionals. They have paid for their open source work. They can be hired, contracted, whatever. It's not that they are like students sitting at home, having nothing better to do than hacking on the source code. And then when they find something better to do, they drop it. Actually, I've been in a situation with a prospect where they brought me in to present Postgres as an alternative to Informix. And they had a large audience in the room, in the room. So I gave all the speech and showed them the advantages. And then we had a discussion. And at the end of the day, well, eventually we came to the end, one guy stood up and said, well, I don't believe this open source thing works. Why? Yeah, because once these developers develop a social life, they are all gone and nobody cares about the software. Okay, so I'm married. I have three kids. I kind of consider that a social life. And he said, yeah, maybe, but I don't trust it anyway. And that's it. The German government, they made the decision to buy new licenses from Informix because of that one argument. There's nothing you can do about it. And I'm pretty sure all of you also have a social life. And you're still doing open source. And this is actually a study done by a professor. He checked. I'm not sure if it's it's not about all of open source. It could be just the colonel or some other major cogent. And you can see the red one is people who are partly paid for their open source work. So they also do some more on the side. The yellow one is they are paid 100%. They are only paid for developing open source. And only the blue are pure volunteers. And I'm pretty sure that the red piece is not because they only paid like half time for their open source work. But it's because sometimes you have to do stuff that the company needs as well. And that's not pure open source work. But most of us in November position where we are have some way or the other to work on open source. We all belong in there. So it's not standard fiction. And that's it. Nobody interrupted me. Does that mean nobody has a question or a comment? Okay, thanks.