Today is day 3 of 29 Days of Open Source Alternatives, and the final post for the Game Development and Multimedia segment.

I haven't used Audacity myself, but anytime I ask a content creator what tools they use for content creation, Audacity is always mentioned. Because I co-host two podcasts, and I'm very invested in finding more ways to talk about storytelling, Audacity is on the top of my list as a tool to explore ways to share my creative process.

**Today is day 2 of 29 Days of Open Source Alternatives, and in this short week of February, we're covering Game Development and Multimedia. If you'd like to see more open source games, you can check out my OSS Games Page. **

Before coming into tech, I spent a lot more time writing and working creatively, mostly writing screenplay or tv pilot specs. It's always been my dreams to see my stories come alive on screen. You know that crane shot you see in the most epic of all scenes in action movies? That has always been my dream.

Today starts my 29 Days of Open Source Alternatives series, where I'll be exploring open source alternatives to proprietary software in the categories of Game Development and Multimedia, Development Tools and Platforms, Productivity and Collaboration Tools, and more. If you'd like to see the list of the open source alternatives I'll be covering this month, head over to my 29 Days of Open Source Alts Page or check out my list of open source games.

Last year, we decided to homeschool my 13 year old for a semester. When he told me that he was really interested in game development, I installed all things Unity and tried to get him up and running.

Narrator: we never got things up in running.

All the major browsers now support the <dialog%gt; element. Why add this HTML element? User land code, code that developers write to fill in gaps of the browser, was doing similar things repeatedly, especially around focus trapping, and browser engines responded by adding this functionality directly in the browser.

There's been a lot of talk recently about how to get into open source. I think part of the challenge of breaking into open source is overthinking it.

https://x.com/BekahHW/status/1742920548353745068?s=20

We need to reframe how we think about starting with contributing. Getting started with open source can feel intimidating, but it's just like learning a new game with complex rules. You wouldn't jump straight into a game without reading the instructions. In the same way, you shouldn't overwhelm yourself with open source. Take it step-by-step.

Are you looking to migrate from Jest to Vitest for your React application? Look no further.

I recently migrated the OpenSauced app repository to Vitest. Here's the pull request if you're interested.

So far in this series, we’ve explored maintainership from a high level understanding of what’s required, why you should consider it, and how to get started. But what are the day-to-day tasks of a maintainer?

The first project I actively maintained was something that I hadn’t initially considered for open source contributions. It was open sourced, but I didn’t anticipate anyone contributing but me. When I was encouraged to share it with contributors during Hacktoberfest a couple of years ago, I had to make some updates so people understood what the purpose of the project was, how to run it, and the technology behind it. Looking back at it, there are, of course, things I could have added or done differently.

Job seeking is really challenging, but if you've talked to me in the last six months and asked me how to find a job, you know that I've mentioned using open source. I know, I know. That can be an overwhelming experience. But hear me out if you're an early career developer.

Yesterday, I decided to make some "quick" changes to the OpenSauced docs site. Now, I know that "quick changes" is essentially a bad word in tech. Anytime you say it, it will indeed not be quick. I wrote up a quick issue that described reorganizing a couple of things and adding a quick intro page. I made the changes, wrote the page, pushed my changes, and made the Pull Request (PR), only to see that I failed. Ugh. It was quick, but it wasn't right. Not really having the time to dig into it, I left my PR open and determined to get back to it the next day. Understanding why a project is failing may look different depending on how it is set up. For us, we're going to look at implementation errors, compliance issues, check the deploy log.

Every week at 10:30a ET, I do X/Twitter spaces about open source. I’ve been fortunate enough to learn from some amazing folks in the space, and two conversations really had me thinking about this topic. I chatted with Rachel Nabors of Clerk and Ben Holmes of Astro about open source projects and the contributor’s journey. They both shared their philosophies on how to cultivate a positive contributor journey. As a former educator, it made a lot of sense: If we want to see return contributors, we need to create a space that encourages them to return. Part of this means cultivating a contributor journey that allows your contributors to grow, receive recognition for their contributions, and provides a positive experience. Creating an impactful contributor journey requires deliberate thought and understanding, listening, and a willingness to grow with your contributors.