I’ve been running an Intro to Open Source workshop for a couple of months now, and one of the biggest challenges for participants often dealing with is keeping their branch up to date and managing merge conflicts. Listen, if you see that “merge conflicts” message and you panic, you’re not alone. I may or may not have used the strategy of deleting my entire local repository, forking, recloning, and redoing my code to avoid navigating merge conflicts more than once. Luckily, there are much better ways of dealing with updating your branch and merge conflicts than that. If you’ve ever felt that panic and wanted to burn it all down, take a deep breath and read the post below that walks you through the process of keeping your branch up to date while waiting for reviews. Keeping your branch in sync with the main repository helps to avoid conflicts and create a smooth(er) merging process.

Welcome to Day 5 of our #100DaysOfOSS series. Until October 31, we'll be doing Open Source Software (OSS) terms from A to Z. We'll be diving into a different letter of the English alphabet, uncovering OSS concepts, and sharing our thoughts on them.

Today, we're covering the letter "B" for Bug.

We are very excited to kick off #100DaysOfOSS, a challenge where no matter where you are on your tech journey you can deepen your knowledge and understanding of the world of open-source software. Whether or not you plan on participating, we want to provide resources for anyone interested in growing their experience through open source. A great way to make progress and to grow is by starting with some goal setting and then exploring the different paths you can take. The first part of this post should help you to set those goals, and the second will go into more detail about the types of paths you can take as part of your open source journey.

When I started learning to code, no one told me what Git was or why it was important. It was one of those words that I pretended that I understood because everyone just assumed that I knew what it meant. But up to that point, I had been using built in IDEs, and I hadn’t used git. For one of my bootcamp projects, I had to have a certain number of commits to pass. I forgot about commits, and only had about three. I went through and did the whole project over so I could add the required number of commits. When you’re working on a simple project like I was, one that no one else would check out or contribute to, it can be less than intuitive to remember to commit. I just wanted my project to work as quickly as possible. I know now that I was probably taking the wrong approach to learning. Because moving into tech, I’d be working collaboratively, and these tools could be incredibly helpful to ensuring that collaborative relationships worked well. Hopefully, this beginner’s guide to Git will help you understand the usefulness of Git and how you can use it as part of your toolbox.

Inspired by the great work of the #100DaysOfCode challenge, we're launching #100DaysOfOSS, starting July 23rd, and running through the end of Hacktoberfest, October 31.

With this challenge, OpenSauced hopes to help contributors enhance their skills, expand their abilities, and gain practical experience over 100 days, as well as support maintainers, onboard more contributors into open source, and expand the OSS community. With a focus on open source software (OSS), we encourage contributors of all technical backgrounds to immerse themselves in the world of collaborative development and engage with a supportive community.

Interviewing is a skill that can be strengthened. Interviews can be frustrating, demoralizing, casual, intense, and occasionally fun. They can make you doubt yourself or they can validate your skillset. There’s a lot being evaluated in these interviews and I know, personally, that nerves have gotten the better of me in that process. But just like any other skill, the more you learn about how to do it, the more you practice, the better you get. When you’re interviewing for a tech job, you’re going to be asked about your experience. Contributions to open source projects are a great way to demonstrate your skills because they can demonstrate your technical skills, showcase your collaboration, problem-solving abilities, and passion for your work. Even if you’ve had a stellar experience as a contributor, you need to know how to effectively talk about your open source experience during the tech interview. In this blog, we’ll explore how to talk about your open source experience in a tech interview.

In my last role, I focused on the community side of developer relations. Part of that included creating open source projects to help onboard new developers and to create opportunities for community members to interact. When I started at OpenSauced as a Developer Experience Lead, there wasn’t a huge jump from community to developer experience. In fact, I wrote a little more about it in this LinkedIn post if you’re interested. The overlapping goals of Developer Experience, Community, and Open Source to empower community members, have a growth mindset, and believe in collaboration culminate into the potential to be part of something incredible. In this final blog post in our series, we'll explore how DevEx and OSS combine forces to elevate developer experience, enabling developers to work more efficiently, collaborate effectively, and create great open source projects.

One of the questions I’ve heard quite a few times since starting at OpenSauced a couple of months ago is “How can I use open source to get into DevRel?” The answer is one word: Contribute. Contribute to docs, contribute to code, contribute to the community. Contribute by writing, contribute by creating content, contribute by sharing. To be in Developer Relations, your journey will require technical expertise, communication skills, community-building skills, and, most importantly, empathy. In my last post, I talked about the overlap of DevRel and Open Source. In this post, I’ll get more personal to help you create a plan to use open source to support your journey on the DevRel path.

The story of open source is a story about community. It’s about people coming together, learning from each other, growing together, and creating, of bringing their talents and perspectives to build something great. It’s a story of what humanity can do when we work together. I don’t know what Linus Torvalds thought when he created the Linux operating system and released it to the public for free in the early 1990s, but I’m sure it was about doing things differently.

The first time I pair programmed was with one of the founders of the bootcamp I attended. I was super nervous. We talked through some concepts I was working on, and he asked me to open up an editor. Ok, side note, I had spent the previous years teaching college English. When someone said “editor,” I assumed a text editor. I opened up google docs. It wasn’t until he said something like, “Do you have notepad or something else that we can use?” that I realized he was talking about a code editor. I think I was using the now-sunsetted Integrated Development Environment (IDE) Atom, but since then, I’ve been using Visual Studio Code (VS Code), which we’re going to be talking about in this blog post, as a way to get started with creating an open source repository.