(upbeat music) >> From our studios in the heart of Silicone Valley, Palo Alto, California, Nick is a Cube conversation. >> Hello, and welcome to the Palo Alto Cube Studios, I'm John Furrier, host of the Cube. We're here for great Cube conversation with Gilad Bracha who's a distinguished engineer at Shape Security, has a legacy in the programming world, one of the early folks working on Java, a variety of other great things: Small Talk, Newspeak, a variety of programming accomplishments. A legend in the industry, thanks for coming on. >> Well, thanks for having me, it's a pleasure to be here. >> You know, one of the things we always talk about on the Cube is how I work for a company, they do this, they do this great, here's our differentiator, here's our advantage, a lot of marketing speak, and then we also do a lot of interviews around disruption, around cloud computing, getting to DevOps, network effect, changes of network, moving packets around store and compute, all the benefits of cloud computing but we don't really talk about the underlying languages that are driving all the changes and this is something that you're an expert in and I want to get your thoughts on this because, you know, computer science is at an all time high. You can't go to Berkeley, you see what's going on at Berkeley, the number one major is computer science, the data classes, dreams of starting a company, but computer science is changing a lot. More people are coding but does that mean there still more computer science going on? So, a lot of people are trying to understand where the future is going to be and underneath it all is the programming languages themselves. >> Yeah, well-- >> Your thoughts on computer science and the languages out there. >> So, too much to say. But computer science is a lot, there are trends and there's a lot of emphasis now on machine learning and things like that. And it's interesting because that affects, which language you use can make these tasks a lot easier or a lot harder. And we've, you see certain languages being picked up for that purpose and new languages being done for numerical stuff like Julia, people are using R, God forbid and it's really interesting to see that. To me, it's interesting because there's a whole set of languages, the APL family of languages which really go back to the early 60s. But they're just phenomenally designed for these kind of large arrays of data for doing mathematical operations in parallel on large arrays or multi-dimensional arrays, essentially, tensors, back before that word was used in programming. And there's huge potential for doing better in terms of programming with those things. So that is one new, not new but area that's been kind of coming alive again. >> Yeah. >> That's really cool. >> You know, it's interesting, too, you bring up a point. We were talking before we came on camera about Lisp and all these other cool science out there. With, now, the advent of unlimited compute with cloud and, now, kind of new connected devices, a lot of the old science is coming back into vogue because of some of the use cases. I mean, I remember when I graduated college in the 80s, we had departments that were actually called data processing departments. And they used data processing, that's what they did, they processed data. That's the number one use case today is processing data. So, a lot of the old is coming back because it's relevant in this new era. So, I got to ask you, what is your favorite science and computer science that you think is relevant? You mentioned APL, what concepts, we TensorFlow with Google, things like that coming back, you see machine learning and AI, these are not new concepts. >> Well, some of them, I mean-- >> What's your thoughts? >> Machine learning, definitely, there have been breakthroughs in the past, I don't know, 10, 15 years and but the basis of it, the beauty of this is the basis of this is the real hardcore math in calculus and statistics, that stuff is golden and wherever it applies throughout the universe and you look at reasoning about these things and it comes up again. That's the root of it all. Making it so that you can manipulate things closer to level you can with math is really challenge for programming languages, so that you don't spend your life dealing with, sort of, irrelevant, boring details, oh, this has to be lowercase, that has to be tab, this tool doesn't work on that operating system. Most of our effort as software engineers goes, we're dealing with junk, really, and we should try and abstract over that and get over that. >> What are some of the exciting things that get you excited for programming language because there's a lot more excitement, a lot more opportunities now; you're seeing you can stand up software very quickly these days, and so there's some really quick and dirty ways to get software written with languages. Some want more principle-based design languages that have all the integrated components. What's the trade-off, what are some of the things you like around the new trends? >> So I'll give you something that meets both of the criteria that is both very principled but actually makes it much easier to put something together. One of my favorite new things that have come in the past few years is a thing called Elm which is a language, essentially, the main application, so far, has been to build websites, essentially, UI that's targeting a website but it is a functional programming language but it is much more approachable than the traditional academic stuff, even though the ideas are basically the same, but they're very well engineered. Actually, better engineered in many respects than a lot of the traditional stuff that you see like the Haskells and OCamls and stuff. And it started for the web, so it's a different game but it's a joy to use, it has great error messages, it has a time traveling debugger which is one of my favorite hobby horses, so you can actually go back and roll the computation back to where a problem occurred. And that, kind of, is interesting because it meets both of those points. >> Talk about this live programming, you mentioned rolling back and this is around live programming. >> Yeah. >> This is an exciting area. >> Oh, yeah. >> Your thoughts on live programming because we're seeing collaboration where I can have a screen open. I saw a demo at Amazon Reinvent last year or year before where people can be in different parts of the world or different offices in the same building and coding the same, I get the collaboration piece but there's also live programming languages that have built-in compile that's changing the old ways of debugging. Your thoughts. >> Right, so, definitely, that is something that people who have a heritage in small talk or Lisp, kind of, remember those systems or, if they're very lucky, still get to use them. And the thing is that most program languages don't have that level of interactivity when you work with them as a developer because there is too much of a feedback loop between when you actually specify what you want to happen by writing code and when you actually see what actually happen when you run your code and it typically doesn't do remotely what you wanted it to. That feedback loop is too long 'cause you have to go through compiles and bills and whatever, and the idea of live programming is to shorten that so that you, ideally, instantly see you change something and you can see the output and the output gets changed accordingly and you don't have to wait and, in particular, you don't have to go and rerun your program, get to the same point where you were, especially when you're debugging, right? That's the beauty of fix and continue debugging which is sort of a small but important piece of live programming where you can basically go and change a function and, immediately, proceed with the computation. You don't have to restart, you don't have to get to where you were, recreate the state, make sure the heap is in the same thing and that just, A, it's productive, it saves time. It's just a joy to watch and play with this thing, it's much more tactile, you actually feel-- >> It's faster, too, you don't have to, all the steps involved, classic debugging, restart, do it all over again. >> It's faster and it's less error prone 'cause those steps, you make mistakes, you went through all these steps and you forgot one thing or whatever or you did something wrong and didn't notice and you chased some, you know, went on a wild goose chase trying to figure out a bug, so it really is a huge H to product, a huge help to productivity and it's just so much fun to work with these systems. >> Well, I got to get this question for you while you're here because I get this question all the time and it's common. A lot of the young kids want to program, they see the future, they know that coding is a good skill to have. What's your advice to parents out there or kids, whether they're in elementary, or high school, or college, that might have a focus on, say, you know, I'm a neuroscience major or I'm doing this but I want to learn how to code? What's your advice for how to learn how to code because I've seen, oh, learn Java, I'm like, okay-- >> God, no. >> Not really my first choice. >> Eat spinach. Do 50 push-ups. No, it's not that comfortable. >> No, no. >> Java's not my first choice for recomm-- >> It's also 50 push-ups and spinach are better for you. Java is actually possibly damaging, at an early age, you should not be doing that. >> Doing Java, in particular? >> No, no. >> Why is that, it's just too complex? >> Because it's a lot of irrelevant boiler plate. It's a lot of stuff that should've been obsolete before and will be obsolete by the time you, hopefully, get to work for real and it's painful and if you aren't really into it, it'll just turn you off of the whole field. >> What's going to get someone excited, is it Elm, is it gaming, is it some sort of-- >> Yeah, so, Elm is good because you can run it, you don't need much setup, you can run in a web browser. I'm a Smalltalker and I still love the Smalltalk systems and they're still, overall, is a complete programming experience, they're still unmatched. Except for list machines which are kind of hard to come by. And so, I'd focus on those-- >> People tend to talk about Python, they talk about some of these languages. If someone's going to tinker around, what's going to be the addictive, if someone's going to-- >> So, people get addicted to all kinds of things but I would-- >> In terms of a good-- >> I tend to avoid the mainstream. People tend to latch on to the mainstream because they think it's a good career move or whatever. My advice is, you get good, learn the fundamentals in the cleanest way possible, then the mainstream stuff will be easy, rather than focusing on it, 'cause there's so much irrelevant detail in those systems and the programming experience is not that great. So, try something a little less meaty, closure is a lisp that you can use and there's closure script as a version that runs on the web. Try Elm. Try Smalltalk. >> And all these languages, they can actually produce something of value? >> Yeah, they can definitely, I think, still 70% of the world's container traffic is still run by a Smalltalk application. >> Really, I did not know that. >> Yeah, well, few people do. In Smalltalk, you find that that sort of heyday, in some sense, for commercial applications was in the 90s or 80s, whatever, but replacing those applications, a typical story is, someone says, ah, we should use Java 'cause everybody's using Java and we can get lots of programmers and they spend a lot of money and the new application doesn't work 'cause they can't actually rebuild the thing they built in Smalltalk at any reasonable cost, at any reasonable reliability. So, there are a lot of those systems out there, Morgan Stanley's still running Capital, their Smalltalk system for managing money. So, yeah, you can certainly build things. >> Well, Gilad, I love your commentary here, so I love that you're not shy to hold back. I've got to get your thoughts on cryptocurrency and the Blockchain world. >> Oh, dear. >> A lot of different languages, you got Ethereum, you have, some say, oh, I'm going to use Linux. If you're using Java, we're going to import it in, Javascript supports it, so there's been kind of like this, every kind of crypto currency, Blockchain, has their own language for decentralized applications. Your general thoughts on this. >> So, there's a need for, to slow down and be more careful, all right. Ethereum lost God knows how much money. I've heard quotes but I don't know if it's 50 million or 150 million but a fair amount of money due to problems that were classical distributed programming problems and could have been avoided by, essentially, more careful design of language in the system. There's a pressure now to turn things out in a hurry, right? In the old days, these systems took years and years of research in their little corner and, now, everybody has to do something too fast and that hurts. And, often, it's people who don't have the expertise and the background 'cause there's lots of research on all kinds of problems and smart people get snippets of those and they don't quite know what they're doing. And I don't think there's a cure for that because the incentives are there but that's why we're seeing these problems. >> So be careful, the message is be careful. >> Be careful. >> But they're rushing, all this cash is rolling in, they got to have some language. >> Sure, as long it's not their 150 million dollars that they lost, that's fine, but someone was probably upset. >> And, by the way, the security problem was software-error based. >> Most of them are. >> So, this transitions into Shape Security where you're not working as a distinguished engineer, working on some hard problems. I know it's pretty confidential but you guys do power 200 million iOS apps, this is from the PR statement. >> Probably more by now but yeah. >> Past 24 hours, you blocked more than two billion fraudulent login attempts, two million legitimate attempts. Essentially, defending intrusion detects and seems to be the company's value properties, but I don't want to get too much into the company because you're, obviously, on the engineering side. But security from a programming language side is software and people. >> Mm-hm. >> Right, software gets bugs. >> And people make them worse. >> And people make mistakes. >> People make them worse. >> Yeah. >> This is the central process problem in security. Your thoughts in computer science. >> So, most of the time, I mean, Shape does real security and this is fascinating to me but, most of the time, I've been looking at security at the programming language level because, you know, still, I think 70% of intrusions often, not the intrusions but, basically, these big software fiasco security problems get down to array buffer overflows. Which is ridiculous 'cause this is problem that was solved decades ago. Why are we still dealing with this? That's because, you know, programming language design, the whole approach to security, access control lists, whatever, there was another approach which was capability-based. And these two grew up together in the 60 and the world, as typically, it makes the wrong choices, it takes what seems appealing in the short term and not what is sort of a more thorough thing. So, object capabilities is a really interesting way of looking at this thing. There are people working on putting some of this into Javascript so that you could use it somehow. Great work by Mark Miller and company at Agoric. I'll do a shout-out to them. So, I've usually been on that side of things, but real security, there's a lot more to it, that's just one small layer of things and, above that, there's all the humans and the multiple systems they build. The configurations, they're just mistakes, the things that happen through social engineering about which, basically, I don't know much about but I will say that making things simpler is key because that's why people make mistakes. Things are too complicated. Every piece of the system has some bunch of clever engineers who really think it through and make it really sophisticated but when you compose these, it becomes, no one understands, a thing that no one understands what's going on and we need to simplify. My work is to try to simplify at that programming language level which the typical languages people use are too complex. >> And this is really where the software always has holes in it and you just got to be on top of it and make it tight, as it were. >> Right, basically, you can't understand the consequences when you have too many moving parts, as it were, too many constructs in the programming language. The composition is endless and you can't, it's very hard to foresee how they're going to interact and what someone will come up with, eventually. Oh, you could use this to attack that. Or, this crates this bad scenario that people don't notice. And, really, there's no remedy to that. You can work and you should be careful, you should test things, you should verify, if you can, formally, but if you just try and keep it simple, clean abstractions that are very simple and composed well, you will simply avoid, by definition, most of these problems. >> Final talk track around open source. It's been well-documented that proprietary software that's funded by companies when kind of stopped and innovating, kind of, dies on the vine. Open source is great, got leverage, you get out in the open, yeah, it's great. So, open source has been growing like a weed over the past couple decades and, recently, it's been phenomenal. The open source people say, oh, security is better in open source. At the same time, you bring up the notion of language security and those programming languages. How do you see that rectifying itself? How is the security paradigm with open source going to be stabler? What do companies need to do because open source is being used everywhere. >> Open source is used everywhere for good reason but open source is not, by itself, a magic thing, right. It's still, you get problems, open source is also open to malicious contributors, to problems, and the systems are too big for, even though there are code reviews and everything, so it's a double-edged sword, in some respects and sometimes the quality just suffers. These are social organization and each one is different and they have problems, so I don't know that that is, it's good that you shine light on something, it tends to purify it, and certainly that's a great strength of open source that you cant have things buried in there that you don't know. By the same token, it is not a panacea because the other thing is someone has to fund this somehow. All the open source models have to find somewhere to keep this going. So it's a more complicated thing to pull off. >> Especially with all these appliances now, okay, which version of Linux are you running, do I review the code? How do people ensure the security know that whether it's an appliance, or a device, or phone, or anything and it doesn't have some sort of back door or security vulnerability? >> Well, backdoor, I don't-- >> Backdoor, side door. >> Or just code-- >> This is a conspiracy theory. >> Or poor code. >> Poor code, well, poor code, you know, the open source is full of poor code is the truth. And the other thing is that, one problem with the open source is it also makes it easier for people to attack it because they can see how it's engineered. So, there is a reason that secure systems tend to, actually, maintain a certain level of secrecy. So I wouldn't go overboard on the open source ideology that it's inherently more secure. It has the advantage that you can see what you're getting. It has the disadvantage that everyone, including your adversaries, can see that. >> You don't know that going in, buyer beware kind of philosophy. >> Yes. >> And so, ultimately, you need to trust, like, it always comes down to trust at some level 'cause there's no way you're going to verify the software or the hardware, the bits, the you know. You can have problems in the hardware, this is a big problem nowadays, actually, with certain vendors. I don't want to get into those political footballs but-- >> Yeah, super micro. >> Yeah, and so, you really have to see who, you do have to take a risk in who do you trust. Who has a reputation, who is responsible for things that have worked? And there are no easy answers and it's beyond my pay grade. >> Let me get your thoughts on Capital One because we know that story, as of this week and they're on an Amazon estuary bucket, firewall filtering failed, someone just stumbled into it. I mean, the person that hacked it wasn't like, probably, a famous hacker, she was bragging on Twitter and message groups like, saying, hey, I just got in. So, door's open, keys are running in the car, walked right to the safe, safe was open. >> So, I don't know anything about that incident specifically and, I mean, beyond what you and I have read on the web or somewhere-- >> That's a human error. >> But they're usually there's always, almost always human error involved. It's also why you need, sort of, it's like countermeasures, right, and counter, counter, countermeasures. You simply have to monitor, right? So that when something, when you have an intrusion, you check it, now, that's not easy but there are lots of clever things that people are doing. You can have security as an afterthought. It's really hard. That's generally the problem is that people don't think about it early enough. >> Final question before we break: What's the human problem that you see most with developers? 'Cause if humans make mistakes, which they do, what's the common mistake developers, programmers make when coding that could be avoided with just a little bit sharper focus? >> Well, it's not about focus but I'd say null pointer exceptions are the biggest, like, after array buffers, they're the other, Tony Hoare called it billion dollar mistake in 1980 in his award speech, I think. And we're talking now, it's probably a trillion dollars, right? And this is something that can be mechanically checked by the programming language and it's probably the number bang-for-a-buck feature that you might throw in. >> Just say no to null? >> Yeah. >> That's the philosophy. >> Yeah. >> Gilad, thanks for coming on the Cube, appreciate the conversation. >> Thank you very much. >> I'm John Furrier, here in Palo Alto at the Cube Studios. This has been a Cube Conversation, thanks for watching. (upbeat music)

