 Hello. Wow, that's huge. OK. Last year, the screen was a lot smaller and a lot dimmer. Oh. OK. OK. Forking code comes with significant costs. When you fork out an open source project like Backstage, you're locking yourself into a system that is growing and changing ever so rapidly. And far too often, when developers copy and paste code, they rarely do so with a test. So without tests and without a plan of keeping your forks up to date, it doesn't take long before your developers are blaming, before your developers misdirect their frustrations towards Backstage. That's a nicer way of saying it. Hello, my name's Min Kim. I'm an engineering consultant at Frontside. I'm up here today because this is what it takes to get a free KubeCon ticket. So for the next few minutes, I'm going to discuss some ways you could avoid forking out Backstage packages. First thing you should do is actually check if you need to fork. I know it's weird that that needs to be said, but for a lot of companies, Backstage is its first instance of working with open source. Lack of experience contributing to and working with open source projects has led developers to forking code, even when it's completely unnecessary. By actually looking at the code, you can evaluate if you need to fork out the entire package. Sometimes a feature you're looking for could already be a configurable option in Backstage. Next, if you're looking to customize UI components from Backstage, you could take advantage of its theme API. Using the theme API, you can overwrite the styles of Backstage components without having to fork it out. You could do quite a bit with those overwrites to make Backstage feel like your own organization's in-house app. So if you've reviewed the code and the changes you need aren't related to styling your user interface, you could use patch package to modify Backstage packages. Patch package to modify Backstage. The nice thing about patch package is that every time you upgrade those packages, you need to rewrite and reapply those patches again manually. Although some may see this as a downside, but patching is not meant to be a long-term solution, it's supposed to be painful. And sometimes pain is good. No, sorry. Unless your developers enjoy the laborious work of writing those patches over and over again, they'll now have a very good reason to create that pull request in the Backstage monitoring bow as soon as possible. One of the most common excuses I've heard for justifying forking is that they don't have time to wait for pull request reviews and they don't have time to wait for Backstage release cycle. I found these excuses usually come from those who've never even tried to contribute to Backstage. So maybe I should have said they think they don't have time to wait for pull request reviews. Nevertheless, adjusting your plans to account for release cycles is a smart and agile thing to do when working with open source software. Moving a deliverable into the next sprint to allow upstream to release your changes will provide the same value to your users just in a slightly different order and at measurably lower costs. But if your developers are still itching to fork out Backstage, next time perhaps you could suggest one of the methods I've mentioned. That's it for me. You can, if you want to talk to me for some reason, that's my handle for LinkedIn GitHub and Discord on Backstage. And I'm here all week. So if you see me waddling around, you can also say hello. Thank you. Thank you so much, Min.