 And welcome to the numerous audience here. Before I start, if any questions come up, feel free to interrupt me. Let's discuss more than me talking. And I don't like the idea of just answering questions after the presentation and then circling back to maybe slide three or four. Let's keep it open so if anything comes up, just a show of hands and I'm willing to take a break. Anyway, short history of myself. Yeah, I'm not just looking that way, but I am an old timer in terms of doing open source and free software. All these dates here are when I started as a developer. So I'm doing a lot of things for the more than 20 years now. And Asbrief, that's my professional background. Since 2000, working for a company, no worries. It's not a marketing pitch here just so you get an impression that I do know what I'm talking about, actually. So we are a company supporting open source, doing a lot of services for open source. Postgres in particular, but also a lot of other open source bits and pieces. And that not just in Germany where I come from as you can probably tell from my accent, but also all over the place, again on the list here. And let's directly go into the topic. So what I did is I had a look at what kind of market share we as an open source and general get. Started with a standard thing in email. And as you can see, on the left hand side we have the MTAs. On the right hand side is IMAP servers. Almost everything here is open source. Not really surprising because it's the internet and open source has already been very close, but still. The same holds for web servers. Assuming that the Google web server or web servers, I don't know, are more or less based on open source, if not completely. It's again like three of four web servers are open source. It's slightly different in databases, but not that much actually. Yes, Oracle is number one and we have Microsoft SQL with a large deployment base, but my SQL is almost as much. And Postgres, well, it's getting a fair share. It's more than DB2 nowadays. Everything below DB2 is not really worth mentioning. Two points there that I find interesting is that Cybase, which is not exactly an unknown database vendor and now owned by SAP, of course, is less than SQLite. And of course, I find it interesting that Informix doesn't even show up anymore. So the survey is, let me see, it should be on this. Oh no, no date there. I think the numbers were from 2012. I have to check that again. I couldn't find really up-to-date numbers on the Internet. I guess nowadays my SQL will be less. Postgres will be more. But in general, open source might be on the same level. We've done a lot of Informix migrations throughout the years, but nowadays we see more Cybase migrations and DB2. Anyway, to make the story short, I could simply say, okay, that's it. We arrived. We made our way to the data center. Open source is a big piece for business IT. And if that is what you're looking for, like the essence, you're free to leave, but if not, well, let's start at the beginning. Oh, that's probably too early. I guess nobody ever worked with this one in the room. A little bit later. Anyone here who doesn't recognize both? Okay. So on your left side, that's Richard Storman, kind of the founder of the free software movement. It's not really correct, but it's the one who really drove it forward. On the right-hand side, that's Linus Torwartz, the one who created the Linux kernel. And of course, there's this discussion whether or not it's a Linux operating system because most of the tools we use are canoe tools, and of course, canoe is where Storman started. So these two are really important for the whole free and open source software movement. Speaking of which, I'm not going into the details what is different between free and open source. I'm going to use both as synonyms. I'm well aware that there are small differences, but I don't think we need to discuss those now. So let me get another try. Finally, we reached Berkeley. I'm pretty sure that everyone who's here knows that Berkeley has some meaning for the Postgres world. But if not, here are some more pictures. That might be more difficult to find out who's who. Anyone knows who's that? The gentleman on the top left. You were in JD's talk, right? Yeah, that's Michael Stonbaker, the one who started the Postgres project. Back then, he was working for the University of Berkeley. He started Ingress first to find out what's possible and what we have to do on a relational databases. Right about the time that Oracle was started, actually earlier than that. And after Ingress, he figured we know everything about relational databases. We want to learn more about object relational. He started a new project called Postgres as in post-Ingress. And it's really post. There is not a single line of code that he took over. This picture here, these six gentlemen are essentially the first six of the community. The seventh, called Byron Nelson, who disappeared even before the picture was taken or before I joined. You might have seen Bruce running around here, where you certainly have. He's a bit older now. Jan is here. And Vadim was here at least on Wednesday. Before Wednesday, I've never met Vadim in person. And when preparing these slides, I checked the old commit logs and found out I was actually... This is some lane, the one who did most of the source code. And I was actually the very next one getting commit rights on the Postgres source code after. So I barely missed that picture. This is a developer conference picture from, I don't know when. A lot of people are here. I can see Peter here, Josh here, Joe Conway is somewhere there. A lot of these guys are probably here today. What I want to do with this slide is just show you... We started with one, well, academic project. And now we have just a couple of the developers who meet in, I think it was Toronto. And as you see here, the community is big. It's really big. The timeline just briefly already mentioned Ingress and Postgres. Not sure if you guys know that Stonebreaker actually managed to sell both, or make both proprietary to make both commercial. So there is Ingress, there was a company called Relation Technologies then acquired by CA and then brought back to life as Ingress again. And with Postgres the same, started a company called Delusqua that was then acquired by Informix. So a lot of the features we saw in Informix in the later versions were actually Postgres. So we started out with this academic project, created an open source community around it. But how did we make it to the data centers? So I figured, yeah, it's easy. Just get the route between Berkeley and some place in the Silicon Valley. If anyone ever tries checking that I have no idea if there's a data center. The one up on the top is really Berkeley. The other one is somewhere in Mountain View. I have no idea, might be residential. But anyway, I'm not a native of the Bay Area, but I wouldn't have taken this route. Being more of a touristy guy, I would have gone over Bay Bridge and not over what is it, the Barton Bridge or whatever the name is. Would have stopped at Treasure Island, or at the side of San Francisco. Maybe some locals would as well, roadblock, lines, traffic jam, whatever. And that showed me one thing. Open source is absolutely similar to that. It doesn't always take the high road. It's not the easy way just straightforward. But as open source we did arrive in the data centers. Let me give you a little bit of information about the history of how we made it. And speaking from my own experience, coming from a country that got into open source, I'd say five to ten years earlier than yours. This is a drawing from a solution we did for a couple of customers in 2003 by the first one. They needed software, or I'd say they needed a complete system to scan emails for spam viruses and so on, incoming and outgoing. And this had to be up 24-7, of course. One of the customers is the German Meteorological Service and they even send storm warnings via email. So they cannot afford to have the system down, not even for a couple of minutes. We created a full open source solution for that. All of the bits and pieces in there are part of the corresponding open source projects now. So if you install the software packages from Debian, from Debian Archive, you get exactly that. It's a whole cluster. And you might imagine... I mean, it used to be a big cluster and still is. One of the versions we have was supposed to handle 17,000 emails per minute in 2003. And just do the math and check back what kind of lines we had in 2003. That was quite a bit. You cannot get 17,000 emails per minute over a standard 10-megabit line. Not possible. Not even 100 is enough. So as I said, it's completely open source. We did the system integration and everything. Those systems are still up and running after 12 years. And I have to admit I'm really proud, not just on us, but also on the open source world, because this whole system has a total downtime of not, not a single second downtime. We did change all the software pieces. We did change all the hardware and everything. But the cluster, as it's such, is running for 12 years without it. Do that with proprietary software, with closed source software. Good luck. So what happened then? The early adopters doing that and stuff like internet infrastructure like emails always has been very much geared towards open source. What happened is open source kind of moved up the stack. So people started with the infrastructure like mail and web service. And then all the languages came up that people used to do websites like Python, Perl, Ruby, whatever. They're all open source, right? And so quite naturally, a lot of the web systems are completely open source, like e-commerce systems and everything. And then people realized, well, I'm trusting open source to run my shop. Why shouldn't I trust open source to run my data? So we went down the stack again and finally arrived at databases and of course what's the most important application there is ERP systems. So why has open source been able to make such an impact? There are some reasons from businesses. We asked our customers, but we also participate in the future of open source survey. You probably know about that, Mark, but I'm not sure if anyone else ever heard about it. These numbers are a little bit older. The current one has been run already. There's a survey run every year where you just get a web form and you answer questions and then they try to find out what's going on in open source and why are people going into open source and what should come next. Very interesting numbers there. So I think those are 2013 numbers and I just looked up the top three reasons why business went into open source and why business are using open source. Interesting enough, there's no item license cost there anymore. There are so many other advantages that bring much more to the table than license cost that people don't worry about that at all. Software quality used to be something like fifth place, 2011. It's now number one. It's interesting. Let me briefly go through those three points in a little more detail. Anyone here ever worked with this? It's a Commodore C64. Actually, my second computer was like a revolution. 64 kilobytes of data. Yes, that's kilobytes. The one before that had 3.5 kilo. One time I brought this slide up in the presentation. One guy approached me afterwards and said, I had tears in my eyes when I saw that old thing again. We used to call it a bread box. Anyway, it's one single piece of computer. Everything is solidly sold in there. There's no way to change pieces. Now just assume your database is like the memory. There is no way to get other memory in there or more than 64. If you need a more than 64 kilobytes, yes, you bought the next generation computer. You cannot change it. It's not flexible in any means. Just assume you're fine with that computer. Your software works well. The processor is fast enough. The audio is great. The video is great. But you just need more memory. Not possible. Simply not possible. Open source is more like this. Well, you need more memory. Yeah, fine. Put another one in there. We need a larger disk. Fine. Take out the smaller one. Put the larger one in. It's very easy. And as I said, it's the same for open source. If you run a system with, let's say, that ERP system, you have an e-commerce system on top and the database. And you want to replace your ERP system. You don't have to update the database at the same time or vice versa. If it's open source, worst case, you have to recompile it against the older version. But you're not forced to do anything. Which, in the closed source world, is not exactly the case, at least not always. In terms of render log in, this is not just about license and cost and closed source code. Anyone ever think about data formats? There are actually files out there that nobody can read anymore. There are files in a format belonging to a company that went bust. And now the documents are gone. There's no information about that data format. No way you can ever figure out what's in there. No thing about it as, well, there are government regulations, at least in Europe, where some industries have to store data for 50 years, 5-0. I have no idea. Anyone want to wage a guess how computers look in 50 years? Well, I guess that. I wouldn't want to. But we have to make sure that data is still there. How can we do that with closed formats? Even if it's a big company defining the format. So what? Big companies can go bust as well. So it's really, ridiculously important to have open formats, open standards. Well, probably a decade ago, I don't know, a while ago, I was doing some time on a trade show promoting open source when a sales rep from a well-known company approached me and talked to me about office software. And he said, yeah, the biggest problem, of course, with Microsoft Office and Libre Office is incompatibilities. You don't get the format as they should be. And he told me, yeah, that we got XML now. You, in my opinion, the open office or whatever the name back then was, developers are just too stupid. We have XML so they can just read it. I said, yeah, if your XML was open, but you're using binary blocks and you don't tell us what's in the binary. So even if it looks like it is open, it still isn't. Make sure that you're in a situation where you really get your data and keep your data and you're the one handling or making the decision where the data is stored. So you can move it as well. And the same thing, of course, make sure you use software that has a community and not one vendor who's just willing to give you bits and pieces as open source because that vendor might change its strategy as well. Wouldn't be the first time. As for quality, classical waterfall model, anyone here a software developer? Okay, so you guys know about the waterfall model. I hate it, to be honest. I don't think this one can deliver good software. And it's not really used in open source. What's the problem? The problem, a waterfall is a one-way street. You need people to do the requirements and then other people do the design. There's nothing in there that feeds back. So what happens, essentially, let's look at Niagara Falls, a real waterfall. You're from there? Really? Yeah, I took that picture, well, six years ago. But anyway, I would have loved to go there this winter to see it frozen. I only saw pictures of that. I would have loved to see this big thing in ice. What did they say? Ten stories high, the ice? Yeah, okay, there isn't this advantage of that. I admit. Anyway, what you see in the middle there, what the waterfall really produces is mist, right? Now, the interesting thing for those of you who don't speak German, there's a German word called mist, same writing, M-I-S-T. The meaning, though, is completely different. The translation to English of the German word mist is crap. I always find that amusing, a waterfall produces crap. And this actually holds for software development. Not always, but unfortunately more often than not. In open source, you have the option to be part of the development. As a user, you don't have to develop your own source code. But you can talk to the developers. You can tell them this is the way the workflow goes. This is what we need in terms of feature. This is what doesn't work. And yes, you're developing this software. We found this bug, whatever. Talk to us. Speaking as community. Talk to us. Help us making the most out of the software. We can only have so many test cases, right? And everyone who's working on PostQuest uses their own, usually even production databases, well, on the test server, of course, to try everything out. But still we're limited. But you guys have a lot more. Try it out. And then again, talk to us. Learn to collaborate with us. It gives you better software. It gives us options to create better software. It's a win-win. Brief word about security. It's very interesting because a lot of people call that a liability for open source. And I haven't heard that for a long time but I made my way to, actually, Saudi Arabia last year, where somebody brought up the old argument that software that's open is inherently insecure because everyone can look into it. Well, it's actually the other way around. Everyone can look into it and find the problems. And most people from the industries realize that. We've seen a huge, but how about you, Mark? Seen the same push? Absolutely, yeah. So we all agree. It's not just us as a company, but all the companies see that. That's where the security argument comes from, right? Yeah, right. There's a thousand people looking at it, not just five guys in Q&G. Giving enough eyes every bug is shallow or whatever Linus Wu was. Yes, you have to have a lot of eyes. But still, there are a lot of people. There are a lot of companies. And I mean, we all agree probably which bus to take if we want to take a bus. So the choice for business critical usage, I just brought up a couple points there. I'm not going to read them to you. There are a lot of points that people really like that you like when using open source. And there's a reason why license causes at the end. So let's have a look at the cost structure for running software. Because what you're interested in is not just license cost. What you're interested in is total cost of ownership, right? And this is, again, other data, but it's difficult to find the new one. How total cost of ownership divides on the software hardware training, downtime, it's the staff here, and Miss Angelus. If you were able to reduce the license cost to naught, you still only reduce the TCO to at most 7%. And that doesn't take into account that support and other stuff. You also need for open source is part of the license cost in that model. So reducing the license cost itself doesn't make a huge difference. You can get almost as much from other aspects like training where there are a lot of cases where it's easier to train on open source, on downtime, because open source in a lot of cases is more reliable. And also on the hardware side, because a lot of bits and pieces work on older smaller hardware. But the real huge difference is the staff requirements. You see it's like 60% is staff cost. And there's a lot under staff that you see here. A lot of things people have to do, and it really depends on how much work do you have to put into it. And a lot of these things make open source essentially cheaper, because you have to put less work into it. One problem is there are published results for that. How much you can save? But still a lot of people simply don't believe it. Or even don't believe that open source in itself is sustainable. I've been in that situation as personally, me, that people questioned the way that open source works. He literally told me, as soon as these geeks develop a social life, they are gone and stopped working on it. I was like, wait a moment. I'm married, I have three children, and I still do. Doesn't that qualify as social life? Yeah, maybe, but I don't believe it anyway. Unfortunately, that's the way it is. But of course, to get there and to figure it out, you have that way around. Most people don't start from scratch. So you have to find a way to get there first, which is migration of course. But the migration in itself is an investment, right? You have to find out how much do you have to invest on how much can you save, ideally in advance. How this is measured is the return on investment. Probably heard about that. The basic idea is how long does it take me until my benefits are higher than the costs. So I essentially save money after my return on investment. And we did some math there. It took a lot of migration projects we did, mostly databases, some are VPN or email, and kind of simplified it a little bit. Instead of having the license cost saving put into a yearly payment or bi-yearly payment or whatever, we put it on monthly payment. I'm pretty sure nobody pays licenses on a monthly base, but it makes it easier to show what happens. And as you can see, on the x-axis you see the upfront investment in terms of, well, those are euros. And on the y-axis you see month for the return on investment. So even if the external investment, so the investment they had to put into an external contractor was seven-digit, it's still only eight months until they recovered. And this is just the license cost. This does not include all the other advantages we have. And yes, the zero-zero thing is actually true. I've been personally in a migration that costs them an additional time one hour. So that's an immediate return on investment. Unfortunately, it won't go that way all the time. How do we get there? This is a list of, well, let's say bullet points. You should keep in mind when doing migrations. Some are very obvious like a capable manager or a solid planning base. Some are actually not so. Oh, well, that might sound obvious, but people tend to forget it like training and maintenance and support are involved. Redundancy has become better. The interim temporary and isolated solutions, not exactly. Did anyone ever put an interim solution in a system? Still running? When my wife and I moved to the second apartment together, the first boy was more and the second one wasn't, we were the first renters of that apartment. And for a couple of days, a fan in the bathroom broke. So we called them, they came in and fixed the spring that was broken in there on a Friday afternoon. Weekend comes, the fan doesn't work again. So we called them again, they came on Monday and the spring was broken again. And he was like, yeah, we didn't bring a new spring and we exchanged that the other day. So what he did is just get his pen out, open it, take the spring out and put it into our fan. It said, well, this should work for as long as we need to bring the right spring. We never saw these guys again. We moved out of the apartment after four and a half years and the fan never broke down. It's probably still working on that spring or the fan. This is what happens. And yes, it's nice, it works. But think about it, you might have to do a migration again. And then you have this isolated system that doesn't make sense or might not even be documented. Good luck with the next migration. Don't forget that. So these are more or less generic rules. When we go into open source, we have some, let's say, additional requirements. How about licenses? It's not really easy to understand, let's say, the underground of open source licensing. And no, it's not just for ISVs. There are a lot of situations where it might be important even for non-ISVs. There are situations where even using it on a web creates problems. There are situations for us like Postgres Project, we have to be careful. There's no way for us to accept GPL code, for example. Because once you put GPL code in, everything is GPL. It's interesting, well, for lawyers. Do we have a lawyer here? Oh, that's good. I talked about the same thing with the same slide on presentation last year in India. And you could immediately see when I started talking about licensing, I was getting these bright eyes, like, yes. Yeah, both were lawyers. They made a living out of it. It's a lot of things, and yes, you have to worry about it. I mean, basic incompatibilities are well known. So most of the stuff we have figured out. But that doesn't mean everyone has it figured out. So a lot of us simply choose to not care. What is important to me is there are two things that I really want to bring out to the public. There is no real license like public domain. Public domain is not a license. The only way for you, you, or you to put something into public domain is writing it and then dying. You cannot assign it to public domain. With one exception, by law, stuff done by the federal government here in the U.S. is public domain. But only inside the U.S. So if you take that software out of the U.S., it's not public domain anymore. And if you write software, put stuff in there saying put into the public domain, it essentially carries no license. And no license or no license information is the most restrictive one of them all. You're not allowed to do anything with it. And there's another point of protecting your property, and that's a software patent. While patents in itself are not a problem, software patents and open source don't really mix. The patent idea, or the idea behind the patent is keep everything by yourself until it's finished. And then apply for the patent and then give it out. And this description alone should tell you it's not what the open source world is about. The open source world is about sharing the software. And this is not just for the communities. The way open source development works has a great benefit for all companies, for internal processes. There are a lot of things where companies internally develop like a lot of different software again and again and again because you don't know that the other department already did the same, for example. You don't get the same, let's say, quality of software because you don't have peer review and so on. There's a lot of things you can learn from open source as a software development department inside a company. And we should also learn about open source is, let's say, procurement divisions. You see a lot of tenders that say, okay, bring us the software. We do our tests and if we decide your software is the right one, we buy it. That doesn't really work with open source. It's easy if they tender for a database because the database is there. But usually they tender for a solution. That means you have to integrate bits and pieces. And open source, you have to develop the solution, essentially. You cannot do that for a test case, right? But then after we did it, it's already finished. The work is done. So service providers. I kind of alluded to it a little bit that you're not locked to one. It's your choice. And I've seen customers really making the decision to change service providers, not because of, well, the service provider didn't work well, but just because they wanted to show their superiors it's possible. They're not locked in anymore. Okay, fine. As open source companies, we have no way of locking people in other than doing a good job. However, there are companies that only claim to be open source or claim to understand open source. And of course, there's the community itself. I mean, the community, especially for Postgres, is what the software vendor is usually for its own software. But that is also an analogy that's not really 100% true. So what do you do about support? Yes, you can do the community support. Easy. Just send an email to hackers and somebody will take care of it eventually, depending on what the content is, depending on the way you avoid your email. But you cannot get the community to sign an SLA. And when it comes to, well, communication skills between companies and open source, there are a lot of different ways you can do it. I mean, as I said, I'm still doing open source development myself. I get bug reports that are not in, well, I found this problem or I think this should run otherwise. They are like, this doesn't work. You have to fix it now. Why? You're not paying me. So why should I fix it? Besides, it's not even a bug. It's documented. It should work the way it does. So what we as, let's say, open source and Postgres companies do is we have people who know both. We have people who know the business side of it, but also who know to work with communities, in particular Postgres, but also other communities. The language is different. The way you interact is different. And it's really important if you get to choose, there are a lot of companies to choose from. So it's not about marketing for one and only one company, but make sure you get companies that really know what they are doing and that are not trying to jump on the moving train and have no idea about it. In other words, you should make sure that you have or that your suppliers, your contractors have specialists there who know what they're doing. And speaking of specialists, very simple thing, we don't have enough. We don't have enough Postgres specialists. Yeah, and I see everyone like, yes. I don't really know how to fix that problem. I do know that it helped us to start actually teaching at a university. But even for the people that do get expertise in Postgres to some degree, how do they prove it? It's really, really difficult for them to do it because, yes, you can read a book about Postgres, but does that mean you're a specialist? No. But you can do some certification. Oh, yeah, that sounds great. But I'm not sure about all the certifications we have. Actually, I don't know how many. Do you have certification on Postgres? Is it on Postgres or is it on EDB? OK, so we have at least one. I know that API Japan has one, but that's about it. I'm kind of very of certifications. Personally, I do have a small history in quality assurance. And I think it was, that means check, ISO 9001. People were talking about all the time. And of course, this is the life vest, right? On the other side, we have concrete blocks. Which one would you want to have if you fall over or fall into water? It's easy, right? ISO 9001 allows you to build a life vest out of concrete. You can get that certified. It's actually easier to get it certified because you don't have to worry about a return process. Once they are used, they are gone. Yeah, it's ridiculous. Absolutely. But 9001 is only about your processes. How do you process the product? How do you process returns and so on? It doesn't say anything about the quality of the product, what it's supposed to do. Certifications like that don't make sense at all. And by that, I think you don't have to worry about the two-minute warning. I'm done. And if my count is right, we've got like 10 minutes for questions. So how do you say the skill set of the resources required in Postgres area? There is no official survey, but you can easily do a survey. Just go to that room over there, one level down, talk to all those Postgres companies or talk to the three companies in the room here and ask people, I bet you will not find a single company saying we don't have a problem there. Everyone I talk to says, yes, we'd like to hire, we'd love to hire, but we don't find anyone. I think one of the problems that I've seen in general, and I'm no way expert in Postgres, I do what I have to do, but it's the support. It's like you either use community or there's consulting companies, it's all or nothing. So either you do it free or you have to pay a consulting company that you don't know how long you're going to have a relationship with in order to get paid support or whatever that is. I wonder whether there's a middle ground there. As in having stuff free and only... I don't want to say free, but it's almost like you want to be able to work with someone, but it almost has that baggage like consulting companies would either be too expensive or they would send mediocre individuals and stuff like that. Postgres consulting in general doesn't have a good reputation. I don't know why. I'm surprised about it. This is what people tell me. I think we're talking about the bandwagon problem here. I'm pretty sure there are a lot of companies out there that have a very good reputation. I could easily name a few with a bad reputation as well. We're probably thinking about the same right now. There is a problem for you because you have to figure out which consulting company really knows what they're doing. But if you find out they do not, you can easily switch. That's the big advantage. And you can go out and try the community solution and just go for that consulting company if the community solution doesn't work. We see a lot of customers that say classical break fix and security support, the community is fast enough, we don't need them to do it. But if we have a problem like we just deployed the latest version of our own software and now the database doesn't start up anymore. But it's four o'clock in the morning and people start using their cell phones at six and we need it for that. They need somebody to call and fix the problem in those two hours, right? And you cannot expect the community to do that. So what you can do is do both. And it's your decision which problem you send to the consulting company and which problem you send to the community. But I think the most important part is find out if that company really knows what it's doing. There are companies out there offering support in open source on an SLA base that have literally nobody on staff knowing anything about it. They have this network of specialists that don't have a... they essentially have them on retainer. So there's no SLA. You send the ticket, they will respond. They have the team to respond and everything. But do you get an answer on time? I don't know. And then there are other companies that have their own people that know the source code inside out. And they would certainly answer your question on time. I'm not saying it's guaranteed that you get the problem fixed in half an hour. That depends on the problem you found. Yeah, so to answer that, it's just basically mostly separate individuals. There's not a single entity that can... I don't like dictatorship, but people do look at... and again, it's all managed feedback, not necessarily mine. And I differ from their viewpoint, but they're the ones who decide to check it out. Yeah, the big difference is if you run like an Oracle system, it's easy, it's Oracle. They know their software, so go to them. With Postgres, there are a couple companies that are mostly on the same level. And it's your choice. I mean, you can easily take the cheapest one or the one that's closest to you. You get more options, but the disadvantage, of course, is you have to do more due diligence and make a decision. But eventually, I'm pretty sure you get a better solution, worst case with a second or third contractor. Anything else? Salman, thank you. See you at the party.