>>From San Francisco. It's the cube covering get lab commit 20, 20 Raji you buy get lab. >>Hi, I'm Stu Miniman and this is the cubes coverage of get lab commit 2020. We're here in San Francisco. It's a little bit chilly but uh, my first guests, uh, on the program are used to the weather cause they're coming to us from Wisconsin. Uh, both from Northwestern mutual, uh, sitting to my left here is Kyle person who is a senior engineer and sitting to his left is Sean who is also a senior engineer. Gentlemen, thanks so much for joining us. Thanks for having us. Alright. We thought, you know, both of us coming from colder climates that may be coming to San Francisco would be a little warmer, but they have hand warmers, they have warm drinks and it is the warmth of the community that will warm our innards. I'm short right there. It says get warm. That's what we're here to do. All right, Kyle, let's start with you. Northwestern mutual. I think most people are familiar with the organization, but give us a little bit of a, you know, how people should think of Northwestern mutual in 2020 and, uh, your roles. >>Yeah. So obviously we mean we're a large insurance company but also into financial services and products and we're really trying to become more of a digital company as well. We think that that's going to be a differentiator in the marketplace. You know, having apps that our customers can interact with, um, trying to speed up underwriting, things like that. So we're really just trying to be a technology company as much of an insurance company. Okay, >>great. And Sean, I understand you're, you're on the same team as Kyle helping you along with that digital transformation that that's been all the buzz for the last couple of years. Yeah. He can't get rid of me. We flew, you know, 1200 miles and I'm still sitting next to, uh, but yeah, at Northwestern mutual, I mean, going back a number of years now, the, the company started down this path of doing a digital transformation where we wanted to be, you know, a software company that is providing financial service and financial stability for our clients. So it was a big shift that we, we started, we knew we needed to modernize everything. So we started down that path. Great. So we had that. So Kyle, maybe if you, it can, you know, when did get lab enter the picture, what was kind of the initial use case and, uh, let's, let's go from there. >>Yeah, it was before my time. I'm, Chad has been there for a long time. Most of the ride, but uh, yeah, it's been several years and it's been, uh, you know, starting out with SCM, moving into CEI and then, you know, adopted sustainer journey that you hear about even in the keynote today. That's pretty much how we charted our course. Okay. >>So Sean, you've been there since the beginning of a, uh, to get lab usage? Pretty much it, it showed up a couple months before I got there. But, uh, going back to your early mid 22, yeah, 2015, uh, we had kind of a more of a pilot group of engineers that were, were starting out, you know, to get us down this path to where we wanted to go and they needed a new tool, something that worked better than what we currently had at an M and a, they settled on, on get lab because it provided, you know, one being open source was a huge selling point for us. Um, and it was just ever-growing. So it allowed our developers to really get going and get going much faster. Okay, great. And in the keynote, okay, Kyle, they were talking about how it's not just about the dev, the second the ops, but really not allowing everybody into the same tooling, even marketing and finance. What's kind of the breadth of the organization is it is mostly devs that dev and ops does security, you know, who, who's involved in using this tooling. >>It's everybody. We're a, we're figuring out our, you know, everyone's kinda got their own spin on things. So we're in that, um, classic position where I think we have the tooling sprawl that everyone talks about and we're, we're constantly evaluating, you know, how does Gilad fit into that picture? What do we bolt on? You know, we have the luxury of being able to integrate with other things as well. But then if certainly if we can get an economy of scale where we can just use get lab, it's to provide that seamless interface. That's something we always look to do too. All right. >>So Sean, my understanding is a NM is also using Coubernetties and that's something that you're involved in. So very money you bring us in people, you know, sometimes get misconstrued as to the scope and the purpose of, of Kubernetes. We've been at the cube con cloud date of con for a number of years, but uh, why don't you set the stage for us and kind of walk us through the, the what and the why of Kubernetes? Yeah. For us at least being able to leverage something like Kubernetes, which when you really back out and you know, do the 10,000 foot view, it's container management and being able to go into a more modern architecture. We're leveraging containers for pretty much whatever we can, or at least what makes sense. Um, and that's kind of how we started down the path with get lab moving into Kubernetes. You know, we were, we were trying to figure out like, where do we want to go so, you know, let's not just push the boat out a little, let's drop, kick the boat off the end of the pier and see where we end up. >>So we started working down that path of deploying get lab into Kubernetes cause it allowed us to easily expand and make the application highly available. So even if some easies go down in AWS, which knock on wood never happens. Uh, we're still good to go. Our users are, wouldn't even notice. Okay. Um, so you mentioned AWS. Is that your primary cloud, your only cloud? What, what is your cloud situation? Yeah, that's, that's a Northwestern mutual is public cloud. Okay, great. And speak a little bit to, you know, Amazon does have plenty of its own tooling. Uh, maybe a little bit about how get lab and, how those fit together for you. Um, well, I mean, we use get lab CIS specifically to be able to provision different services in one, not that we need as long as they fit near within our security requirements. And, you know, everything we do, we get vetted out through our internal processes, but it's really allowed our developers to move forward so much faster. >>You know, it's kind of gone are the days of, let me fill out a request for, you know, X, Y, Z and, you know, wait two as it goes through somebody's work queue and they eventually get around to it. Um, allowing our developers to just, you know, do their commits, get their, you know, peer review and just deploy and provision right away, allows us to get our applications to market just so much faster than even a few years ago. Alright. So Kyle, the two of you are presenting here at the show, uh, you know, we, we love, we heard GitLab talking on stages. You know, customers don't just use it, they commit, they add feedback in and they speak at the show. So maybe speak a little bit of, uh, you know, NMS, you know, involvement as to uh, you know, are you committing code and what, what are you speaking about? >>So we're here to speak about our journey on Kubernetes. I'm trans covering the application side and I'm going to talk about our, our dabble in Kubernetes CII. So we're, we're really looking to, um, we're looking for efficiencies I guess in, in density. That's a primary driver behind trying to explore the trail. But also, um, one of the things I'll talk about in the talk is, is boosting our security posture using Kubernetes. So a lot of times people are using API keys and they're getting stale and not being rotated. Uh, we can do some neat things with Kubernetes and it's native. I am offerings to boost our security posture by moving towards role based access and getting those credentials that are rotating and providing us, uh, you know, non stale sort of authentication credentials, things like that. >>Sean, yeah, pretty much covers it. Uh, uh, and beyond with the CIA, you know, being able to run and get lab itself within Qube and having the different components broken out and we're alive. It's, it, it's enabling us to limit any kind of attack plane that could exist. You know, it's, you have to get through a lot to even get to it. So it's really just been a huge, a huge plus for us. OK. I, I'd love to hear both. Both of you have been to these events a number of times. You're speaking to event. What, what, what's the value of coming to get loud commit? I mean, for me it's a, a huge networking thing and being able to relay our experiences that we've gone through to other people that are out in the community. I mean, I know lots of, you know, everyone wants to see, you know, what can you do in Kubernetes and like, here's some of the things that we've done. >>Here's some of the things that you know, works that didn't work. You know, we would recommend you going this kind of route if we were to start it over again. And beyond that, you know, meeting people from all over the world, like, uh, we were talking with some, uh, some guy, gentleman Nico from white duck who is from Germany. It's not something you get to do, you know, face to face all the time. Alright. Sean, can you share with our audience any of those? You know, if we could do it over again, we'd change something. Is it an organizational thing or technical piece or until don't don't use EFS for getting repo data. It will not end well for you can take away. All right. Kyle, how about you? You've been to a number of these shows, uh, you know, the networking, the piece or you know, what else, what, what, what, what for you personally and for NM, uh, you know, brings you back. >>Yeah. Networking is a big thing. I think it's also getting feedback on, you know, what we're doing. Does it make sense? Just like get lab is throwing things out there early, trying to tighten up that contribution loop. We want to get our ideas out there and then this is an opportunity for people to ask questions about our presentation. If maybe we're off in the wrong direction, maybe we can get that steered back on course. Um, you know, we're just really here to get the feedback. Yeah. I always love talking to people in the financial industry and you talk about open source, you know, if, if you went back, you know, five years ago, you'd probably get a little bit of sideways looks as to wait, you know, you're doing what, um, are we past that? Do do you feel are most people, uh, you know, really understanding where we are with, with cloud and open source in general that it, you know, it makes perfect sense for a financial institution to be part of it. >>I'd say at NM we, we've finally gotten past that curve and now we're, we're trying to, you know, make it even easier for our internal developers to easier participate in open source, you know, their internal products and contribute more to the community. Uh, we've completely done an about face from, you know, probably 15 years ago where it was open source. You wanted to, what to, yeah, let's go. How can we make things better? It's, it's all about, you know, our, our customers. So we want to make sure we create the best product and experience for them. That's awesome. Yeah, there's still some barriers there. I mean, it's all about managing risk, right? So you have to do things diligently and make sure that your bases are covered. And so it's not like it can be a free for all. We have to do our due diligence, but we, you know, we love to contribute. And we love to get up without their there as we can. All right. Well, Kyle and Sean, thank you so much for sharing with our audience. Best of luck with your presentations and, uh, have a great time at the show. Thank you. All right. Uh, thank you to, to NM for joining us. I'm Stu Miniman and thank you for watching the cube.