Kyle Quest: You ask people, throw away the tools you have, throw away how you build the applications and do it this new way. That's too much to ask. If you don't ask people to change, then you're more likely to succeed and that's why DockerSlim was successful because it allowed developers to keep what they had and get the outcomes they wanted. Eric Anderson: This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson. Today, I am joined in the studio with Kyle Quest. He's the creator of DockerSlim, and now works at Slim.AI, which is helping to commercialize and kind of mature DockerSlim. Kyle, thanks for coming. Kyle Quest: Nice to be here. I don't just work there. I actually founded the company, and there's a connection there. I will talk about it later. Happy to be here and happy to talk about DockerSlim and the problems it tries to solve. Eric Anderson: Awesome. You're here to talk about the story of DockerSlim, but tell us first what it is so that we can kind of understand the context of the matter. Kyle Quest: So DockerSlim is about helping you develop containerized applications and take them to production. It started as a hackathon project and it focused only on what I call minifying images. It takes an image that's less than optimal and maybe more developer friendly, and it creates an image that's more production ready. It has less stuff in that container image so the attack surface is reduced. It only contains the application and what it needs, and then it also generates additional security configurations that you can also leverage. So it saves a lot of time. It allows web developers or any other developers focus more on the application side and less on the infrastructure side. Containers is one of those fundamental components in the cloud native infrastructure landscape. So that's kind of fundamental. You want to focus on the application, but you have to deal with containers and the less you have to do there and now the better it is. Kyle Quest: It's actually, I'd say it's one of those hidden problems when it comes to DevOps, there's tons of definitions of DevOps, but one of my favorites is, you build it, you run it. It's awesome. It's amazing. But it also means that the application developers need to be infrastructure experts and that's just not realistic. It's stuff to keep up with everything that's going on with web applications and the frameworks and all of that, and then you need to know about the infrastructure. That's just not realistic in their natural kind of hacks that emerged, the DevOps engineer role. That's how it appeared because there is a disconnect between that concept and reality. So they introduced people who know more about the infrastructure, but then by doing that, they introduced another problem. Kyle Quest: Now, you have two different people working with the infrastructure side and the application side. People on the infrastructure side, they don't understand the application, people on the application side, they don't understand the infrastructure. In a way, DockerSlim kind of bridges that gap, it helps you take your application and get it to production with the cloud native infrastructure you have, and right now it means containers. Eric Anderson: So in my head I'm imagining a compression, like I would zip up a file to make it smaller. But you're pointing out that it's more than just making it smaller, that has security benefits, speed benefits. Kyle Quest: Yeah. We benchmarked a number of different parameters. So for example, the startup time, the push time for images, because if you have a fat image, it takes longer, you have more data. So it takes longer to push that image to your registry, and then it also takes longer to pull that image from the registry to the node where it needs to be. There are lots of details there around caching and layers and all of that. But fundamentally that is a problem even with layers and all of that, and it's even a bigger problem with a serverless and the tech there. Then, one of the fundamental concepts in security is the concept of attack surface. I'm a security person. I've been involved in security for more than 25 years probably. I've done pretty much everything. It's nice to see the concept of attack surface reduction going mainstream. Kyle Quest: It's awesome, but there are practical implementation challenges. It's easy to say, well, don't put stuff you don't need in your images, like they say in the container best practices. But how do you do that? Nobody puts stuff they don't need in their containers unless you do it for the fun of it. Usually you end up with the stuff there because you think you need it or the application pulls it or some other reason. So there are those practical details that prevent this concept from being a reality. It's good that more people are aware of that, but there's still an implementation challenge that to have that as a reality. DockerSlim actually helps you with that because it gives you the stuff that you need and eliminates the stuff you don't need. Eric Anderson: Got it. There's actually more I want to talk to you about there, because people have tried to do this in other ways in the past, unikernels and other approaches to kind of remove stuff we don't need. But before we go into that, we'll come back to it. Tell us the story of how you got here, you mentioned a hackathon, is that the beginning? Or were you working on kind of related stuff before this? Kyle Quest: One of the fundamental concepts behind DockerSlim is application intelligence, and an application centric approach to solving these DevOps and cloud infrastructure challenges. My initial POC way back actually didn't involve containers and we barely had containers back then, but the concept is universal. So if you look at a lot of the solutions that are out there, lots of popular tools, they are all pretty much infrastructure centric for a number of reasons. One of them is because it's easier. Another reason is that it's just where we are in the evolution of things. We are in the stone age of the cloud native infrastructure. In a way, it kind of feels like application development back in the day when you build applications with assembly, not punch cards anymore, but assembly. Nobody builds applications in assembly anymore. So it's kind of in this early stage, lots of new things, new tools, exciting, but there's also a lot of what you have to do is doing it the hard way, kind of dealing with the assembly language of the cloud native infrastructure. Kyle Quest: It's definitely not going to stay that way. One of the reasons why we're there is because we're kind of focusing on the backend of that cloud native infrastructure tooling side. Where we're close to the resources and we are trying to automate that, and eventually will evolve closer to the application side. Because we are closer to the infrastructure, there is a disconnect between the infrastructure and the application. Like I mentioned with DevOps, you have application developers who know the applications, then you have DevOps engineers who know the infrastructure, but there's a step in between that you need to go through. You have lots of tools on the infrastructure side, Terraform, other things. I'm not saying DockerSlim is like Terraform, but I'm saying that Terraform is a great example of an infrastructure centric tool. It takes a long time before you can run Terraform Plant, Terraform apply. Kyle Quest: You need to build all of those configurations, and like with one of my previous projects and previous companies, we built a pretty advanced system from scratch but Terraform, it took more than a year. So there's all this hidden work that happens, lots of manual work, lots of domain knowledge on the infrastructure side, and a lot of work on the application side, reverse engineering, what it actually does. So there's all this manual work and complexity that you deal with in, in this so-called stone age. One of the reasons for it is because the tooling that exists, it's more infrastructure centric and you need humans to program those tools. Those humans need to know a lot about those tools, about the infrastructure behind those tools and all of that. Kyle Quest: With DockerSlim, it piloted the idea of an application centric approach. So what does it mean? It means that DockerSlim captures a whole bunch of information about the application, what it is, how it's structured, what it needs, how it interacts with the different components and the outside world. Then, once it captures that information, it leverages that information to automate some of the activities that you have to do manually. For example, right now, to create optimized images, you need to manually do a lot of things. You need to pick a base image that might be smaller, then you need to structure the layers in a certain way, you need to optimize the commands in your Dockerfile. You might need to move things around, or do a whole bunch of other things. That requires a lot of domain knowledge and it requires time. For example, if you use multistage builds, you build your application in one stage, and then you copy its artifacts to another stage. But do you know what to copy? Kyle Quest: You actually don't know, always know what to copy. Yeah. It's simple for a simple whole world application, but for a more complicated application, you have a lot of things. Yeah. You kind of need to go and research a lot of things and things change, your application change, your dependencies change, and you have to do it manually. So by capturing that application information, that information can be leveraged to automate a lot of the manual things that happen now. That's really the idea behind DockerSlim doing that and automating the things that had to be done manually, something that required domain knowledge about how to do it properly. Eric Anderson: So if I could try and summarize what you're saying here. We're in the stone age of cloud native, despite all the enthusiasm for cloud native, it's still early days. That's evidenced by the fact that we're doing all this manual work. To get to build an application, we have to build all this infrastructure. You might say this is kind of low level things, we're stacking on top and there's a lot of domain knowledge and the work that goes into that. We should be building things kind of top down just to find the application and everything else to takes care of itself. You're saying DockerSlim is a foray into that world. DockerSlim looks at the application, determines what's necessary and gets rid of everything else. Kyle Quest: Yes. It's not necessarily a gacha, but one thing to keep in mind and something that's really important is when you want to introduce something new and you change the tooling that developers have. You ask people to change how you do things, what tools you use, that's going to be a difficult sell. One of the examples of that is darkling. It's this interesting concept, interesting language that allows you create these cloud native applications. It's awesome, it kind of accomplishes some of the same things in a way kind of helps you as a developer, not think about the infrastructure side, but you have to switch your languages. You have to change your tools and that's a hard sell. So, and that's another important thing about DockerSlim is that it helps you keep the tools and the processes you have. Kyle Quest: For example, you don't need to change your base image. If you're using Debian or Ubuntu, it's okay, we'll get you that optimized image, you don't need to deal with Alpine. Some people say, "Just use Alpine," sounds good in theory, but in reality, lots of gacha. See if you're lucky enough that it works for you, good, but tons of problems. Kind of different, but serverless. People will say, "Well, we have serverless. So we don't have that problem." Well, not really the case. You still need to know about the... Need to know about the limitations and constraints of serverless, where it works, where it doesn't work, how to configure it. So yeah, those different interfaces to work with, even with those, you need to know about the infrastructure and then they lack the application context. Even those higher level constructs like serverless. Eric Anderson: So Kyle, you've done a lot of interesting things throughout your career. You were doing a bunch of data work. I mean, you've been through Microsoft, through CrowdStrike, led companies. At what point do we start the story that feels like you're headed towards DockerSlim? Kyle Quest: Well, I think it started before that and it's kind of related to the security work I've done. Like I mentioned, I've been involved in security for quite a while, more than 25 years. One of the things I try to do over the years is identifying malware and attackers and observing what they do. There are a lot of interesting techniques and tools that exist in that space. That tooling can be repurposed and that's exactly what I did with DockerSlim. So there are a lot of interesting capabilities in terms of identifying what malware does, what it is, how it's structured, how it behaves and those techniques and the knowledge you get from that is useful in other ways. So it's taking those tools that are used for malware in the concept, and pointing them at your normal applications, and then leveraging that tooling to capture the application information. Kyle Quest: That's actually, in Slim.AI, AI stands for Application Intelligence, not Artificial Intelligence. It's that fundamental concept, and the concept started back in the day when I was doing security, a lot of security hunting malware and trying to understand it, classify it, and all of that. Then, eventually it evolved in a version that was applied to Windows and Windows applications, trying to identify what the applications are, their components, kind of creating an application DNA. Then, leveraging that information, leveraging the application DNA information to do application backup. So you could move applications and all of its dependencies, that's before containers and all of that. Another one is having a more intelligent way of identifying malware, where instead of a blacklist, you have the opposite. There's only so much you can do what those denial lists or blacklists, and it's brittle, because you don't know another malware comes. With a good software, white listing was kind of hot at that point, but white listing also, the white listing, the traditional white listing doesn't work as well because it's too inflexible. Kyle Quest: You have a hash for an application, for an executable or for a shared object, and then it may a change because the application changes. It gets update all the time, and all of that, so it lives. That kind of way of identifying the good applications and kind of the reverse was brittle. I figured, there must be another way to have a more flexible way to identify the good applications and the bad applications. Eventually, when I started doing more cloud development and container development, those concepts kind of emerged again. Because I kept seeing those same problems with applications, delivering applications to production. But the application developer and the DevOps engineer problems where it took weeks to get something to production and then maintaining the applications in production was more challenging. Because again, it's constantly being updated. Kyle Quest: You need to change how you deploy things and all of that. So that concept of capturing the information about the application expanded its scope. Then, yeah, like I mentioned, the initial POC was with AWS, no containers whatsoever. I used it to automatically generate AWS configurations I needed for my applications, including security groups and policies and all of that, that you have to create otherwise manually. Then later on, when containers gained more traction, Docker actually had those hackathons, global hackathons. I figured, well, maybe it's a good time to apply the same concept to containers. That's how the initial version of DockerSlim was created, and the rest is history. Eric Anderson: What impresses me a bit about your background, you've done some, like I said, some really cool things and yet, you were going to this kind of hackathon to work on a new project. You would think somebody of your caliber wouldn't maybe have the time for hackathons, but I thought it was kind of cool that you were doing some community work. Kyle Quest: Yeah. I'm pretty hands on in general. I try to participate in different events and in some cases hosting events, and all of that. Yeah. I'm still a big fan of doing that, and I plan to do a lot more of that. Eric Anderson: So you have this history of security and application centric intelligence, and you come to this hackathon. Did you know you were going to work on container compression at the hackathon? Or did that just happen? Kyle Quest: I did know. I planned, I prepared for it. I thought, well, there's going to be a hackathon. It's going to be about containers and Docker. So what could it be? It kind of naturally emerged because it's a theme that kept revisiting over the years with different tools and technologies, and all of that. So I figured, we need to work with containers, creating production ready containers was too much work, too much manual work and required too much expertise and like most people, especially in 2015 weren't container experts. So it made sense. Eric Anderson: Then, after the hackathon, you're excited enough about the thing you built there that you kept working on it, presumably? Kyle Quest: Yeah. Because I literally built it for myself, so I kept working on it so I could use it more. I could use it for more applications and it's still an ongoing process. Because, again, I start with my needs and then expand to other use cases. There are a lot of different applications where the flow and the UX side of things can be improved. For example, the initial goal for DockerSlim was to optimize server applications with web APIs and HTTP APIs, like microservices, that was the goal. Because that's the kind of systems I was building at the time, still building applications with the HTTP APIs and all of that. So that was the starting point and it worked much better there, and then kind of other use cases came up. Eric Anderson: Do you get awards at hackathons? Is there a winner? Kyle Quest: Yeah. So with that hackathon, DockerSlim got the first place in Seattle and then it got the second place in the plumbing category. I still have the t-shirt and the sweatshirt they send me. Eric Anderson: Yes. Yeah. Historical artifacts for sure. Was it open source initially, or when did that happen? Kyle Quest: Yeah. Yeah. Yeah. I mean, that's the whole point of those hackathons, that you create something open source, and then you submit a PR with your application. Then, yeah, it barely worked when it was submitted. I spent probably an hour thinking about whether or not I should submit it or not, because it was barely functional. So I got that close to not submitting. Eric Anderson: Yeah. I'm so glad you did. When do other people show up to the open source project? At what point do you find other users? Kyle Quest: It happened over time. It didn't happen overnight. Docker, they published the hackathon results. So a few people learned about the project that way, then at some point it was even mentioned in one of the Docker blogs way back. So it got more visibility and exposure that way, and over time people would look for a way to slim their images and they ended up landing there. So they would type DockerSlim and they would get either pants or the tool. Eric Anderson: Good. At what point did you think we should create a company here? Kyle Quest: So over the years, the tool got a lot more traction, more people were using it in ways that I didn't expect the tool to be used. People had tried to incorporate the tool in their CICD pipelines, tried to use it for their embedded systems. There was somebody trying to use DockerSlim to optimize images for robots that it was kind of interesting that they had containers in those robots, but that's what they wanted to do. There was more and more traction, more interest, people kept asking for different things. The problem resonated with a lot of people, and the approach also resonated with a lot of people. The demand kept growing and the use kept growing, and in addition to increased use, people would keep asking a lot more. For example, they wanted to know, well, we have these optimized images, tell me what happened, or help me integrate DockerSlim in my pipeline, and all over that. Kyle Quest: So naturally this bigger need emerged to have an end-to-end solution, something that would connect the dots and integrate what the environments developers had. So that's the goal, but Slim.AI to take it to the next level, kind of take the core engine and build the platform around it, but lots of connectors. So it's kind of this fabric that helps you deliver containerized applications to production. There's a lot of related capabilities, for example, that are not in DockerSlim, but Slim.AI it's kind of like Google for containers. You go in there, you can connect, and we're not connecting to every single registry type, but that's the intent. You go in there, you get access to all public registries and then you can also connect your own private registries or your authenticated accounts. Kyle Quest: Then, you can search across all of those different places. So it kind of unifies all of those different silos that you wouldn't be able to do with DockerSlim. So that's kind of a great example of how it kind of fits together. With DockerSlim it powers our visibility capabilities, but you get to visibility by discovering the container images that are located in all of those registries and all of that, and there's a lot more that's there. It'll take a while to describe every little capability now, and there's a lot more coming as well. Eric Anderson: This is the first company you started, right? I think you've done a lot of joining companies, and being key kind of technical leader in early companies. But is this the first one you founded? Kyle Quest: There's always startups. They start with something small and a lot of times they don't go too far. So I've had a number of ideas and started a few things, but they weren't as successful because it happens a lot. So DockerSlim and then with Slim.AI, it's been the most successful project and commercial company. So that's life. That's how things happen. Eric Anderson: Yeah. It's always the last place you look, the way you find something. Kyle Quest: Yeah. You just keep trying. Eric Anderson: So I mentioned unikernels a while earlier, if we kind of pivot back to talking about the technology, which I thought were kind of exciting in the early container days. It felt like maybe a potential evolution never really materialized probably for obvious reasons. This seems like a more, as you said, application intelligent way of getting rid of the excess in Linux you don't need. Kyle Quest: It's kind of related to what I talked about asking for change. Eric Anderson: Right? Kyle Quest: Unikernels is a cool concept, cool tech, but it's different. It's so much different that it just didn't, kind of like with Dark Lang, it just didn't get the adoption that it probably deserves and maybe it's too early. Maybe we revisit the concept later on it'll be easier and more natural later on. But at this point, and when it emerged initially it was too different. It was different from the way people built applications. So you ask people throw away the tools you have, throw away how you build the applications and do it this new way. That's too much to ask, like with anything, tech, losing weight, just don't eat this food. Well, easier said than done it. It really, it's difficult to change and if you don't ask people to change, then you're more likely to succeed. That's why DockerSlim was successful because it didn't ask people to change. It allowed developers to keep what they had and get the outcomes they wanted. Eric Anderson: Maybe that's the magic of DockerSlim. Was it obvious to you that this could be done at the beginning? I think some people would wonder, how do you know what you can take out and what you can leave and not hurt the application? Do you actually execute the application in order to trace all the dependencies that are necessary? Or do you have a more kind of fast intelligent ways of figuring out what's unnecessary? Kyle Quest: Yeah. So this is kind of the idea behind that is based on the body of work that's been done when it comes to malware, and dealing with malware and understanding that. Just like with malware, you have opportunities to inspect the application statically, and then you also inspect the application dynamically. So you have static and dynamic analysis, and to have better coverage, you obviously want to combine the two. That's exactly what happens with DockerSlim. Is it perfect right now? No, because first of all, the algorithm is still early on and it needs to evolve, and there are certain types of analysis, types that still need to be added. So it'll need to mature and that's the whole point to be able to invest more and mature the concept, mature the algorithm and get more out of that. Kyle Quest: But the core idea there, you combine static analysis with dynamic analysis and you get that coverage you need. You don't need perfect coverage. You need to make sure that the components that get loaded are loaded. With some languages it's more involved than others, say in some languages you have the concept of lazy loading, where things don't get loaded until later on. You can pick on it, you can come up with lots of excuses that, yeah, it's not going to work, but in reality there's theory and then there is reality where things work 99.999% of the time. I'm more practical and closer to reality than theory. So I stick with facts, and one way to ensure that you have something that should do what you need to is tests. That's one of the things we're trying to simplify, integrating your testing infrastructure with the process. So that way you can run your test before, you can run your test after, you can verify that the behavior you get is what you expect and you get the same outcomes. Eric Anderson: Yeah. No. It does seem unique, right? When you take a malware, look at it, you discover new things. Kyle Quest: Yeah. For example, with malware analysis there's lots of disassembly going on. You take apart the malware and you slice it and dice it in many different ways. Yeah. It's amazing the kind of research and experiments that happen there. So yeah, leveraging that is super useful. Even on the testing side, with concepts like fuzzing, blackbox fuzzing where you generate input to an application, and then you observe what happens in the application and what parts of the application get triggered. Then, you adjust the input to trigger other parts of the application. So there are a lot of interesting things that could be leveraged. Eric Anderson: As we kind of wrap up here, Kyle. You mentioned, we're in the stone age of cloud infrastructure and we need to take a more application centric approach, and Slim is an early kind of foray into this. What's the next foray? Or are there things you're doing at Slim.AI, for example, that take us closer? Or what do you get excited about as another hurdle? Kyle Quest: So I would kind of go back to the concept of application intelligence. Right now we're looking at containers, but the concept of the application centric approach and application intelligence is universal. You have the same problems with Lambda and serverless, you have the same problems with IS, and all of that. We're starting with containers. Containers is a fundamental part of the cloud native infrastructure, but expanding that to other parts will be super exciting and that will lead to an opportunity to redefine how you do DevOps. Because right now DevOps, I mentioned that you have app developers, DevOps engineers, there's this disconnect and the domain knowledge you need to have in order to get something in production, and all that manual work. Changing that, imagining not spending all that time, creating Terraform configs or dealing with Docker files or dealing with Kubernetes manifest, and all of that. Kyle Quest: Automating a lot of that work and getting the applications to production faster, and application developers thinking more about the applications and less about the infrastructure. They create their applications, and then the cloud infrastructure they need that it's either fully automatically generated, or it's automated in a way that doesn't require a lot of time and a lot of domain knowledge. So kind of redefining how DevOps is done ultimately are going beyond containers, applying the concept of application intelligence in the application centric approach. That's where I get excited. Eric Anderson: Totally. I don't know if this is what you're saying, Kyle. But I'm imagining from what you're saying that it take serverless and Lambdas, if today I want to do serverless or Lambdas, I have to go read a bunch of documentation on the limits. Maybe even use kind of a different development environment that I'm used to in order to know not to exceed those limits. Then, I feel safe and I can deploy it to production, but I might have to do it in a different process than I'm used to. You're kind of saying that maybe I get to use all my existing tools and I don't have to think I'm deploying to Lambda. I just kind of write my application, and I hand it off to something that says, "Do you want to deploy this in a certain manner so that it's serverless?" and it just does it for me? That's a potential kind of best case future scenario. Kyle Quest: Yes. Something like that but there are a number of stepping stones towards that. Also, it's not a pure opaque abstraction where you just say, "I want stuff running in serverless." It's more of a flexible toolkit. There's a default path, but if want to customize, because that's where the past solutions failed. If you look at what happened when past solutions like Heroku, et cetera, emerged. They were exciting and all of that, but they hard coded the use cases. If you fit those use cases, it's fine, but if you don't, you're out of luck, and then eventually you kind of outgrow that and that's kind of what you need. You need to be able to customize that kind of higher level construct to a specific need, to a specific environment at some point. So you need to be able to support it. Kyle Quest: So something like that where you get this default behavior, but then there's an advanced mode where you can customize. You can get to the details of that serverless deployment, where you can see that, yes, it's Lambda, it's an AWS and you can make adjustments. But the things that you do there would be automated as well. So you wouldn't have to manually do them. So that's the key, again, not replacing the tools you have, still using AWS, still using the same services there is just getting to a usable state faster, as opposed to manually creating configs for Lambda. You get them either... You start with of the default, you make a few adjustments or you get something out generated, and then you customize if necessary or something like that. Kyle Quest: But yeah, I think that's the key, you need to be able to have this default but customizable in order to make it work. Otherwise, it's going to be the same thing that happened, but passes it. It's going to be good for a certain use case, but then there'll be limits in terms of what you can do and limits in terms of adoption because of that, because eventually you outgrow it. They happened in the past with the companies I worked with, used App Engine in Google, outgrew it, moved to AWS. It was super expensive, super complicated. Eric Anderson: You're helping me realize that it's one thing to imagine a future in a rosy scenario, that's one kind of form of innovative thinking. Another is to innovate in kind of a backwards compatible context to where you can get some of the benefits of the future, but still work within the context of the present. It seems like you've struck that happy medium with DockerSlim, it still works with all your tooling and yet you're a step closer to the future. Kyle Quest: Yeah. It may not be ideal, but it's practical. I'm seeing something similar with SixDoor, for example. SixDoor, you have notary, for example. It's kind of a competitor in a way when it comes to signing images. One of the examples of the same approach there is how they deal with signatures. They reuse tags for that. It's a hacky approach, but it works with the existing tooling, with the existing registries. You don't need new capabilities in the registries. You don't need to change the OCI spec for the registries and all of that and it's much easier. That's the route that I chose for DockerSlim. You find a way to use the tools you have. Don't ask people to change and make it work good enough for things to work right now with what you have. Eric Anderson: We're using up a lot of time here. It's been great to have you. Anything last you wanted to say that we didn't cover. Kyle Quest: I would say if you never tried DockerSlim, give it a try. It's pretty straightforward. Once you install it, you run DockerSlim with DockerSlim build Nginx, that's the easiest example to use. Then you'll see what happens with your Nginx image, and then you run Nginx and you'll see it in action, and you'll see before and after. If you want to see more, try the SAS that we have. It's available now, there's a link on the DockerSlim page and there's a link on the Slim.AI page. You'll be able to do lots of cool things that developers care about. For example, being able to DIF images in a way that looks very similar to doing PRs and DIFS and GitHub and all of that. Kyle Quest: So yeah, give it a try, connect registries, try searching and reach out. If you have ideas and if you need something, or if something doesn't work. That's what I want to be able to do. I want to be able to help developers with their specific needs. You're building a containerized application, you don't know something, or you wish you could do something in an automated way. I want to learn about those problems and use cases. Eric Anderson: I love what you said. We actually chatted before we started recording the episode here, and I was asking, Kyle, "Would you want to talk about community development and this or that?" He's like, "I don't know how to do those things. I just really like working on these problems and really like collaborating with people." There's a certain amount of authenticity I get, you're not really scheming about how to make DockerSlim a major project. You're just trying to make it work and make it work for everybody's problems, and very practically oriented and people oriented. I think that's serving you well. Kyle Quest: I'm happy to help, whenever somebody mentions something, I try to investigate and even if it's not related to DockerSlim. It's kind of one battle at a time, and I want to use that as an opportunity to improve DockerSlim. So other people don't have to go through those problems anymore. So yeah, there's no magic solution in terms of on the community side. Yeah. I wish I had more time, and now we have more people participating and contributing, that's good. So growing the number of contributions and that's one of the things on my to-do list. There's a couple of videos for DockerSlim, it's code structure and all of that, want to do more so others can contribute easier and all of that. So that's one of the investment areas that I do have, making it easier to contribute. Eric Anderson: Awesome. Thanks for coming today. This has been fun. Kyle Quest: Awesome. Eric Anderson: You can find today's show notes and past episodes at contributor.fyi. Until next time. I'm Eric Anderson, and this has been Contributor.