Scaling up generative AI operations can be costly. At OpenSauced, we faced this challenge while building StarSearch, until we found a low cost solution to deploy an OpenAI-compatible API using open source technology.

How We Saved 10s of Thousands of Dollars Deploying Low Cost Open Source AI Technologies At Scale with Kubernetes

At OpenSauced, we are thrilled to announce our latest feature: **StarSearch**. Get in-depth insights into contributor history with our AI-powered feature, StarSearch - and you can [join the waitlist now](https://oss.fyi/OS-StarSearch)!


![star search example](https://cdn.sanity.io/images/r7m53vrk/production/3bd42049113673545a329b3e04569c6018a7c121-1440x1101.png?w=450)


With StarSearch, you can now uncover, understand, and leverage contributor history.

## What Can You Discover with StarSearch?

- **Contributor Activities**: Learn the details of contributions and contributors.
- **Key Contributors**: Identify the key contributors to projects and ecosystems.
- **Work-Based Connections**: Find potential collaborators based on their contributions to specific projects.
- **Hidden Experts**: Discover untapped talent in the ecosystem.

![gif of starsearch](https://cdn.sanity.io/images/r7m53vrk/production/36bb08fe40cf2f29e9def6cddfd25e0c6503f063-800x600.gif?w=450)

## A Solution to Sourcing Talent

Recently, Adam Wathan of Tailwind CSS expressed a challenge: attracting applicants well-versed in a niche combination (Rust and Tailwind) despite offering competitive salaries. Inspired by this challenge, we asked ourselves, "Wouldn't it be cool if we built something to find this persona?" StarSearch allows you to get answers to your questions even when you don't have the context. The context for this question: most of the developers on the list work on front-end focused teams with an interest in developer performance.

[![adam wathan tweet](https://cdn.sanity.io/images/r7m53vrk/production/641ea26c1301a1dc6e5d298c0c0b44d416d26e64-1180x736.png?w=450)](https://x.com/adamwathan/status/1773341818773540949)

We’re not just another tool; we're here to redefine the meaning of open source. Let's uncover the stories behind the code together - [Join the Waitlist Today](https://oss.fyi/OS-StarSearch) and be sure to follow us on [Product Hunt](https://www.producthunt.com/products/opensauced) to be notified when we go live!

Get in-depth insights into contributor history with our AI-powered feature, StarSearch

The Future of Open Source Collaboration is Here: Meet StarSearch

As the first day of Maintainer Month, it's a good time to reflect on the role of the maintainer in the open source ecosystem. Despite the necessary role they play, their efforts can be underappreciated and the experience can be overwhelming. As [Ashwin Ramaswami from the Linux Foundation Blog](https://www.linuxfoundation.org/blog/open-source-maintainers-what-they-need-and-how-to-support-them#:~:text=There%20is%20no%20fixed%20definition,lead%20an%20open%20source%20project.) puts it, "There is no fixed definition for maintainers, but broadly, the term refers to those contributors who lead an open source project."

## The Unseen Labor of Open Source Maintainers

A definition I like better is from [Steven J. Vaughan-Nichols](https://www.zdnet.com/article/hard-work-and-poor-pay-stresses-out-open-source-maintainers/), where maintainers are compared to "the conductors of an open source project orchestra." They’re often responsible for writing code, managing documentation, triaging bug reports, creating awareness, communicating to diverse groups of people, and supporting and encouraging community engagement. You can imagine, then, that the day-to-day tasks can feel overwhelming, as [Nolan Lawson's 2017 reflection](https://nolanlawson.com/2017/03/05/what-it-feels-like-to-be-an-open-source-maintainer/) describes: “Outside your door stands a line of a few hundred people... You want to help all of them, but for now, you’re putting it off. Maybe you had a hard day at work, or you’re tired, or you’re just trying to enjoy a weekend with your family and friends.” 

## The Sustainability Crisis

The traditional model of open source maintainership — which often relies on volunteering and inconsistent or total lack of funding — is increasingly proving unsustainable. This lack of support puts both the future of the maintainers and the projects at risk for abandonment. A [2021 survey by Tidelift](https://blog.tidelift.com/dealing-with-burnout-in-open-source) showed that a significant portion of maintainers feel undervalued, which we know can lead to burnout and even mental health issues.

One of the biggest challenges maintainers face is the balance of making progress towards the vision and purpose of the project and the ever-changing needs of the users. This balance - [and the challenges of scaling a project](https://opensauced.pizza/blog/scaling-oss-projects) - requires careful consideration, prioritization, and focus, otherwise your team will find themselves on a series of side quests but never moving forward on the main path.

Beyond issues and bug reports, maintainers also have the responsibility of cultivating and managing their project's community. This often means mediating conflicts, establishing coding standards, and creating a welcoming environment for community members. This portion of the job requires an altogether different skillset, utilizing strong core skills, requiring emotional intelligence, diplomacy, and a desire to create a healthy, productive ecosystem. This all plays into the cognitive load the maintainers bear.


## Reducing the Cognitive Load of Maintainers

> **Cognitive Load**: the amount of mental effort used in your working memory. 

A high cognitive load not only impacts the maintainer’s efficiency and creativity but can also contribute to burnout. If we can reduce the burden for maintainers, we’ll be creating a healthier and more sustainable open source ecosystem. In addition to [being an empathetic contributor](https://opensauced.pizza/blog/stop-burning-out-maintainers:-an-empathetic-guide-for-contributors), here are some strategies to alleviate the cognitive demands open source maintainers face:

### Streamlining Communication and Workflows

One of the top asks I’ve heard from maintainers is finding a way to more easily triage issues, closing duplicates, removing stale issues and angry rants, and making the process of sorting issues less complicated. There are already features and actions that can help make this happen, but we have a long way to go to empower maintainers to focus on the most critical tasks first. In addition to this, identifying low-quality submissions and removing unnecessary communications can help decrease the amount of attention maintainers need to shift to respond to pull requests and issues.

### Leveraging Community Support

One of the most effective ways to reduce a maintainer's cognitive load is to delegate responsibilities to trusted community members. This is easier said than done, however. Because these roles are often volunteer, volunteers often “disappear” or stop communicating and maintainers must ensure the quality of work is sufficient and that volunteers have adequate support. It takes work to create roles for community moderators, issue triagers, and peer reviewers in order to distribute the workload more evenly. The first step is to become a dedicated community member who shows up, answers questions, engages with the community, and demonstrates that maintainers can depend on you. If there isn’t already, a volunteer can offer to create defined roles and responsibilities as well as create detailed documentation on what each role entails and what is expected to reduce volunteer turnover. Another option would be to create a structured onboarding process that includes important information about the project and connects volunteers to mentors or people who have a deeper understanding of the project.

### Encouraging Asynchronous Work
Maintainers often feel pressure to respond immediately to community requests, which can be stressful and divert their attention. Encouraging an asynchronous work environment with boundaries can help decrease the pressure maintainers often feel when a new notification comes in. This involves setting expectations within the community that not all communications will receive an immediate response. 

### Focusing on Documentation
Well-maintained documentation can significantly reduce the cognitive load for maintainers by answering common questions and providing clear instructions for contributors. As part of this, when contributors run into issues with a project, they should create an issue to update the documentation.

### Providing Training and Resources
Finally, providing maintainers with access to training and resources on best practices for project management, stress management, and effective delegation can help give them the skills they need to manage their cognitive load. Workshops and mentorship programs can also be helpful maintainers as well as finding ways to connect maintainers as part of a community, reducing the feeling of isolation that often accompanies maintainer roles.

## Celebrating and Supporting Maintainers

Let's show our appreciation for open source maintainers throughout the year, not just in May.  Here's how you can get involved:

- **Financial Support**: Explore funding options for critical projects.
- **Contribute Code or Content**: Help advance the project with your skills.
- **Reduce Cognitive Load**: Help triage issues, write documentation, or answer community questions.
- **Send a Note of Recognition**: Thank a maintainer for their hard work at [oss.love](https://oss.fyi/love)

The goal for all of us should be to create a future where maintainership isn’t just sustainable, it’s fulfilling and rewarding. 

This article highlights the critical but under-appreciated role of open source maintainers and explores ways to create a more sustainable and rewarding open source ecosystem.

Maintainer Month: Enhancing Support for Open Source Maintainers

## Open Source Insights

There is no community tool that will replace building meaningful connections. Working in open source can be challenging to track and measure. Identifying what is success in a project can be hand-wavy and is sometimes met with a focus on the wrong metric. Organizations like the CHAOSS give us a lot of metrics, but no direction. There is currently no definitive statement on what success looks like in open source, but I have a few opinions to share. 

![data on the react-router](https://gist.github.com/assets/5713670/a8ac194d-54ef-4389-b25c-0d174f7014cb)

In a recent talk I gave on discovering unconventional metrics, I outlined the overlooked metrics of new outside contributors and company representation.  

![conference talk on unconventional metrics](https://gist.github.com/assets/5713670/5777bc9e-2bca-462f-92f6-7a427c190ba5)

_[Link to conference talk](https://www.youtube.com/watch?v=V91M6vs11RY&t=1s)_

### New issues show interest

One key indicator of a thriving open source project is a consistent influx of new contributors opening issues. When a project regularly attracts new participants who are willing to invest their time in reporting bugs, suggesting improvements, or requesting features, it demonstrates the project's vitality and relevance to a growing community. 

![podcast episode with brendan burns](https://gist.github.com/assets/5713670/5371a5f5-c89f-4ca0-907a-0e3740973af8)

_[Link to podcast](https://www.youtube.com/watch?v=0MeGKxjv3P4)_


The Kubernetes project learned this first hand 10 years ago (this July) when they saw several issues opened by Red Hat employees. Find that story in my [conversation with Brendan Burns here](https://www.youtube.com/watch?v=0MeGKxjv3P4).


This cohort of engaged users, who may eventually become code contributors or long-term maintainers, is essential for the sustainability and growth of the project. By tracking the number of issues created by new authors over time, open source maintainers can gauge the success of their community-building efforts and the overall health of their project.


### Open Source Contributors Metrics

It is not enough to track issues; tracking how issues are uniquely created by outside contributors play a role in the success of a project. These individuals, who are not part of the core development team, represent connected companies and communities with an interest in the project. Their contributions help to enhance the project's functionality, usability, and accessibility. Moreover, outside contributors serve as ambassadors for the project, spreading awareness and attracting new users and developers to the community. By leaning into this metric, open source maintainers can ensure the long-term viability and impact of their project.


The chart below highlights confidence for stargazers and forkers in the top 8 most popular JavaScript projects.

![contributor confidence](https://gist.github.com/assets/5713670/77602eef-f21b-43f0-bbe2-ae32c5248288)

A metrics we are testing internally now is the “Contributor Confidence,” the ability for an individual to contribute more than once. Open source generally over indexes on [good first issues](/blog/good-first-issues-dont-exist), but following the journey through repeat contributions tells a better story for health.

### Tracking Success

Open source is the bedrock for so many developing tools and companies, it would be paramount to figure this out so we can see the continued growth from the projects we depend on. 

Tools focused on measuring community tend to focus on drive-by interactions like forks and comments but rarely give a sense of what impact the project is providing. Now with the [acquisitions of crowd.dev](https://www.crowd.dev/post/crowd-dev-acquired-by-the-linux-foundation) and [orbit.love](https://orbit.love/blog/orbit-is-joining-postman) last week, I could not be more proud and validated that the path we are on for sustaining open source through meaningful metrics is needed more than ever. 

By focusing on open source projects, we're able to provide specialized insights that cut through the noise to give you the information you need for an impactful open source project.

![coming soon dashboard](https://gist.github.com/assets/5713670/da322777-7d72-469d-8c11-44855d115c19)

Remember open source feels better when done together. Explore OpenSauced to discover how you can measure. Follow our [changelog](/changelog) for updates as we ship more metrics to our workspaces. 


Discover how to effectively measure the success of your open source project by tracking community engagement metrics, such as issues created by new contributors and the impact of outside collaborators. Learn why these indicators are crucial for the long-term growth and sustainability of your project.

Managing successful communities in open source

In 2023, I had a chat with Max Stoiber, CEO of Stellate, on [a podcast to learn about his early success on GitHub](https://www.youtube.com/watch?v=zccUlq1As1o). His first open-source project, [react-boilerplate/react-boilerplate](http://react-boilerplate/react-boilerplate), gained a whopping 10k stars in just one weekend after appearing on the homepage of Hacker News. This success led Max to drop out of university and create several other popular open-source projects, including [styled-components](https://github.com/styled-components/styled-components). This library accelerates the process of building styles in React components.

Nowadays, the number of projects hitting 10k stars is more common, inflating the overall number of GitHub Stars. Presently, GitHub has over 100 million users, but back when React Boilerplate started, GitHub had fewer than 10 million users. Getting 10k stars on a project seemed impossible, but with 10x the amount of users, the value of the GitHub Star has suffered from inflation. 

Looking back in 2023, the biggest projects with the highest star growth can attribute these star events to intentional marketing. Landing on the front page of Hacker News is still challenging, but tweeting your project's social card can return similar results. The industry has changed a lot in the last 10 years, and where there was a time when open source was driven by weekend code sessions, today open source is fueled by sustainable sponsorship and venture capital. This is not entirely a bad thing, as it provides a sustainable future for the biggest projects we get to use and love. 

The challenge in this new reality is defining what is worth looking at and whether GitHub Stars are still relevant for discovering projects worth your time. Correlating the best metric to identify projects to invest your time in depends on who has the biggest reach in a community. This seems contrary to how open source started and marks a shift in how we think about success in open source moving forward. These high growth moments are now indicators of big events like appearing on a subreddit or getting mentioned by a developer influencer on YouTube. 

A popular site to see your star growth is star-history and it has become a standard for sharing your GitHub Star growth hacking journey. They also link a post on "[how to get more github stars.](https://star-history.com/blog/playbook-for-more-github-stars)"

Some notable projects with Star events in the last year include godot, daytona, plane, and zed. 

### Growth Hacking With GitHub Stars 

**godot/gotengine** capitalized on the Unity announcement on September 12th, of 2023, with their own announcements. At that time, they had been working on their tool for some time and already had a community they tapped into to share their open source alternative game engine. 

![godot stars](https://gist.github.com/assets/5713670/8d58d2af-bbe9-49fb-9888-15b23ac47b28)

*(note this chart is available on [oss.fyi/godot](https://oss.fyi/godot/))*

**zed-industries/zed**, the successor to the atom editor built in rust, coordinated the launch for their repo with friends and trusted acquaintances to create a star event that registers as the edge of the graph. That, indeed, is a vertical line if I ever saw one. 

![zed data](https://gist.github.com/assets/5713670/7f8441c5-3ed9-456c-98bb-e1e31867566a)

**daytonaio/daytona**, a self hosted cloud developer environment, learn from its predecessors to become the most starred project for a few days. 

![daytona data](https://gist.github.com/assets/5713670/eb9973e2-3342-4bdf-b2f0-61b03e11a4c0)

Finally, **makeplane/plane** came into some heat when they posted their chart with unnamed competitors. The stars are valid, and the result of conscientious growth hacking. 

![makeplane](https://gist.github.com/assets/5713670/99cec310-b769-443c-8f17-5673b7145d3a)

The open source community does not like to be sold and asking for a star is a low effort way for makers to grow and engage a community through open source. With that said, there are still a lot of open source maintainers and contributors who prefer not to participate in the process of growth hacking to gain GitHub Stars, and a lot of pushback came from engineers who built their careers on growing open source differently.

The Plane team wrote up outlining their growth hacking journey in a follow up post to the [original tweet](https://x.com/planepowers/status/1703627427946311832?s=20).

*(Read about their journey to 20k stars [here](https://plane.so/blog/how-we-got-to-20k-github-stars).)* 

### The Problem with Open Source Star Inflation

Now that we have established that stars are the metric for growth hacking, what is the metric for showing the project's health? In our opinion at OpenSauced, there is not one metric but a few and you can start aligning alongside stars. 

There is no doubt that thanks to growth hacking we are seeing GitHub Star hyper-inflation. Now, with currency inflation, it is encouraged to find alternative places to store your assets. Still, with GitHub being the home for open source, I don’t imagine a new stargazing like currency showing up anytime soon.

Stars are not quite a representation of adoption, but if we look closer, we could correlate a combination of metrics to tell a bigger story:

1. Commit velocity is a quick way to see a project’s activity.
2. Stars are a quick way to see early interest, but there is no correlation.  

![commits and stars](https://gist.github.com/assets/5713670/e95d0805-740d-4ac4-9fe9-23661d4dabe7)

_Above is a star and commit velocity charts in grafana for the makeplane/plane project. 
_
There is a shift happening in open source, and I think it would be unfair to not recognize the folks that built projects that made this ecosystem, the same ecosystem that makes it so easy to become an overnight (over a few months) success.  

In a conversation with [Brendan Burns on that same podcast](urhttps://www.youtube.com/watch?v=0MeGKxjv3P4), I learned that early Kubernetes used issue counts to measure interest and pull requests to assess adoption. Taking it a step further, you can see a correlation from forks to stars.

![stars and forks](https://gist.github.com/assets/5713670/90ec7a6f-8311-4df1-bb4d-2aebec19cf58)

*The chart above is the correlation between stars and forks.*

Based on my conversation with Brendan this correlates to adoption and when you really dig in you will find that with plane being so new, their contributions made exclusively form plane from employees, with the exception of one contribution from a developer member of the French Government. Perhaps a sign of adoption starting with them.

![contributors for plane](https://gist.github.com/assets/5713670/e8f392c7-403e-4ea0-9a8d-2d05edfdf3ce)

The logical next step is to examine contributions from organizations and determine if there's a solid star-to-PR pipeline. If you're keen on monitoring your star-to-PR pipeline, consider setting up a workspace on OpenSauced to begin uncovering valuable engagement insights.

![growth hack workspace](https://gist.github.com/assets/5713670/ec34dd25-dfef-4f1a-8a21-a3d0dde0d8cc)

*([oss.fyi/growthhack](https://oss.fyi/growthhack))*

As the open source landscape evolves and GitHub Stars continue to inflate, it's essential for developers and contributors to consider multiple metrics when evaluating the health and success of a project. 

![engagement metrics](https://gist.github.com/assets/5713670/b5f77668-57ba-4c3b-b3a7-348c5ddaeda1)

By looking at commit velocity, issue counts, pull requests, and forks alongside stars, we can better understand a project's adoption and overall value. Let's continue to support the open-source community by focusing on meaningful contributions and nurturing authentic engagement, ensuring that we maintain the integrity that makes open source so special.

If you are interested in seeing better metrics for measuring open source success, consider creating a [workspace](http://app.opensauced.pizza/start).


GitHub Star inflation raises concerns in open-source projects. Evaluating a project's health and success now requires considering commit velocity, issue counts, pull requests, forks, and stars for a complete picture.

Growth Hacking Killed GitHub Stars

The growth of an open source project is a testament to its value and relevance. But, growth brings its own set of challenges, especially when it comes to managing the influx of contributions, maintaining project health, and communicating with core members of your team. Finding the right approach to manage this growth can be as important as the development of the project. 

## The Complexity of Open Source Growth

> “The problem facing maintainers today is not how to get more contributors by how to manage a high volume of frequent, low-touch interactions. These developers aren’t building communities; they’re directing air traffic.” Nadia Eghbal from Working in Public: the making and maintenance of open source software, p. 13

Open source teams are often working not in one repository, but in multiple or sometimes even organizations with different issues, contributors, and teams. Keeping track of GitHub notifications is hard enough on its own, but add to that building relationships with contributors, reviewing pull requests, updating documentation, and more, sometimes you lose sight of the ultimate goals of the project and forget to think about health and sustainability. On top of that, if you’re working on projects either in tandem or as part of your job, there’s often an element of needing to justify what you’re working on. The challenge of balancing code-centric and community-centric needs can be overwhelming.

So how do you cut through the noise and make sure that you have a good sense of direction and the value that your project is creating? 

## Understanding Your Open Source Project with Workspaces 

Understanding the direction and value of your project can be challenging. To navigate these challenges effectively, it’s helpful to:


- Understand your project at a high level
- Collaborate and create transparency with your team
- Streamline contributor engagement
- Measure and share success

Let’s take a look at how we do this at OpenSauced with our new [Workspaces feature](https://docs.opensauced.pizza/features/workspaces/).

### High Level Overview of your Open Source Project

Being able to look at all your repositories and understand them at a high level, makes it easier for you to share this information, collaborate with others, and understand where your projects stand in terms of health. This is our team page for our most frequented repositories:

![workspaces overview](https://cdn.sanity.io/images/r7m53vrk/production/ebc453a4df91fbad4eaaf30a64682788e07a904d-2894x1486.png?w=450)


When we look at our OpenSauced repositories together, we all have a clear understanding of where our projects are succeeding and where they’re stagnating. In the image above, you can see that over the last 30 days, we’ve had a high activity level, with close to 20 contributors in the app repo, which is reflective of the new feature we’ve launched called [Workspaces](https://docs.opensauced.pizza/features/workspaces/ ).

On the other hand, we can see that three of our repositories have had low activity levels, with the AI repo actually showing that there’s no activity. This repository was primarily contributed to and maintained by our interns last summer, and hasn’t been prioritized among all the other work we’ve done. 

### Collaborating with Your Open Source Team

Understanding the activity for all of our projects has allowed us to make decisions as a team, set goals for our projects, and understand what brings the most value to those using our product. 

With our OpenSauced Workspace, all of the team has been added with the ability to add, edit, and delete the repositories we’re tracking. This gives the whole team a sense of what’s going on. For example, if John creates a new repository for something he’s working on, he can add it to this Workspace so we all can see the activity of his project. More ways we can gauge how we’re doing as a team include:

- **Velocity of PRs and Issues**. We have a high rate of merged pull requests in the last month, and have been closing more issues than have been opened. 
- **Star-to-fork ratio**. We know that people are contributing and starring the project at a healthy rate, indicating a growing contributor community. 

Your workspace doesn’t have to be the repositories in your organization, though. Sometimes it’s important to track other open source projects you depend on, projects that are similar to yours, or projects that your contributors are also involved in. Think of your workspace as a point of communication for your team. Providing them with the information they need to know, equips everyone for success. 

### Streamline Contributor Engagement

Having a high level understanding of your project is a good step in understanding your project’s value, but really understanding what’s happening beneath the surface is the next step in being able to assess project health, growth, and the contributor community. 

But what does that mean? I can’t look at my GitHub repository and know if it’s a healthy project. I can see there are contributors, but I don’t know what types of contributions they’re making, if they’re repeat or one-time. It starts to become a really complex process that takes more time away from doing what you usually want to do as a maintainer or contributor: create PRs and work on the codebase of the project.

In Episode One of [The Business of Open-Source: A Conversation with Heather Meeker](https://podcasts.apple.com/us/podcast/the-business-of-open-source-a-conversation/id1509803992?i=1000647496795), Heather Meeker says, “If you look at how many contributors there are to a project, how many downloads there are of the project, how engaged the community is. You have amazing intelligence about product market fit.”

As the number of contributors grows, it’s important to differentiate between high-impact contributions and those that require less immediate attention. Organizing your repositories, and understanding how contributors are contributing, allows for better management of tasks and more efficient triage processes.

GitHub tells you the number of contributors you’ve had as a total, but that’s not a good way to evaluate the health of your project. Understanding your contributors over the recent history of the project is more valuable. For example, it might show that you’ve had 3,000 contributors, but if you haven’t had any in the last 30 days, then there’s probably a major issue with the health and sustainability of the project. 

A better indication would be seeing sustained and consistent contributions over the last thirty days. Your graph will likely depend on the size of the project. For example, this is our Repository Insight into our contributors activity, which reflects a Medium Activity Level for our repositories.

This is Godot’s Repository Insight into their contributors activity where they have high level of activity:

![godot workspace + insight page](https://cdn.sanity.io/images/r7m53vrk/production/0d55f8084e18316da37a24650a43819b9afeb8d6-1920x1080.svg?w=450)

Part of dealing with the pain points that comes from growing your project is elevating key contributors to teams to help sort through the challenges of maintaining an open source project. But it can be hard to keep tabs on who your volunteers are, whether they’re still active, and finding time to adequately recognize their efforts and impact on the project. 

![triage team gif](https://cdn.sanity.io/images/r7m53vrk/production/b06ad1bdb3c96a577b6e17eb7d6792d92f7af8af-1080x1080.gif?w=450)

Being able to categorize the types of contributors you have and see them at a glance, allows you to make informed decisions about the future of the project. If you find that the members of your triage team aren’t active anymore and that’s why you’ve been feeling extra pressure, then it’s time to recruit new triage members or reach out to the inactive members. 

Or if you see that one of your teammates has been doing exceptionally productive work lately, you’re better able to acknowledge and recognize that teammate's contributions. 

Not everyone on your team will need to know all the information about contributors, but giving them access creates opportunities for communication, transparency, and collaboration.

### Measure and share success

There are many different reasons you might need to measure the success of your project. Without insight into your project's activity level, health, and contributor community, it can be a challenge to show the value of your projects. At OpenSauced, we find it helpful to have real-time analytics on our projects so we can highlight our key achievements, recognize the impact of our contributors, and communicate the hard work that’s been put into our projects. It’s also helpful to see how your contributors are talking about your project. 

![Ayu's docs highlight](https://cdn.sanity.io/images/r7m53vrk/production/ae032e1ab1f08b7615074b4038c9497fd311be6d-1034x1000.png?w=450)


## Final Thoughts

The path of open source projects has unique challenges, especially as projects scale. Effectively managing the growth of an open source project goes beyond code contribution; it involves a holistic approach to community building, project health monitoring, and clear communication. Adopting strategies for comprehensive understanding and collaboration is key to sustaining project growth and ensuring success. The ultimate goal is to create a thriving environment where both the project and its community can flourish.

If you want to learn more about Workspaces, check out our YouTube walkthrough:


[![YouTube Walkthrough](https://cdn.sanity.io/images/r7m53vrk/production/7e24477fa86d8ae02022020a553322d3916907d0-720x405.png?w=450)](https://www.youtube.com/watch?v=xpxIyR4-rRc) 




Gain insights into the challenges of scaling open source projects, with solutions for comprehensive understanding, collaboration, and sustainable project development.

Navigating the Challenges of Scaling Open Source Projects

Last year Nat Friedman and Daniel Gross kicked off the AI Grant and have incubated 60 companies with the pre-seed and seed funding. 

_[AI Grant Announcement on Twitter](https://twitter.com/natfriedman/status/1752831181677305952)_

Applications are open once again and I was curious to see what open source projects benefited from participating in the previous batches. My thesis is that open source provides an organic opportunity for growth and traction for AI startups. 

This list was put together by tracking all public GitHub organizations that took AI Grant funding on OpenSauced. There I was able to quickly see project activity and which projects have an open source developer community alongside that matches up with the traction and engagement.
 
![insight page on opensauced](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z1i1c5dzlegobxgd1gqd.png)

The OpenSauced AI Grant recipient list is public and viewable here.

## Rowy 

You know, Rowy is open-source, and it's not just for developers. I always tell this story when I start working with new engineering teams. I once built an entire database for my employer's marketing site using Google Docs and a bunch of code. Only later did I discover that there were companies offering this as a service - they're called CMSs! Thankfully, I survived my over-engineering days, and now there's an even better solution: using a spreadsheet-like interface to manage a database without even realizing it.

What's cool about Rowy is that it opens up your database to the rest of your team since they probably already know how to use a spreadsheet. Low-code tools are getting more popular by the day, and Rowy stands out by using GPT-3 to generate projects and workflows.

Not too long ago, Rowy launched BuildShip, which takes things up a notch by helping users create workflows for no-code tools. You might think that no-code tools come with limitations and lock-ins, but BuildShip is here to change that. It's compatible with over a million npm packages and offers one-click deployment options to various cloud platforms like AWS and Azure.

Rowy has been around for a few years and it looks like the majority of the recent contributions still mostly come from their cofounders (marked in OpenSauced as maintainers), but it seems like they have decent traction with over 5k stars and almost 500 forks. 

![rowy contributors on opensauced](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2m4i9dexqf6t0rnbldwp.png)

While searching through their GitHub repo, I saw they engage the community by allowing them to upvote items on the [roadmap](https://roadmap.rowy.io/roadmap). This seems like a clever way to build a highly engaged userbase, and it shows. 

[rowyio/rowy](https://github.com/rowyio/rowy)

Stats from the repo:
⭐ 5.5k
👀 58
Forks: 457
License: Apache-2.0


## Replicate

Replicate allows you to run machine learning models using a cloud API without needing to be an expert in machine learning or infrastructure management. You can run open-source models published by others, or package and publish your own, either publicly or privately. The great part is that many of these models are open-source on GitHub, making it an excellent resource for learning.

Think of cogs as GitHub repositories that you host on Replicate for private or public use in your projects. Managing and hosting ML models can take several paths, most of which require a strong background in MLOps, which can be intimidating for beginners.

With Replicate, you can explore hosted cogs and easily integrate them into your project with just a few lines of code. I highly recommend browsing through some hosted models for inspiration for your AI side project.

Explore some hosted replicate cogs

![replicate contributors on opensauced](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cxamidl8jkfpxhh0xync.png)

A number of the example cogs are made from Zeke the founding Designer at Replicate.  Thanks to cog model, the approach towards contribution to the Replicate open source project is really approachable and will be a driving force for more users adopting shared models on their platform. 

The secret sauce for a lot of open source is making the project extensible and cogs are proving that model. Their community is growing fast and onboarding new hosted cogs every day, some with up to 100k runs. 

https://github.com/replicate/cog

Stats from the repo:
⭐ 6.4k
👀 62
Forks: 434
License: Apache-2.0


## Chroma

Every time we've experienced a major shift in computing - from mainframes to PCs, the web, mobile devices, and the cloud - we've seen the birth of a new software stack. In this latest stack, AI takes charge of the application logic layer. It's programmed using natural language, and it's incredibly flexible. But there's more to the story than just logic - we can't forget about memory.
To handle the memory, storage, and state layers, we need a completely new approach: AI programmable memory. This goes beyond simply storing and fetching information; it actually determines what info is accessible to the AI. This is crucial for making AI systems reliable, controllable, easy to understand, and safe.

Enter Vector Databases: these specialized databases are designed to efficiently store, manage, and work with high-dimensional vector data. They're not like your traditional databases with tables or documents - instead, Vector Databases use mathematical representations of data points in multi-dimensional space. This makes searching and retrieving information faster and more accurate, especially when dealing with huge data sets or complex queries.

By taking advantage of advanced indexing and search algorithms, Vector Databases boost the performance and scalability of AI applications. They're an essential ingredient for developing next-gen AI systems, and that's where Chroma comes in. It's a Vector Database that lets users create LLMs (Language Learning Models) to power intuitive AI experiences for their users.

I recently sat down with one of the Chroma founders to talk about their unique position in the space and how they stand out from other solutions.
https://www.youtube.com/watch?v=BqKUOKMkdic&t=34s

Their secret sauce seems to be making vector searching and building knowledge bases accessible. Not only do they work in Python, a well known language for AI/ML, they also have JavaScript and Rust SDKs support by the community. 

[chroma-core/chroma](https://github.com/chroma-core/chroma)

Stats from the repo:
⭐ 10.8k
👀 73
Forks: 882
License: Apache-2.0

## Submit to the AI Grant

Gaining traction for startups can be even more challenging than building the project itself. Securing funding and exposure creates a win-win situation, and these projects have all benefited from being accessible to the open-source community. My thesis on open-source is validated as AI startups gain significant traction by not only making their projects open but also extending them to the community.

If you are considering building or launching an AI project in 2024, I recommend considering submitting for the AI Grant before the deadline, February 16th. I wasn’t able to cover all open source projects that received a grant, but here a few more worth checking out:

[RunPod](https://github.com/runpod)
[Hume](https://github.com/HumeAI) 
[Coframe](https://github.com/Coframe/coffee)

And if you like to see the longer list of previous open source submissions checkout [oss.fyi/aigrant](https://oss.fyi/aigrant).

Taking a look at the most successful open source projects in the AI space to discover what their secret sauce is for growth.

AI Secret Sauce: Traction In Open Source

As a bootcamp grad myself, I can understand that it’s overwhelming to try to break into the industry with so many people giving you advice. I remember being a couple of weeks short of graduating and one of the school's founders telling me to get involved in open source. I felt panicked. *Why am I hearing about this for the first time? How do I do that? *What* does that even mean?* 

Here’s the thing: contributing to open source isn’t about a checkbox, it’s about building a connection. I think that’s where we get it wrong a lot of times.

There’s recently been a lot of talk about whether or not people should be contributing to open source. I’m not going to talk about that directly, but I’m going to talk about what might cause someone to not want new contributors: burnout. 

It’s no surprise that many maintainers are facing burnout. There are a lot of reasons for this, including [lack of recognition](https://opensauced.pizza/blog/the-need-for-recognition-in-open-source), [loneliness](https://opensauced.pizza/blog/the-lonely-journey-of-open-source-maintainers), lack of compensation, high demands, and increasing responsibilities. 

> “Just keep in mind that my time is finite and if I have to go back and forth on your PR for stuff you could have caught yourself with a second look, you take time away from other PRs” - Sindre Sorhus

If we want a healthy open source ecosystem, we cannot put all the work on maintainers. Contributors have to share the responsibility and be good open source citizens. Maybe right now you’re thinking, “What does that mean?” Well, I’m about to tell you.

## Read the Directions

I don’t know about you, but in grade school, there was always that one teacher that would create a quiz with a bunch of directions. At the end of the directions, it would say something like, “As soon as you’re done reading the directions, hand in your quiz.” Half the class would be writing huge essays, and the other half would be turning in their papers. The ones who were still writing were panicked because, *How are all those people finished already?!?!* The teacher did it to make a point: Read through the directions in their entirety to understand the assignment. Open Source is no different.


- **Read the Readme**. Do you understand all the steps to get the project running? Have you tried to follow the steps to run the project?
- **Read the Contributing.md**. Do you understand how to communicate with maintainers? Do you understand your responsibilities as a contributor?
- **Read the issue**. Have you read it a second time? Have you looked at screenshots, gifs, or videos provided in the issue? Do you understand what the issue is asking? (If you don’t, do not ask to be assigned the issue until you understand.)
- **Read the PR template.** If you’re to the point of submitting a pull request, make sure you read through each section of the PR template and answer each section.

Any time a maintainer has to give you feedback because you haven’t spent the time to read through all the content they’ve prepared to enable you to succeed in your contribution, you’re contributing to their burnout. Reading directions is not optional.

## Check Your Work

It is not the maintainer's job to proofread and check your work. I’m going to say that again: It is not the maintainer's job to proofread and check your work. It is *your* job to make sure your work, well, works. Ask yourself:


- [ ] Can I run this locally without errors?
- [ ] Have I manually tested it?
- [ ] Have I addressed everything that’s asked for in the issue?
- [ ] Have I run tests (if applicable)?
- [ ] Does the build work in GitHub?

Any time a maintainer has to give you feedback because you haven’t spent the time to check your work, you’re contributing to their burnout. Checking your work is not optional.


## Be a Problem Solver

I have four kids. When they get stuck on a problem, I tell them, “Be a problem-solver. What can you do to figure this out?” Sometimes they cry, sometimes they yell, and sometimes they succeed. I know that sometimes it’s impossible to figure it out on your own, but there are plenty of times that it’s growing pains. You have to push yourself and believe that you can solve the problem. If you’re stuck, before you ask for help, ask yourself:

- [ ] Have I read the error messages?
- [ ] Have I spent time understanding the problem? (A good indication that you understand the problem is if you can explain the error, why you think it’s happening, some possible solutions, and what you’ve tried.)
- [ ] Have I checked for typos
- [ ] Have I googled the error messages?
- [ ] What have I tried to do?
- [ ] Have I read the documentation?
- [ ] Have I looked at other issues in GitHub that address a similar problem?
- [ ] Have I debugged the error message?

### Do the Work

I taught college English for ten years. When I assigned a student a paper, I expected them to do the work. I pushed them to work hard, improve, and think deeply about what they were putting on paper. I don’t think that’s too much to ask from contributors. This isn’t to say, don’t ask for help. But ask to take on issues that you think you can handle. If you can’t, then ask for help from the community, your support system, or the maintainers. But remember, they shouldn’t be solving the problem for you. They should be directing you towards the correct solution. 

If you’re asking them to do the work for you, you’re not going to grow. To be transparent, if you’re frequently taking on issues and asking other people to solve the problems for you, the maintainers will notice. Not only does that impact your reputation, but it damages your relationship with them.

Any time a maintainer has to give you feedback because you haven’t spent the time to problem solve, you’re contributing to their burnout. Problem-solving is not optional.

## Communicate Appropriately

This is a big one. The Contributing guide usually talks about how you should communicate with the maintainers. If it doesn’t, at the very least, you should assume that within the PR, issue, or in their communication platform public channels (like Discord) are the designated communication spaces. 


It’s best practice to not:


- Direct message a maintainer.
- Ask a maintainer to review your PR or issue outside of GitHub (for example, in a livestream, X Space, or during an event).
- Ask a maintainer for a review if you know they’re out of the office (including on vacation, on the weekends, etc.). It’s worth noting that if you know they’re on vacation, you probably shouldn’t ask them on their first day back. They’re getting caught up, and any attention they take away from catching up to respond to you, is time they have to make up.

It is best practice to:

- Accept feedback willingly.
- Listen to maintainers.
- Communicate with empathy, this includes not only being kind, but also being patient.
- Actively listen. 

Ok, so that last one might feel out of place when communication takes place asynchronously. What I mean by that is to take the time to holistically understand what a maintainer is asking you to do. If they have a comment on your PR that applies to the whole PR, don’t fix it in one place and force the maintainer to come back to provide you with the same feedback in every place.


### Communicate Clearly

Here’s a checklist:

- [ ] Write clear titles (for PRs, discussions, and issues)
- [ ] Provide screenshots or gifs to demonstrate problems or fixes
- [ ] Complete Issue forms or PR templates. **Do not skip any of the required fields.**
- [ ] Be specific in your descriptions, bug reports, and PRs.
- [ ] If you’re stuck, have you clearly outlined the problem, what you’ve tried, and shared any relevant code?

Another part of appropriate communication is how you ask for things from a maintainer. Open source projects aren’t for making demands.

###  Do Not Make Demands

![first of all how dare you](https://media.giphy.com/media/v1.Y2lkPTc5MGI3NjExcWM1eWE5dG1hYm1rMzR2anZnMXliNnlhcjQ3bHoxMTE2YmRlc2RvYyZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/PtKM2ocDxZia4/giphy.gif) 

Second of all, it’s not ever ok. There are people maintaining projects, and unless you’ve funded them for life, you have no right to make demands. You’re welcome to propose a fix or a feature, but the maintainers are in charge of prioritizing.

Any time a maintainer has to address your response outside of the appropriate space or has to ask you follow-up questions because you haven’t provided the full context of your issue, you’re contributing to their burnout. Appropriate and good communication is not optional.


## Takeaways

90% of companies are applying or using open source software in some way. We’re all in this together to create a stable and healthy open source environment. This post is not to point fingers at anyone. It’s to ensure that we all learn how to support each other in meaningful, productive, and empathetic ways. Part of ensuring that we can have a healthy open source environment is being a thoughtful contributor and good open source citizen. It’s on all of us to ensure open source maintainers don’t burn out. 


Explore empathetic ways to support open source maintainers and prevent burnout.

Stop Burning Out Maintainers: An Empathetic Guide for Contributors

10 years ago my open source journey started with an email to a maintainer because I really wanted to use his library but could not figure out how to code myself out of a simple error. I was given a ton of grace and returned the favor of the maintainers' patience that unblocked me by shipping a few documentation pull requests to make sure future developers could benefit. 

I have been involved in open source either directly or adjacently since that first PR. During my tenure in open source I kicked off the open source curriculum at a bootcamp where students would make legit contributions projects and learn from the experiences I lived through. Today the need for developers and bootcamps graduates looking for opportunities for contribution to open source projects has risen. 

*The U.S. Bureau of Labor Statistics (BLS) projects that there will be roughly 162,900 vacancies for software engineers over the decade between 2021 to 2031.*

The challenge is that these opportunities can be hard to come by and we are now seeing the industry asking, “Should I contribute to open source to level up my resume?” I will answer that and more in this blog post, but first let’s break down this opportunity.

## The Opportunities You Make

Based a [recent Twitter thread](https://twitter.com/t3dotgg/status/1739833869724160352), finding open source opportunities for the sake of leveling up one’s resume proved to be a hot topic. Thanks to the recent record number of layoffs in 2022 and 2023, I see a trend for more folks looking to make contributions. The 6-figure salary question is now, “Where are the best places to find good first issues?” I recently saw that due to some contributor frustration in normal subreddits, folks are considering [making a subreddit to share insider knowledge to get contributions into open source](https://www.reddit.com/r/opensource/comments/197yymt/is_there_interest_in_a_subredit_named/). 


In a previous post, I mentioned that good first issues do not exist and the best way to contribute is by creating an issue. I believe that contributors find more opportunities for contribution when they find a bug or issue for a project. They are in a better place to make a contribution than if one is handed to them. 

As Dax says, “Contributing to oss is a side effect of using OSS.” If you are looking for the hand out or a good first issue, you are approaching the problem backwards. Opportunities in open source are the ones you make by using open source. Try your hand at using the project and challenge yourself to be a power user. 

[![dax twitter thread](https://gist.github.com/assets/5713670/e859bd00-97c9-4ef9-8fb4-ae3ffc9db9c8)](https://twitter.com/thdxr/status/1739837931127284121)

## The Best Contributors Are Power Users

When chatting with JJ from the Next.js core team, I learned about his interest in the project during the early days. His curiosity was met with opportunity as he leveled up his own skills by taking the opportunity to work on the framework issues. This opportunity only presented itself thanks to his desire to learn more about React, JJ chose Next.js for every project while working on consulting projects. 

*[JJ's story](https://www.youtube.com/watch?v=bpI50u2qxJU&list=PLHyZ0Wz_A44VR4BXl_JOWSecQeWcZ-kS3&index=12)*

His interest got noticed by the small core team and earned him a job via the DMs. JJ mentions that this experience was the one that earned him the job he has today, maintainer on the Next.js project at Vercel. Though past performance is a predictor of future growth, I chat with contributors and maintainers to learn the secret sauce for finding these opportunities. In this case, the opportunity to build a network from open source contributions.

## Building a Strong Network Through Open Source Contributions

Contributing to open source projects not only helps you level up your skills but also allows you to build a strong network within the developer community. As you work on various projects, you'll have the opportunity to collaborate with other developers, maintainers, and users. This collaboration fosters a sense of camaraderie and helps you establish connections with like-minded individuals.

By actively participating in discussions, submitting pull requests, and providing valuable feedback, you demonstrate your expertise and commitment to the project. This can lead to recognition within the community, which can open doors to new opportunities, such as speaking engagements, job offers, or even invitations to join other projects.

Moreover, your contributions to open source projects are visible to potential employers and collaborators, showcasing your skills and experience in a tangible way. This can help you stand out in the job market and make it easier for others to reach out to you for collaboration or mentorship.

Contributing to open source projects not only enhances your resume but also helps you build a strong network within the developer community, leading to new opportunities and connections that can propel your career forward.

## Should you contribute to open source to level up the resume?

Now back to the question at hand. If you are looking for a good first issue, then you have already missed out. The best contribution is the one who understands and lives to tell the story. When interviewing candidates for OpenSauced, I like to hear about the hard problems engineers face and hear stories about how they can persevere. OpenSauced is unique, we are open sourced and appreciate a good contribution story. But what is not unique is there are a bunch of engineers not doing open source and getting jobs. So if you want to leverage open source as your unfair advantage, make it an advantage by showing that you care about the success of the project and have a story to share. 

If you are not interested enough to become a power user, my recommendation is submit the resume and leave the open source for others to contribute to. 

But if you truly want to stand out in the hiring pool, stand out as a contributor. Try using open source projects with a critical eye for fixing problems for thousands of developers. Open source is not a necessity for getting a job, and should never be. Open source is an opportunity to try new things and approach new problems.

[![nick's opensauced highlight](https://gist.github.com/assets/5713670/4e850430-b378-416f-b233-49b66b31c67b)](https://app.opensauced.pizza/feed/948)

If you are interested in discovering opportunities in open source and properly highlight your success in open source, then I encourage you to try OpenSauced.    


The focus on open source contributions purely on career advancement will not benefit anyone in open source long term. Instead become a power users and display genuine interest in a project's success and will never need to build a resume again.

Resume Driven Contributions

TL;DR: GitHub Organization Insights is no more, but OpenSauced is stepping in with open source Insights for Projects and Teams, available today. With Insights and Lists features you can learn more about contributor engagement, track trends, and empower your open source projects. 

## The Importance of Open Source Insights

Understanding the health and impact of open source projects, teams, and organizations is crucial to sustainability and growth in open source. In 2019, GitHub launched a beta of [Organization Insights](https://docs.github.com/en/enterprise-cloud@latest/organizations/collaborating-with-groups-in-organizations/viewing-insights-for-your-organization), offering invaluable data and analytics. 

![organization nav for insights](https://gist.github.com/assets/5713670/3bf9d533-f844-40c6-a416-9852a1e82c7c)

Now, with [its deprecation](https://github.blog/changelog/2023-12-19-upcoming-deprecation-of-organization-insights-activity-overview-beta/), OpenSauced steps forward with an even more comprehensive OpenSauced solution: Insights and Lists.

### OpenSauced Insights: Seeing Your Project Clearly

Last year we shipped tools for maintainers to gain repository insights and contributor lists.  What we learned from this is that folks responsible for the health of the project depend on these insights to help them understand the activity and trends around their contributions to validate with stakeholders.


We believe insightful metrics are essential for a project's success. Our open source Insights provide real-time data on pull request (PR) activity and velocity and monitor the status (open, closed, merged) to optimize workflow and identify bottlenecks. Some of the largest open source projects provide commit access to community contributors and need to regularly check who needs access and who doesn’t. The fastest way to do that is to see a visual representation of who is making contributions and who is not.

![homebrew contribution list](https://gist.github.com/assets/5713670/4ceeff3a-717a-479b-8a48-40778c42b4fc)

Getting updates on contribution patterns has also proven useful when seeing a distribution of contributions and identifying when a project is at risk of no or low maintenance. In a recent conversation with an enterprise, we learned that after a number of acquisitions, they now maintain 10+ GitHub organizations and their public repositories. They have no easy way to know which projects need to be deprecated and which ones could use some additional maintenance to prevent deprecation. 

### Drilling Deeper with Lists

![open sauced contributor list](https://gist.github.com/assets/5713670/b6a1ed91-d168-48ff-b0c8-42035a9948e8)

Our List feature allows you to organize contributors for granular analysis. You can also track specific teams, repositories, or new and alumni contributors to understand where work is distributed. When most of the industry considers stars as the metric for success in open source, what we found is that new contributors is the metric. Seeing new contributors and their impact provides fuel for maintainers to repeat that success.  

OpenSauced sets out to be that home for those organizational insights that you can be proud of by providing a way to gather knowledge about your repositories at the organizational level. This is why we are embarking on a path to track not just repositories but entire organizations. This will be the key to unlocking insights across organizations.

![gif link showing the syncing of orgs](https://docs.opensauced.pizza/assets/images/team-sync-insights-d4d7794d5e28b72ffb375595c988cd37.gif)

Test out our latest version that allows you to [sync a team from your organization](https://docs.opensauced.pizza/maintainers/maintainers-guide-to-open-sauced/) on OpenSauced and generate a list to highlight their contributions across organizations.

Stay saucy

Bdougie, CEO of OpenSauced



GitHub Organization Insights is no more, but OpenSauced is stepping in with open source Insights for Projects and Teams, available today. With Insights and Lists features you can learn more about contributor engagement, track trends, and empower your open source projects.

Mind the Gap: Advanced Organization Insights

If you're a Hacktoberfest contributor, you have built-in metrics for success-four pull requests-but for maintainers, it's a little bit different. You have to decide what success looks like for your projects. We want our contributors to succeed, to grow our projects, and to welcome new community members.

Prior to Hacktoberfest, our OpenSauced team decided what repositories we wanted to opt-in. We wanted to ensure that we had the bandwidth to support contributors at all stages and to create a clear contributor journey that allowed for growth within our open source ecosystem. Making these decisions set us up for a successful Hacktoberfest.

Our Hacktoberfest story isn't just about the present; it's about the future and the relationships that we’ve cultivated over the last month.

## Hacktoberfest Repositories
We decided to opt-in eight of our repositories. The repositories we chose represented a path for contributors to move from getting their first-ever Pull Request (PR) to working on more challenging issues. 

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gm2ie81oekg4bsu4kx84.png)

We had consistent contributions across our repositories throughout the month, seeing an increase across each of our opted-in repos. Our team worked quickly to ensure clear communication and support for submitted PRs and questions on issues, leading to a high rate of PR velocity. As they say, teamwork makes the dream work.   Our team's commitment to supporting contributors was exemplified by a PR acceptance rate of over 75% during that time! 

You can see all of the repositories, including their activity, PR Overview, velocity, contributors, and more here:

[![Insights page for OpenSauced Hacktoberfest](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yhyjt1iaeu1tfj6s3ipj.png)](https://app.opensauced.pizza/pages/BekahHW/230/repositories)

## Contributors 

[![Contributor Dashboard](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s1z0ai0xgsgwkpuq5zn3.png)](https://app.opensauced.pizza/pages/BekahHW/230/dashboard)

During Hacktoberfest, we had consistent contributions that continue today. Some of the highlights include:
- 129 Contributions from external contributors
- 83 Repeat contributors
- 68 New Contributors

Of our new contributors, we saw a lot of activity across our repositories and beyond during Hacktoberfest. It's great to be able to see where our contributors are also spending time to get an idea of their skill level, interests, and specialties.


[![contributors activities](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xosoq90b2psab1yjqeqv.png)](https://app.opensauced.pizza/lists/90109872-8c67-4c26-838b-d12c18df08c4/activity)


Outside of OpenSauced, some of the notable projects they contributed to include:

- [Facebook Rapid](https://github.com/facebook/Rapid)
- [GitHub docs](https://docs.github.com/)
- [Appwrite Pink](https://github.com/appwrite/pink)
- [freeCodeCamp](https://github.com/freecodecamp/freecodecamp)
- [Microsoft autogen](https://github.com/microsoft/autogen)


The `app` repo for OpenSauced, in particular, saw a healthy influx of new and returning contributors. 

![break down of app repo](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mkzkxhyf65trlswpf2ta.png)

> To find details about your own project using our pizza CLI, run `npm i -g pizza` in your terminal to install the CLI. Next, run the `pizza show` command with your repo address: `pizza show https://github.com/open-sauced/app`. To find out what other commands you can run and more installation options, check out the [pizza-CLI repo](https://github.com/open-sauced/pizza-cli). 


## Highlights
One of the great parts of seeing our contributors progress through the month was seeing what they were most proud of through their highlights. We had 112 highlights during that time, including blog posts, issues, and PRs. It’s great to be able to share in our contributors' stories. 

Through the highlights, we saw people making their first Hacktoberfest contributions, adding test coverage, working on features, fixing bugs, adding community health files, creating issues to invite a new group of contributors to join in, and more.

[![Issue Highlight](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zyn2s0xi4xngbbl9qwu3.png)](https://app.opensauced.pizza/feed/717)

One of the best parts of Hacktoberfest is seeing new contributors grow throughout the month and continue to make meaningful contributions. When we started our Hacktoberfest at OpenSauced, we encouraged contributors to [look beyond the green squares](https://dev.to/opensauced/hacktoberfest-2023-beyond-green-squares-4d6j), and it’s been great to see this reflected this year through collaboration, growth, and continued contributions. We’ve had an increase in new contributors, a growing enthusiasm of those outside our core team, and contributors supporting our team by triaging, creating issues, and reviewing pull requests. 

[![PR Highlight](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uaqsqobpiudhnyeyqam2.png)](https://app.opensauced.pizza/feed/538)

## What's Next?
We believe in making the OpenSauced experience great for everyone who uses it and all our contributors. We welcome continued contributions, including issues, bug reports, pull requests, blog posts written about your OpenSauced experience, and [your feedback](https://github.com/orgs/open-sauced/discussions/categories/general-feedback-or-bugs). If you want to learn more about how to use OpenSauced to see how your projects are doing, check out our [Introduction to OpenSauced](https://docs.opensauced.pizza/) or [get started today](https://app.opensauced.pizza/).

 





Hacktoberfest 2023 brought new contributors to OpenSauced and continued contributions, leading to a successful year.

Our Hacktoberfest Success Story

By highlighting diverse contributions and fostering a culture of recognition, we can inspire both current and future generations of developers and collaborators.
In open source, anyone can contribute to the software that helps to power our world. It’s actually kind of mindblowing that we have the opportunity to make such an impact. 

But let's be honest, not all contributions are created equal, at least not in the eyes of the open source community. While code commits and Pull Requests (PRs) get the limelight, other forms of contributions often go unnoticed. This isn't just a missed opportunity; it's a problem that needs to be fixed. Recognition isn't a vanity tool; it's the lifeblood of a thriving, inclusive, and diverse open source community.

## The Human Need for Recognition
Remember Maslow's Hierarchy of Needs? Right above physiological and safety needs, we find the need for belonging and esteem; it's hardwired into our psychology. Studies have shown that recognition activates the same neural pathways as financial rewards. Recognition isn't just a feel-good factor; it's a fundamental human need that allows us to feel valued and connected.

## The Open Source Dilemma
Contributions come in all shapes and sizes—code, documentation, design, community engagement, and even triaging. But the spotlight is often only on contributions that directly relate to code. At [OpenSauced](https://opensauced.pizza/), we recognize that contributions aren't just green squares.

Open source communities bring together individuals from diverse backgrounds, united by a shared passion for developing and improving open source projects. Within open source, recognition plays a crucial role in motivating contributors, sustaining their motivation, and nurturing a healthy ecosystem. 

While open source communities are often supportive, they aren’t immune to negative feedback and demanding responses. Although these elements can be constructive, they can overshadow the positive interactions that are necessary for community health. This is why it’s so important to amplify the positive interactions and contributions that often go unnoticed. Establishing a positive tone helps create a resilient community and discourages bad actors from participating.

## Acknowledging Diverse Contributions
Traditional recognition systems in open source often focus on code contributions, overlooking the diverse ways people can add value to a project. Recognizing diverse contributions creates a sense of belonging, encourages collaboration, and creates a positive feedback loop that benefits everyone involved.

When diverse contributions are recognized and celebrated, it signals to current and potential contributors that their diverse skills—whatever they may be—are valued. This creates a virtuous cycle, attracting a wider range of skills and talents, which in turn enriches the ecosystem even further. At OpenSauced, we encourage contributors to share their journey of different kinds of contributions on our [highlights feed](https://insights.opensauced.pizza/feed). Acknowledging diverse contributions creates a virtuous cycle, attracting a wider range of skills and talents, which in turn enriches the ecosystem even further.


## Building a Culture of Recognition
Recognition not only celebrates the accomplishments of individual contributors but also nurtures a culture of appreciation and motivation within open source communities. According to [a Forbes article](https://www.forbes.com/sites/forbeshumanresourcescouncil/2023/08/11/how-financial-incentives-and-recognition-can-improve-productivity/?sh=6f88381e6d43), employees want recognition and by creating a culture that promotes recognition, productivity is encouraged as well. Recognition becomes a kind of incentive to participate. [Deloitte also cites the importance of recognition](https://www2.deloitte.com/us/en/blog/human-capital-blog/2023/future-of-total-rewards.html): “Organizations with recognition programs had 31% lower voluntary turnover and were 12 times more likely to have strong business outcomes.” Acknowledging and highlighting the efforts of contributors can create a positive feedback loop. 

It's worth noting that recognition can also have effects after the event happens. [A field experiment conducted with Wikipedia](https://pubsonline.informs.org/doi/abs/10.1287/mnsc.2016.2540) shows causal evidence of powerful and lasting effects of purely symbolic recognition. We might anticipate that once individuals have received recognition, they put in less effort. However, the study shows that they continue to strongly react to that recognition. 

Additionally, recognition signals to others what type of behavior is acceptable and appreciated, without explicitly telling them. This is helpful when working with volunteers, as it allows you to convey your appreciation for their contributions while respecting their autonomy, decreasing the need to tell them what to do.

This culture of appreciation fuels collaboration and inspires community members to actively participate, resulting in increased project momentum and quality.


## The Ecosystemic Importance of Recognition in Open Source
### A Well-Rounded Ecosystem
In her book, "Working in Public," Nadia Eghbal discusses the "invisible work" that often goes unnoticed but is necessary for the health and sustainability of open source projects. This includes documentation, community management, and even emotional labor. Recognition of these diverse contributions isn’t a nice-to-have; it's an ecosystemic necessity that supports maintainers.

Yes, code is necessary for an open source software project. But without other contributions like documentation, triaging, community support, and educational content, the ecosystem would collapse.

### The Economics of Recognition
Eghbal also talks about the economics of attention in open source. In a world where so many people are working to get attention, recognition becomes a form of social currency. Think about customer reviews in e-commerce or citations in academic research. Recognition increases the "market value" of contributors, making them more likely to be "invested in" by others in the form of collaboration, mentorship, and opportunity. We can think of recognition, then, as an investment in human capital that’s beneficial both to the contributors and the community.

Recognition is the key to unlocking the full potential of the open source community. At OpenSauced, we're on a mission to redefine what it means to contribute to open source. Recognition in open source isn’t limited to current contributors; it has a profound impact on inspiring the next generation of developers and contributors. 

So, the next time you merge a pull request, close an issue, or read a well-written piece of documentation, take a moment to recognize the person behind it. A little recognition goes a long way.


By highlighting diverse contributions and fostering a culture of recognition, we can inspire both current and future generations of developers and collaborators.

The Need for Recognition in Open Source

It’s lonely, being a maintainer. I’ve heard this sentiment multiple times in the last couple of months. Maintainers, especially solo maintainers, are stuck in a cycle of reviewing PRs, supporting community, navigating spam and angry messages, coding, project management, product marketing, and more. Even reading the previous sentence could make you feel tired. And imagine doing that alone.

[![Tweet: I just realized that the image from Spiderman where he's trying to keep two halves of a boat from falling apart into the ocean is a great metaphor for maintainer burnout](https://cdn.sanity.io/images/r7m53vrk/production/a231a5cbfe41ff43b4e5284a61c0785af55aa461-584x478.png?w=450)](https://x.com/choldgraf/status/1149670192982700032?s=20)

## Combatting Maintainer Loneliness
It’s no secret that maintainer burnout is an epidemic in the open-source community. Contributors come and go, but maintainers bear the long-term responsibility for the project's health and sustainability. This burden grows exponentially with the project's popularity, leading to a form of burnout that leaves maintainers with emotional exhaustion and a decreased sense of accomplishment. One of the major contributors to maintainer burnout is loneliness. 


> As a maintainer, it's important to remember that you're not alone in this journey, and that there are always other maintainers and contributors willing to help. - [Adriano Raiano, maintainer of i18next](https://www.linkedin.com/pulse/joy-pride-burden-maintaining-open-source-adriano-raiano/)

Humans are meant to be part of a community. Communities can help to bear the responsibility, emotional labor, and to acknowledge the challenges that come along with being a maintainer. It’s not just about sharing the labor, though. It’s about connecting with other people who understand what you’re going through. Without getting too much into the science of things, the neurons in our brains activate when we relate to a story someone tells. When we hear and connect with stories, our bodies release oxytocin, a neurochemical that helps us to connect with others. 
The point of all of this is to say that it’s important to share our experiences with others who understand the challenges that we’re facing.

Finding connections and communities of people who can share their stories as well, can help to decrease the incidence of maintainer burnout. When we realize that we’re not isolated and alone in our feelings of burnout or in the challenges that we’re facing, we’re more likely to feel a sense of belonging and satisfaction. 

## Identifying the *Right* Kind of Support
Navigating the journey of a solo maintainer can be complicated by “contribution farming,” low quality or spammy PRs, and lack of maintainer bandwidth to keep up with the issues and PRs of the community, not to mention the "invisible labor" that maintainers perform, such as community management, documentation, and issue triaging. But when open source projects have the *right* contributors, pressure on maintainers is alleviated both because the *right* contributors often take on some of the invisible labor and they require less labor to support. 

> I have noticed a large difference in my enthusiasm and activity in a project when someone else is making contributions, asking questions, or otherwise thinking about the problem the project is trying to solve. When the project is stagnant, or the issues coming in are fairly pedestrian, I am less interested. - [Sean Walberg](https://www.linkedin.com/pulse/observations-being-open-source-maintainer-sean-walberg/)

Collaboration and community can help maintainers find the right contributors, but there’s also an option for maintainers to recruit or identify contributors who could be a good fit for their project. I know, it’s a Catch22. We say that maintainers are overwhelmed and don’t have time for additional tasks, but I’m telling you that adding an additional task will make life easier for them. It’s an investment in the future. 

Identifying project-fit contributors by their technical capabilities, proximity to the project, and the type of contributions they’re already making, allows maintainers to build a community that benefits the project and the maintainer. 

## The Return of Social Coding
You can have a good community and still feel lonely though. Sometimes this loneliness stems from a lack of recognition. The work of maintainers matters, but that value often isn’t expressed by users. In the era of [social coding](https://opensauced.pizza/blog/social-coding-is-back), there’s an opportunity for maintainers to showcase their contributions, whether that’s code, issue resolution, community engagement or something else, to put their hard work in the spotlight and open the door to connect with other maintainers, and to be recognized by contributors. 

> When you tell your story, it humanizes you. 
When maintainers feel seen and heard, they’re more likely to have positive interactions with the community, which can lead to a ripple effect, creating a culture of recognition and support that everyone in the open-source ecosystem can benefit from. But more importantly, it can help to decrease the pervasive loneliness that many maintainers feel. 

## Finding the Right Connections
Finding the right connections can be challenging, but opening the opportunity to connect with others can be the difference between being lonely and feeling supported. 

### Share Your Story
Start by talking about your work, and sharing the highlights of what you’re most proud of. When you share your story, you’re inviting someone else to share theirs.

[![UlisesGascon Highlight](https://cdn.sanity.io/images/r7m53vrk/production/73b5e23793266c2a2e9796190839ab4fe3ae68ef-584x496.png?w=450)](https://app.opensauced.pizza/feed/463)

## Identify the Right People for You
Are there some maintainers out there you’d like to connect with? Have you considered starting a community of maintainers who might be able to support each other, not technically speaking, but as human beings? If you’re not ready to reach out to them yet, keep a list of all the maintainers whose stories you’d like to hear.  

Or maybe you need help and the *right* contributors, and that’s your top priority. Create a list of contributors you think would make a great fit for your project and then reach out to them as you have the bandwidth. 

![Contributors List](https://cdn.sanity.io/images/r7m53vrk/production/bd31e60f670a8519ccc57a9db93fa6a38ecc9411-610x484.png?w=450)


### Connect
It can be hard to reach out to others, but if you’ve shared your story and you know the people you’d like to connect with, that can make it easier. Strengthen your network by requesting a [connection](https://docs.opensauced.pizza/community/connections/).

In an industry where maintainer loneliness is too common, connection, community, and recognition can provide hope and humanize maintainers. Remember that recognition is a form of contribution too—one that can make all the difference in a maintainer's journey.

If you want to connect with me, please follow me and send me a connection request: [@BekahHW](https://insights.opensauced.pizza/user/BekahHW) and if you'd like to show support for OpenSauced, head over to our [Product Hunt page](https://www.producthunt.com/posts/opensauced) and show us some love today!

Connection, community, and recognition are key to preventing maintainer loneliness. Learn how to create a healthier open source ecosystem for maintainers in this blog post.

The Lonely Journey of Open-Source Maintainers: A Call for Connection and Recognition

You’re more than your green squares. There, I said it. Green squares capture only a small portion of the developer journey. Green squares alone won’t get you hired. But do you know what will? Having a well-rounded skillset, being a good communicator, and showcasing your abilities. Let’s make this Hacktoberfest different. Let’s make this year about impact, growth, and relationships, about setting a standard for new contributors and open source overall. Let’s reject green squares as the marker of our success. Because this is only the beginning. 



### A New Approach to Hacktoberfest

![a multi-colored contribution graph](https://cdn.sanity.io/images/r7m53vrk/production/f465d037f1ba9aec37848d6b00432f3b862d3dc1-485x198.png?w=450)

The goal of [Hacktoberfest](https://hacktoberfest.com/participation/) is to get four pull requests to participating repositories in between October 1 and October 31. Participating in open source in a meaningful way goes beyond pull requests. Supporting the needs of projects and maintainers include answering questions, providing mentorship, [triaging issues](https://dev.to/opensauced/what-does-an-open-source-triage-team-do-2egd), writing blog posts about projects and your involvement, reviewing PRs, pair programming, writing issues, and sharing your own story.  Instead of trying to find the fastest way to four PRs, look for the most meaningful path to four PRs and grow your skillset by providing support as you make your open source contributions.

## The Open Source Hacktoberfest Journey 
Imagine you’re on a journey, and you have a map that shows your starting point and an X that shows your ending point with a big treasure chest. To make it to the ending point, you’re going to need to gain skills because you start at the beginning of the jungle, but as you move forward, the terrain gets increasingly difficult. Sometimes you have to navigate through water. Sometimes you are climbing mountains. You grow with each of these experiences.

But, what if, instead of pushing forward and forging one path to the treasure, you decide to keep starting over once you were faced with a new challenge. You never get stronger, you never make progress, and instead you find yourself at the beginning wondering why you feel like you haven’t accomplished that much. The truth is, that building credibility is a lot like making your way through that path. 

## Build Your Credibility with Open Source
Fixing white space on four repos is not going to gain you credibility. In fact, it will negatively impact your credibility. The key to building credibility is that you don’t stop when things get hard. You grow skills on your journey and continue to build on them as you move to harder challenges. Showcase your expertise and growth throughout October. I highly recommend keeping track of your progress publicly. I’ll be using [my Highlights](https://insights.opensauced.pizza/user/BekahHW?tab=highlights) to showcase the growth I’m most proud of.


If you’re new to open source, that’s ok! There are issues out there that fit your skill level. You can check out [my Hacktoberfest Repos for Beginners list](https://insights.opensauced.pizza/pages/BekahHW/655/repositories) to help you get started. These repositories are aimed at practicing skills like forking, cloning, committing, and creating PRs for text updates. Get started with projects like those and build a relationship with the maintainers and community members of the open source organizations. 

### Tips for Growing Credibility in One Month

It can be much more efficient to grow your skills in one project or open source ecosystem than in four different organizations. 

To build credibility, consider each part of the path as building a skillset you can talk about and demonstrate. That might looks something like this:

- **Continuous Learning**. Start where you’re comfortable and build from there. If you’ve never contributed to open source before, I recommend our Intro to OSS course followed by a PR to our guestbook.
- **Transparency**. Your contributions are open for everyone to see. Don’t let that scare you. Use it to your advantage. Ask good questions when you need to.
- **Feedback Reception**: Receive feedback with an open mind, ask clarifying questions as needed, and be respectful in all interactions.
- **Collaboration and Teamwork**: Review PRs and answer questions of other contributors to demonstrate your communication skills.
- **Leadership Skills**: Remember, you’re one step ahead of the person who started today. That means you have the ability to mentor, encourage, and identify the strengths of others.
- **Showcase Expertise**. As you grow in your contributions, you’ll be able to demonstrate your skills and expertise. Whether it’s coding, documentation, community management, or something else, your journey should serve as a snapshot of your experience during the month of October.

Remember, it's about the quality of your contribution, not just the quantity. No one is going to care about many times you’ve added a period to the end of the sentence. But they will notice if your journey is a progression of growth. This is why I like to look specifically at [people’s highlights](https://insights.opensauced.pizza/feed), because it provides a much better story of the growth journey of contributors. Let’s take a look at a journey that demonstrates growth:

- First PR: you added a period to the end of a sentence.
- First Issue and Second PR: you created an issue to add a section to documentation to clarify installation instructions and created the PR to do that. 
- Third PR: you took on an issue that built on your current skillset. 
- Blog post: You wrote a blog post about how you contributed with your third PR.
- Fourth PR and blog post: You found the treasure. You demonstrated that you understood a project, you contributed with purpose, and you knew how to make a meaningful contribution to the project. You shared that in your blog post to bring visibility to the project, show that you’ve communicated throughout the process, and now you’re encouraging others to contribute as well.

## Be the Standard for Open Source

Don’t just participate in Hacktoberfest 2023. Lead by example and set the standards for contributions. I’m a big believer in the idea “We share our stories to invite others to share theirs with us.” Share your story this Hacktoberfest. Let other contributors know about your progress, why the PR you made was meaningful, and how you’re pushing yourself to grow. 

Setting the standard doesn’t stop at your own contributions. It’s about uplifting others, sharing what you know, and fostering an open source community where everyone is encouraged to bring their best to the project. Like and share the highlights of other contributors. Leave them positive comments are their posts. By setting the standard, we can cultivate a community where everyone sees the importance and value in contributing meaningfully.

### Setting the Standard: babblebey
One of the most recent examples I’ve found of a contributor who’s set a great standard is the story of [@babblebey](https://insights.opensauced.pizza/user/babblebey?tab=highlights). 

@babbley has been a consistent contributor to OpenSauced repositories, as evidenced by [this list of merged PRs](https://github.com/open-sauced/app/pulls?q=is%3Apr+is%3Aclosed+babblebey). But if you look deeper into his contributions, you’ll see that he fills out the PR template, provides context and clear descriptions, and receives feedback well from his PR reviewers. 

He’s highlighted some of the important parts of his journey, communicating the impact of his work to others.

![babbleybey's highlight](https://cdn.sanity.io/images/r7m53vrk/production/6800cc6ff9eacf81294ccb2637b36de331c046ef-707x666.png?w=450)
I’ve been fortunate to have chatted with him when he attended some of our OpenSauced Office Hours in Discord as well. I can truly say that I’ve been motivated by the energy and enthusiasm that he brings to the work he’s doing. His journey showcases his growth, collaboration and communication skills, and the strong skillset that he’s developed. He’s made meaningful contributions both in code and in community. Setting the standard for open source contributions has lead to new opportunities, and I couldn’t be happier for him:

![image](https://cdn.sanity.io/images/r7m53vrk/production/7e8715d6ba8c87ad164bd948bdd365c3a7b6327c-589x366.png?w=450)
[Link to post](https://x.com/babblebey/status/1704254801280643508?s=20
)


## Continuous Contribution: Beyond October

Hacktoberfest is the beginning of the journey. It’s the hero accepting the call to adventure. The goal should be to feel empowered by the end of the month and to take the momentum you have to continue contributing to open source. 

Leadership doesn’t stop at the end of October. Open source projects don’t stop at the end of October. Take the time to look at the next path, the next adventure that challenges you in new ways. If you’re committed to continuous contribution and growth, stay engaged, provide consistent value, and champion the open source projects that you’ve grown with. 


You’re more than your green squares. Green squares capture only a small portion of the developer journey. Green squares alone won’t get you hired. But do you know what will? Having a well-rounded skillset, being a good communicator, and showcasing your abilities. Let’s make this Hacktoberfest different.

Hacktoberfest 2023: Beyond Green Squares

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.