>>Good afternoon, brilliant humans, and welcome back to the Cube. We're live in Detroit, Michigan at Cub Con, and I'm joined by John Furrier. John three exciting days buzzing. How you doing? >>That's great. I mean, we're coming down to the third day. We're keeping the energy going, but this segment's gonna be awesome. The CD foundation's doing amazing work. Developers are gonna be running businesses and workflows are changing. Productivity's the top conversation, and you're gonna start to see a coalescing of the communities who are continuous delivery, and it's gonna be awesome. >>And, and our next guess is an outstanding person to talk about this. We are joined by Stephen Chin, the chair of the CD Foundation. Steven, thanks so much for being here. >>No, no, my pleasure. I mean, this has been an amazing week quote that CubeCon with all of the announcements, all of the people who came out here to Detroit and, you know, fantastic. Like just walking around, you bump into all the right people here. Plus we held a CD summit zero day events, and had a lot of really exciting announcements this week. >>Gotta love the shirt. I gotta say, it's one of my favorites. Love the logos. Love the love the branding. That project got traction. What's the news in the CD foundation? I tried to sneak in the back. I got a little laid into your co-located event. It was packed. Everyone's engaged. It was really looked, look really cool. Give us the update. >>What's the news? Yeah, I know. So we, we had a really, really powerful event. All the key practitioners, the open source leads and folks were there. And one of, one of the things which I think we've done a really good job in the past six months with the CD foundation is getting back to the roots and focusing on technical innovation, right? This is what drives foundations, having strong projects, having people who are building innovation, and also bringing in a new innovation. So one of the projects which we added to the CD foundation this week is called Persia. So it's a, it's a decentralized package repository for getting open source libraries. And it solves a lot of the problems which you get when you have centralized infrastructure. You don't have the right security certificates, you don't have the right verification libraries. And these, these are all things which large companies provision and build out inside of their infrastructure. But the open source communities don't have the benefit of the same sort of really, really strong architecture. A lot of, a lot of the systems we depend upon. It's >>A good point, yeah. >>Yeah. I mean, if you think about the systems that developers depend upon, we depend upon, you know, npm, ruby Gems, Mayn Central, and these systems been around for a while. Like they serve the community well, right? They're, they're well supported by the companies and it's, it's, it's really a great contribution that they give us. But every time there's an outage or there's a security issue, guess, guess how many security issues that our, our research team found at npm? Just ballpark. >>74. >>So there're >>It's gotta be thousands. I mean, it's gotta be a lot of tons >>Of Yeah, >>They, they're currently up to 60,000 >>Whoa. >>Vulnerable, malicious packages in NPM and >>Oh my gosh. So that's a super, that's a jar number even. I know it was gonna be huge, but Holy mo. >>Yeah. So that's a software supply chain in actually right there. So that's, that's open source. Everything's out there. What's, how do, how does, how do you guys fix that? >>Yeah, so per peria kind of shifts the whole model. So when, when you think about a system that can be sustained, it has to be something which, which is not just one company. It has to be a, a, a set of companies, be vendor neutral and be decentralized. So that's why we donated it to the Continuous Delivery Foundation. So that can be that governance body, which, which makes sure it's not a single company, it is to use modern technologies. So you, you, you just need something which is immutable, so it can't be changed. So you can rely on it. It has to have a strong transaction ledger so you can see all of the history of it. You can build up your software, build materials off of it, and it, it has to have a strong peer-to-peer architecture, so it can be sustained long term. >>Steven, you mentioned something I want to just get back to. You mentioned outages and disruption. I, you didn't, you didn't say just the outages, but this whole disruption angle is interesting if something happens. Talk about the impact of the developer. They stalled, inefficiencies create basically disruption. >>No, I mean, if, if, so, so if you think about most DevOps teams in big companies, they support hundreds or thousands of teams and an hour of outage. All those developers, they, they can't program, they can't work. And that's, that's a huge loss of productivity for the company. Now, if you, if you take that up a level when MPM goes down for an hour, how many millions of man hours are wasted by not being able to get your builds working by not being able to get your codes to compile. Like it's, it's >>Like, yeah, I mean, it's almost hard to fathom. I mean, everyone's, It's stopped. Exactly. It's literally like having the plug pulled >>Exactly on whenever you're working on, That's, that's the fundamental problem we're trying to solve. Is it, it needs to be on a, like a well supported, well architected peer to peer network with some strong backing from big companies. So the company is working on Persia, include J Frog, which who I work for, Docker, Oracle. We have Deploy hub, Huawei, a whole bunch of other folks who are also helping out. And when you look at all of those folks, they all have different interests, but it's designed in a way where no single party has control over the network. So really it's, it's a system system. You, you're not relying upon one company or one logo. You're relying upon a well-architected open source implementation that everyone can rely >>On. That's shared software, but it's kind of a fault tolerant feature too. It's like, okay, if something happens here, you have a distributed piece of it, decentralized, you're not gonna go down. You can remediate. All right, so where's this go next? I mean, cuz we've been talking about the role of developer. This needs to be a modern, I won't say modern upgrade, but like a modern workflow or value chain. What's your vision? How do you see that? Cuz you're the center of the CD foundation coming together. People are gonna be coalescing multiple groups. Yeah. >>What's the, No, I think this is a good point. So there, there's a, a lot of different continuous delivery, continuous integration technologies. We're actually, from a Linux Foundation standpoint, we're coalescing all the continued delivery events into one big conference >>Next. You just made an announcement about this earlier this week. Tell us about CD events. What's going on, what's in, what's in the cooker? >>Yeah, and I think one of the big announcements we had was the 0.1 release of CD events. And CD events allows you to take all these systems and connect them in an event scalable, event oriented architecture. The first integration is between Tecton and Capin. So now you can get CD events flowing cleanly between your, your continuous delivery and your observability. And this extends through your entire DevOps pipeline. We all, we all need a standards based framework Yep. For how we get all the disparate continuous integration, continuous delivery, observability systems to, to work together. That's also high performance. It scales with our needs and it, it kind of gives you a future architecture to build on top of. So a lot of the companies I was talking with at the CD summit Yeah. They were very excited about not only using this with the projects we announced, but using this internally as an architecture to build their own DevOps pipelines on. >>I bet that feels good to hear. >>Yeah, absolutely. Yeah. >>Yeah. You mentioned Teton, they just graduated. I saw how many projects have graduated? >>So we have two graduated projects right now. We have Jenkins, which is the first graduated project. Now Tecton is also graduated. And I think this shows that for Tecton it was, it was time, the very mature project, great support, getting a lot of users and having them join the set of graduated projects. And the continuous delivery foundation is a really strong portfolio. And we have a bunch of other projects which also are on their way towards graduation. >>Feels like a moment of social proof I bet. >>For you all. Yeah, yeah. Yeah. No, it's really good. Yeah. >>How long has the CD Foundation been around? >>The CD foundation has been around for, i, I won't wanna say the exact number of years, a few years now. >>Okay. >>But I, I think that it, it was formed because what we wanted is we wanted a foundation which was purpose built. So CNCF is a great foundation. It has a very large umbrella of projects and it takes kind of that big umbrella approach where a lot of different efforts are joining it, a lot of things are happening and you can get good traction, but it produces its own bottlenecks in process. Having a foundation which is just about continuous delivery caters to more of a DevOps, professional DevOps audience. I think this, this gives a good platform for best practices. We're working on a new CDF best practices Yeah. Guide. We're working when use cases with all the member companies. And it, it gives that thought leadership platform for continuous delivery, which you need to be an expert in that area >>And the best practices too. And to identify the issues. Because at the end of the day, with the big thing that's coming out of this is velocity and more developers coming on board. I mean, this is the big thing. More people doing more. Yeah. Well yeah, I mean you take this open source continuous thunder away, you have more developers coming in, they be more productive and then people are gonna even either on the DevOps side or on the straight AP upside. And this is gonna be a huge issue. And the other thing that comes out that I wanna get your thoughts on is the supply chain issue you talked about is hot verifications and certifications of code is such big issue. Can you share your thoughts on that? Because Yeah, this is become, I won't say a business model for some companies, but it's also becoming critical for security that codes verified. >>Yeah. Okay. So I, I think one of, one of the things which we're specifically doing with the Peria project, which is unique, is rather than distributing, for example, libraries that you developed on your laptop and compiled there, or maybe they were built on, you know, a runner somewhere like Travis CI or GitHub actions, all the libraries being distributed on Persia are built by the authorized nodes in the network. And then they're, they're verified across all of the authorized nodes. So you nice, you have a, a gar, the basic guarantee we're giving you is when you download something from the Peria network, you'll get exactly the same binary as if you built it yourself from source. >>So there's a lot of trust >>And, and transparency. Yeah, exactly. And if you remember back to like kind of the seminal project, which kicked off this whole supply chain security like, like whirlwind it was SolarWinds. Yeah. Yeah. And the exact problem they hit was the build ran, it produced a result, they modified the code of the bill of the resulting binary and then they signed it. So if you built with the same source and then you went through that same process a second time, you would've gotten a different result, which was a malicious pre right. Yeah. And it's very hard to risk take, to take a binary file Yep. And determine if there's malicious code in it. Cuz it's not like source code. You can't inspect it, you can't do a code audit. It's totally different. So I think we're solving a key part of this with Persia, where you're freeing open source projects from the possibility of having their binaries, their packages, their end reduces, tampered with. And also upstream from this, you do want to have verification of prs, people doing code reviews, making sure that they're looking at the source code. And I think there's a lot of good efforts going on in the open source security foundation. So I'm also on the governing board of Open ssf >>To Do you sleep? You have three jobs you've said on camera? No, I can't even imagine. Yeah. Didn't >>You just spin that out from this open source security? Is that the new one they >>Spun out? Yeah, So the Open Source Security foundation is one of the new Linux Foundation projects. They, they have been around for a couple years, but they did a big reboot last year around this time. And I think what they really did a good job of now is bringing all the industry players to the table, having dialogue with government agencies, figuring out like, what do we need to do to support open source projects? Is it more investment in memory, safe languages? Do we need to have more investment in, in code audits or like security reviews of opensource projects. Lot of things. And all of those things require money investments. And that's what all the companies, including Jay Frogger doing to advance open source supply chain security. I >>Mean, it's, it's really kind of interesting to watch some different demographics of the developers and the vendors and the customers. On one hand, if you're a hardware person company, you have, you talk zero trust your software, your top trust, so your trusted code, and you got zero trust. It's interesting, depending on where you're coming from, they're all trying to achieve the same thing. It means zero trust. Makes sense. But then also I got code, I I want trust. Trust and verified. So security is in everything now. So code. So how do you see that traversing over? Is it just semantics or what's your view on that? >>The, the right way of looking at security is from the standpoint of the hacker, because they're always looking for >>Well said, very well said, New >>Loop, hope, new loopholes, new exploits. And they're, they're very, very smart people. And I think when you, when you look some >>Of the smartest >>Yeah, yeah, yeah. I, I, I work with, well former hackers now, security researchers, >>They converted, they're >>Recruited. But when you look at them, there's like two main classes of like, like types of exploits. So some, some attacker groups. What they're looking for is they're looking for pulse zero days, CVEs, like existing vulnerabilities that they can exploit to break into systems. But there's an increasing number of attackers who are now on the opposite end of the spectrum. And what they're doing is they're creating their own exploits. So, oh, they're for example, putting malicious code into open source projects. Little >>Trojan horse status. Yeah. >>They're they're getting their little Trojan horses in. Yeah. Or they're finding supply chain attacks by maybe uploading a malicious library to NPM or to pii. And by creating these attacks, especially ones that start at the top of the supply chain, you have such a large reach. >>I was just gonna say, it could be a whole, almost gives me chills as we're talking about it, the systemic, So this is this >>Gnarly nation state attackers, like people who wanted serious >>Damages. Engineered hack just said they're high, highly funded. Highly skilled. Exactly. Highly agile, highly focused. >>Yes. >>Teams, team. Not in the teams. >>Yeah. And so, so one, one example of this, which actually netted quite a lot of money for the, for the hacker who exposed it was, you guys probably heard about this, but it was a, an attack where they uploaded a malicious library to npm with the same exact namespace as a corporate library and clever, >>Creepy. >>It's called a dependency injection attack. And what happens is if you, if you don't have the right sort of security package management guidelines inside your company, and it's just looking for the latest version of merging multiple repositories as like a, like a single view. A lot of companies were accidentally picking up the latest version, which was out in npm uploaded by Alex Spearson was the one who did the, the attack. And he simultaneously reported bug bounties on like a dozen different companies and netted 130 k. Wow. So like these sort of attacks that they're real Yep. They're exploitable. And the, the hackers >>Complex >>Are finding these sort of attacks now in our supply chain are the ones who really are the most dangerous. That's the biggest threat to us. >>Yeah. And we have stacker ones out there. You got a bunch of other services, the white hat hackers get the bounties. That's really important. All right. What's next? What's your vision of this show as we end Coan? What's the most important story coming outta Coan in your opinion? And what are you guys doing next? >>Well, I, I actually think this is, this is probably not what most hooks would say is the most exciting story to con, but I find this personally the best is >>I can't wait for this now. >>So, on, on Sunday, the CNCF ran the first kids' day. >>Oh. >>And so they had a, a free kids workshop for, you know, underprivileged kids for >>About, That's >>Detroit area. It was, it was taught by some of the folks from the CNCF community. So Arro, Eric hen my, my older daughter, Cassandra's also an instructor. So she also was teaching a raspberry pie workshop. >>Amazing. And she's >>Here and Yeah, Yeah. She's also here at the show. And when you think about it, you know, there's always, there's, there's, you know, hundreds of announcements this week, A lot of exciting technologies, some of which we've talked about. Yeah. But it's, it's really what matters is the community. >>It this is a community first event >>And the people, and like, if we're giving back to the community and helping Detroit's kids to get better at technology, to get educated, I think that it's a worthwhile for all of us to be here. >>What a beautiful way to close it. That is such, I'm so glad you brought that up and brought that to our attention. I wasn't aware of that. Did you know that was >>Happening, John? No, I know about that. Yeah. No, that was, And that's next generation too. And what we need, we need to get down into the elementary schools. We gotta get to the kids. They're all doing robotics club anyway in high school. Computer science is now, now a >>Sport, in my opinion. Well, I think that if you're in a privileged community, though, I don't think that every school's doing robotics. And >>That's why Well, Cal Poly, Cal Poly and the universities are stepping up and I think CNCF leadership is amazing here. And we need more of it. I mean, I'm, I'm bullish on this. I love it. And I think that's a really great story. No, >>I, I am. Absolutely. And, and it just goes to show how committed CNF is to community, Putting community first and Detroit. There has been such a celebration of Detroit this whole week. Stephen, thank you so much for joining us on the show. Best Wishes with the CD Foundation. John, thanks for the banter as always. And thank you for tuning in to us here live on the cube in Detroit, Michigan. I'm Savannah Peterson and we are having the best day. I hope you are too.

