 Testing, testing, one, two, three. That sounds about right. Yeah, OK, yeah. Hello. Yeah. It's switching off. Are you kidding? I don't know. It's the subframe bright, but it's over. Do you want to start? Do you want to do testing, testing? Hello. Let's get this party started. So hello, everyone. Thank you for joining us. Sorry for the few minutes delay here. My name is Pedro. And I'm Nikita. I'm a product marketing manager on cybersecurity at Google. And I do marketing for security products. And I'm just a security engineer on the Google open source security team, where I actually work full time making security contributions to important open source projects. In our work explaining the new cyber threats to customers or repository maintainers, we've often found analogies to be very useful tools, which is why we'll actually start today with COVID-19. Since it's something we all unfortunately experienced and remember vividly. For example, you probably remember images like these. In 2020, we all saw many graphs like the one on the left showing the exponential growth of a contagious virus, how one case could spread to 2, 4, 8, 16, and so on, eventually making its way around the world. We also saw images like on the right of worldwide travel patterns and how COVID would spread through social networks. We honestly witnessed firsthand just how connected the world has become. And with that in mind, here are two more graphs. Again, a striking exponential increase starting at the end of 2019 to 2020 and a highly interconnected network. But these two, as you might expect, aren't actually about the spread of COVID. They're about open source projects and software supply chain security. The graph on the left actually shows the rise in software supply chain attacks over the past few years. These are hacks that target a piece of software or some component early in their own software development lifecycle in order to harm a different target later. The enormous 480% average growth rate over the four years shows just how lucrative and enticing these attacks have become. And on the right is an image from the depths.dev website, which we'll mention quite a bit today. It shows a typical open source project right there, together with the other packages that it depends on in order to function. As we're all aware, open source software is incredibly interconnected. And while these connections and code sharing speed up development and support innovation, they also mean that security risks or vulnerabilities in one project can impact many others. Just as COVID spread was a direct result of how people interact and depend on one another, today we'll explore how vulnerabilities can spread based on how projects interact and depend on one another. So here's our agenda for today. We'll start with a quick overview of what is open source software. Then we'll talk about how supply chain attacks are affecting open source projects. Then Pedro will dive into the topic of dependencies and how the web of connections between open source and between open source can cause risks to propagate. And that is the last point is why we'll be using public health efforts during COVID as a familiar analogy. We'll borrow from lessons learned during public health efforts to take steps to protect ourselves and others. By making this analogy, we don't intend to downplay the severity of a global pandemic that so severely affected millions of people. We're using COVID and public health efforts to respond to it as a way to make the unfamiliar more familiar. And we hope that it will be a useful frame of reference. Any comparisons we make are meant in the most respectful way. First off, what is open source software? We're talking about projects whose code is made freely available for anyone to use, modify and build upon. You might think immediately of big name projects like Linux, Android and Chrome shown over there. These projects have giant communities built around them of hundreds of contributors. But there are so many smaller open source projects as well. Maybe a project you start to try something new are just because you care about a particular feature. And even though these projects may stay small, they can become crucial parts of the overall ecosystem of shared software. So open source is everywhere, including in essential infrastructure. So this slide shows data from a survey of different industries, outlining how many of their code bases used open source code. Turns out, almost all of them do. 96% of enterprise software, 93% of healthcare, 97% of financial and almost 100% of the surveyed energy industry code bases contained open source code. This presence in essential infrastructure means that protecting open source software is actually a national security concern. In fact, in 2021, the US government issued an executive order on cyber security that included provisions about open source. And in 2022, bipartisan centers crafted a bill to protect open source software. But if you're a more visually oriented person than a legislatively minded one, here's a different way of understanding this emphasis on securing open source. See in this, emphasizing how open source is foundational to all digital infrastructure. But it also highlights how important people are in this equation. If you're that developer in Nebraska, thankfully maintaining a small yet essential project, you might not even know that it's so vulnerable, that it may have become an attractive target. You might not be getting the support you need. And when it comes to open source, security has a lot to do with the people behind these projects, the actions they take, and the ways those actions can affect others. In fact, we'll hardly talk about code at all today. And our main points apply no matter which coding language or platform you use. So now let's talk about supply chain attacks. There's an official definition at the top here that you can see, but for today's purpose, we can just say that a supply chain attack involves injecting code into your project to harm those who depend on you. And while this definition is about attacks, not everything we'll talk about today starts from a malicious mindset. Some things just start as innocent bugs that nobody had noticed. For example, one of the most recent supply chain emergencies that dominated the news started as an innocent bug that had been overlooked for nearly a decade. When it was finally discovered, it set the internet on fire. A vulnerability in log4j, an open source project relied upon by a huge portion of the Java ecosystem sent developers around the world, scrambling to patch an accident to the bug that opened a major security risk across the entire ecosystem. Or there was Left Pad, which wasn't an attack per se, but just a few lines of code that disappeared and broke the internet. Any of these other headlines, from banking to business, it seems like most hacks we hear about these days are related to supply chains. And open source is a major target. Precisely because of its role in holding up the entire digital infrastructure. Open source projects are well open. Anyone can inspect the code for problems, right? In fact, there's a saying about the benefit of open source that many eyes make all bugs shallow, implying that open source is in fact safer than other software since so many people are looking at and reviewing the code. And that may be true for big projects where there's a strong community and hundreds of contributors, plenty of support and plenty of eyes. But for each of those big projects, there's at least as many smaller ones with maybe just one maintainer. Many eyes won't make bugs shallow if no one's looking. When it's just you taking care of a project that everyone uses, but that isn't getting the support it deserves. And that was the case in this example that you might have heard of before, the event stream attack. Just take a look. In this case, a malicious actor asked, literally just asked for ownership of a project and the original maintainer gave it to him for the reasons explained here. And why did the attacker want ownership of this project? Well, as it happens, it was used by a crypto wallet app. So after gaining ownership of the project, the new maintainer just added a little bit of code in order to steal crypto, specifically Bitcoin, from the crypto apps users. This addition wasn't discovered for months after the package had already been downloaded eight million times. And at this point, applications all over the web were already running the malicious code. And one thing that I find really striking about this example is just the simplicity of this attack, especially compared to its enormous impact. While you may have heard of some very well-known supply chain attacks, such as CodeCov or SolarWinds, which are super complex and maybe even have nation-state level backing, others are really, really simple, just using social engineering like this to gain access to a project. So your project might not be directly involved with anything sensitive or critical, or, well, so you think, you never really know what your dependents are gonna be doing, but it could still be at risk merely based on what it's connected to. For example, Event Stream here was also used by many other projects. They may also have been affected even if they weren't the primary target, even if they were just collateral damage. But okay, we've already covered quite a bit. Let's switch gears here, because at this point you might still be wondering, what does this have to do with public health? Why did we even mention COVID at the start? Well, in our different roles, both Nikita and I work to raise awareness of supply chain security. And that requires communicating effectively about risk. So we researched papers about risk and given the circumstances at the time, basically all their titles were some variation of lessons learned from COVID-19. In fact, there were so many, there was even lessons learned from the lessons learned from COVID-19, which summarized the hundreds of different papers into a few main lessons. And since the COVID pandemic and this sharp rise in supply chain attacks were happening at roughly the same time, I wondered whether there were any lessons from COVID for open source that we could borrow. And as it turned out, there were quite a few, but today we're gonna focus on three, evaluating risk, monitoring, and communication. But for these connections to make the most sense, we'll first need to talk briefly about dependencies, just to make sure we're all on the same page. And just a quick shout out to Nicky Ringland, Josie Annagara, and Eve Martin Jones on the Deps.dev team for sharing some of the images and data on the following slides. So let's talk about dependencies just to get everyone on the same page. These are packages that you add to your project to provide some sort of functionality, right? That's running pip install numpy on Python, npm react for JavaScript to go get gin for go, et cetera. So the projects that you rely on are your dependencies and projects that rely on you are your dependents, also known as reverse dependencies. When you release your project as a package that others can install, all your dependencies also go along for the ride. Or to put it more visually, let's just take a look at how dependencies fit into a project's typical development process. Typically, a project starts with an idea. You think, I'm gonna create a new tool, it's gonna be great, it's gonna be awesome with so many features, so you spin up a new repository and you start writing your code. But eventually, your project might actually start to contain other people's code too. And when I say that, you might immediately think of external contributors. These are people who get interested in your project or want to contribute a feature or fix some bug, so they open a pull request with their own code for you to accept. And that's a fantastic way to scale up a project and start creating a community around it. But there's actually another way, another type of other code, shall we say, that we maybe don't think about as much, especially not in this way, and that's obviously dependencies. Somewhere along the line, on honestly likely immediately after you even started the project, you probably added a dependency on some other package. And let's be real, you didn't add one dependency, you added many dependencies because dependencies are great. With just a line or two of code, you can build off of someone else's work and save yourself from having to write that functionality yourself. Honestly, it's in many ways, it's like having the world's greatest developers on your team contributing to your project. But there are two things to keep in mind about dependencies. First, when a bug is in your code, when it's in your repository, you can just fix it yourself. Even if it originally came from an external contributor, the code is in your repository. You can just go ahead and fix it. But when the bug is in a dependency, other people must be involved for it to be fixed. Even if you go ahead and you fix the bug and you send it in as a PR, someone else still needs to merge that PR. Someone else still needs to cut a new release version before you can actually benefit from it in your own project. And second, each dependency likely has its own dependencies and each of them have their own dependencies. It can be turtles all the way down. So every dependency that you add increases the chance of there being a bug somewhere. And it's not a linear increase. It's more of an exponential one. So when you package up your code and you release it to the world, all of your dependencies go along with you. And when someone installs your package and adds it into their project, then not only depending on you, but they're depending on all your dependencies as well. And let's be clear, that's a good thing, right? That's how ecosystems of shared open source code get built. That's what supports so much innovation in open source. But it does mean that you might wake up one day and find out that one of your dependencies has turned into a massive security risk and set the internet on fire. And at this point, that affects not just your project, but potentially everyone else who depends on it. So for example, say your project is the creatively named package A. And you added several dependencies for some functionality because, again, dependencies are awesome. And yeah, those dependencies have their own dependencies and those dependencies have their own dependencies. And that's fine, it works great, it's fantastic. But then one day you might wake up and discover that there's a problem deep in your dependency tree all the way down in package K over there. You can call this log for K. Well, that might actually have consequences for your project, because the problem might not be isolated to package K. It might affect package I. And it might spread to anything that depends on I. And at the end of the day, it might affect you. And all because of a risky project you might never have even heard of because what we call an indirect dependency. And this isn't some theoretical problem. The vulnerability in log for J that set the internet on fire, that was one bug in one project that ended up affecting at least 17,000 projects connected to it either directly or indirectly. Indeed, as much as 98% of the time when a package is affected by a security vulnerability, it's affected indirectly, where the risk to you might not be so clear because you might not even be aware that you're affected by it. So you might be hearing this and thinking, okay, sure, I need to keep my dependencies up to date to make sure I have all the security patches. How hard can that be, right? Well, unfortunately, while it's easy to talk about dependencies with tiny little tree diagrams, dependencies often don't look like this. They look more like this, a complex, highly interconnected graph. So here you can see again a tiny little teal dot in the center. And that's our package, shall we say. And the lines point to all the other packages it depends on for some functionality. And these graphs, they might be bigger than you think. For example, the average NPM JavaScript package has around six direct dependencies, but 110 indirect dependencies. In graph form, that can look something like this, right? It's typical projects direct dependencies, you know, might seem interconnected but still somewhat manageable. But then you compare that to its indirect dependencies. It gets a lot messier. And some projects bring more risk and more complexity than others. For example, there's this one, which has a dependency chain, sorry, 58 levels deep. But if you had added this package to your project, you might not even have realized the sheer number of dependencies that you were exposing yourself to. And you might not even like to be aware of the difficulty you'll have tracing a vulnerability through all of these different layers of connections. After all, installing this package is still just a matter of, shall we say, PIP install XYZ, right? It's still just one line of code. So returning to the analogy of COVID, many of us had the experience of spending time with a friend only to get a phone call or a text a few days later when they'd found out that they'd been exposed shortly before meeting us. Heck, I had to make a few of those calls myself. So if doing contact tracing through just a few levels of connection were challenging, imagine tracking it through 58 such levels. I hope that this visualization of how open source projects are connected through dependencies is helping to show why so many lessons from the pandemic will be applicable to this topic. So for the rest of the talk, we're going to touch on lessons from public health efforts and apply them to open source software. We'll talk about actionable steps that you can take regardless of your experience with security. Lesson one, here's the first one. If we rewind to three years back, knowledge about risk was absolutely essential when COVID was at its peak. Without it, public health workers couldn't accurately judge risk, plan the right responses or communicate guidelines to the public. Communication was especially difficult and it was that some health organizations found emphasizing only the worst case scenarios led people to make poorer decisions because they were overwhelmed. They could not communicate guidelines properly and plan the right responses. But you don't want to be understating risk either, right? So with time, health officials refined their guidance. They targeted different recommendations to different populations based on factors like age, immunity, workforce profiles with high-risk jobs and so on and so forth, all based on understanding the different risks. So to connect that analogy to open source, how do you gauge risks to your projects and the projects around you so people make the right decisions? These are two free tools we can introduce you to that can help out a lot. Scorecard to understand your own or another project's risks and then depth.dev to understand how projects are interconnected. With these two together, you can better understand what risk category your project falls into, how to evaluate projects you use or depend on and which recommendations actually apply to you. So first off, the scorecard. The open SSF scorecard is a free automated tool created by the Open Source Security Foundation. It runs nearly 20 checks on open source projects. A check is a way to evaluate a common security practice known to correlate with risk. For example, one of the biggest indicators of risk is whether a project is maintained or not. You may be using a project or relying on it as a dependency, not knowing that it was abandoned years ago and is no longer getting bug fixes or any security updates, which you'd want to know about. This slide shows sewer cards for three projects and you can see how the different checks are weighted according to critical, high, medium and low risks. Scorecard provides a ton of information for projects on GitHub and GitLab with lots of ways to access it. Here are the three most useful ones for open source developers. You can use the scorecard web viewer to look up scores for one million projects. The link for it is in the scorecard repo on GitHub toward the top of the readme. If your project isn't included in the one million projects, you can run the CLI tool to get the scores. Again, instructions for those are also in the readme. And if your project is on GitHub, you can add a GitHub action which will run scorecard on each change to your repository and alert you if any change you make causes any security regressions. In its name, scorecard isn't just scoring you. It's meant to help open source developers. It gives you advice on how to raise scores that indicate potential areas of improvement that makes scorecard super useful. Not only to evaluate someone else's project, but also to understand the potential risks before you add it as a dependency. But it can also be used as a checklist of things to improve your own project's security. This slide exemplifies one of those pieces of remediation advice. It explains how a security policy helps people safely report vulnerabilities found in your project and suggests where you should place them or the files and what you might say in it. The second tool that we talked about is Google's deps.dev website. That's the URL, deps.dev. We've mentioned deps.dev quite a few times by now. This site has a wealth of insights about millions of open source packages and how they're connected. So for instance, if you look up a package, you can see some information about it in the overview tab there. Often you can see its scorecard score. And if you click on the dependencies tab as this slide shows, you can see how many projects it relies on. You can click on the graph button on the right top corner to see a cool visualization like those we've shown in the previous slide. You can also choose that third tab where you see the dependents to know how many projects rely on this one. If it's your project, just that knowledge could shape how risk-averse or risk-tolerant you want to be. If that tab shows that it's a small toy project that many others are using, maybe you can worry less and have a greater restorance. But if you find out that quite a lot of projects are relying on yours, that might guide you in future decisions and lower your restorance. And now for lesson two. Monitoring was key for containing COVID. But it was really challenging. Communities had to spin up entirely new programs like free testing clinics and contact tracing through telephone calls in order to try to limit the spread as it was happening. However, with time we saw how advances like at-home tests made monitoring more accessible by bringing it directly to us. Likewise, new apps on phones warned us of possible exposures and all that automation relieved some of the burden of making manual phone calls for contact tracing. All this monitoring made action plans possible. Some cities offered free home delivery of antiviral medication to high-risk individuals. Other places delivered food and care packages for those who tested positive in order to help contain the spread. By bringing those resources directly to people, they and the community around them were more likely to benefit from these resources than if people had had to seek them out themselves. So for an open-source project, the analogous solutions are tools for vulnerability monitoring and alerting and dependency update tools. Monitoring tools like OSV, which stands for the open-source vulnerabilities database, let you know whether you've been exposed to vulnerability somewhere in your dependency graph. You may have heard of CVEs, the Common Vulnerability Exchange Program, but OSV is specific to open-source and has a lot of associated tooling. And you can see all the ecosystems that it covers at the bottom of the slide there and they're continuously adding new ones. OSV tooling can also alert you so you can take preventative action. Often, that action really is just updating to a new version of a dependency. So a project that you rely on discovers it has a vulnerability, it fixes that vulnerability, and then just releases a new version of their package with that patch, and all you have to do is update your package to use the new version. It's often painless, literally just a simple version bump. But if you have a large dependency graph, there could be a lot of updates happening all the time. And we're human, so sometimes we'll just forget or just get overwhelmed. So our suggestion is don't even try to remember, just automate the process. Just as you'll receive a notification on your laptop or your phone letting you know about new versions of your apps or operating system, there are automated tools to send you notifications about your dependencies. They'll even send you pull requests, so all you have to do is merge them to update to a new version. And if you have automated CI testing, you'll even know right away whether there are any relevant breaking changes. You can think of these tools as delivering the needed resources right to your doorstep, making it easier for you to use them. On GitHub, there's Dependabot. There's also a Renovatebot that's available in basically all platforms, including GitHub, and many languages also have their own dedicated tooling for this. To the left, analysis of successful community health efforts during COVID found that messaging and communication were key. Communities that were less receptive to outreach, whether because of language barriers or distrust of the messenger, when trusted community members or leaders worked with health professionals to amplify their messaging, more people were receptive and able to adopt the recommendations. Speaking as a marketing specialist, this makes total sense to me. Effectively communicating can have a real impact, and we've seen from outreach efforts to improve security for open source projects that trust in the messenger makes a difference. So, code contributions, and certainly if you have the ability to contribute improvements or bug fixes to projects, that can have an amazing impact. But communication can too, and I bet a lot of people in this room also have incredible skills outside of coding. You can raise the topic of security in forums where people respect and trust you and communicate about why you think it's important to prioritize security improvements. Soft skills support community education. You can generate awareness by drawing on your own marketing skills by publishing blog posts, articles, or even as in my experience, raising awareness of the need for public sector support. I've seen from my own marketing work that these actions can help land open source security as a critical focus area in government forums. And contribute to documentation. There's some growing evidence that projects that document their security are less likely to regress on them and more likely to maintain their hardened security over time. So we'll close with an example of this type of action. Remember how we mentioned security policies when talking about scorecards remediation advice? A security policy is a type of documentation for a project that helps people safely report a vulnerability and understand the project's security efforts as well. Well, this is an example of community outreach by Joyce Broom, a Google software engineer based in Brazil. She reached out to an open source project that's considered critical to digital infrastructure. A project like that little block in that XKCD diagram that we saw earlier. She suggested making the project's existing security policy even more visible to users by moving it to the standard location for GitHub projects. So someone looking to report a vulnerability could easily find it. This is a type of contribution anyone can make regardless of tech ability. The maintainer said yes. They thanked her, they made the change to boost the security policy's visibility and then later they added this. This change got applied to 20 high profile projects downstream. And downstream here is just another way of saying projects that depend on this one. So one non-coding action helped make at least 20 projects a little more secure. And really that's the final thought that we like to leave you with today. And that is that just as risks can propagate through communities as we've shown, so can proactive, positive action. You can have an impact on those around you. So if you already maintain an open source project, please try out some of these suggestions. And if you're just new to open source, welcome. It really is a great place to be. So thank you everyone for listening. And we'd also like to give a special shout out to all the people who contributed to our talk. Any questions? Not so much a question, but kind of a comment, or maybe you could elaborate on this. There's a phenomena here of software EOL. And I was listening to a web presentation a couple of days ago about web, not necessarily, this was with Python 3, Python 4, Python 2 to Python 3. Now, if you have something that's developed with an old Python version, and you have a dependency that you really don't want to mess with to go to the next version, how does that affect this sort of thing? Because they were offering a little bit of, well, if we find a CVE in Python 3, we'll backport it to a certain version of Python 2 for you. And they also offered that we will also take a look at some of the dependencies in your project. But how would they go about maintaining a large database because I think they'd have to go through these sort of things going back from one version to the next? Yeah, so just to make sure I understood the question, the question is regarding the use of Python 2 to Python 3, the question is regarding cases where it can be challenging to update to a new version also because, especially going from Python 2 to Python 3, there are many different things that would need to be changed in a project. Is that the question, basically? Okay, so in those cases, the suggestion here isn't necessarily like you must always be at head, you must always be at the latest version. That's not necessarily the case. In fact, you might see, you even see ecosystems such as Go where by default, actually, you say I accept any version above 1.2 or whatever, and it will just give you 1.2. It won't give you latest, it will give you the oldest version that satisfies your constraints in order to, exactly because that older version, it's the one that's been most tested, it's the one that people are most used to. And so, I mean, the suggestion here isn't necessarily like be at the latest version, it's be at a version that you trust, a version that you are confident in. One suggestion here would be that if you want to make sure that you're at a version that you can trust is you can also pin your dependencies, right? So you can have a requirements file that has the hashes in them, and then you do pip install bar bar dash dash require hashes, for example, in Python. And that will make sure that you always get the version that you expect, that this old version of the package perhaps hasn't been modified so that you think that you're running the latest version that runs in Python, I don't know, 2.6, which is even end of life by now. But actually, it's someone put in a malicious version that is affected by it. So long as it's a version that you trust and that you are comfortable with, that is reasonably okay. It does mean that you need to do this monitoring in case there are any vulnerabilities that are discovered in that version that you are using. And if there are any, if you are very outdated, there may be significant breaking changes that you would need to deal with in order to bump to the next safe version. But that's honestly fine. It's a choice that the company needs to make, right? Sometimes making these big migrations, especially from Python 2 to Python 3 or other big things with many breaking changes, a company can always decide or a project can always decide to say, that is not worth it for us. We are willing to maintain this to monitor this older dependency and take, shall we say, the risk of eventually having to make this migration at a very short schedule because this old version is found to have some sort of vulnerability. That is okay, it's a choice that a company can make. Right? Any more questions? All right, so thank you very much. Okay, thank you. Okay, yeah. All right, let's just get this back to slide one. Okay, I'm on, yep. Pocket, put this in your pocket. Um, yeah, why not? We're not quite there yet though. No, I would like one. Um, fail to start, no direct connectors. Because it's no direct connectors, it's not a direct display. We can't do it because, you know, it's not XORG. We can't do that manually with XRender. Oh, I can't always make it extended display. I just forgot the exact thing for that, by TTY. I'll wear them anyway for the effect. They don't actually do anything. Actually wait, I can put the speaker notes on them. I know, I know, I'm aware. Thanks for trying. Hey, if you get that done before, we can try it. The page isn't loading, the page isn't loading. We're wired. I'm trying to load the presentation page. The problem is those that the, no, I did. Well, I didn't, anyway. The problem is I had to plug it into this side because this side is too jammed, full of ports. I can put it over here, but I'll have to squish them. Well, right now, you just confused it. By doing that, you confused it. Now the internet's going, uh, and it lost it. So you're gonna have to go back again. Go back. Go back to the other one. At least it didn't fall asleep. It is what it is. Try it now. No, it just wasn't, I'm not connected to it. It says connected, unconnected. No, it's not, that says connects, not connected. Okay, all right, now it should be fine. Now try it. Get your eyes checked. We're all good. It doesn't? It really doesn't. If they were not sunglasses, I would say yes. If they didn't look like sunglasses, that'd be awesome. Because they look like sunglasses as a- I know, I know, I can- But I would just say, just go. I need, well, I guess I don't need the speaker notes because I've already, okay, we got it. Ready to start when you are. Not many people, well. Hello, good afternoon. Welcome to the 145th scale presentation in Ballroom B. The presentation is growing up with open source with Nova King. All right, hi everybody. So this is a talk about all of my previous experiences with open source, the lessons I learned along the way and how it all built up to my latest project though and why all of that previous experience was necessary. I'm also going to go into how I think things could possibly improve right now because the open source ecosystem has changed and computing has changed. So first in the timeline is WebOS mods. So my mom is legally blind and she had a really, really difficult time seeing her phone. Now, nowadays most phones have a text slider where you can just increase the phone a ton. But back then they didn't really have that. And so what I did is I actually edited the core files of the phone. See, this was running something called WebOS. And WebOS had almost every single app using web technologies though. And honestly, it worked really, really well. It got shut down due to other reasons, but for the time it worked well. So all I had to do was just look into the file system of the phone, take out the individual file for the overall theme and then just change everything to bump up the text file, the text size. And this was only possible because HP had decided that developer mode should be incredibly easy to access and nothing should really be off limits for you to modify your own phone. And so I was able to create what's called a patch file that just simply said, remove this line of code and add this one in with the bigger text. And if you look to the side, you'll see pre-wear which allows you to apply patches. And so I took that piece, I took that patch, put it into pre-wear, put it on her phone and now the text was way bigger. Did it mess up a few UI elements here and there? Yes, but ultimately though, if she can't see the phone then the bigger UI elements don't help. So it was an essential thing in order to make her phone work. So it increased accessibility hugely compared to anything else because ultimately though, the original designers don't know every single kind of accessibility that someone might need. They don't know how well you can deal with say text size. They don't know how if you need more contrast. They can guess and they can add these things in preliminarily but there will always be people like for example, me who I have a hard time navigating certain interfaces because my brain works much more spatially than linguistically and they just can't account for everybody. So open source allows you to actually make things work for you. And that's what I learned all the way back in 2010. Well, I was nine I think it was. So yeah, I was nine years old when all of this happened. And so this was one of my first experiences. Was that all in the old Palm pre? This was the pre three and the pre two. If you're going to talk, put it through the microphone. Wait for the microphone, yeah. Yeah, thank you for confirming that. That was the software on the old Palm phones before they went to Android and I would call HP bought that and open source and it's still accessible for people to work on, isn't it? It is, however, because it's not supported you generally don't have as many ecosystems of applications. Okay, it's kind of a big trade-offs with open source. And yeah, and LG has it. Thank you. So here is my first scale talk. Now I'd been to scale the year before scale 10x but I was just, you know, I was 10 years old and I had never been to scale. So I just decided, you know, why not look around? But then I decided, hey, you know, I like all of these talks though and I want to share my experience as an 11 year old about how you can be involved in open source. So it was pretty naive at the time, a lot of the stuff. You know, and it was very code oriented because I was doing mostly programming at the time. I do more design stuff and programming now. But you know, it was stuff like, for example, you know, pick your programming language like that's something you have to do but you know, it's obviously not. But you know, it did teach me public speaking at that. So, you know, and so I learned a ton from this. I mean, I learned public speaking though. I learned how people reacted. You know, I had funny little gags where I literally just threw candy at people when they participated in the talk. It was great. It was hilarious and all. And so, you know, the whole presentation though, I had to stand on a soapbox because I was so tiny at the time. You know, and I'm surprised that the whole room was packed considering. And at the time, scale didn't have the next generation track, right? This was something that I was just like, I'm gonna go in the general track to speak about this. I mean, the next year, because of me and Keela Banks, you know, they made the next generation track because they were like, oh wow, kids actually want to speak here? So, that's really nice and all. So, then we have the Energia MSP430 code. I forgot, I'll be perfectly honest. I don't know what I did here. And the reason why is because all of their stuff is probably on some other entire Git hosting service. And it was so long ago that I completely forgot. I know I fixed something very important, but I forget. For context, the Energia is like the Arduino IDE, but for MSP430 launch pads. And that was basically incredibly low power. We're talking actual microwatts. So, that's really good for if you're chucking something all the way into space and every bit of power counts. You know, or you just want to run something that lasts for actual months to years. And so, I fixed something on it, but I can't remember what. And so, archiving in open source is incredibly important. And I have code, but it's all on GitHub. But what happens when GitHub inevitably dies? Because nothing lasts forever. So, I really should have archived it. And that's my bad. And that's why I learned from this whole experience. Then we go to scale 12X when I was 12. The Blender Workshop. So, basically, what's it called? This is my first workshop class. And it was one hour long. I was teaching people how to model and render a model of a die. And one hour, teaching a whole room of people as a 12 year old. We did not get anywhere close to done. Everyone, like half the class was behind and all, though. But I did learn a lot about taking feedback, though. I learned more about Blender for just doing this whole talk because I learned SketchUp, which was proprietary and all, and for different things. But just knowing how to teach, that's what this whole class did. I found that you often have to get into the action in order to actually be able to learn things. Like, for example, getting the demos to work in this particular talk, which we'll see if they work out by the end. Next, we have the Witch E emulator, which is something you can actually try at home. So, yeah, the Witch E is basically an emulator or an educational project to replicate the oldest digital decimal computer that still works. It's a mouthful, but basically in the 1950s, the Harwell Institute created this thing called the Wolverhampton Instrument for Teaching Computer History. Wait, no, that's the project name. It's the Harwell Decotron, is what it was called. And it actually used, it used zero to nine, so it used base 10 numbers instead of the binary we're used to today. RAM was actually Decotrons, vacuum tubes that basically were spinners. And so you could actually see, as the memory was cycling, you could see the Decotron spin in the computer. So it's a lot more tangible than most computers are nowadays, though, because now it's all just shoved in memory, which is this black box that you can't really see. So I'm going to play the video here. Please work. Otherwise, I'll be getting the source code and running this myself. I'm getting the source code, aren't I? It's fine. I'll get the source code. So I'm going to actually grab the source code for a paper tape that was used in the actual witch. So you could actually run this. You could punch it into a five-hole paper tape, feed it into the witch, and it would work. Let's go squares. So I just paste in and make, I want this one to be looped. Oh, no, wait, that's a straight tape, right? And then we have tape two, which is looped. So back then, we didn't have four loops and such. So we basically had to, once again, we had to actually take the tape and then actually physically tape it together at the ends in order to make a loop. And then whenever you reach the certain instruction, it would actually switch to the third or fourth tape or so on in order to do the control flow of the program. So learning about this though was really interesting. I made this whole emulator in JavaScript, which actually isn't the worst thing for a really old computer like this. So I can hit start and the stores will fill with all of the values. These were designed to be actual, like Decotron loading spinner things, but we never really got around to it and also it was just too tiny. So as you can see though, we're just loading all of those memories, all of those values into memory, and then the accumulator is going. And the accumulator is a way bigger area of memory. So I learned so much about the core of how computers work. Computer history though, all the weird and wacky things. I learned emulation and working with other people because I was working with David Anders, AKA Purple Plague for this entire project though because I didn't know the witch. I just knew JavaScript and I'm using Ennio, which was a thing from WebOS. And so I needed a lot of help. And while this project never really won any awards or anything, I'm still incredibly glad that it's still out there for everyone to try. On this website, witch-e.nosuch.network, and you can also find the witch-e repository, right? This is a project that was archived successfully. So, and as you can see here, we have .01 and .0001. So it just got the square of that number, square of that number and it'll just keep doing this over and over again for pretty much infinity. Now you might be asking, this seems like a really simple computer. Why would someone make it? And that's specifically because it does things perfectly reliably. That's why computers were made after all though. You used to have people who were called computers. So learning about computer history made so much more possible, you wouldn't believe. I went on a bit of a tangent, but it's important. Then we have the scale 13x talk. For the record, in the middle of there, I was just working on random projects, but nothing really notable. I was learning 3D modeling and so on. But I did a talk on the witch-e, right? And so this is my first talk about a project that I actually built, right? So some things I learned in this include, I learned basically representing your own project is surprisingly difficult though. A lot of open source people feel like their projects aren't that good. And I was actually feeling that at this time too. Because well, I was so used to my own project though that it seemed all natural to me. But I also learned better clear public speaking. Because this is an incredibly complex topic, I had to boil everything down into simpler terms for everybody. I had to make things interesting. I had to basically refine all of the skills I learned in order to do this. Because the first talk I was just doing an initial, I was just explaining things though, and it's a simpler topic. The second one though, I was doing a workshop and I had to learn to work with others. And then the third one is where I had to basically learn how to not just speak about a topic, but speak sort of for myself as well. Okay, jumping over to 14x though. So for scale 14x, this was a lightning talk. So it was at upscale, which was on Saturday this year, I think, right, Saturday or Friday? It was Friday, yeah. And basically the idea is, if you weren't there, you had five minutes for all of your slides. You have, I think, 20 slides, five minutes, so you get like five seconds of slide and you just have to go. It automatically jumps. And I was doing a talk about choosing the correct framework for your project. Now I don't know if this came across well, but this is my slide. As you can tell, it's heavily broken because I didn't choose the right framework from my own project. Yeah, this was a case of where everything fails and I just have to roll with it. So since every slide broke, I basically had to say, oh yeah, this is what was supposed to happen, right? Like I did, for example, with the witch-e right now. The video didn't play, so I had to go and do the demo. In person, and so I had to adapt on the fly though because realistically, what else am I gonna do? And so this is the first instance of what I call demo syndrome, right? Where you do everything right. You put so much time and effort into making it work perfectly and then on the exact day that you're presenting it, it all dies, every single bit of it. That's, yeah. Yeah, this broke before I even started. It had to go five minutes late because the slides wouldn't even load. And this is because I was using Google presentations, Google sheets, or sorry, Google slides, and then I exported that to PowerPoint and then I imported it to LibreOffice and then I modified it in LibreOffice and then it was imported into a different version of LibreOffice. And really, I should have just figured out exactly which version of LibreOffice I was using and just built the slides there. Yeah, choosing the right tool, it was very important because this whole talk was hypocritical at this. But I did learn from this experience though, right? So that's important. And this will come into play later with Stardust though because one of the main things I said is if something doesn't work, literally, you sometimes just have to take it, throw it out, and restart though. You have to be very careful when you do but you have to do that. 50 next talk, editing multimedia using open source tools. This taught me a lot about user experience specifically because I had compared proprietary tools like Adobe Premiere for video editing to open source ones like Cade and Live. And so with that though, I had to evaluate things not just as someone who likes software and programming, but also through a design perspective because it doesn't matter how technically good something is if it's interface is absolutely garbage. And so I had to critically examine every piece of the interface. Of course, in the talk I was heavily biased though because again, this is an open source conference and I really like open source and so on but at the same time though, I had to sometimes give a point to the proprietary stuff because it was just better pretty much for the open source stuff I said it's simple but of course simple doesn't necessarily mean it's good to use, so. And by the way, the image here, that's of cutting out the background of all of those candy hearts. So trying to get into a transparent image. I wish I had a video for this one. 70 next, iotail. So my dad was doing a whole part of a track where he talked about microcontrollers and how do you put MicroPython on it so where you can use them for, what's it called? So where you can use them for embedded applications. For example, you can put a microcontroller and you can hook it up to wifi and you can have it constantly running as a reliable source for say, monitoring plants, internet of things, right? Because it's internet of things, ALE. But he didn't know Arduino. He didn't know C++. He didn't, so I had to take over for the talk for him. And so, what's it called? This whole entire thing was just like, it was basically me with no preparation in a room trying to teach a bunch of people about this topic. And so, I'll be honest, there wasn't many lessons I learned from this other than just like, I had to practice everything I learned. I had to be very, very fast. So all of that, I rushed through all of that because I wanna talk about how all of those experiences helped me with my latest project, Stardust XR. Now Stardust XR is a three-dimensional user interface for augmented and virtual reality. So you've heard of the Quest devices. You've heard of Apple Vision Pro, right? And in order to make those, you have to have a fundamentally different interface than 2D. And so Stardust is a fundamentally different interface that is made for when you wear a headset on your head, you use hand tracking, you use controllers that are in 3D space, and you can also use eye tracking and so on. So it required very different design. I'll even show you some images of it too, just while we wait. So you can, for example, you can place panels in 3D space like this, right? You can interact with them for 2D compatibility, but you can also do a lot more, and I'll get into that. But in the actual construction, in the actual construction of this project though, because this is not something I could do myself, right? This is the equivalent of Wayland or Xorg or so on. It's the equivalent of GNOME, KDE, et cetera. It's a massive project that there's no way I could do by myself, but I need to start it by myself because at the time, nobody really cared that much about augmented virtual reality. In terms of open source though, I had to learn contribution, right? I had to learn because a lot of the tools that I wanted to use simply just weren't available though. There were things that were similar, but I had to basically turn them into what I needed in order to make this project. So I started with StereoKit. Now, the whole point of StereoKit and why I needed it was because, see that code up top? That code is all you need to make a literal model in 3D space like that. I needed that simplicity because I just didn't have time to write an entire renderer, to write an entire graphics pipeline from scratch. I mean, it's ridiculous though just how much time it would have taken. But StereoKit didn't run on Linux. And so I basically had to talk with a project maintainer though. I had to ask, okay, hey, I wanna add this to Linux though. And then I had to do most of the work, but I got a lot of help along the way to actually implement it though. So I had to learn though, I had to use all of the skills of interacting with people that I learned at the previous talks. I had to use all of the programming skills that I had to use there. I had to use the design skills that I had picked up along the way in order to make all of this work to where StereoKit is actually very, very, very reliable on Linux today. In fact, it's not just used for other projects though. It's used, sorry, it's not just used for Stardust XR, it's used for other projects, right? So for some context though, this is something you would see in a VR headset. So you could launch an application made with StereoKit in a VR headset and you would see this, for example, right? This is an example of some of the more unique UI in StereoKit though, that is the kind of thing I need that isn't really possible in other tools or at least not easy in other tools. And then this is an example of another thing I made that StereoKit adopted, which is this little grip surface. So when you move your hand close to something, now it has little dots to indicate that, you know, it's all grippy and you can drag it around, right? So, okay yeah, so this is Monado. This is another core piece to doing it. Stardust may create the 3D objects for you to interact with your favorite apps through, but it doesn't really allow you to work with the headset though, it needs a separate component for the actual headset and allowing you to use it. So I made several contributions to Monado. Let's start off with this one. So this headset is called the Project North Star. Now the Project North Star is an open hardware AR headset. That means you can see all the way through it, right? You put it on your head though and these little reflectors basically bounce light from a screen to the side though. So it looks like the actual objects are floating in space, but they're sort of ghost-like, they're hologram-like. So why am I telling you this? Well, because, see that right there? This is all running entirely on Linux though. I created the initial driver for the North Star though and I also did the majority of the port of StereoKit to Linux and that means though that this developer, my friend Moshi, was actually able to use it to develop open source hand tracking. And all of this effectively means though that it started the ability for you to take an old headset, say the Windows Mixed Reality line of headsets which is now officially deprecated by Microsoft and bring it back from the dead though, right? Because now you can use the inbuilt cameras and it can automatically know where your hands are. So now your hands can be a controller for 3D objects. So you can open up a heart in 3D for example though using your hands. Another thing though that was related was I created this thing. You see, Monado is a bit of a pain to launch and a bit of a pain to use because it's very low level software. So I created something, a little prototype I called Rex. It's a Xenoblade reference. And the idea was I had taken a look at what Minecraft launchers had done, right? Because Minecraft is also an incredibly complex game that has a lot of different configurations you can put it in. You have tons of mod packs, you have tons of versions, all of that. So I made this, which is just a way to simply say I want to launch Monado that works well for this headset with these settings with one click of a button. It never really went anywhere. However, it inspired someone to create Envision which is sort of the next generation version of this which is much, much easier to use it's much more up to date and it's actively maintained an entire community for Linux augmented and virtual reality enthusiasts. Right, so now we go to the Scale 20x talk last year. So this is my talk about Stardust though and the overall Linux VR ecosystem as a whole. Now what this taught me is a huge massive case of demo syndrome though. No matter how hard you prepare ahead of time though, demo, and actually I'm, no I'm not going to. What's it called? So I had brought a wired headset with me which you can see on me right there and I plugged it in and well I only got a few demos in before it totally failed. In fact it failed so badly that the video player itself it actually glitched out so heavily. I'm very sorry VLC forever doubting you because VLC was the only thing that worked that day. And demo? Fair enough. We got a Seig fault in the Intel Mesa driver effectively meaning no demos today but I have this video as a backup and I also have even more. So basically though this is a showcase of Stardust and what's really, really cool about it. So all of those talks though, all of interacting with people, seeing what they needed though, learning programming and design and everything though. It all led to this. Basically an interface to where for contact this isn't actually possible in anything else. You can't just take a pen, a virtual pen and you can't draw around all of your favorite windows in 3D space in literally any other standalone headset. The Quest can't do this, the Vision Pro can't do this. Of course that's because they decide not to do this but that's the beauty of open source. Just like I said in the web OS slide because I have control over the system I can make it do something that's way better for me than was ever possible before, right? And because I had been able to talk with people and show them demonstrations of what I'd done before I was able to make this demo video to just quickly and concisely help people understand what was going on here, right? 514, okay. We got plenty of time. Sorry I rushed through this. Another thing you'll notice though is that I literally just took a terminal application and I tossed it into a, I tossed it into the TV. So that's something that is really, really important for accessibility reasons. Because I learned though that no one thing, one size fits all, not even close in fact. What's it called? So I decided why not take it and make it to where you can just switch interfaces on the fly though. Because there's so many different real world situations where AR and VR will happen, right? You could be sitting on a train though and trying to interact with your tech talk feed. You could go on, you could be having a giant desk in front of you and you wanna interact with all of your windows floating in front of you. All of that though, you need different interfaces. And so being able to just take your favorite app and put it inside of a TV for retro gaming or such, I mean that's incredibly powerful. Yeah, and so then I also have the workspaces, right? Where you can literally just grab the side of a workspace and you can bring it up and down just like no workspaces but in 3D. And all of this was only possible because I had all of that previous experience. Because I learned demos, I learned programming, I learned what people needed, I learned design, all of it. And now we come to the current talk. Which is, why is this, it's not going full screen. Oh well, so now we come to the current talk. Where, well I wasn't very prepared compared to the other talks though because I've been so busy doing a lot this year. I've been improving on Stardust for the past year. To the point where, if I go to the Stardust server, I've created an entire community full of people though that are helping with this project. Being at scale those previous years taught me a ton about how to build and maintain a community. I'd been to the Expo Hall where people could just literally share anything they wanted to. I'd been to talks where people could go into more specifics about exactly what they wanted. And what I've learned is that being inclusive and actually just having a place that people can share what they're doing is incredibly important in order to be able to make open source thrive. So here basically I'm showing off one of the special features which is the ability to save and restore state. That basically means though that if you leave a virtual object here, you go a couple cities over and you go back, it'll still be there. And yeah, this is basically a project showcase at this point. Go ahead. Give the mic. Oh thanks. So actually let's talk more about that community though. Because community is an important part of open source. So if we look here, this video though, a lot of clients here were made by different people. We have the entirety of this inspired by this initial post right here where this is navigating around an environment with hand tracking though. So this was the original inspiration for this video that I'm about to show you. The key though is that that was only doable in isolation. You were only able to run that one app at that time though. But with Stardust you're able to run that and other apps at the exact same time though. So I had to take inspiration from that person who actually published the source code and I copied a lot of that source code in order to make this possible. See that hexagon launcher? That was made by members of my community Viola and several other people though in order to actually make this work. You know? And what's it called? NC Flatland though. That was inspired by a lot of the work that other people like Simula VR had been doing with their flat window managers here. Also, Simula, it'll take a bit. Yeah, it'll take a bit. I don't think the internet likes me today. That's not gonna help. Not in this case. Oh, well, here, I'll just show you the image results. Okay, here we go. This is it. Yeah, so that, for example though, and also motor car, which I can't, yeah, there we go. Right, and that and motor car were a heavy inspiration for Stardust though. They had come up with some ideas that are used today literally like actual decades before they were in use. Like, where is it? I can't. I guess I'm not finding the image today. But basically though, yeah, that was a heavy inspiration. Where was I? Where was I again? Oh yeah, theming. Right, so theming in virtual reality is incredibly important. It's not just a really nice, pretty thing. It actually sets your mood and all. And so, well, proprietary platforms though think that, they want to be able to control what you do so that they can follow you through channels like the App Store though. My experience with WebOS though, especially, being able to actually just take it apart and do what I wanted with it, really, that's not doable anymore. And with that experience that I got back then, most kids don't get that nowadays. So I'm actually kind of worried for the future of open source development because most of the kids have something like an iPad. A tablet that has programming applications that don't really let them do more. It lets them do tiny little apps inside of a window. But I learned to do things because I was like, oh, I don't like how that is. I don't like that the tech size is small. I don't like though that I'm stuck to doing multimedia editing this way. I don't like that I have this giant machine that I can't understand. So I want to make a bigger version of it though. I want to make the tech size bigger. I want to make my own emulator. And I was able to just do that because I had computers that let me do that. I didn't have to ask someone to buy me a better computer though, right? You pay $700 for a tablet though and you can't even do programming on it. Well, what is this, you know? And I just kind of feel bad for a lot of the kids that are growing up nowadays. And sure, there are plenty of them that will get into open source and all, but in a lot of times they don't have the same opportunities that I did. I had parents who were remarkably technology friendly compared to a lot of people though that don't really understand the innards of how everything works. Most people have phones that don't exactly let them do things. And so I think it's really important to make platforms though, that a lot of people use, that have really, really good UX though, to draw people in. They have the opportunity to let kids explore how to actually build things. And you can't do that inside of a tiny little box like Scratch though. Scratch is incredibly nice for teaching people how to make applications. It's just too small. You can't expand out of there easily. And sorry, I went on a bit of a rant, but it's a bit frustrating for me. Then we have, what's it called? That landed in Poltergeist. Oh, one second, we have Comet. So, what was it I was talking about? Oh, wait, actually, someone sent in another example of Stardust. Yes. No, no, it's okay, it doesn't need a mic. This is another example of community collaboration. I collaborated with Matthew Krogan over there, I think, in the back, to get Stardust XR working on these pair of glasses right here, right? So, the demo is failing, of course it is. But here's a pre-made video of being able to interact with all of your 3D applications though. And honestly, the only way I even met Matthew was through scale though. And the only way I kept going to scale was because I had those opportunities to speak at scale. So, without the ability to do that, this would have never happened. So, I'm really grateful to Matthew and to scale into everyone. Is my talking hour long? Yeah, that's what I thought. Oh, so I can stay as long as I want. Yippee! We can spend all day waiting for this demo to work. Maybe the demo will work today after all. Yeah, Nvidia's breaking. Oh, here's a fun one though. Here's a fun one. So, being an open source allows you to design for things that are not really seen necessarily as that important. Like, this is a button that doesn't pretend to be pushed while you're pressing it though. The only reason I was able to think about this is because I'd seen so many sorts of weird interfaces from open source. I mean, you have stuff like Nemo UX though, where you literally have Windows flying all over a, all over a giant table, right? Like, here's an example though. Actually, I can show you this video. I can show you some of my open source inspiration for what I've been doing here, if it'll load. We'll wait for that to load. I guess it doesn't want to load. Shoot. So, here's another thing though. I went to another thing called MIT Reality Hack, back in 2020, which is basically a giant hackathon for augmented and virtual reality. And with the team, I created this, which is called the Spatial Universal Interaction System. It solves a very key problem in AR and VR, which is how do you deal with a bunch of objects though, that have been created by a bunch of people and also all want to be interacted with at the same time, right? With any input, which is a ridiculously hard problem to solve though. So the, what's it called? Because everything was open source though, I've taken this code and I've basically ported it, not just the Stardust, but I ported it to StereoKid and I've also been trying to update the Unity source code, which means though that this hopefully will eventually be seen in a lot of different projects or be inspiration for somebody to make something even better. Actually, how about we go for questions? I know I've said a lot of things though and so I figure, you know, anyone have any questions? So Stardust is written in Rust, right? But did it have a history before you wrote it in Rust? Oh, I forgot to talk about that, yes. So Stardust was originally written in C++, which it had, what's it called? So because Stardust was written in C++ because at the time though, I thought because of my previous experiences though, Rust is too complicated, why would I need it? And basically what's it called? So I wrote it though and then I spent two months straight debugging error after error after error and because they weren't, the number of errors wasn't going down though, there was actually someone going up. I had to take some of my own advice and this is difficult though, but this is where the, wow, the whole page froze. This is where the advice that I got that I gave myself during the lightning talk came in right here, right? I had to rewrite it entirely in Rust or something else though. And I chose Rust after a really long time figuring out what would work, but when you're fighting a losing battle though, when the tool that you're using is just making life even harder for you, you know, sometimes you have to just cut your losses and rewrite it in something better. And that's a really huge time loss. So you have to take special care, but it's worth it. How long did it take you to write it in Rust? It took six months. So I know you're thinking though, why, you know, if it only took two months of hardship, why did you rewrite it and it took six months? And the specific reason why is because it had a lot of other benefits. And actually that was one of the best decisions I ever made in terms of the Stardust project because now people are able to contribute it's much easier to package it though. It's much easier for everybody to use it. It's much more stable. It's much more lightweight, everything though. And another bonus, I got the whole Rust community behind it. So just changing the programming language actually got a whole new set of people to be interested in this project, right? So yeah, thank you. And it seems like you're able to develop it at a faster rate than Apple and Microsoft and all the other people who are interested in VR. So what they have is polish though. Big companies generally tend to focus heavily on one specific use case though. Something that they think is what people want and will get them money. But with open source, you have to build a community and you have to be engaged with people. So you have to more develop what they want, assuming you want to get any large amount of contributors and such. So that forced me to create something that is more useful. It's still in early stages of course, but right now we have something for mind palaces, for example. Like I showed before, Comet. Though being able to create a mind palace is one of the best use cases in my opinion for augmenting of virtual reality. And that's incredibly difficult to do on anything else. So that's why I focused a lot of my energy there. And already though, you have people like Matthew actually using Stardust for monitor replacement though because it's more lightweight. And you have people like for example, Saphira Kai who were working on getting it for mind palaces and for reminders and so on. And that would have only happened because I had to engage with the community because I had to talk with a ton of people that all wanted a ton of different things. And so it required making it useful for all of them. Thanks so much for the questions. Any more? So we've talked a lot over the past few days about Stardust and getting it places. But what's your next big feature? What's the next big thing you want to tackle with Stardust? Yeah, so Stardust of course needs a lot of contributors though. And in order to get contributors, you have to have something that is an actual functional and useful thing that developers are interested in. To get anywhere, to get people to use your tool, you have to make it user friendly. To get developers to use your tool, you have to make it user friendly and developer friendly. So one of the biggest things is installation, right? Because there have been a bunch of developers though who are super rust experts though, they've been able to mostly just install this through the harder channels, right? By installing 500 packages and then building it. But one of the key things is, how do we get this to where anybody can just download it, install it, try it out, provide feedback though so that they can say, oh, this doesn't really work for me. And then we can know exactly what to build. A lot of the contributors here that are on Stardust though are developers that are so focused on code that they just don't really have time for project management, right? And that means that we need a clear direction to focus. And so having that feedback though from more installs helps. And so to that end, we've gotten Nix packages thanks to the help of Matthew and several other people. We have Fedora packages thanks to the ultramarine people at Fira Labs. And we've got AUR packages that are currently in the process of being built and so on. And that's because the Stardust community has intersected with these other communities though. The Stardust community has intersected with the Nix community and with the ultramarine community and the arts community and so on. So yeah, good question. Any other questions? So let's say you really wanna work full time on a project like this. What does it take? That's something I have yet to actually figure out because while I do work full time on this though a lot of the time, that's only because I've been doing jobs though in order to pay the bills, saving up money and then basically coasting on it while I work on things, right? So for example, I worked at Hallows for two years, right? And Hallows was very useful. Hallows for the record is basically education and training for augmented virtual reality. The images don't wanna load because of this internet but it's what's it called? Well basically though the idea is that you can use your hands and such in order to create lesson plans and such. And the basic, so I worked here for two years though and that's actually where I learned a lot more of the specifics of XR interaction design, right? For example, a lot of the interfaces in Stardust are heavily inspired from Hallows though. I learned about signifiers and affordances. I learned about a ton of things that were important and I also gained a lot of money though that I could use to where when I quit that job though to focus on Stardust for a lot longer, I had literally one and a half years worth of money, right? Where I could live full time on that. What I'm trying to do now though is I'm trying to be able to get that funding while I'm still working on Stardust. When you have to work on a second job it takes a lot of time away and thanks to scale I found a lot of different people though that I can talk to and build relationships within the future so that I can hopefully get paid to do the things that I love and that help them too. So yeah, thank you for the question. Is it working? Yep, that's Nvidia for ya. Demo's broken again. It's 5.38 though so we got about 15 more minutes. Does anyone have any more questions or should I explain more of what I've been doing? I'm just curious since you're sort of the leader of this community and there's a lot of people sort of depending on it. How do you deal with burnout? Yeah. So burnout is generally, from what I understand, burnout is the result of putting a lot of effort into something and seeing no emotional return or very low emotional return and that's happened to me a lot throughout this project though. I mean something as big as this though where there's so much work to be done that you can't easily show to people who aren't interested, developers who know all of this already, the only way I've been able to deal with it though is to build a series of people who are supportive though and some of them understand the inner working so they can help and say oh wow that's really cool and they can help out on that. But then I also have people, I also have the cool demos channel for example where I get to show off all of the stuff and I can get compliments and such though. And also I've been learning to pace myself a bit more because that's one of the most difficult things in a lot of this stuff is you're so interested and you're so invested in this particular project though and everything that you wanna work on in as much as physically possible but it is not possible. So you have to pace yourself though so that you don't burn out. And that's easier said than done of course but it's, thank you. Do you think that if you did get a job doing VR that might actually contribute to burnouts because then you would be working on it full time and then you would also be working on the open source project and it would just you begin to hate what you love. The question was if you did get a full time job and got paid well to do this, do you think it would contribute to the burnout because actually you don't wanna spend all 100% of your time on this, right? Because. Yeah. So sometimes when you work on the same thing that you love that can lead to burnout, what do you think about that? Well burnout though, it can happen from doing multiple things. Sometimes though, when you use up a lot of mental energy on a particular full time job though and then you go home and you work on something though you can still get burnout from that though, right? Burnout isn't necessarily, this is the amount of time total I am working on this though it could just be I don't have enough breaks though and so therefore I keep putting myself into a state of stress whenever I'm working on this thing though. So financial stress is only one kind of stress though. There's emotional and a lot of other ones. So it may work for some people. I've tried it with a part time job and while I can do it it's not ideal. So I've been exploring other avenues with of course a regular job as a backup. Actually I think it's almost, I think the talk is almost over because we got four minutes left so. And one time for one last question. Well thank you. Oh, you have a question? Or no, okay. Yeah, thank you everybody. I already got one earlier.