 Okay, hello and welcome back to the AWS startup showcase. I'm John Furrier, 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, Liz Rice, Chief open source officer, ISO Valen, CUBE alumna, great to see you. Brian Laro, who's a co-founder and CTO of begin.com. Erica Windich, who's an architect for develop experience, AWS hero, also CUBE alumni. Casey Lee, CTO gaggle, doing some great stuff in EdTech. Great collection of experts and experience, folks doing some fun stuff. Welcome to this conversation, this CUBE panel. Hi. Thanks for having us. 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 ISO Valen, I focused on Cillium, 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 Open UK, which is really pushing for more use of open technologies here in the United Kingdom. So kind of 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 on a project these days called architect. It's an open source project built on top of AWS SAM. It adds a lot of sugar and terseness to the SAM experience. It 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. 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. 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 it'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, I totally agree. 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 SDKs and CLI components from my current employer. And previously, recently I left New Relic where I was working on integrating with open telemetry 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 SDKs and developer tools is kind of where Docker and OpenStack and the SDKs that I work on now all very much focusing on developer as the user. You're always on the wave, Kate, I was on the wave, Erica, great stuff. Casey, what's going on with you? You got some great ad text 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 Action workflows locally. And so this tool uses Docker containers to emulate the GitHub Action environment and gives you fast feedback on those workflows that you're building. A 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 I 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 kind of 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, well make sure the SiliconANGLE writers catch that quote there. Great call out. All right, let's start, Ron. You made me realize when you mentioned the patching that you've been kind of watching all the stuff going on. Brings up the question of the evolution of open source and the commercialization trends have been very interesting these days. Just seeing cloud scale 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're starting to see the, Netflix donates some something. You got, you know, Lyft donates 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 kind of a new kick up 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 kind of why it's front of mind for me right now, because 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 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. It was open source wasn't around. Like you had to kind of deal it under the table. Now it's free. But I mean, the old way was you had to convince the enterprise. Like you got to harden it, to build the community and the community managed 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. You know, 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 like well-known, trod happy path, but how these were a lot better with the more diverse community with lots of options, with lots of ways to approach these problems. And I think it's just great. The challenge that we have with all these options and all these Cambrian explosion of projects and all these competing ideas, right now the sustainability is 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 the tough one for a lot of folks. Yeah, Rika, can 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? Mark, I'm verified. What's code? I mean, all, I mean, these are questions. Like, well, how do you navigate? Yeah, I think this has been something that's been happening for a while. I mean, back in the early OpenStack days, 2010 for instance, Rackspace, OpenSourcing, OpenStack and Anso Labs and so forth. And then trying, having all these companies forming and creating startups around this. I started at a company called Cloud Scaling back in late 2010 and we had some competitors such as Piston and so forth where a lot of the Anso 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, and 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 preceded 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 outsize 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 the vulnerability in it brings 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 an adventure capital model in and saying, hey, that boring little logging thing could be a key ingredient for, say, solving some observability problems and it's like, let's put some cash. Again, then we never seen that before. Now you're starting to see that kind of real smart investment thesis going into open source projects. I mean, Prometheus, Kraft, these are the projects that turned off companies. This is turning up companies. A decade ago, there was no money in DevTools, but I think that's been fully debunked now. There used to be a concept that the venture community believed, but there's just too much evidence the contrary, companies like Cashacord, Datadog, this goes on and on. I think that the challenge for the open source comes back to foundations and working 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 say, I won't say white spaces, but 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 pre-commercialization 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 log for J-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 what quantifying criticality was the article he wrote on how to use metrics to determine how valuable, how important a piece of open sources 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, 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 kind of 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, 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 would make 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 score critical. Well, this brings up a good point. Well, we 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 pre-visibility here. Anyone want to highlight a project 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 and 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 pulled it out. You never know where the next lightning in 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, 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 the panel here is, when you go into an enterprise, 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, 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, could be committing resources into the docs or into 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 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. It's hard. If enterprises can find people 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 raise the reduced the amount of dependency on maintain projects collectively. I think the business model's there. I think one of the things I'll react to and then get your guys' comments is remember which KubeCon it was, it was one of the early ones and 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 kind of goes away because I think this idea of participation is also talent. But also committing that talent back, right, into the communities. As a business model, like, okay, hire some great people but listen, don't screw over the open source piece of it because that's 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 large 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, it's gonna come. 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 open sector, they'll invest in Docker, they'll invest in some of the CNCF projects and then these other projects kind of get ignored. Something that I've been a proponent of for a little bit of 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 Liz there are some projects that I don't know about but I also know that there's some startups like Sneak 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 having some sort of solution for observability of their 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 certain criteria 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 at software people develop software. You see under the hood kind of software SREs developing very quickly in the cloud scale but also you got your, you know 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 got the development of, you know 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 is the future of open source going to make the developers just want to code 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 YAML or JSON 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 and a database and do auto scaling behind all this stuff we can present that to a developer as a library and they can just consume it as is. And 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 change 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? Do you think they're taking care of form? No, I'm only kidding. No, I'm only kidding. 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 tunables that you can control further. You asked about a project that may not get enough recognition is something called Docker Slim, which is designed to optimize your containers and will make them smaller. But it also constrains the security footprint and will remove capabilities from the container. It will help you build security profiles for AppArmor and the Red Hat one, SC Linux. Yeah, and, you know, this is something that I think a lot of developers, you know, 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, you know, when I say users, I mean developers, you know, 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, you know, serverless offerings, which have these security constraints built in out of the box and sometimes maybe less tunable, but, you know, very strong by the thought. And I think that's, you know, a good place for us to be is where we just enforce these things and make you do things, you know, in a secure way. Yeah, I'm a huge fan of Kubernetes, but it's not the right hammer for every, you know, 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, you know, security profiling and making it easier to kind of shrink wrap your applications. That, you know, 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. We're at 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. And if GitHub's to be believed, we think there's 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 to move towards the front end. We saw that at re-invent when Amazon's really pushing amplify, because they're seeing this too. It's interesting because this is where folks start. And so a lot of the abstractions 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. So figuring out what those edges are is still the challenge, I think. All right, thank you very much for coming on the CUBE panel. AWS heroes, thanks everyone for coming on. I really appreciate it. Thank you. Thank you. Thanks for having me. Okay, that's a wrap here. Back to the program and the awesome startups. Thanks for watching.