(upbeat music) >> Hello, and welcome back to AWS Startup Showcase, I'm John Furrier, your host. This is the Hero panel, the AWS Heroes. These are folks that have a lot of experience in Open Source, having fun building great projects and commercializing the value and best practices of Open Source innovation. We've got some great guests here. Liz Rice, Chief Open Source Officer, Isovalent. CUBE alumni, great to see you. Brian LeRoux, who is the Co-founder and CTO of begin.com. Erica Windisch who's an Architect for Developer Experience. AWS Hero, also CUBE alumni. Casey Lee, CTO Gaggle. Doing some great stuff in ed tech. Great collection of experts and experienced folks doing some fun stuff, welcome to this conversation this CUBE panel. >> Hi. >> Thanks for having us. >> Hello. >> Let's go down the line. >> I don't normally do this, but since we're remote and we have such great guests, go down the line and talk about why Open Source is important to you guys. What projects are you currently working on? And what's the coolest thing going on there? Liz we'll start with you. >> Okay, so I am very involved in the world of Cloud Native. I'm the chair of the technical oversight committee for the Cloud Native Computing Foundation. So that means I get to see a lot of what's going on across a very broad range of Cloud Native projects. More specifically, Isovalent. I focus on Cilium, which is it's based on a technology called EBPF. That is to me, probably the most exciting technology right now. And then finally, I'm also involved in an organization called OpenUK, which is really pushing for more use of open technologies here in the United Kingdom. So spread around lots of different projects. And I'm in a really fortunate position, I think, to see what's happening with lots of projects and also the commercialization of lots of projects. >> Awesome, Brian what project are you working on? >> Working project these days called Architect. It's a Open Source project built on top of AWSM. It adds a lot of sugar and terseness to the SM experience and just makes it a lot easier to work with and get started. AWS can be a little bit intimidating to people at times. And the Open Source community is stepping up to make some of that bond ramp a little bit easier. And I'm also an Apache member. And so I keep a hairy eyeball on what's going on in that reality all the time. And I've been doing this open-source thing for quite a while, and yeah, I love it. It's a great thing. It's real science. We get to verify each other's work and we get to expand and build on human knowledge. So that's a huge honor to just even be able to do that and I feel stoked to be here so thanks for having me. >> Awesome, yeah, and totally great. Erica, what's your current situation going on here? What's happening? >> Sure, so I am currently working on developer experience of a number of Open Source STKS and CLI components from my current employer. And previously, recently I left New Relic where I was working on integrating with OpenTelemetry, as well as a number of other things. Before that I was a maintainer of Docker and of OpenStack. So I've been in this game for a while as well. And I tend to just put my fingers in a lot of little pies anywhere from DVD players 20 years ago to a lot of this open telemetry and monitoring and various STKs and developer tools is where like Docker and OpenStack and the STKs that I work on now, all very much focusing on developer as the user. >> Yeah, you're always on the wave, Erica great stuff. Casey, what's going on? Do you got some great ed techs happening? What's happening with you? >> Yeah, sure. The primary Open Source project that I'm contributing to right now is ACT. This is a tool I created a couple of years back when GitHub Actions first came out, and my motivation there was I'm just impatient. And that whole commit, push, wait time where you're testing out your pipelines is painful. And so I wanted to build a tool that allowed developers to test out their GitHub Actions workflows locally. And so this tool uses Docker containers to emulate, to get up action environment and gives you fast feedback on those workflows that you're building. Lot of innovation happening at GitHub. And so we're just trying to keep up and continue to replicate those new features functionalities in the local runner. And the biggest challenge I've had with this project is just keeping up with the community. We just passed 20,000 stars, and it'd be it's a normal week to get like 10 PRs. So super excited to announce just yesterday, actually I invited four of the most active contributors to help me with maintaining the project. And so this is like a big deal for me, letting the project go and bringing other people in to help lead it. So, yeah, huge shout out to those folks that have been helping with driving that project. So looking forward to what's next for it. >> Great, we'll make sure the SiliconANGLE riders catch that quote there. Great call out. Let's start, Brian, you made me realize when you mentioned Apache and then you've been watching all the stuff going on, it brings up the question of the evolution of Open Source, and the commercialization trends have been very interesting these days. You're seeing CloudScale really impact also with the growth of code. And Liz, if you remember, the Linux Foundation keeps making projections and they keep blowing past them every year on more and more code and more and more entrance coming in, not just individuals, corporations. So you starting to see Netflix donates something, you got Lyft donate some stuff, becomes a project company forms around it. There's a lot of entrepreneurial activity that's creating this new abstraction layers, new platforms, not just tools. So you start to see a new kickup trajectory with Open Source. You guys want to comment on this because this is going to impact how fast the enterprise will see value here. >> I think a really great example of that is a project called Backstage that's just come out of Spotify. And it's going through the incubation process at the CNCF. And that's why it's front of mind for me right now, 'cause I've been working on the due diligence for that. And the reason why I thought it was interesting in relation to your question is it's spun out of Spotify. It's fully Open Source. They have a ton of different enterprises using it as this developer portal, but they're starting to see some startups emerging offering like a hosted managed version of Backstage or offering services around Backstage or offering commercial plugins into Backstage. And I think it's really fascinating to see those ecosystems building up around a project and different ways that people can. I'm a big believer. You cannot sell the Open Source code, but you can sell other things that create value around Open Source projects. So that's really exciting to see. >> Great point. Anyone else want to weigh in and react to that? Because it's the new model. It's not the old way. I mean, I remember when I was in college, we had the Pirate software. Open Source wasn't around. So you had to deal under the table. Now it's free. But I mean the old way was you had to convince the enterprise, like you've got a hard knit, it builds the community and the community manage the quality of the code. And then you had to build the company to make sure they could support it. Now the companies are actually involved in it, right? And then new startups are forming faster. And the proof points are shorter and highly accelerated for that. I mean, it's a whole new- >> It's a Cambrian explosion, and it's great. It's one of those things that it's challenging for the new developers because they come in and they're like, "Whoa, what is all this stuff that I'm supposed to figure out?" And there's no right answer and there's no wrong answer. There's just tons of it. And I think that there's a desire for us to have one sort of well-known trot and happy path, that audience we're a lot better with a more diverse community, with lots of options, with lots of ways to approach these problems. And I think it's just great. A challenge that we have with all these options and all these Cambrian explosion of projects and all these competing ideas, right now, the sustainability, it's a bit of a tricky question to answer. We know that there's a commercialization aspect that helps us fund these projects, but how we compose the open versus the commercial source is still a bit of a tricky question and a tough one for a lot of folks. >> Erica, would you chime in on that for a second. I want to get your angle on that, this experience and all this code, and I'm a new person, I'm an existing person. Do I get like a blue check mark and verify? I mean, these are questions like, well, how do you navigate? >> Yeah, I think this has been something happening for a while. I mean, back in the early OpenStack days, 2010, for instance, Rackspace Open Sourcing, OpenStack and ANSU Labs and so forth, and then trying, having all these companies forming in creating startups around this. I started at a company called Cloudccaling back in late 2010, and we had some competitors such as Piston and so forth where a lot of the ANSUL Labs people went. But then, the real winners, I think from OpenStack ended up being the enterprises that jumped in. We had Red Hat in particular, as well as HP and IBM jumping in and investing in OpenStack, and really proving out a lot of... not that it was the first time, but this is when we started seeing billions of dollars pouring into Open Source projects and Open Source Foundations, such as the OpenStack Foundation, which proceeded a lot of the things that we now see with the Linux Foundation, which was then created a little bit later. And at the same time, I'm also reflecting a little bit what Brian said because there are projects that don't get funded, that don't get the same attention, but they're also getting used quite significantly. Things like Log4j really bringing this to the spotlight in terms of projects that are used everywhere by everything with significant outsized impacts on the industry that are not getting funded, that aren't flashy enough, that aren't exciting enough because it's just logging, but a vulnerability in it brings every everything and everybody down and has possibly billions of dollars of impact to our industry because nobody wanted to fund this project. >> I think that brings up the commercialization point about maybe bringing a venture capital model in saying, "Hey, that boring little logging thing could be a key ingredient for say solving some observability problems so I think let's put some cash." Again then we'd never seen that before. Now you're starting to see that kind of a real smart investment thesis going into Open Source projects. I mean, Promethease, Crafter, these are projects that turned off companies. This is turning up companies. >> A decade ago, there was no money in Dev tools that I think that's been fully debunked now. They used to be a concept that the venture community believed, but there's just too much evidence to the contrary, the companies like Cash Court, Datadog, the list goes on and on. I think the challenge for the Open Source (indistinct) comes back to foundations and working (indistinct) these developers make this code safe and secure. >> Casey, what's your reaction to all of this? You've got, so a project has gained some traction, got some momentum. There's a lot of mission critical. I won't say white spaces, but the opportunities in the big cloud game happening. And there's a lot of, I won't say too many entrepreneurial, but there's a lot of community action happening that's precommercialization that's getting traction. How does this all develop naturally and then vector in quickly when it hits? >> Yeah, I want to go back to the Log4j topic real quick. I think that it's a great example of an area that we need to do better at. And there was a cool article that Rob Pike wrote describing how to quantify the criticality. I think that's sort of quantifying criticality was the article he wrote on how to use metrics, to determine how valuable, how important a piece of Open Source is to the community. And we really need to highlight that more. We need a way to make it more clear how important this software is, how many people depend on it and how many people are contributing to it. And because right now we all do that. Like if I'm going to evaluate an Open Source software, sure, I'll look at how many stars it has and how many contributors it has. But I got to go through and do all that work myself and come up with. It would be really great if we had an agreed upon method for ranking the criticality of software, but then also the risk, hey, that this is used by a ton of people, but nobody's contributing to it anymore. That's a concern. And that would be great to potential users of that to signal whether or not it makes sense. The Open Source Security Foundation, just getting off the ground, they're doing some work in this space, and I'm really excited to see where they go with that looking at ways to stop score critically. >> Well, this brings up a good point while we've got everyone here, let's take a plug and plug a project you think that's not getting the visibility it needs. Let's go through each of you, point out a project that you think people should be looking at and talking about that might get some free visibility here. Anyone want to highlight projects they think should be focused more on, or that needs a little bit of love? >> I think, I mean, particularly if we're talking about these sort of vulnerability issues, there's a ton of work going on, like in the Secure Software Foundation, other foundations, I think there's work going on in Apache somewhere as well around the bill of material, the software bill of materials, the Secure Software supply chain security, even enumerating your dependencies is not trivial today. So I think there's going to be a ton of people doing really good work on that, as well as the criticality aspect. It's all like that. There's a really great xkcd cartoon with your software project and some really big monolithic lumps. And then, this tiny little piece in a very important point that's maintained by somebody in his bedroom in Montana or something and if you called it out. >> Yeah, you just opened where the next lightening and a bottle comes from. And this is I think the beauty of Open Source is that you get a little collaboration, you get three feet in a cloud of dust going and you get some momentum, and if it's relevant, it rises to the top. I think that's the collective intelligence of Open Source. The question I want to ask that the panel here is when you go into an enterprise, and now that the game is changing with a much more collaborative and involved, what's the story if they say, hey, what's in it for me, how do I manage the Open Source? What's the current best practice? Because there's no doubt I can't ignore it. It's in everything we do. How do I organize around it? How do I build around it to be more efficient and more productive and reduce the risk on vulnerabilities to managing staff, making sure the right teams in place, the right agility and all those things? >> You called it, they got to get skin in the game. They need to be active and involved and donating to a sustainable Open Source project is a great way to start. But if you really want to be active, then you should be committing. You should have a goal for your organization to be contributing back to that project. Maybe not committing code, it could be committing resources into the darks or in the tests, or even tweeting about an Open Source project is contributing to it. And I think a lot of these enterprises could benefit a lot from getting more active with the Open Source Foundations that are out there. >> Liz, you've been actively involved. I know we've talked personally when the CNCF started, which had a great commercial uptake from companies. What do you think the current state-of-the-art kind of equation is has it changed a little bit? Or is it the game still the same? >> Yeah, and in the early days of the CNCF, it was very much dominated by vendors behind the project. And now we're seeing more and more membership from end-user companies, the kind of enterprises that are building their businesses on Cloud Native, but their business is not in itself. That's not there. The infrastructure is not their business. And I think seeing those companies, putting money in, putting time in, as Brian says contributing resources quite often, there's enough money, but finding the talent to do the work and finding people who are prepared to actually chop the wood and carry the water, >> Exactly. >> that it's hard. >> And if enterprises can find peoples to spend time on Open Source projects, help with those chores, it's hugely valuable. And it's one of those the rising tide floats all the boats. We can raise security, we can reduce the amount of dependency on maintain projects collectively. >> I think the business models there, I think one of the things I'll react to and then get your guys' comments is remember which CubeCon it was, it was one of the early ones. And I remember seeing Apple having a booth, but nobody was manning. It was just an Apple booth. They weren't doing anything, but they were recruiting. And I think you saw the transition of a business model where the worry about a big vendor taking over a project and having undue influence over it goes away because I think this idea of participation is also talent, but also committing that talent back into the communities as a model, as a business model, like, okay, hire some great people, but listen, don't screw up the Open Source piece of it 'cause that's a critical. >> Also hire a channel, right? They can use those contributions to source that talent and build the reputation in the communities that they depend on. And so there's really a lot of benefit to the larger organizations that can do this. They'll have a huge pipeline of really qualified engineers right out the gate without having to resort to cheesy whiteboard interviews, which is pretty great. >> Yeah, I agree with a lot of this. One of my concerns is that a lot of these corporations tend to focus very narrowly on certain projects, which they feel that they depend greatly, they'll invest in OpenStack, they'll invest in Docker, they'll invest in some of the CNCF projects. And then these other projects get ignored. Something that I've been a proponent of for a little bit for a while is observability of your dependencies. And I don't think there's quite enough projects and solutions to this. And it sounds maybe from lists, there are some projects that I don't know about, but I also know that there's some startups like Snyk and so forth that help with a little bit of this problem, but I think we need more focus on some of these edges. And I think companies need to do better, both in providing, having some sort of solution for observability of the dependencies, as well as understanding those dependencies and managing them. I've seen companies for instance, depending on software that they actively don't want to use based on a certain criteria that they already set projects, like they'll set a requirement that any project that they use has a code of conduct, but they'll then use projects that don't have codes of conduct. And if they don't have a code of conduct, then employees are prohibited from working on those projects. So you've locked yourself into a place where you're depending on software that you have instructed, your employees are not allowed to contribute to, for certain legal and other reasons. So you need to draw a line in the sand and then recognize that those projects are ones that you don't want to consume, and then not use them, and have observability around these things. >> That's a great point. I think we have 10 minutes left. I want to just shift to a topic that I think is relevant. And that is as Open Source software, software, people develop software, you see under the hood kind of software, SREs developing very quickly in the CloudScale, but also you've got your classic software developers who were writing code. So you have supply chain, software supply chain challenges. You mentioned developer experience around how to code. You have now automation in place. So you've got the development of all these things that are happening. Like I just want to write software. Some people want to get and do infrastructure as code so DevSecOps is here. So how does that look like going forward? How has the future of Open Source going to make the developers just want to code quickly? And the folks who want to tweak the infrastructure a bit more efficient, any views on that? >> At Gaggle, we're using AWS' CDK, exclusively for our infrastructure as code. And it's a great transition for developers instead of writing Yammel or Jason, or even HCL for their infrastructure code, now they're writing code in the language that they're used to Python or JavaScript, and what that's providing is an easier transition for developers into that Infrastructure as code at Gaggle here, but it's also providing an opportunity to provide reusable constructs that some Devs can build on. So if we've got a very opinionated way to deploy a serverless app in a database and do auto-scaling behind and all stuff, we can present that to a developer as a library, and they can just consume it as it is. Maybe that's as deep as they want to go and they're happy with that. But then they want to go deeper into it, they can either use some of the lower level constructs or create PRs to the platform team to have those constructs changed to fit their needs. So it provides a nice on-ramp developers to use the tools and languages they're used to, and then also go deeper as they need. >> That's awesome. Does that mean they're not full stack developers anymore that they're half stack developers they're taking care of for them? >> I don't know either. >> We'll in. >> No, only kidding. Anyway, any other reactions to this whole? I just want to code, make it easy for me, and some people want to get down and dirty under the hood. >> So I think that for me, Docker was always a key part of this. I don't know when DevSecOps was coined exactly, but I was talking with people about it back in 2012. And when I joined Docker, it was a part of that vision for me, was that Docker was applying these security principles by default for your application. It wasn't, I mean, yes, everybody adopted because of the portability and the acceleration of development, but it was for me, the fact that it was limiting what you could do from a security angle by default, and then giving you these tuna balls that you can control it further. You asked about a project that may not get enough recognition is something called DockerSlim, which is designed to optimize your containers and will make them smaller, but it also constraints the security footprint, and we'll remove capabilities from the container. It will help you build security profiles for app armor and the Red Hat one. SELinux. >> SELinux. >> Yeah, and this is something that I think a lot of developers, it's kind of outside of the realm of things that they're really thinking about. So the more that we can automate those processes and make it easier out of the box for users or for... when I say users, I mean, developers, so that it's straightforward and automatic and also giving them the capability of refining it and tuning it as needed, or simply choosing platforms like serverless offerings, which have these security constraints built in out of the box and sometimes maybe less tuneable, but very strong by default. And I think that's a good place for us to be is where we just enforced these things and make you do things in a secure way. >> Yeah, I'm a huge fan of Kubernetes, but it's not the right hammer for every nail. And there are absolutely tons of applications that are better served by something like Lambda where a lot more of that security surface is taken care of for the developer. And I think we will see better tooling around security profiling and making it easier to shrink wrap your applications that there are plenty of products out there that can help you with this in a cloud native environment. But I think for the smaller developer let's say, or an earlier stage company, yeah, it needs to be so much more straightforward. Really does. >> Really an interesting time, 10 years ago, when I was working at Adobe, we used to requisition all these analysts to tell us how many developers there were for the market. And we thought there was about 20 million developers. If GitHub's to be believed, we think there is now around 80 million developers. So both these groups are probably wrong in their numbers, but the takeaway here for me is that we've got a lot of new developers and a lot of these new developers are really struck by a paradox of choice. And they're typically starting on the front end. And so there's a lot of movement in the stack moved towards the front end. We saw that at re:Invent when Amazon was really pushing Amplify 'cause they're seeing this too. It's interesting because this is where folks start. And so a lot of the obstructions are moving in that direction, but maybe not always necessarily totally appropriate. And so finding the right balance for folks is still a work in progress. Like Lambda is a great example. It lets me focus totally on just business logic. I don't have to think about infrastructure pretty much at all. And if I'm newer to the industry, that makes a lot of sense to me. As use cases expand, all of a sudden, reality intervenes, and it might not be appropriate for everything. And so figuring out what those edges are, is still the challenge, I think. >> All right, thank you very much for coming on the CUBE here panel. AWS Heroes, thanks everyone for coming. I really appreciate it, thank you. >> Thank you. >> Thank you. >> Okay. >> Thanks for having me. >> Okay, that's a wrap here back to the program and the awesome startups. Thanks for watching. (upbeat music)