A social post that went viral recently stated that if you are junior and not contributing to your green squares, you have no chance of getting a job. The tweet forced many developers with jobs to respond, but they need to respond to how hard it is to get a job today as a junior or laid-off mid-level developer. 

Right now, green squares represent someone's work in open source. Squares are not a representation of a developer's resume, and to further make the point, it is also confirmed by the defunkt co-creator of the contribution graph himself.

![defunkt's quote post](https://user-images.githubusercontent.com/5713670/259939543-510c3f63-5fb5-46ea-8933-5692763ddfe8.png)

[Link to X post](https://twitter.com/defunkt/status/1687944148949811200)

So if the contribution graph is not a measurement of one's skill, are we left to become Creator X influencers in hopes of a giant paycheck from Elon instead of that sweet 6-figure engineering money? 

![drowning in the contributor graph meme](https://user-images.githubusercontent.com/5713670/259939648-8c2789c9-e71d-471b-b611-fd42ba3ee8b3.png)

photo credit [x.com](https://twitter.com/devagrawal09/status/1688785540286382080)
 
Building influence is a beautiful way to stand out, but in a market trending towards more layoffs, we can agree that an X following is not an excellent measurement of a developer's skill.

I suggest we shift focus to Moneyball, a term popular because of Brad Pitt.

## Moneyball for engineers 

The concept of Moneyball emphasizes the use of advanced statistical analysis, particularly sabermetrics, to identify undervalued and overlooked players in Major League Baseball. The Oakland Athletics popularized this concept in 2002 to win 103 games.

Baseball is similar to programming in that applying frameworks speeds up the paths to success and gets to endgame sooner. Developers looking at contribution graphs with a lot of green squares to one without a lot of greens is simply pattern matching, and for a while, that was a great way to hire for your startup until it wasn't. 

The problem is that green squares are like home runs; the more you have, the more you are noticed, but once anyone looks closely, the deepest green of squares could be nothing but performance-enhancing cron jobs. 

![cron job to create dummy commits](https://user-images.githubusercontent.com/5713670/259939517-1e721dac-1ed6-434b-9199-238314cbef29.png)

[Link to post](https://twitter.com/johncodezzz/status/1687912460848939008)

Green squares was a framework that no longer holds value because it encourages the wrong metrics. Just like the introduction of the pitch clock, players need to adapt to stay relevant. Open source continually adapts and shifts with industry trends. 

>For those unaware, In September 2022, Major League Baseball announced a new pitch timer that would significantly increase the speed at which the game is played.

With new tools, languages, and frameworks coming out all the time—even the newest developers are months from achieving greatness with mentorship from suitable project veterans. 

## What's better than green squares?

At OpenSauced, we have been working on a way to highlight a developer's skill and expertise. Just like looking at the back of the baseball card for stats, you should see the highlights of the developer pretty quickly. This is only our first pitch at this, but it is broader way to showcase your contributions (in open source). 

[![oss.fyi/bdougie](https://user-images.githubusercontent.com/5713670/265903246-fe79bae5-36af-4a90-83dc-2dfd77fa98bc.png)](https://oss.fyi/bdougie)

At this point, we can say that the data helps to show where people are participating, but the highlights show what they’re most proud of. 

Highlights allow contributors to share:


1. The work they’re most proud of.
2. Their ability to clearly communicate their work and accomplishments.
3. The ability to identify their most impactful work. 
4. They variety of work they’re doing. (Do you need a utility player? Someone that can write, create good issues, and PR like a boss? Or do you want someone who swings for the fences and is dependable for creating features in high-stakes situations?)

We’ve seen it time and again. Open source is more than code—it's a journey of growth and opportunity. Your contributions reverberate far beyond lines of code; they forge connections, foster mentorship, and move you towards new and unexpected pathways. So, keep collaborating, innovating, and contributing—because the world of open source is not just about code but the opportunities it unlocks for your personal and professional journey. For example, Sunday’s open source journey that led to his role at OpenSauced.

[![sunday's blog post](https://user-images.githubusercontent.com/5713670/265903259-80b580ae-2be9-434e-9145-2276302e2156.png)](https://dev.to/opensauced/how-i-got-hired-contributing-to-open-source-projects-546i)

Events like Hacktoberfest emphasize getting enough contributions within the month to earn a reward, but we need to develop the idea of a tangible reward. Part of it is the career, but it takes the journey to get there. You grow in skills, have the opportunity to learn together, build your reputation, and expand your network so that you’re never without a chance, support, and personal fulfillment.

Look beyond the fences of open source and put yourself in a place to knock it out of the park. 

Right now, green squares are a representation of someone's work in open source. Squares are not a representation of a developer's resume

Moneyball for Engineers

I’ve heard the advice over and over, “find a mentor.” While having a mentor can be valuable, relying solely on one mentor isn’t the most effective approach to learning and growing. Instead, let's redefine what it means to receive mentorship to benefit the most people. What does that mean? It means that we see mentorship as daily opportunities to learn and grow with people that we may or may not have direct contact regularly. It means that we see communities as the most valuable resource for mentorship. That we can receive mentorship by interacting with people in online environments, and by seeing every conversation as an opportunity to learn something new. That we ask questions, provide feedback, and that we mentor ourselves as part of that journey.

## Why Community Mentorship is Better than 1:1 Mentorship
I want to take a second to define what I mean here. When I say 1:1 mentorship, it means that you have a regular or semi-regularly scheduled time to meet with the same person for guidance and the opportunity to learn. I’m not saying you shouldn’t do this. But I am saying that community mentorship, or seeing a group of people and your interactions with them as mentorship, is better. Below you’ll find some of the reasons why.

### Diverse Perspectives

If you’re meeting 1:1, you’re limited to that person’s knowledge, exposure, and perspective. One of the key advantages of having a community of mentors is the diverse perspectives you’ll see and hear. Different voices and experiences provide a broader understanding of the industry, new ideas, and offer more opportunities. The community perspective can come from online communities on discord or slack, meetups, or by interacting with various authors through blogs and forums. That experience will allow you to hear a variety of viewpoints, allowing for a more well-rounded understanding of tech and best practices.

### Supportive and Diverse Network

Building a network can consist of peers, experienced techies, and even experts in the industry and benefit you throughout your career. Engaging with a diverse group of people in tech at all stages of the journey allows you to learn from different perspectives and also facilitates knowledge sharing, collaboration, and the formation of lasting connections that may lead to future opportunities. It becomes an opportunity to peer mentor and grow through teaching and collaborating with others, key skills we all need in tech.

### Accessible Knowledge
What happens if you have a question that determines an important part of your tech journey and your mentor is unavailable for an extended period of time? Having the collective knowledge of a community allows for availability at all times. That means that you can seek guidance and answers to your questions whenever you need them, without being limited by a mentor's schedule.

### Continuous Learning
Every interaction in a community is an opportunity to learn, whether that’s active or passive. Early in my career, I worked mostly 1:1 with an experienced developer. I learned a lot from that experience, but I learned the most when I actively engaged in a community. A lot of that learning came from reading slack conversations between developers. I was able to see how they asked each other questions, the processes they used to debug, and read different approaches to the same problems. Communities are a constant stream of fresh ideas and insights.

### Supportive Environment
Community mentorship can create a continual support system. You might find that other community members have the same goals and you can support each other, sustain motivation, and get emotional support through the journey. One of the most beneficial experiences I had when I was learning to code was hearing people who were ahead of me in their journey saying that they experienced the same frustrations. I stopped feeling so alone and was able to gain confidence as they shared their stories and advice with me.

### Continuous Opportunities for Growth
I strongly believe in horizontal mentorship–the ability to mentor at any stage. We all have our strengths and weaknesses, and you can always share those strengths to help others. Community mentorship often provides these opportunities for growth and development. You can contribute your expertise, collaborate on projects, and become a mentor yourself. 

### Resilience and Continuity 
Having a community of mentors ensures that you’ll continue to be mentored even if one individual's mentorship ends. The collective support of a community empowers you to overcome challenges and setbacks.

### Empowering Self-Directed Learning
Redefining mentorship as an amalgamation of learning experiences enables a more self-directed and proactive approach to skill development, and builds the skills you need to thrive as a person in tech who needs to problem-solve and learn to work independently. 

Rather than relying on a mentor's schedule, you can own your learning process and explore topics that interest you most at your own pace. This autonomy cultivates self-reliance. It can be challenging to discern what information is right, follows best practices, or isn’t there just for clickbait. This is where you leverage your community of mentors. Ask for recommendations and references. Let people know what’s worked for you in the past or what style of learning you find most effective. Once you’ve settled on resources, don’t forget that many of those learning resources come with a community built in. There might be a forum for the class or an async communication platform. 

The ability to create your own learning experience allows you to access the newest information, tailor your learning pace, and explore areas of tech that you most enjoy. 

If a structured learning experience isn’t for you, you can also find a particular content creator or content creators that you learn well from, and consume their content as a form of mentorship. As part of that, you might have the opportunity to ask questions, suggest future content, or let the creator know how valuable the information has been to your journey. 


### The Power of Online Communities

Over the last couple of years, online communities and forums have exploded with opportunity. I’m confident that there is a community that suits your needs out there already (but that doesn’t mean you can’t start your own if you can’t find one!) If you’re not sure where to start OpenSauced offers a lot of different opportunities to be part of a community and ask questions:
- [#100DaysOfOSS](https://docs.opensauced.pizza/community/100-days-of-oss/)
- [OpenSauced Discord](https://discord.gg/opensauced)
- [OpenSauced Twitter + Twitter Spaces](https://twitter.com/saucedopen)

Actively participating in communities allows you to seek guidance, ask questions, and contribute your expertise. While mentors can provide awesome guidance, the traditional 1:1 mentorship model might not be the most effective or accessible option for everyone. Redefining mentorship to include various online resources and interactions can empower you to find your own path to success. Remember, it's not about having a single mentor; it's about building a network of support that uplifts and inspires you on your tech journey.


Thriving in Tech: Embracing the Power of Community

You Don’t Need a Mentor: Embracing the Power of Community

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. 

At the time, most operating systems were proprietary software, and users had to pay for them. Linux was different. It was open source software, which meant that the source code was freely available for anyone to use, modify, and distribute. The story of open source is one of innovation, collaboration, and community. And it’s a story that invites you and me into it every day. 

In this beginner's guide, we'll explore the fundamentals of open source development, including project selection and meaningful contributions–how we can be part of the story. And if you’re ready to start on your open source journey or to share your work in open source, sign up for [OpenSauced.pizza](https://insights.opensauced.pizza/)!

## Benefits to Contributing to Open Source
My favorite benefit of contributing to Open Source is meeting new people and being a part of new communities. The long-term benefits I’ve had because of those relationships have been incredibly rewarding. But that’s not the only reason to contribute. Here are a few more reasons:

- Learn new skills: Open source projects are a great way to learn new programming skills. You can learn from the code of other developers, and you can get feedback on your own code from the community.
- Make a difference: Open source software is used by millions of people around the world. By contributing to open source projects, you can help make that software.
- Gain real-work experience: When you contribute to an open source project, you are demonstrating your skills in a number of areas, including:
- Programming: Writing code that is both functional and readable.
- Problem-solving: Identifying and solving problems in code.
- Collaboration: Working with other developers to achieve a common goal.
- Communication: Communicating your ideas clearly and concisely, whether that’s in writing documentation or discussing the issue you’re working on.

You can check out more reasons in [Beyond Content Creation: How Open Source Contributions Can Help You Get Noticed](https://dev.to/opensauced/beyond-content-creation-how-open-source-contributions-can-help-you-get-noticed-4l5n).


## Getting Started with Open Source
There are a lot of things to consider when you’re trying to get started. If you need help understand the terminology, start with this post: [Open Source Terminology 101: A Primer for New Contributors](https://dev.to/opensauced/open-source-terminology-101-a-primer-for-new-contributors-k46
). Once you’re familiar with the terminology, you need to find the right project. Check out [Choose Your Own Adventure in Open Source: Paths to Success](https://dev.to/opensauced/choose-your-own-adventure-in-open-source-paths-to-success-167p) to explore different reasons for getting involved in open source projects to help you figure out where to get started. Some other considerations when you’re getting started, include:
Find an active project. If a repository hasn’t been updated in a while and the maintainers aren’t responding to issues, discussions, or comments, that’s a sign that the project isn’t active. 

If you look at their repository, you should be able to see when the last PR was merged in.

![last contribution](https://cdn.sanity.io/images/r7m53vrk/production/1d580ab74f4ed7a48391532dd480022dff1507cc-591x62.png?w=450)


- Talk to people who are contributing to open source. The best introduction to a new project is often a personal one. Ask people in tech communities you’re a part of, or go to [OpenSauced Insights](https://insights.opensauced.pizza), and check out the [list of contributors](https://insights.opensauced.pizza/javascript/contributors/filter/recent) for the technology you’re interested in and reach out to them to learn more about their experiences contributing to the projects they’re a part of.
- Find a project that has beginner-friendly issues. Projects with "good first issues" or "beginner-friendly" labels are often good for beginners. 

![good first image](https://cdn.sanity.io/images/r7m53vrk/production/23ddbe0889ac541dc4f475e8cef280f82e78bb6b-613x145.png?w=450)


If there aren’t any labels for beginners, don’t forget that the [best first issue is the one that you write yourself](https://opensauced.pizza/blog/good-first-issues-dont-exist).

- Read the project documentation. Once you’ve found a project that you want to contribute to, it’s important to read the project documentation. This will help you understand the project's goals, its codebase, and its coding standards. Always read through the README and CONTRIBUTING guides. Not only can you get a better understanding of the project, but the expectations for how to contribute should be explained and clear.
 
> **Check out [OpenSauced Community Health Files](https://github.com/open-sauced/.github/tree/main).**

- Engage with the Community. Join the project’s communication channels, like Slack or [Discord](https://discord.gg/6KYErCXf), their discussions, their blog, and introduce yourself. Ask questions and express your interest in contributing. Becoming a part of the community will expand your connections, help you to gain insights into ongoing discussions and development timelines, and may be an opportunity for mentorship from experienced contributors.
- Start small. Look for issues that are small and easy to fix. As you gain experience, you can start working on larger issues or taking on more responsibility. Don’t be afraid to ask for help or to let the maintainers know if you’ve taken on an issue that you can’t complete. It’s all part of the process.
- Be patient. It takes time to learn how to contribute to an open source project. Don't get discouraged if you don't get everything right the first time. Just keep learning and practicing, and you'll eventually get the hang of it.


## Community Collaboration
Being part of an open source project is being part of a community. They are there to support and help you within their capacity. Here are some tips to get the most out of the community experience.

- Review the Code of Conduct (COC)–or if they don’t have one, create an issue asking for one. The COC is there to keep the community safe and supported and it’s essential to understand what that means in the context of your community.
- Ask for help. If you’re stuck, not sure what to do or how to communicate, ask a question. **Be specific about the issue you're facing and the steps you've already taken to address it.** 
- Offer Support and Assistance. It doesn’t matter how much experience you have, there’s always someone a step behind you that you can help, and recognizing that you can help others at all stages by providing your support and unique insight can help strengthen the community and foster a positive environment for learning and growth. Actively participate in discussions, share insights, and contribute to the project and community.
- Code reviews are an important part of the open source contribution process. Embrace code reviews as opportunities for growth and improvement, and respect the feedback and suggestions provided by reviewers and project maintainers, even if they challenge your initial approach. Incorporate the feedback gracefully, and strive to understand the concerns raised. 


## Documentation and Technical Writing
Contributing to documentation is an impactful way to support an open source project. Some ways to do this include:

- Identify areas where documentation can be improved, like missing or outdated information, unclear instructions, or incomplete explanations. Improving the documentation makes it easier for new contributors to understand and contribute to the project, which leads to a more inclusive and welcoming environment.
-  Document your changes clearly and concisely. Explain any code modifications, including considerations. Clear documentation helps future developers understand and maintain the codebase effectively.
- Creating guides or tutorials is another way to contribute. Share your knowledge and expertise by creating or improving user guides, tutorials, or other educational materials. Having resources helps to effectively onboard new users and empower them to make the most of the project's capabilities.

## Contributing Beyond Code
You don’t have to know how to code to contribute to open source. [Non-code contributions]( https://dev.to/opensauced/how-to-contribute-to-open-source-without-knowing-how-to-code-a-guide-with-project-suggestions-59e5) can have a huge impact. Here are some other ways to contribute:

-  **Project management**: organize issues, create project roadmaps, or coordinate releases. 
- **Translations**:Many projects need translations to make the project accessible to a wider audience. 
- **Triaging**: Helping with bug triaging or participating in forums supports the community. You can address user-reported issues, reproduce bugs, or offer help. This improves the project's stability and the user experience.
- **Promotion**: Actively sharing the project helps raise awareness and attract more contributors and users. Sharing your positive experiences with the project, writing blog posts or articles about it, or speaking at conferences or meetups about it, helps its growth and impact.

## Dealing with Challenges and Learning Opportunities
Imposter syndrome and self-doubt can affect anyone, especially when you’re starting out. It's normal to feel uncertain. Everyone’s journey will look different. It’s important to surround yourself with supportive community members, seek encouragement, and remember that this is a learning journey–there will be growing pains.

Part of this journey means that you’ll receive feedback and constructive criticism. These are opportunities to grow. Listen, understand the perspectives of others, and use feedback to grow as a contributor.

Embrace collaboration as an opportunity to learn from others, share ideas, and build meaningful relationships. 

## Learning the Basics of Contributing
As you progress, it’s important to learn the basics as you begin your open source journey. Here are some key concepts to understand.

### Version Control System
Version control systems (VCS) are tools that help developers manage changes to source code and other files in a collaborative development environment. This means that multiple people can work on the same codebase simultaneously while keeping track of changes, facilitating collaboration, and providing a history of modifications made over time. Git is one of the most widely used VCS, allowing for capabilities like forking, cloning, and pulling. You can check out the [official documentation for Git](https://git-scm.com/doc) for more information.

### Coding Techniques
Every project will have its own strategies for writing efficient, maintainable, and high-quality code. Some of those considerations include:

- **Code Organization**: How the code is structured will impact readability and maintainability. To learn more about how these decisions are made, look into concepts like modularization, separation of concerns, and design patterns.
- **Code Readability**: Writing code that’s easy to understand helps in collaboration and reduces the likelihood of bugs. Ways to do that include using descriptive variable names, writing clear comments, and consistent formatting. 
- **Performance Optimization**: Writing efficient code can improve the speed and resource usage. Ways to improve performancing include: algorithm optimizations, data structure choices, caching, and profiling. 
- **Error Handling**: When we ship software, it’s important to think about how to handle errors. What happens when an error occurs?
- **Code Testing**: Each project will have different approaches and use different software for writing tests.  They might implement unit testing, integration testing, and test-driven development (TDD) or other methods or combinations of methods to ensure they’re shipping reliable code. 

### Project Contribution Workflows
Because open source projects have maintainers and contributors collaborating to create, it’s important that there are processes that help to ensure a positive experience working together, ensure code quality, and maintain a healthy codebase. As part of this, there are some workflows implemented, including: 

- **Code Versioning and Collaboration**: We talked about this above with Version Control Systems. It’s important to learn how to clone repositories, create branches, commit changes, and push code as well as understand collaboration workflows like forking, branching, and pull requests. I highly recommend creating your own projects for practicing, and even better, bring in a friend who’s new to coding and practice together! For more information on how to do this, check out our Intro to Open Source section on [How to submit a contribution](https://github.com/open-sauced/intro/blob/main/05-how-to-contribute-to-open-source.md)
- **Issue Tracking**: Issues are used to report bugs, suggest features, or discuss improvements. Understand how the project you’re working on uses issues, labeling, and prioritization. You can check out how we handle issues in our [Insights repository](https://github.com/open-sauced/insights/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc). 
- **Communication**: Take some time to explore how the project communicates. Are they using discussion boards or async communication platforms like Slack or Discord?
- **Contributing**: Before contributing, review the project's guidelines and standards. Be prepared to update your Pull Request (PR) based on feedback and work collaboratively with other contributors. There’s a lot that happens after your PR is submitted. So much so, that I wrote [“What happens after you submit a PR to an Open Source Project?”](https://dev.to/opensauced/what-happens-after-you-submit-a-pr-to-an-open-source-project-4ed1). There can be a lot of reasons why a PR isn’t accepted. You can find out more about that [here](https://dev.to/opensauced/understanding-why-pull-requests-get-rejected-in-open-source-projects-1jd0).


### First Time Contributor Resources
For more resources on getting started, check out the following:

- [Git documentation](https://git-scm.com/doc)
- [GitHub documentation](https://docs.github.com/en/)
- [Open Source Guides](https://opensource.guide/)
- [Intro to Open Source](https://github.com/open-sauced/intro/)
- [How to Start an Open Source Project with VS Code](https://dev.to/opensauced/how-to-start-an-open-source-project-with-vs-code-4106)
- [Writing Your First Pull Request: Tips, Best Practices, and AI-Powered Tools for Success](https://dev.to/opensauced/writing-your-first-pull-request-tips-best-practices-and-ai-powered-tools-for-success-3bg9).


Contributing to open source is an opportunity to learn new skills, connect with other contributors, and to make a positive impact. Keep in mind that maintainers are human beings who work hard to keep projects going. Always be respectful, patient, and kind. Hopefully, this guide is helpful on your open source journey. If you have any questions, let us know! We look forward to [seeing your highlight on OpenSauced](https://insights.opensauced.pizza/feed) soon.

Learn the fundamentals of open source development, from choosing projects to making contributions, in this comprehensive beginner's guide. Support open source innovation with OpenSauced.pizza.

Open Source 101: A Beginner's Guide to Getting Started

We did it! Today we celebrate our 1000th developer on the platform since our public launch in December 2022. 

Seven months ago, we started building this project to encourage contributions to open source. It began by supporting maintainers and companies just trying to understand the frequency of contributions. Recently we added the ability to auth using your GitHub to give us a better idea of where a developer might want to contribute.

### No more gatekeeping

There are a lot of barriers to contributing, and I don’t think finding projects to contribute to should be the first hurdle. More companies are starting open source by default, and employees are choosing to work for open-source projects thanks to the trend towards remote work we saw in 2020. Now is a better time than ever to participate.

Also, in 2020, we built [app.opensauced.pizza](https://app.opensauced.pizza/), a CRM-like experience to manage your existing contributions. In 2021, we built an [hot.opensauced.pizza](https://hot.opensauced.pizza/), a discovery engine, and [API](https://api.opensauced.pizza/) to find the hottest up-and-coming projects to contribute. Today, we plan to close the gap between the best developers and great projects by combining our learning into the newest tool in our kitchen, [insights.opensauced.pizza](https://insights.opensauced.pizza/start).


### Why is this working?

Developers want to be connected to something bigger than what they are building. Open source is more than a project. It is a movement. As the world continues to become more connected, developers have an opportunity, despite their physical location, to participate in building the next phase of technology. 

Companies are already choosing open source more often when building their future roadmaps. The innovation we have seen in Ai, Frontend Tooling, and Infrastructure has been fueled by the advent of open-source. The best employers use a lot of open-source and allow employees to contribute back to projects or, even better, to use company time to do it.


> 82% of IT leaders are more likely to select a vendor who contributes to the open source community ([source](https://www.redhat.com/en/resources/state-of-enterprise-open-source-report-2022)).

We are no longer limited by where we went to school or were previously employed. Our resumes can live as [Highlights on OpenSauced](https://opensauced.pizza/blog/social-coding-is-back), a shareable validation for previous work. Open source is ushering in a new generation of developers not limited to Cracking the Code Interviews. OpenSauced will catalyze change in how we approach sourcing the best talent. 

[Connect your GitHub today](https://insights.opensauced.pizza/) and join us in our movement towards 100k developers that choose open source. 

We did it! Today we celebrate our 1000th developer on the platform since our public launch in December 2022. 

1000 Developers Choose Open Source

GitHub launched in 2008 with the tagline, “[Social Code Hosting](https://web.archive.org/web/20081111061111/http://github.com/),” but is GitHub a social coding network today?

### Is GitHub a Social Network?

To answer the question, no, GitHub is today's code collaboration platform. The developer network GitHub has built centralizes around private and open-source project collaboration. Though today their focus has broadened beyond being a social network, you must see the 100 million developers on the platform and think, why not call it a social network? The challenge for most contributors is the silo created when they only work in one or two repositories (probably private).

### Open Source Highlights

At OpenSauced, we are looking to break the barrier for contributors in open source with our newest feature, Open Sauced Highlights, ushering in a new phase of Social Coding.

[![bdougie's highlight](https://user-images.githubusercontent.com/5713670/220782577-9124a92b-0e1a-4f38-92ac-2ff7e54870e5.png)](https://insights.opensauced.pizza/user/bdougie)

Where an average contributor may contribute to one project during their career, we see an opportunity to highlight those contributions and share your experience with others. Whether you are just starting in open-source or the core maintainer of [trpc/trpc](https://insights.opensauced.pizza/node/dashboard/filter/trpc/trpc), we would love to see your highlights. 

> Watch the demo of me creating my first highlight below

[![highlights announcement on youtube](https://user-images.githubusercontent.com/5713670/220782838-b546430b-56e3-4316-a572-88b2e0719029.png)](https://youtu.be/yOwQJ3zGPpI)


GitHub launched in 2008 with the tagline, “Social Code Hosting,” but is GitHub a social coding network today?

The Return of Social Coding

From my time at GitHub, I learned that the label “good first issue” was created in response to the popularity of the first-timers-only project. Thanks to folks like [Scott Hanselman](https://insights.opensauced.pizza/user/shanselman) and [Kent C. Dodds](https://insights.opensauced.pizza/user/kentcdodds), there is a pathway into open-source contributions that is approachable. The good first issue adds a label to identify bugs and minor fixes for anyone looking for a safe space to try their hand at an approachable contribution.
*This blog post came out of a series of tweets I created last year.*

[![preview of the tweet mentioned](https://user-images.githubusercontent.com/5713670/215290449-2ec23c92-334f-4bd7-be8a-ccb22c82a057.png)
](https://twitter.com/bdougieYO/status/1561746501738459137)



## Good first issues today

Fast forward to today, and you can’t ask someone how to find good first issues and have them rattle off goodfirstissue.dev or firstpr.me or even opensource.guide. As someone who leads developer advocacy at GitHub, I can say most of those folks have not used those tools, and I can say that with confidence because the majority have not been updated since before 2018.

Today there are 280 million repositories on GitHub. Of that number, only 230 thousand have more than five contributors. There is a lot of answer to why that is, but to state it, only 0.1% of the projects on GitHub provide an approachable space for new contributors.


## What’s wrong with good first issues?

Unfortunately, the notion that you can browse GitHub and search for a contribution is invalid, and we have been preaching that sentiment for years. I share this as an advocate for open-source, but good first issues do exist. Most of what is labeled needs more context for anyone new contributor to approach. There is a lot to be desired regarding good first issues. We have got this far, and I haven’t shared the punchline, but here goes:
> The best good first issues are the ones you open.
Now, I can explain.


## Purpose-driven good first issues

Good first issues exist for the sole purpose of leaving a breadcrumb for a new contributor. These are issues that a maintainer could complete in less than 10mins. They are not set up to take a lot of time, and if you follow my beliefs, there should be a clear path to the solution provided by the person who labeled the issue.

The clear path to the solution can be the actual code to be copied and pasted with a line number or a rough idea of its implementation. Some recent good first issues include fixing broken links and adjusting mobile responsiveness. The other truth is that exploring projects you have never used, hoping to contribute, is worse than sharing quotes from a book you have never read. Before you try to do any project, please install it. Cloning a repo down from GitHub and running it locally can expose many opportunities for contributions. 

https://hot.opensauced.pizza

![](https://paper-attachments.dropboxusercontent.com/s_2FD9E296945D49A46BA2E3670B43E3C7BF8D4BDB8ECA0D0929CC68CE90FB97A7_1674938128550_Screen+Shot+2023-01-17+at+11.14.40+PM.png)



We have been running a small exploration project to discover the hottest new repositories on GitHub, and most of those projects barely have a README. These projects need extra eyeballs, and we would love for folks to try them out and report back. All projects need to start somewhere; it takes a particular person to be willing to try a new project and provide context on their experience. Not every open-source project is created equal, just like the same person doesn't create every issue.


## Examples of good first issues

Let’s look at some completed good first issues in the OpenSauced org.

[![issue 295 preview](https://opengraph.githubassets.com/92a34945aa0405c0fae796e50f9958fb8781cf23b36fd00f7886c21949114670/open-sauced/hot/issues/295)](https://github.com/open-sauced/hot/issues/295) 

[open-sauced/hot#295](https://github.com/open-sauced/hot/issues/295)







This issue was opened initially due to inconsistencies with the fonts in the project. The issue clearly states the problem and provides a solution. This was picked up by a brand new contributor.

Another issue was an opportunity for refactoring duplicated code into its own reusable React Component. Now, this required someone with knowledge of React, but each line was outlined where it a duplicated, and a previously merged pull request was provided to show where similar work was completed and could be referenced. 

[![preview of issue 287](https://opengraph.githubassets.com/004a85c10be69f65e682fabfbe628d12b1ad37ecbca92ea66acb75901e24cd2b/open-sauced/hot/issues/287)](https://github.com/open-sauced/hot/issues/287)

[open-sauced/hot#287](https://github.com/open-sauced/hot/issues/287) 


This is work I could have done in about 10 mins, but I chose instead to leave for a new issue for a new contributor. The second contribution was completed by a new contributor who continued contributing throughout the summer and later became a full-time engineer at OpenSauced. The good first issue was a stepping stone to learning the project and becoming a consistent contributor.

I will leave you with this thought. If you are genuinely interested in leveling up and contributing to open source through good first issues, start by opening up issues you found and getting mentorship from the existing contributors or maintainers. You and the project will be better off for it, and at the very least, try running the thing locally.

If you want to find projects or track your own, consider checking out OpenSauced. And, of course, if you are looking for new contributors to your project, do not hesitate to reach out on our [discord](https://discord.gg/opensauced).



There is a lot to be desired when it comes to good first issues.

Good first issues don’t exist

Open source projects can be a great way to retain engineers, as they provide a platform for engineers to collaborate on and contribute to meaningful projects. This can help to keep engineers engaged and motivated, and can also provide opportunities for personal and professional growth.

### Create community first

One way that open source projects can help to retain engineers is by providing a sense of community and collaboration. Engineers who participate in open-source projects have the opportunity to work with a diverse group of people from around the world, which can be both stimulating and rewarding. This sense of community can help to foster a sense of belonging and engagement, which can in turn help to retain talented engineers.

### Turn open-source into opportunity

Another way that open source projects can help to retain engineers is by providing opportunities for personal and professional growth. Participating in open-source projects allows engineers to develop new skills and expertise, which can help to keep them engaged and motivated. It can also provide opportunities for engineers to take on leadership roles and have a real impact on the direction of the project, which can be a highly rewarding experience.

### Ride the wave

Furthermore, open-source projects can help to retain engineers by providing a platform for them to showcase their skills and expertise to a wider audience. Engineers who contribute to open-source projects have the opportunity to demonstrate their abilities to a global community of fellow developers, which can be a great way to build their reputation and advance their careers.

Overall, open-source projects can provide a powerful platform for retaining engineers by fostering a sense of community, providing opportunities for personal and professional growth, and enabling engineers to showcase their skills and expertise. This can help to keep engineers engaged, motivated, and committed to their work, and can ultimately help organizations to retain top talent.



Open source projects can be a great way to retain engineers, as they provide a platform for engineers to collaborate on and contribute to meaningful projects. 

Retaining the best engineers

Earlier in 2022, httpie announced that it lost all its stars due to a small error. The devastation of losing 10+ years of attention and traction sounds devastating, and we can all only learn from their experience to ensure we don’t make the same mistake. But, I want to digest whether any of this matters.

Projects with 15K stars are in the top 1000 repositories on GitHub

### Stars are a bad metric

GitHub Stars is not a good metric for engagement or the quality of the project, and I am not alone in that conclusion. However, you can't ignore that the industry has centralized around the GitHub Star.
Since the httpie's stardust, httpie has regained nearly half of the stars it had prior but gained the love and support of a community. Before this incident, I had not used httpie for anything and now find myself testing out the product with my APIs to see the quality of the product.

Losing all their stars became an opportunity to attract more attention to the project and expose that this open source project has a business. I am not insinuating that losing them was intentional, but I am stating that I had not used their service prior and was not aware of the product side of the business until this year. 54k stars on GitHub was validation that at least 54k individual GitHub users cared enough to validate that it was worth checking out. Per information grather from OSS Capital's COSS Community newsletters, projects with 15K stars are in the top 1000 repositories on GitHub.

### Measure with engagement

Httpie has regained its position on the elite list of top open-source projects after being at the bottom only months prior. The value the project provides extends outside of the universe of stargazers. Thousands of projects and developers use their open-source project. They have an avid readership on their blog and an engaged customer base. I led developer relations at GitHub during this incident and was DM'd by quite a few users of httpie.

The accurate metric for growth should be on community, not stars. By focusing on a growing community, httpie could scale quickly and gain exposure to a few OSS trending algorithms. Though their outside contributions were small, they had an established user base. They were in a much better place than most who found themselves in a similar situation, looking for growth and awareness. My recommendation for them is to grow their contributor community.

During my tenure at GitHub, I got the question"How to gain traction in open source," and the response was always similar. Grow a community of users and contributors who would miss you if you were gone. This validation can be from users, contributors, and even stargazers. This is arguably harder to track than stars, but at the end of the day, it comes down to when you experience a stardust event. What community can you reach out to for graceful recovery?

### Measure with OpenSauced

If you are interested in growing your contributor community, consider joining our OpenSauced Insights community. You can get alerts on contribution and community growth, so you always know when to make an impact.

*(thumbnail image generated by Dalle 2)*


The GitHub star is the wrong standard for measurement for growth.

The Return of Social Coding

Is GitHub a Social Network?

Open Source Highlights

Subscribe for Extra Sauce