 Oh, I'm good. Okay. Hello everybody. Once again, my name is Dave Neary. I work for Red Hat. And my pandemic project for the last year, I started an interview series called Open Source and Business, which I have been recording live with an audience and posting to YouTube on a regular cadence since about this time last year. So I'm going to talk a little bit about some of the motivations that I had for that event, for that series, some of the questions that I had that I wanted to kind of dig into. And then we're going to hear some of the lessons that I think are like common themes that have come out through those speakers, as I've had more and more people that I've spoken to that I think are interesting. And we're going to hear from, you know, extracts, highlights from some of the interviews. Okay, so back in spring of 2020, about five years ago, that was a joke. Okay, never. If you have to say it, it's not funny. That's what I've been told. I was having all these conversations on Twitter and on social media in general, and I was seeing a lot of articles and a lot of discourse around open source business models. And, you know, there was a lot of, this time last year, a lot of discussion around some of the license innovation that's been happening in the open source space with MongoDB and server-side public license and the Commons Clause and so on. And I was struck by the fact that, you know, the discourse around open source in business and startups was very much dominated by, you know, how do I get VC funding? How do I scale quickly? Successful exits, whether that's an IPO or an acquisition. And there was a lot of people saying things like, we're never going to have another red hat or, you know, there's no successful open source business model. We haven't proven out business models. And yet, when I looked around, some of the people I know have what they would call very successful businesses. Now, they're not billion-dollar businesses. They're, you know, maybe running a couple of million dollars in revenue and they've got maybe 20 employees. But for what they're doing, they're very successful businesses. So I was concerned that maybe this definition of success was a bit limiting. And I wanted to really think about things with a broader lens. And there was a second trend that I've seen that started with, you know, roads and bridges from Nadia Ekbal, which kind of talked about some of the ways that, you know, fundamental infrastructure underlying the internet. And, you know, the technology world in general is relying on volunteer support. It's not very well funded. And we're seeing a lot of trends in the direction of how do we create more sustainable software communities and how do we ensure that we're, you know, securing our software supply chain has been really a hot topic for the last 12 months. But even before, it's something that's been a long-standing constraint. And really, I think Heartbleed back in 2014 was the thing that really raised this to the front of mind for everybody. It was the fact that, you know, you have OpenSSL was a project that was maintained by two volunteer developers called Steve, who had been doing it as a labor of love. And when you looked around, there were a lot of these projects that were underfunded. But while I have a ton of sympathy for that perspective, all of the attention seemed to be focused on a group of... this idea of developers of important software deserve a salary. That there were either pooled funding models like the Linux Foundation Core Infrastructure Initiative, which did a great job of getting, you know, millions of dollars of funding available to pay for developer salaries, but created another problem, right? Who deserves a paycheck and who doesn't? And then there's the TIPJAR models or the solidarity funding models, things like TIDELIFT and Open Collective. And again, I felt like that conversation was a little narrow and didn't come in, didn't think about, you know, there have been some projects that have been very, very successful at creating sustainable communities without necessarily having companies behind them. Or, you know, I just, again, I felt like there was something missing in the discourse around this area and I wanted to dig into it a little bit. And so, most of all, I felt like the discourse around open source and business in general had become a little bit polarized and was lacking in nuance and I really wanted to bring some nuance to the discussion. So I got a group of people together. Matt, A.C., Stephen, Wally, Leslie, Hawthorne and Deb Bryant helped me to kind of brainstorm a set of speakers. We invited a bunch of people who were experts in their field and we interviewed them. And we prepared these interviews basically to dig in on a specific topic, different topic every week and kind of try and get some, like I said, some nuance around this discussion. And so these are some of the lessons learned from about 25 hours of interviews so far. I've got a third season that's just starting now and I wanted to share some of the common threads that I saw through the series so far. So the first one, the biggest question I had when the series started was what models exist out there that maybe aren't getting the media attention or maybe aren't getting the awareness that exists? You know, what successful models exist for supporting open source projects that's sustainably? And one very common thread that I found is that there's a lot of projects that are really successful where companies or universities or governments are funding developers to work on that project, but they're doing it in a way where no single actor is taking the entirety of the community. And the thing they have in common is that they're user-driven communities. And one really, really nice example that I came across talking to Larry Gritz of Sony Picture ImageWorks and Carol Payne of Netflix, both representing the Academy Software Foundation, another project housed by the Linux Foundation. One common theme, there's a collection of open source projects in the film industry that are collaboratively developed by these studios. There's no economic incentive for any single actor to commercialize these things. And the studios really have a mix of they use home-built tools, they use these collaboratively developed open source projects and they use standard proprietary off-the-shelf software, basically picking the best tool for the best job. But I think this idea of adding this collaboratively developed software is really innovative. And I asked Larry what led to this? And he pointed out two industry trends, which I think are really interesting. We're gonna hear about it now, relating to how the labor market has changed over the last 20 years in Hollywood and how the film industry in general has changed in terms of how special effects are distributed. Right, so there's two interesting things that happened, I would say, mostly between 15 and 10 years ago. One is the labor issue that you mentioned is that the margins in this business are small. And so there was a big transition for most of the artists working on the films, essentially being permanent buyers to almost all of them across the industry being hired for a particular show. When that show wraps, you hope there's another one coming up behind it so you can just transfer them from one to the other, but that doesn't always happen. And so the labor force started to be much more about moving from company to company with each project and you always hope you get them back. And so that definitely set the stage for, there's a lot of overhead when someone comes in if you have to train them up on all these proprietary only tools and then they leave and they kind of resent the fact that you've filled their heads with information they can't use anywhere else. And so more reliance on both standardized commercial apps but also on these open source projects kind of means a lot more people and knowledge, portability from project to project and company to company, which is kind of necessary. And the other thing is like these big film projects themselves, it used to be more that a big facility like mine or like ILM would take on essentially an entire movie. And that was pretty standard until about 10 years ago and it's actually quite rare now. Even the big places, they might, instead of getting all 1800 shots for a movie, they might get 300 or 400, but each of five big places will get 300 or 400. And so part of that is because the production schedule is compressed and they're doing this work in parallel at different facilities. And so that means a lot more collaboration is necessary. And so obviously you need to share files between different studios and that's where the open file formats kind of came into their own, I guess, right? Yeah, yeah, that's a lot of time. Like when I came into the industry and started, I started as a technical assistant at ILM and a lot of the stuff that we were doing at that time was developing pipelines around how do we share files between vendors and even between like subcontractors for a couple different things at ILM. You know, we would send shots out for certain tasks and just them back in for others and stuff like that. And there was a lot of the things that I was working on and it's how I got introduced to OpenColor.io, which is an open source project under the Academy Software Foundation because we had to have a way to send what is the color pipeline for this project out to companies and tell them what we'd done and what we did and how to replicate. So that was a big one. A lot of the other big ones on that basis falls under that to the Academy Color and Coding System, which is the other big open source project I work on. But you have to have a way to say how this image is encoded and have different facilities and different programs know exactly what to do with that. So it's between software packages and it's between different companies too. And so it's both of those things that intertwine together. It's like that interoperability that becomes big factor in why things, why open sources start to play a huge part. I came across another user-driven community. This is Envoy, a project started by Matt Klein. And he did this while he was working at Lyft. And, you know, he had a lot of pressure when Envoy became a successful project to start a company around it. And he wrote a really, really interesting blog post, which I will add to, if I'll add some notes to my presentation at the end. But he wrote a really interesting blog post about why he would never start a company around Envoy and he gave all of his reasons for it. And one of the reasons was that he felt that Envoy would be more successful as an independent venue. And he has this very strong philosophy of user-driven development that projects succeed better when they're being developed by the people who have the problem that the project fixes. And so I wanted to share his perspective on why that model works. Operate software hand-in-hand. You create better software. So I think, especially in the infrastructure space right now, we see most of the open source and most of the products, they come from the major cloud providers. They come from venture-backed startups. I think very few of the projects that have found wide success come from end users. Meaning they haven't come from users that are building it incrementally to solve business problems that they're facing at that time. So I really strongly believe that when you have to operate your software and you have to solve real business problems that you're facing, it just leads to better software. It leads to software that is easier to operate that has the right features for operations that actually solves real legitimate business problems. So I fell very strongly that developing this thing at Lyft and in some sense, Envoy is a V2 to what I had worked on at Twitter. So that's also part of this is I had some experience building a proprietary system at Twitter. Learned a lot of things from that. Made lots of mistakes like all people do when they go from a V1. So Envoy took a lot of learnings there and I felt very strongly that we had developed something good. Now we can talk about what happened after OpenSourcing later. It's like what has happened? I never would have imagined. But at the time in early 2016, I think we were fairly confident that we had built something that was good that was relatively easy to operate that solved a bunch of business problems. We were relatively confident that other companies like Lyft in Lyft's peer group would probably find value. And I think really what the decision process was is twofold. One is that Envoy was not Lyft's primary business, right? Like Lyft is a ride sharing company. So at the time there was no plan to get into the infrastructure software business. So I think in the spirit of OpenSource and having built some of these systems in the past and honestly just having a feeling of, well, if this is valuable to us, it must be valuable to others. This is not our core business. If we're successful here, maybe we can amplify our effort by putting it out there. I think that that is what pushed us to initially have these conversations. But I think that, and I've said this before, I think a big part of it though, and again, we can talk about this more, is that I think a lot of us were fairly naive about what was really involved in doing OpenSource. So the initial conversations in 2016 were honestly very, very simplistic and they basically boiled down to, we've built this thing, we think it's valuable. We don't really know how to do OpenSource really, but it's not our core business. So let's do some OpenSource. And that's about the extent of it, to be honest. So there are many more examples that I came across during this series. I talked to Chuck, Dr. Chuck Severance, one of the founders of the Sakai Project. Sakai is a learning management system that came from universities. And for the first two years of its existence was essentially developed by developers that were working for the universities that were deploying it. The Drupal Project started in a dorm room of Dris Boithart in Belgium, or I think he was in Belgium at the time. And basically its initial community grew around people who were deploying Drupal as content management systems and needed features or needed extensions. And so Dris spent a lot of time in the early days of the project developing an ecosystem of implementers, of people who were actually using and deploying the software. So I've also seen a trend that Kirsten alluded to and that I've seen the open source program office, sorry, the Linux Foundation to-do group has just released a report on today that there's a lot of verticals that are coming into open source and are saying, yes, we're a telecom but we've got a lot of software in our core network and we've had this really tight dependency on network equipment providers in the past but now all of that is moving to software. Maybe we can collaborate on a common software platform or financial services working on the digital evolution of their industry. So we've seen a lot of these verticals coming into open source with a fresh mind, looking to learn how to do open source together not necessarily as a creating a vendor customer relationship but creating a technology that's a common base and then seeing how to build a commercial ecosystem around that but it's essentially coming from user innovation first. So that's my first lesson. The second one is that, I'm not surprised about this but it's a common thread that I've heard from people that people who build businesses around open source, the values that brought them to open source are actually important in their businesses as well. And so I've got three examples. The first is from James Vazil who is a consultant on open source. He was interviewed by Leslie Hawthorne with Sumina Harry Harishwara and Aaron Wilkinson. And James really pointed out how success in the consulting world and success in open source really require a lot of the same skills and I really like this point. I think I would just say that the power of open source is the power of the communication that it creates and that is going to be true for your consulting practice as much as it is for your clients. And if you can build community and connection around the work that you do and the primary way you do that is by helping other people. Then you start to gather some momentum and you start to gather immunity that returns energy to you in the form of knowledge, network, contacts, resources, help, whatever that is that you need. And that there really is the only way to do it as far as I'm concerned. I don't see another successful set of people doing open source consulting work who aren't somewhat community like them and not just paying lip service to them but actually working to try to better the communities that they are involved with. And so if that's the kind of person you are, I think you have a lot of success ahead of you. If that's not the kind of person you are, then I think you really need to consider whether this is the right pathway. I've said this to a number of people. It's not for everybody. And it's okay if it's not for you. There are so many other jobs in open source and technology and beyond. There are so many other ways to be of value to the world and to help people. This doesn't have to be it. So think about where this sits with you and how you feel about the track record you've created and where you're going with it and build on your successes and improve on your failures but do take a hard look at what you're capable of as a person emotionally because if you can bring that kind of energy, there's a lot out there for you. I also spoke to Alison Genotto of Dracability and that's Roberto Gallopini about bootstrapped companies, right? They both run small companies. They work with smaller companies. And Alison, when I asked her, as a founder of a small company that's growing, how do you decide when to let things go and how do you decide what you should be focusing on yourself? And I really liked her answer. This was kind of the way she answered it. She talked about what kind of company that she wanted to lead and grow. And I really liked her answer. I still contribute a lot of code. For example, what do I want this company to be? Who do I want this company to be? One of the things that we managed to accomplish this year was getting healthcare for all of our employees. We wanted to, not all of them for various reasons that don't matter, but we got healthcare. We have flexible hours so that it's a nice environment for parents to be able to kind of manage their kids. And that's the kind of company that I wanted to build. The fact that we bring on juniors, that's the kind of company that I wanted to build. So I'm a little more split now because these things really do matter and there's certainly some bizdeb, there's some strategic alliances that we've evaluated and things like that. But at the end of the day, right now, it's, these babies don't sleep a lot, you know? I don't know that I could ever stop writing code because the thing is for me, building companies and building products is, that's my jam. And I think the don't sleep a lot is a line that a lot of founders will identify with. I also spoke to Martin Mikos, formerly CEO of MySQL, now CEO of Hackable One. And he touched on something that I thought was really interesting and I think is topical about the ethics of who do you take on as a client? And it's something that's been very topical, particularly through the Trump administration in the US over the last five years. And so he alluded to that and I think what he said made a lot of sense. But we have it at Hackable One at times where there are organizations who would like to be our customers. And then some people don't like those customers, say those are immoral or illegal organizations, we shouldn't help them. And that's another tricky question where we try always to be the doctor, not the judge. We try to operate on all patients, so to speak, make it help them get healthy and help their software get more secure because if software is not secure, it's bad for everyone. So we try not to look at the who or what the organization is as long as they are legally incorporated in the country that we can respect. But we've had a case where we actually ended the program for a customer on a platform because we found their conduct to be so contradictory to the belief of ethical hacking and having a level playing field and listening to everybody's input. So we felt they went through, they weren't authentic in their use of our program because they didn't follow the foundational principles that underlies ethical hacking. But those are difficult decisions and it's important, I believe, to be principled in those so that you don't, otherwise you fall prey of the emotions of the moment and the emotions will change. That's something which we find detestable today might be acceptable tomorrow or the other way around. So those are tricky questions. But that's what I love about, sorry I'm going off in a tangent here, that's what I love about open-source software and ethical hacking and these collaborative common says that exist in the world, that they force you to have a moral stance and an ethical stance and they force you to think about fairness and respectful conduct and those things. Like you can't hide from those questions and I think it makes society better when we are confronted with them because many people will run away from it and think that they don't have to solve them or be silent when they see something wrong happening and that's how really bad things happen. Incidentally, when I was preparing this presentation some of my favorite moments of this were tangents. So Martin is saying you end off on a tangent but I love tangents like this. I feel like they really add a lot to my thinking. The third common thread that I took out of the series is that building a product around an open-source project is it's not a magic bullet. There's no open-source is not secret sauce. There are some basic brass tacks, nuts and bolts, things that you need to do to build a business and whether you're doing it as an open-source company or as a proprietary software company those things don't change. These questions are things like who's your audience and what's the problem that you're going to solve for them? What will you sell and how much can you afford to sell it for? What is your scarcity? What's different between you and your competitors in this space? What's the differentiation between your paid and free offerings? And these are common questions that you're gonna have in any company regardless of whether it's open-source or not. So many of my guests raised questions along these lines so it seemed worth emphasizing. So this is Astasia Myers of Red Point Ventures. Just because I felt like the discourse was dominated by the venture capital world, I still wanted to hear from people who were in VC and in the investment community and people who've taken VC. So I talked to Astasia and she shared her perspective about what the differences between evaluating a proprietary and an open-source company were and what the common factors were. It comes down to the reevaluating startups of around four different buckets. One is really the team, two is the product, three is the market, and four is the financial and user performance to date. The weight that we put on each of those depends on the stage of the business, C versus series D, and the sector that you're operating in, enterprise, consumer, financial services, healthcare. At the earliest stages, we anchor on team first. We wanna really make sure that people have domain expertise, leadership capabilities, and kind of grit. If you go later, you emphasize a little bit less on team simply because at that stage, there's pretty good track record or performance of the management team. So even if they maybe don't come from the category, they've proven their aptitude and their success. So it's a little less weighted the later you go. And there is some difference in enterprise technology we will get that's closed-source versus open-source. So some of the details that are important for us is the founder of the open-source startup, the creator of the project, and have influence over that community. Do they have an asymmetric insight into how the architectures are going to evolve over time? And another thing that's really important for us is, do they have some advantages in terms of distribution that go beyond open-source? Do they have a community that already follows them through a newsletter or podcast or social media? This is incredibly important for the earliest stages because open-source businesses inherently require product growth. And so everything is around product and distribution of the community very early. So it's nice to see some of these indicators with the open-source founders that we work with. One of the things that I really liked about Astasi's take is that upstream participation matters if you're building a business around an open-source project. If you're not in the upstream project, it's extremely difficult to build a product offering and differentiate with respect to competitors. This is Jeff Borek and Steven Wally had a really great discussion. It's kind of an evolution of the debate that they've done at many Linux Foundation events about whether open-source business models even exist. But Jeff asked the question, who pays for free software? And I really liked his answer as being something of a, like I said, a brass tacks response. Dave, your point earlier, who pays for free software? Who in their right mind pays for free software? You typically, oh, big companies do. Oh, no, the financial services sector does. Or companies that lack skills to serve self-interest. And those are all wrong answers, in my perspective. People that pay for software pay for it because they've developed mission-critical apps. Right. That's really another big part of Red Hat, in the Manga of Suze's business model, is subscription support because when it cacks in the middle of the night with software occasionally, it will do. Surprising because it's a wonderful call. So like solving business problems and helping your customers build mission-critical applications on your platform as a kind of a way to grow your business is not a specifically open-source thing. And so I really liked kind of that framing of how you grow your market. So in our very first episode, Adam Jacob of the System Initiative along, and we'll see these two again later when we're talking about supply chains. But Adam Jacob of the System Initiative shared this one anecdote, which had me in stitches, to be frank, about what value proposition means to customers. And that's where the customer product interaction comes in that says, look, it's part of the value prop here that I'm giving you by server by that supply chain is that I'm the one who will react to it and I'll react better than you and I'll react faster and I will get it in your hands and I will solve that problem for you right now. And that's one of the reasons why we talk about upstream contributions, I think personally, like it should not be a bragging thing. Like, oh, we have 22% of these, it's not that it's just, you need to express to the customer that you have enough involvement in the supply chain. Again, you're buying enough from Bosch and Bosch will fix the fuel injector when it's broken, right? But this is, I have enough engineers or and GUI people and docs people and all kinds of people participating in the sub stream community and they have enough expertise that they'll be able to react to a broken supply chain, quick enough, you know. Yes, or just even just above, like one of my favorite redhead stories of all time I'm not to turn it into a redhead festival but personal, like I had this Oracle cluster that was failing all the time, rack cluster back in the day. And it was because there was this query we were running, it was smaller than the size of a kernel task struct and the memory would get fragmented and then eventually the kernel couldn't allocate a task struct anymore and server would reboot because it was like, oh, can't even. And then eventually it did that and it corrupted the on disk file system for Oracle and no one could figure out how to fix this problem. The redhead person could tell me what the problem was eventually. Eventually they were like, I think the problem was this task struct, let's do like you run out of this and then like we added whatever, how are this expensive to like do the matrix dance and like read the raw file system. But both of those existed because there were vendors who knew that those people were real and could make them happen. Redhead put a dude on a plane, came to the sat next to me, the dude who could crack open the raw file system and read it in hex and then see the line that was wrong and be like, oh, that's wrong. And I'm like, what's wrong? He's like, see that little hex there, that's wrong. And then he typed in the fix. He just was like, whoop, whoop, whoop. And I was like, whoa, what are you doing? And he was like, open it now and everything was cool. And I was like, whoa, that is the scariest thing you've ever seen in my life. And like, that's the problem, that's the problem. And you know, it's not because if that can devolve into saying the product is support, it's not, it's not support. Like, yes, in that instance, it's the support that I got, but it's the whole thing. It's the fact that that exists, that those people are there, it's that you have that 20% of the engineers who know you can influence that roadmap, who can fix that Kubernetes, but even if the other people in Kubernetes don't care, you know Redhead cares, and that's all that matters. So another common thread, which wasn't really a surprise to me, but it was brought up so often that I feel like it's something that I should underline is that building a business around open source, community growth and engagement, particularly in the early stages of a company is critical. And we've heard about this from user-based communities already where, you know, you essentially, you grow your developer community by getting more users who can contribute effort to the project. Well, I've got a couple of anecdotes here about how making software quick and easy to use is really a key differentiator between, to grow that large user community is a key differentiator between proprietary and open source companies. So any move that you can make to slow down community growth in the early days has to be avoided. And Astasia emphasized the ease of adoption as one of the key things that she looks at in startups. The ease that we've partnered with and those that have become successful, you know, all enterprise businesses have a few things that we look for. Is the technology really solving a key pain point? Is the software easy to implement, use, maintain? Does it provide a delightful customer experience? These are, you know, first principles for any type of investing, particularly enterprise. But something that's really important for open source-led business models is the ease of implementation we really look at. Can you get up and running as a user within 30 minutes and have time to value in a really short time horizon? Are you writing an open source project that's in a common language so that you have a large user base that can come and use it, like Go or JavaScript or Python? And really, is the open source enabling you to simplify a really complex problem or workflow that makes it easy to adopt? Something that's also a little bit different about open source than traditional enterprise startups that we look at is the role of community and users really early in the company's life cycle. You know, companies that open source startups that do a really good job of engaging the community, listening to them and becoming a trusted partner to those users in the context of their solution, but also the ecosystem at large, tend to perform much better. And so for open source companies, typically even when you get to about, you know, two pizza teams of engineers, you start to look for a DevRel leader to help with that engagement in the community. That idea of hiring DevRel or community management really early was one that kind of surprised me, because I don't see a lot of companies doing that. But I asked Martin Mikos about, whether there was ever any tension between sales teams and community in my SQL, whether, because I've heard this from other companies, you know, whether the sales teams were annoyed because they saw community adoption as last sales. And I thought his answer was really good too. Oh, is that right? Sure, like some people will say, so like some sales reps are like, why are there all these people who pay nothing? But at the core of the company, we had made a commitment. We had picked the license we liked. And then you live with it, like you choose your own license. If you don't like the open source model, don't choose such a license, but we did. And we intentionally wanted everybody to use it, because that gave us powers that were far larger than Oracle's powers. Like I remember when there was a time when Oracle had 50,000 employees and we had 50,000 downloads every day. And I said, look at them. They have 50,000 people who drag their feet as they walk to work. They must be paid a salary and they are not necessarily motivated and passionate about what they do to just hang in there because they need a salary. We get 50,000 new people every day full of passion, drive, voluntary power to do amazing things. And we get 50,000 of them every single day. So the power of our community was far larger than the power of the whole employee base of Oracle, which at the time was the sort of the client. So I am unfortunately going to have to leave Mr. O'Grady behind. I'm going to skip this slide, but when I talked to Stephen O'Grady of Red Monk about the potential tension between community and product compared to managed services, he talked about how the community adoption of open source is a key differentiator and how moving to manage services is really a nice way to segment your paying audience from your unpaid adoption. But again, for a time sake, I'm going to skip that particular one. A hot topic this year has been the idea that there's a software supply chain and that that supply chain needs to be managed and secured. And it's come across so often in the series. I'm going to pick this one particular nugget from Scott McCarty, a product manager at Red Hat, where he shared his theory of, as an open source product manager, that you need to think about upstream projects as basically the same as a supply chain as a supplier to a physical product. I try to view open source as a supply chain for products just like I would view any technology supply chain, whether you're building airplanes or cars or anything else. For example, like people will ask, well, should I be going to DevCon, for example, people with Red Hat? And the answer, you know, product manager in particular in your life, well, it depends. Are you, is system D or Podman or any of these other like low level projects in the supply chain for the product that you're building for me that happens to be true? So it's an absolute yes, right? It's the same thing as if I was an auto manufacturing and Bosch had a fuel injector conference and I was the product manager of powertrain systems or whatever. Of course I would go to the Bosch conference and like try to influence Bosch on whatever features they're gonna add for my, I would try to influence what I want for my product. This is the beauty of software in general, combined with open source. These two things together are magical compared to the fuel injector because a fuel injector costs $5 to manufacture and I just have to pay $7. Like I have to give Bosch a little money that they can make a profit and stay alive. So this natural tendency to try to reduce the cost on the supply chain is a natural thing in all products. And so open source actually does this out of the box. Like again as a PM I look at it as it's a nonprofit entity that doesn't have sales and marketing costs that's still building a great like supply chain product for me essentially that I don't have to go pay for. And if the way I pay is I dedicate engineers to it. So say I dedicate three engineers that cost $100,000 each I'm dedicating $300,000 but I might be getting back a million dollars in product for five years. Easy. Easy. I mean it's like outrage is the return on investment from open source like, you know it's just so much better than a physical supply chain. So it's a new record a lot of ways. I talked to Lee Moore Freed, Jason Kreidner and Alicia Gibb about the open hardware ecosystem and Lee Moore shared a huge positive aspect to having an open source component or open hardware component just part of your supply chain which I think is underestimated in terms of how open source is actually an advantage in supply chain models. We just saw that the ILM team that does the Mandalorian they use some of our NeoPixel rings in the model making of like the razor crest spaceship in this show. Did we design the NeoPixel rings for use by ILM to make models? No, we designed it because we went to this golf club and this cool like Gongo project we saw we're like we should make that but like with like RGB LED and so we made this product because I personally wanted this like we're a cosplay project but then they got used for other purposes because they're, you know, this team which is like, you know, Disney ILM they have all the money, right? Like nobody has more money than the team working on Baby Yoda. Like I wish I had that budget. They could buy anything, right? They can have a custom engineer like design a custom board if they need to but they didn't. Instead they were like here's some open source hardware that we can customize to make this cool flame effect on the spaceship to make the controllers that we need to do this special effects quickly and on a smaller budget than we need to so we can spend the rest of the money on cheeseburger and drinks. You know, we have companies like, you know, SpaceX and Apple, they buy our components but are they used to fuck? I don't fucking know. Like whatever they want, right? Cause it's like they want to do whatever they want. They don't have to sign documentation or NDAs with me. They buy the hardware and use it for whatever. When they have to do fast track ventilator work folks used our hardware. Why? Because they had to quickly get known working hardware with my controllers and sensors to make ventilators. They had to do it in like less than a month. They wanted something that was well documented, well understood and that they didn't have to worry about what if this company, you know, I hate to say it, but they go out of business. Like I see people who do, you know, they have hardware products that they sell them. The company goes out of business and the hardware's bricked. They can't use it anymore, there's no documentation. If you have a ventilator, you don't want your ventilator to get bricked, that's bad, it should work forever, right? It should be easy to repair. And you know, if you're going to do an open source quick turn ventilator, that's important. So open source hardware fulfills many of these niches, but they're all kind of the same. My engineers have to get a product done to market that works, that's well documented, that doesn't kill them in the production cycle. There's nothing worse than an engineer making a decision to go down some technical path and then realizing a month later that they're totally screwed because the documentation isn't complete. They can't get the support they need. You know, the company folds, whatever. With open source hardware, you don't have to worry about that, which is kind of nice, right? You buy it and you have it forever. As long as the physicalness of it exists, the support and softwareness will work. And I think people who do software know the same thing. It's like, would you use a library if you couldn't recompile it when the new Mac OS Big Sur comes out and everything breaks? No, that sucks. It's better for using open source tools that you can then adapt and upgrade as technology improves. And I have lots of software that doesn't work on Big Sur, so I know that this is an issue. Okay, so very quickly, because I know we're out of time, I want to talk a little bit about upcoming themes and guests. In season three, I'm putting a strong emphasis on public funding of software. Software for a public good or for in the public interest. And I also want to talk a little bit. I want to explore a little bit the dark side of open source and the ways in which, you know, there's a kind of an anti-commercialism or, you know, going back maybe a decade, certain companies are demonized and anybody who does anything with those companies ends up being demonized by implication. So this season so far, I'm going to be doing a real time live in person episode. I'm going to be recording interviews this week. If anybody would like to be interviewed or talk about something in this world, I'm around and I'm looking for people who have interesting points of view. I start the season with Laura Walker McDonald, who founded the, well, she was an early product lead and co-CEO of Frontline SMS and she founded SimLab afterwards and she's recently, most recently worked for Dial, the Digital Impact Alliance at the UN Foundation. Talking about sustainable HFAS and one of the reasons why I want to talk to her is because she's written some really excellent essays about SimLab, the company that she ran, failed. And she goes into some detail about why it failed and her husband, Sean McDonald, who was the CEO of Frontline SMS when it spun out as an independent company is actually in the process of writing a similar series right now for Frontline SMS, they're wrapping up the company. I'll be talking to Miguel de Acasa next month, obviously an open source and free software superstar from the 1990s who became something of a target for a lot of vitriol through his time at Zimian and Novell and currently is working on dotnet, open source dotnet tools for Microsoft. And then I'll be talking to Ben Adida, is a Jim Procterman, Benatech is, and like title to be decided. This is a company based in Silicon Valley, paying Silicon Valley wages that's been around for 20 years, doing projects in the public interest, things like audio books for the blind or software for recording testimony. You might remember testimony from abuse victims in oppressive regimes. You might remember a human rights report a few years ago about police shootings in the US that came from the human rights data analysis group which was part of Benatech. So I really want to hear from Jim about how he has made that business stick around and be sustainable for the last 20 years working on things that really it's hard to see the economic incentive for people to buy products there. And Ben Adida, open source and civics, he runs a company called Voting Works. And among other things they did several of the recounts through the south. So Ben is an expert in traceable electronic voting systems. And Voting Works is running open source tools, open hardware, everything is auditable and I'm looking forward to that. So I'm gonna wrap up there. Here's our website, here's our YouTube channel. Please subscribe to the YouTube channel. There will be videos going up every week for the next 10 weeks or so. I'm doing 10 week seasons fall and spring. So I'm looking forward to hearing from you all and seeing you all on the channel. Thank you very much.