On September 28, PearAI’s founder, [Duke Pan](https://app.opensauced.pizza/u/Fryingpannn) (also known as “FryingPan” online), shared a [tweet](https://x.com/CodeFryingPan/status/1840203597478539477) announcing the launch of PearAI, an AI-powered code editor which they described as a "fork of VSCode." This wasn't false, but it wasn't the full truth either, and people were quick to point this out. 

![image](https://cdn.sanity.io/images/r7m53vrk/production/23a1e6f1c83262eb7a5f35d0f733259439b5cb06-966x1088.png?w=450)

It turns out that [PearAI](https://app.opensauced.pizza/s/trypear/pearai-app?range=90) was not just a fork of VSCode; it was *also* a fork of [Continue.dev](https://app.opensauced.pizza/s/continuedev/continue?range=90), an AI-powered extension of VSCode. The problem? Continue.dev was licensed under the Apache 2.0 License, while PearAI was initially launched with a proprietary license called the "Pear Enterprise License." 

When the community discovered that PearAI had essentially cloned Continue.dev without adding significant new features or providing proper attribution, accusations of plagiarism and license violations arose. 

But did PearAI really do anything wrong? The answer is a bit more nuanced than a simple yes or no. PearAI did eventually switch back to the Apache 2.0 License and issue a public apology, but the public felt that PairAI had violated the trust and expectations of the open source community - which can have far-reaching consequences.

In open source, transparency isn’t just a virtue — it’s a requirement. 

## The Importance of Transparency in Open Source

Transparency is a foundational principal of open source development. It goes beyond making code publicly available; it means clear communication about a project's origins, development processes, and in interactions with contributors. 

For example, [jsx-email](https://app.opensauced.pizza/s/shellscape/jsx-email) is a fork of [react-email](https://app.opensauced.pizza/s/resend/react-email) that was created to address some of the limitations of the original project. However, the maintainers of jsx-email continue to be transparent about the project's origins in their README.

[![image](https://cdn.sanity.io/images/r7m53vrk/production/30b29e786e1d1a8d22fa0e6dcf374c6d7ea36afd-1360x774.png?w=450)](https://github.com/shellscape/jsx-email)

The level of transparency can significantly impact the project's success and community engagement. It also mitigates the risk of misunderstandings and accusations of impropriety. Projects that lack transparency can alienate contributors and users.

### Case Study: PearAI vs. Continue.dev

The PearAI and Continue.dev story shows how a lack of transparency can lead to community distrust and community backlash. PearAI’s founder, Duke Pan, admitted that PearAI was built on Continue’s code but that information wasn't easily accessible in its public-facing materials. The situation was worsened when the company introduced a proprietary license, creating the impression that PearAI was not just a fork, but an entirely new product.

After a social media storm, calling out the misleading nature of the project, [Pan issued a public apology](https://x.com/CodeFryingPan/status/1840831339337302204) and switched back to the Apache 2.0 license. 

In the long term, we'll see if PearAI can recover from this incident and rebuild trust with the open source community. At the very least, we should take this as a cautionary tale for other projects about the importance of transparency and proper attribution.

#### Data-Driven Insights: The Impact of Transparency on Community Engagement

The transparency issues between PearAI and Continue.dev didn’t just affect the trust within the open source community — they also increased the visibility and engagement for both projects. Looking at the data shows that the controversy caused notable spikes in stars and forks for both repositories, though the dynamics behind each project’s growth tell different stories.

Continue.dev has demonstrated strong community engagement over the past 90 days. The project has amassed a total of 17.1k stars, with over 900 stars being added in the last seven days at an average of 46 per day. The number of forks, at 1.3k total, with 490 in the last 90 days, shows a healthy growth rate of 5 forks per day. Interestingly, these numbers reflect a surge of interest likely driven by the controversy, as people went to Continue.dev either in support or to compare it with PearAI.

![image](https://cdn.sanity.io/images/r7m53vrk/production/478748ae0638ed7dd6b352708d40e7701da056a4-1336x1092.png?w=450)

**If you want to see a comparison, check out our [Continue v. Pear Workspace](https://app.opensauced.pizza/workspaces/7ef8fcaa-e317-446c-af3e-80f884a678ab?range=30)**

PearAI, despite the initial backlash, has also seen notable engagement, though at a much smaller scale - which is to be expected of a new project. PearAI recorded 524 stars during this period, with 1,735 stars gained in the last 90 days and an average of 19 stars per day. It also experienced an increase in forks at 79 over this time period, with 290 total forks over 90 days and 3 forks per day on average. While its numbers are smaller than Continue.dev’s, this sudden increase indicates that the announcement of the project and controversy has lead to heightened activity.

![image](https://cdn.sanity.io/images/r7m53vrk/production/8803506413c2d01438f54a14d508d7cebd01448c-1002x819.png?w=450)

The old adage that “there’s no such thing as bad publicity” seems to hold true in this case. The controversy surrounding PearAI has inadvertently boosted its visibility and engagement, even if the attention was negative. 

However, a deeper dive into the numbers reveals a more nuanced picture of community engagement. Over the last seven days:

- [Continue.dev](https://app.opensauced.pizza/s/continuedev/continue?range=7) has seen ten outside contributors, with 4 recurring.
- Continue.dev has had 25 opened pull requests with six merged.
- PearAI has seen no outside contributors and only seven opened pull requests.

These metrics highlight a significant disparity in active community participation between the two projects.

Continue.dev's ability to get and retain outside contributors suggests an engaged community. PearAI's lack of outside contributors and fewer pull requests might mean challenges in converting initial interest into sustained community engagement.

While controversy can drive short-term attention, it's the foundation of trust, transparency, and community goodwill that is more likely to lead to long-term engagement and project health. 

For the broader open source community, this case study serves as a reminder of the importance of:

- Maintaining transparency from the outset of a project
- Quickly addressing and rectifying any missteps in community relations
- Focusing on building a welcoming environment for contributors beyond initial marketing metrics

As we continue to watch how these projects progress, it will be interesting to see how these engagement metrics evolve and whether PearAI can bridge the gap in community participation. 

### The Consequences of Failing Transparency

When open source projects fail to be transparent, they risk losing the community’s trust. PearAI’s case illustrates this well. Its initial missteps led to a loss of credibility, with many contributors questioning the project’s legitimacy. The community backlash was swift, and PearAI’s subsequent efforts to rectify the situation were seen as too little, too late by some.

In open source, reputation can be everything. Projects that don’t respect the principles of open source development—particularly transparency and proper licensing—face long-term damage. Even after reverting to an open source license and offering a public apology, PearAI will likely have to work hard to regain the trust of developers and contributors.

### Lessons Learned for Open Source Projects

The PearAI-Continue.dev situation offers several valuable lessons for open source projects:

1. **Clear communication**: From the start, open source projects need to be clear about their origins, whether they are forks, original creations, or collaborative efforts. PearAI could have avoided much of its backlash by being upfront about its relationship with Continue.dev.
   
2. **Respect for licenses**: Proper attribution isn't just a courtesy; it’s a legal and ethical requirement. By applying a proprietary license to a forked project, PearAI violated one of the key principles of open source, which contributed to the backlash.
   
3. **Community Trust as a Competitive Advantage**: Beyond just attracting contributors, transparent projects create deeper community trust, which is a long-term competitive advantage. 

4. **Long-term Vision**: Projects should consider how their actions align with the long-term goals of building a thriving, collaborative community. Short-term gains in visibility or proprietary advantages may come at the cost of sustainable growth and community support.

## Last Thoughts

Transparency isn’t just a best practice in open source — it’s the currency that keeps communities thriving. The PearAI-Continue.dev situation illustrates how quickly things can go wrong when transparency is lacking. While PearAI eventually corrected its mistakes, the damage to its reputation and community trust will take time to heal. This case serves as a reminder to all open source projects: be transparent, respect your contributors, and uphold the principles that make open source a powerful movement.


Understand the important role of transparency in open source through the PearAI and Continue.dev case study.

Transparency is Open Source Currency: Lessons from PearAI

Back in 2020, when the pandemic hit, I lost my first tech job. It was the same day I picked up my kids’ books from school, expecting a three-week break. They never returned that year. Somehow, I found myself interviewing for a DevOps position - at the time I didn’t even know what DevOps was. After the first interview, the interviewer told me to read [The Phoenix Project](https://www.oreilly.com/library/view/the-phoenix-project/9781457191350/) and then she’d give me a second interview. 

In the book, Brent is the go-to Ops Engineer, the one with all the answers, putting out fires, and saving the day. The problem? Brent is a bottleneck, not a multiplier.

## The Hidden Cost of Siloed Knowledge

When knowledge is siloed, we put our teams at risk. What happens to your team when someone goes on vacation? Needs to take some time off? Or even worse, leaves the company? The impact can be stifling and even paralyzing. The hidden cost of siloed knowledge can lead to a phenomenon known as "knowledge hoarding," where team members, whether intentionally or not, become protective of their expertise and don’t share it with others. More costs of siloed knowledge include:

- **Single Points of Failure**: Key expertise is held by a few, creating dependency.
- **Redundant Efforts**: Without shared knowledge, teams may unknowingly duplicate work.
- **Slow Onboarding**: New team members struggle to piece together fragmented information.

If expertise is spread throughout your team and you don’t rely on any single person, you improve your team’s stability and to achieve success. The cost of siloed knowledge is a lot steeper than we realize.

Siloed knowledge leads to optimizing locally, but sub-optimizing globally. What does that mean? It means that teams start to become hyper-efficient in their own bubbles, but the organization as a whole starts to suffer. You’ll see your top engineers reinventing the wheel in different corners of the company, doing redundant work in isolation. And when you bring new people onto the team, there’s no clear path for knowledge sharing with slow onboarding as they try to put together fragmented knowledge. This isn’t a minor inconvenience -  you pay for this in time, morale, and missed opportunities.

In the context of developer culture, this problem can be particularly damaging, leading to inconsistent practices across teams and impeding the development of a cohesive engineering culture. Developers thrive when information flows freely, collaboration is valued, and when everyone has access to the knowledge they need to exceed.  Even within small, agile teams like the ‘two-pizza teams’ popularized by Amazon (teams small enough to be fed by two pizzas), knowledge silos can form if deliberate steps aren’t taken to encourage sharing.

## Shared Ownership: not about blame, about empowerment 
I know some people start to get nervous when we talk about shared ownership. You might think this means shifting blame around when things go wrong. But that’s missing the point. It’s not about pointing fingers. It’s about embracing a team responsibility to contribute, learn, and grow. It’s about creating an environment where everyone feels responsible for the success of the project, not just their own tasks.

When we embrace shared ownership, we’re acknowledging that everyone’s insights and ideas matter and that they have the power to make an impact on the project. 

In a two-pizza team structure, shared ownership isn't just beneficial—it’s necessary. Small teams are designed to be autonomous, fast-moving, and highly collaborative. When everyone on the team has a comprehensive understanding of the project, everyone can make better decisions, avoid duplicating efforts, and maintain high standards across all parts of development. This type of collaboration requires a culture where expertise is shared openly and where the success of the team is prioritized over the individual.


## The CODEOWNERS File: A Tool for Knowledge Sharing 
This is where a CODEOWNERS file can help teams get started. If you know what a CODEOWNERS file is, you might think of it as a way to assign responsibility for review of a particular codebase on GitHub. But I think a better way to think about it is as a map of expertise - a file that outlines the go-to people for different parts of the codebase. 

I want to take a minute to flip the idea that it’s restricting access or creating gatekeepers, and ask you to think of it as a way to highlight expertise and encourage collaboration. When the pull request comes in, the right people get notified automatically. This also means that when someone has a question, they know exactly who to reach out to.  

As part of this, it’s important to remember that a CODEOWNERS file isn’t meant to be a static document. It should change as your team grows and as people develop new areas of expertise. Think of it as a living document representing your team’s collective knowledge.

## Building a Culture of Shared Knowledge and Learning 

Don’t get me wrong: a codeowners file won’t solve all your problems. It’s a tool, and like any tool, its effectiveness depends on how you use it. The real goal should be to build a culture of shared knowledge and continuous learning. 

*Let’s shift our mindset from a culture of ownership to a culture of expertise.*

Ownership implies exclusivity. “This is my code, my project, my responsibility.” This mentality can create barriers and discourage collaboration.

Expertise, on the other hand, is something to be shared and celebrated. Focusing on expertise encourages the mindset of having a deep knowledge and a willingness to help others understand it as well.

When we build a culture of expertise, we also shift the value, not from how indispensable you are, but how much you elevate the whole team. You’re not a code “guardian.” You’re a multiplier. And we all want multipliers on our teams and in our organizations. 

## The OpenSauced Solution: pizza-cli codeowners

So what can you do today? At OpenSauced, we’ve developed a `codeowners` command for our pizza-cli to do the heavy lifting of analyzing your git history, generating a CODEOWNERS file, and keeping it up to date automatically. This means you don’t have to guess who to contact if you have a question about a particular file. (I talk more about this in [The Problem of Knowledge Debt in Tech](https://opensauced.pizza/blog/tech-knowledge-debt).)

For each file in your codebase, the [pizza-cli](https://github.com/open-sauced/pizza-cli) + [GitHub Action](https://github.com/open-sauced/pizza-action) assigns up to three “owners.” Why three? Three creates a balance between clear accountability and shared knowledge by not limiting to a single owner. At the same time, you're also not diluting responsibility across too many people.  

Remember, this isn’t about creating boundaries or “exclusive” territories. It’s about surfacing expertise within your team, starting conversations, and learning from each other.

## Start Small, Think Big
Head over to the [pizza-cli](https://github.com/open-sauced/pizza-cli) and give it a try. You can start small-test it with a single project or team and start the conversation about code ownership and expertise.

![npx pizza generate codeowners .](https://cdn.sanity.io/images/r7m53vrk/production/195078868876074f1b61661796cb02a6b537e989-1642x822.png)

Tools like the pizza-cli are just the beginning. The goal is a knowledge-rich developer culture where everyone thrives.

Tools like the pizza-cli can be helping in making sure that no one person becomes a bottleneck. 

Creating a developer culture of shared knowledge and continuous learning is an ongoing process, but it’s worth the investment. Let’s build teams that elevate each other, embrace expertise, and grow together.

Discover the hidden costs of siloed knowledge in developer culture and how embracing shared ownership and tools like the CODEOWNERS file can enhance team collaboration, efficiency, and success.

Building a culture of shared ownership 

Last week, [the OpenSauced engineering team released the Pizza CLI](https://opensauced.pizza/blog/introducing-the-pizza-cli), a powerful and composable command-line tool for generating CODEOWNER files and integrating with the OpenSauced platform. Building robust command-line tools may seem straightforward, but without careful planning and thoughtful paradigms, CLIs can quickly become tangled messes of code that are difficult to maintain and riddled with bugs. In this blog post, we'll take a deep dive into how we built this CLI using Go, how we organize our commands using Cobra, and how our lean engineering team iterates quickly to build powerful functionality.

## Using Go and Cobra

The Pizza CLI is a Go command-line tool that leverages several standard libraries. Go’s simplicity, speed, and systems programming focus make it an ideal choice for building CLIs. At its core, the Pizza-CLI uses [spf13/cobra](https://github.com/spf13/cobra), a CLI bootstrapping library in Go, to organize and manage the entire tree of commands.

You can think of Cobra as the scaffolding that makes a command-line interface itself work, enables all the flags to function consistently, and handles communicating to users via help messages and automated documentation.

### Structuring the Codebase

One of the first (and biggest) challenges when building a Cobra-based Go CLI is how to structure all your code and files. Contrary to popular belief, there is ***no*** prescribed way to do this in Go. Neither the `go build` command nor the `gofmt` utility will complain about how you name your packages or organize your directories. This is one of the best parts of Go: its simplicity and power make it easy to define structures that work for you and your engineering team!

Ultimately, in my opinion, it's best to think of and structure a Cobra-based Go codebase as a tree of commands:

```
├── Root command
│   ├── Child command
│   ├── Child command
│   │   └── Grandchild command
```

At the base of the tree is the root command: this is the anchor for your entire CLI application and will get the name of your CLI. Attached as child commands, you’ll have a tree of branching logic that informs the structure of how your entire CLI flow works.

One of the things that’s incredibly easy to miss when building CLIs is the user experience. I typically recommend people follow a “root verb noun” paradigm when building commands and child-command structures since it flows logically and leads to excellent user experiences.

For example, in [Kubectl](https://kubernetes.io/docs/reference/kubectl/), you’ll see this paradigm everywhere: “kubectl get pods”, “kubectl apply …“, or “kubectl label pods …” This ensures a sensical flow to how users will interact with your command line application and helps a lot when talking about commands with other people.

In the end, this structure and suggestion can inform how you organize your files and directories, but again, ultimately it’s up to you to determine how you structure your CLI and present the flow to end-users.

In the Pizza CLI, we have a well defined structure where child commands (and subsequent grandchildren of those child commands) live. Under the `cmd` directory in their own packages, each command gets its own implementation. The root command scaffolding exists in a `pkg/utils` directory since it's useful to think of the root command as a top level utility used by `main.go`, rather than a command that might need a lot of maintenance. Typically, in your root command Go implementation, you’ll have a lot of boilerplate setting things up that you won’t touch much so it’s nice to get that stuff out of the way.

Here's a simplified view of our directory structure:

```
├── main.go
├── pkg/
│   ├── utils/
│   │   └── root.go
├── cmd/
│   ├── Child command dir
│   ├── Child command dir
│   │   └── Grandchild command dir
```

This structure allows for clear separation of concerns and makes it easier to maintain and extend the CLI as it grows and as we add more commands.

## Using go-git

One of the main libraries we use in the Pizza-CLI is the [go-git](https://github.com/go-git/go-git) library, a pure git implementation in Go that is highly extensible. During `CODEOWNERS` generation, this library enables us to iterate the git ref log, look at code diffs, and determine which git authors are associated with the configured attributions defined by a user.

Iterating the git ref log of a local git repo is actually pretty simple:

```go
// 1. Open the local git repository
repo, err := git.PlainOpen("/path/to/your/repo")
if err != nil {
    	panic("could not open git repository”)
}

// 2. Get the HEAD reference for the local git repo
head, err := repo.Head()
if err != nil {
    	panic("could not get repo head”)
}

// 3. Create a git ref log iterator based on some options
commitIter, err := repo.Log(&git.LogOptions{
    	From:  head.Hash(),
})
if err != nil {
    	panic("could not get repo log iterator”)
}

defer commitIter.Close()

// 4. Iterate through the commit history
err = commitIter.ForEach(func(commit *object.Commit) error {
    	// process each commit as the iterator iterates them
    	return nil
})
if err != nil {
    	panic("could not process commit iterator”)
}
```

If you’re building a Git based application, I definitely recommend using go-git: it’s fast, integrates well within the Go ecosystem, and can be used to do all sorts of things!

## Integrating Posthog telemetry

Our engineering and product team is deeply invested in bringing the best possible command line experience to our end users: this means we’ve taken steps to integrate anonymized telemetry that can report to Posthog on usage and errors out in the wild. This has allowed us to fix the most important bugs first, iterate quickly on popular feature requests, and understand how our users are using the CLI.

Posthog has [a first party library in Go](https://github.com/PostHog/posthog-go) that supports this exact functionality. First, we define a Posthog client:

```go
import "github.com/posthog/posthog-go"

// PosthogCliClient is a wrapper around the posthog-go client and is used as a
// API entrypoint for sending OpenSauced telemetry data for CLI commands
type PosthogCliClient struct {
	// client is the Posthog Go client
	client posthog.Client

	// activated denotes if the user has enabled or disabled telemetry
	activated bool

	// uniqueID is the user's unique, anonymous identifier
	uniqueID string
}
```

Then, after initializing a new client, we can use it through the various struct methods we’ve defined. For example, when logging into the OpenSauced platform, we capture specific information on a successful login:

```go
// CaptureLogin gathers telemetry on users who log into OpenSauced via the CLI
func (p *PosthogCliClient) CaptureLogin(username string) error {
	if p.activated {
    	return p.client.Enqueue(posthog.Capture{
        	DistinctId: username,
        	Event:  	"pizza_cli_user_logged_in",
    	})
	}

	return nil
}
```

During command execution, the various “capture” functions get called to capture error paths, happy paths, etc.

For the anonymized IDs, we use [Google’s excellent UUID Go library](https://github.com/google/uuid):

```go
newUUID := uuid.New().String()
```

These UUIDs get stored locally on end users machines as JSON under their home directory: `~/.pizza-cli/telemtry.json`. This gives the end user complete authority and autonomy to delete this telemetry data if they want (or disable telemetry altogether through configuration options!) to ensure they’re staying anonymous when using the CLI.

## Iterative Development and Testing

Our lean engineering team follows an iterative development process, focusing on delivering small, testable features rapidly. Typically, we do this through GitHub issues, pull requests, milestones, and projects. We use Go's built-in testing framework extensively, writing unit tests for individual functions and integration tests for entire commands.

Unfortunately, Go’s standard testing library doesn’t have great assertion functionality out of the box. It’s easy enough to use “==” or other operands, but most of the time, when going back and reading through tests, it’s nice to be able to eyeball what’s going on with assertions like “assert.Equal” or “assert.Nil”.

We’ve integrated the excellent [testify library](https://github.com/stretchr/testify) with its “assert” functionality to allow for smoother test implementation:

```go
config, _, err := LoadConfig(nonExistentPath)
require.Error(t, err)
assert.Nil(t, config)
```

## Using Just

We heavily use [Just](https://github.com/casey/just) at OpenSauced, a command runner utility, much like GNU’s “make”, for easily executing small scripts. This has enabled us to quickly onramp new team members or community members to our Go ecosystem since building and testing is as simple as “just build” or “just test”! 

For example, to create a simple build utility in Just, within a justfile, we can have:

```
build:
  go build main.go -o build/pizza
```

Which will build a Go binary into the build/ directory. Now, building locally is as simple as executing a “just” command.

But we’ve been able to integrate more functionality into using Just and have made it a cornerstone of how our entire build, test, and development framework is executed. For example, to build a binary for the local architecture with injected build time variables (like the sha the binary was built against, the version, the date time, etc.), we can use the local environment and run extra steps in the script before executing the “go build”:

```
build:
    #!/usr/bin/env sh
  echo "Building for local arch"

  export VERSION="${RELEASE_TAG_VERSION:-dev}"
  export DATETIME=$(date -u +"%Y-%m-%d-%H:%M:%S")
  export SHA=$(git rev-parse HEAD)

  go build \
	-ldflags="-s -w \
	-X 'github.com/open-sauced/pizza-cli/pkg/utils.Version=${VERSION}' \
	-X 'github.com/open-sauced/pizza-cli/pkg/utils.Sha=${SHA}' \
	-X 'github.com/open-sauced/pizza-cli/pkg/utils.Datetime=${DATETIME}' \
	-X 'github.com/open-sauced/pizza-cli/pkg/utils.writeOnlyPublicPosthogKey=${POSTHOG_PUBLIC_API_KEY}'" \
	-o build/pizza
```

We’ve even extended this to enable cross architecture and OS build: Go uses the GOARCH and GOOS env vars to know which CPU architecture and operating system to build against. To build other variants, we can create specific Just commands for that:

```
# Builds for Darwin linux (i.e., MacOS) on arm64 architecture (i.e. Apple silicon)
build-darwin-arm64:
  #!/usr/bin/env sh

  echo "Building darwin arm64"

  export VERSION="${RELEASE_TAG_VERSION:-dev}"
  export DATETIME=$(date -u +"%Y-%m-%d-%H:%M:%S")
  export SHA=$(git rev-parse HEAD)
  export CGO_ENABLED=0
  export GOOS="darwin"
  export GOARCH="arm64"

  go build \
	-ldflags="-s -w \
	-X 'github.com/open-sauced/pizza-cli/pkg/utils.Version=${VERSION}' \
	-X 'github.com/open-sauced/pizza-cli/pkg/utils.Sha=${SHA}' \
	-X 'github.com/open-sauced/pizza-cli/pkg/utils.Datetime=${DATETIME}' \
	-X 'github.com/open-sauced/pizza-cli/pkg/utils.writeOnlyPublicPosthogKey=${POSTHOG_PUBLIC_API_KEY}'" \
	-o build/pizza-${GOOS}-${GOARCH}
```

## Conclusion

Building the Pizza CLI using Go and Cobra has been an exciting journey and we’re thrilled to share it with you. The combination of Go's performance and simplicity with Cobra's powerful command structuring has allowed us to create a tool that's not only robust and powerful, but also user-friendly and maintainable.

We invite you to explore the [Pizza CLI GitHub repository](https://github.com/open-sauced/pizza-cli), try out the tool, and [let us know your thoughts](https://github.com/orgs/open-sauced/discussions/categories/general-feedback-or-bugs). Your feedback and contributions are invaluable as we work to make code ownership management easier for development teams everywhere!

How OpenSauced engineering used Go and Cobra to build a robust and extensible command line interface

Technical Deep Dive: How We Built the Pizza CLI Using Go and Cobra

A couple of weeks ago, I came across this Reddit post where a developer was trying to navigate a challenge that many of us in the tech community have also faced: managing code ownership in a large, complex codebase.

[![reddit post](https://cdn.sanity.io/images/r7m53vrk/production/924e6d7c74659a5affe0f1c10e743089d0fad96f-924x442.png)](https://www.reddit.com/r/github/comments/1eb1lln/generate_codeowners_file/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)

With over 100 developers and a massive repository, they were looking for a way to automate the creation of a CODEOWNERS file. Their hope? To automatically assign ownership based on who had worked on each file. 

Not everyone in the comments was on board with this idea, calling out that this could be a recipe for disaster. You’re not wrong to be cautious, but let’s not dismiss the underlying need. The OP’s question points to a real issue in the tech industry: how do we manage knowledge and responsibility as the codebase and teams grow?

[![how do you feel about kubernetes](https://cdn.sanity.io/images/r7m53vrk/production/76b87b51577cf723d2197f85002e2dba5f9c6631-1060x370.png?)](https://www.reddit.com/r/github/comments/1eb1lln/comment/levb0wd/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)

If you want to see a complex codebase, Kubernetes is a great example, with contributions from thousands of developers across hundreds of organizations. How do they manage it? They use an OWNERS file system that’s been tested and refined over the years.

The [Kubernetes approach](https://www.kubernetes.dev/docs/guide/owners/) is about creating a map of expertise, facilitating code reviews, and making sure changes are reviewed by the *right* people. This system recognizes that in a project of that scale, no single person can know everything. The solution is to create a culture of shared responsibility and continuous learning.

Here’s the thing: what works for [Kubernetes](https://app.opensauced.pizza/s/kubernetes/kubernetes) might not work for every team. And that’s okay. The key is to understand the principles behind the system and adapt them to work for your team.

When you implement solutions like [automated CODEOWNERS generation](https://github.com/open-sauced/pizza-cli), keep in mind to:


- **Embrace shared ownership**: The goal isn't to create territorial divides in your code. It's to identify who has the deepest knowledge in different areas, so they can guide and support others.
- **Keep it dynamic**: Your CODEOWNERS file should evolve as your team and codebase grow. 
- **Use it as a guide, not a rule**: Code ownership shouldn't be a barrier to contribution. It's about facilitating knowledge sharing, not gatekeeping.

Ensuring that each part of the codebase has an expert responsible for its maintenance and review, effectively helps to manage the hidden debt of lost knowledge.

## The Real Cost of Lost Knowledge

Let’s take a look at what knowledge debt costs us:


- **Time**: New team members spend weeks trying to understand systems that could be explained in hours by the right person.
- **Efficiency**: When you’re spending time figuring out what existing code does, or you don’t understand why the original developer made certain changes, you don’t have the time to spend on making meaningful progress.
- **Morale**: Nothing kills motivation faster than feeling lost.
- **Inefficiency and Redundancy**: You might spend days solving a problem that someone else on your team has already cracked. It's like reinventing the wheel, but the wheel is buried somewhere in your Git history, and you don't even know it exists. This isn't just a waste of time; it's a missed opportunity for collaboration and knowledge sharing.
- **Maintenance Challenges and Siloed Knowledge**: As knowledge gaps widen, the cost and complexity of maintaining older parts of the system increase. This can lead to knowledge silos, where only a few individuals understand critical systems, creating bottlenecks and reducing overall team capability.

Every time a developer writes a line of code without clear ownership, every time a key team member leaves without transferring their knowledge, the debt grows and the culture weakens. It compounds over time, making each new feature more costly, each bug more time-consuming to fix, each team interaction less effective. The debt of lost knowledge is often invisible, and we often don't realize it until we're in a crisis.

## When the Debt Collectors Come Calling

Eventually, every debt comes due. In tech, this often comes during critical moments:

- A production outage caused by a change to a poorly understood component
- A missed market opportunity because adding a feature took months instead of weeks
- The departure of the last team member who understood a core system, leaving the project effectively "underwater"

These are the moments when companies often realize the real cost of their knowledge debt. But by then, it's often too late for an easy fix.

## Enter the CODEOWNERS File: Your Knowledge Map

This is where tools like the CODEOWNERS file come into play. Think of it as a map of expertise for your codebase. But not just any map – a living, breathing document that evolves with your team.

At OpenSauced, we’ve taken this concept to the next level with our [pizza-cli codeowners command](https://github.com/open-sauced/pizza-cli?tab=readme-ov-file#-usage). It's not just about assigning arbitrary owners to directories. This tool identifies who has the most relevant and recent expertise for each part of your codebase.

What sets it apart is its granularity and balance. It assigns up to three "owners" for each file or directory. Pair this with our [pizza GitHub Action](https://github.com/open-sauced/pizza-action), and you've got a system that keeps your expertise map up-to-date automatically. You can learn more about how to get started in [Introducing the Pizza CLI](https://opensauced.pizza/blog/introducing-the-pizza-cli).
Generating your CODEOWNERS file using the `pizza generate codeowners` command automatically creates or updates a CODEOWNERS file, mapping files to the appropriate owners. 

Beyond just managing debt, the codeowners command helps create a culture of responsibility and expertise. It makes code ownership visible and actionable, encouraging developers to take pride in their areas of responsibility and seek out opportunities to share their knowledge.

## Final Thoughts

It's not hard to accumulate knowledge debt in the name of quick wins and feature delivery. But like any form of debt, ignoring it only makes the problem worse-not just for your codebase, but for your entire engineering culture.

By recognizing knowledge debt for the serious threat it is, and utilizing tools like the [pizza cli](https://opensauced.pizza/docs/tools/pizza-cli/codeowners/) to manage it, teams can ensure they're building on a solid foundation. They're not just writing code—they're cultivating a culture of ownership, expertise, and collaborative learning.

Remember, every line of code you write is a promise to your future self and your team. Make sure it's a promise you can keep by managing your knowledge debt and creating a culture of knowledge sharing today. The `codeowners` command is more than just a tool—it's a step towards a more sustainable and efficient development process, and a more collaborative engineering culture. 


As projects grow and teams change, tech companies accumulate "knowledge debt." By adding code ownership practices and tools like the pizza-clicodeowners command, teams can improve their knowledge sharing and reduce their debt.

The Problem of Knowledge Debt in Tech

As software engineering teams and projects scale, a common problem larger organizations can find themselves in is deciphering the “who’s who” of a codebase. This problem only compounds itself if large mono-repos are in use or multiple teams interact in the same space. Developers may find themselves asking “Who do I ask for a review on this? What team owns this part of the code base? Who do I ask for help?”

On the receiving end of this, you may find yourself getting asked questions on things you haven’t been involved in for years. Or you may be missing critical notifications on pieces of code you maintain or your team maintains. Or even worse, there may be cross team miscommunications that cause problems for the code you own.

As teams grow and codebases expand, before too long, it can be very easy to lose the thread on who owns what piece of “knowledge” across your engineering org. This lost context can slow down development, hinder open collaboration, and slowly erode the engineering culture of an engineering organization.

But what if there was a way to automate code ownership, streamline collaboration, and reduce this knowledge debt? Today, the OpenSauced team is very excited to introduce the Pizza CLI, a powerful command-line tool designed to help maintainers, teams, and organizations manage their engineering “ownership” culture and derive insights right on the command line.

## Introducing the Pizza CLI

The Pizza CLI is our solution to the challenges of lost context and asking “Who’s who?” Born from discussions with industry experts like [Bdougie](https://x.com/bdougieYO/) and [Kelsey Hightower](https://twitter.com/kelseyhightower), inspired by robust tools used by hyperscale tech companies across the industry, the Pizza CLI empowers teams to automate code ownership and enhance cross org collaboration directly from the command line.

***CODEOWNERS Generation:*** Easily generate GitHub-style CODEOWNERS or Google-style OWNERS files, granularly mapping out who owns which parts of your codebase based on git history, number of lines touched, and current activity. These owner files can then be used in [GitHub CODEOWNERS automation](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) or as part of more robust CI/CD.

***Attribution Configuration:*** Use a simple YAML configuration to map commit emails to GitHub usernames and teams, ensuring accurate ownership assignments and easy management of entities within your engineering org.

***OpenSauced Integration:*** Seamlessly connect with [OpenSauced](https://opensauced.pizza) to create Contributor Insights pages and metrics, helping you visualize and understand your project's contributor and owner landscape.

## Enhanced collaboration for large teams

By clearly defining code ownership in a granular manner and integrating seamlessly with GitHub CODEOWNERS functionality, the Pizza CLI helps you:

***Improve Efficiency:*** Developers know exactly who to reach out to for code reviews or questions, reducing delays, miscommunications, and team misalignments.

***Enhance Collaboration:*** Ownership transparency creates a culture of shared responsibility and teamwork, further enhancing open “inner-source” between teams and developers.

***Streamline Onboarding:*** New team members can quickly identify code owners, making it easier for them to ramp up and contribute confidently. Oftentimes, this can be automated through GitHub’s integration with CODEOWNER files through automatic PR review requests and notifications.

## Getting Started with Pizza CLI

### Installation

```sh
brew install open-sauced/tap/pizza
```

We offer a number of flexible options for installing the Pizza CLI onto your system (including Homebrew, NPM, Docker, and more). Check out the docs in the repository for a full rundown of the ways you can install this tool.

### Validate your install

Check to make sure you can run the Pizza CLI:

```sh
pizza version
```

This will print out the version you have installed. Successfully running this in your terminal means you have successfully installed the CLI!

### Generate a config

Before you can start generating codeowner files, you’ll need a YAML configuration that attributes git commit emails with GitHub user logins. You can generate a config through the ”pizza generate config” command:

```
pizza generate config /path/to/your/git/repo -i
```

The “-i” flag tells the Pizza CLI to use “interactive” mode. This iterates through the git ref-log and looks at commits and who authored them. It will then ask you to attribute those commit emails to individuals on your team:

![image](https://cdn.sanity.io/images/r7m53vrk/production/219a405602d15d0be47fd0dcdc27e34e7263c7e7-1402x253.png)

Once you’ve finished generating your config, you’ll see that a `.sauced.yaml` file is now in your git repo where you originally pointed the pizza command to. It’s been populated with the associated logins and emails that can be used to attribute changes in the repository to individual owners.

We encourage you to commit this file to your repository as a core piece of configuration “infrastructure” denoting what individuals have what attributions associated with them. Alternatively, if exposing commit emails in the config is not acceptable, you may choose to add it to a private secret store and pull it down manually to make code attributions for individuals on your teams.

You can also attribute GitHub teams to long lists of emails in your YAML configuration:

```yaml
attribution:
  # Keys may also be GitHub team names.
  open-sauced/engineering:
    - john@opensauced.pizza
    - other-user@email.com
    - other-user@no-reply.github.com
```

This way, multiple people can be associated to a single team within your configuration and will get the same attribution to anyone who is a code owner for those files. In other words, this is a powerful way to compose your teams and manage ownership across a whole team of engineers. 

### Generate a CODEOWNERS file 

Now that you have a config, you can generate a CODEOWNERS file:

```sh
pizza generate codeowners /path/to/your/git/repo
```

This will read the `.sauced.yaml` configuration file that you generated in your repo to know which git commit emails are associated with GitHub logins or teams.

The codeowners generation iterates the git-ref log and looks at the number of lines touched and the frequency of updates from individuals. It will find the top 3 codeowners per file who’ve done the most work within the configured time range (note: you can use the –range flag to change how far back to look in the git ref-log!)

We’re very excited to be bringing this tool to you! Knowing who owns what and how to get help from other teams can improve your workflow and minimize bottlenecks. Using tools that help you do that, can make it easier to connect with people when it matters most.

Be sure to [check out the open source Pizza CLI repository](https://github.com/open-sauced/pizza-cli) for a full rundown of everything that’s possible with the Pizza CLI. And feel free to ask any questions or give us feedback in the GitHub issues!!

As always, stay saucy!


A powerful way to generate and automate developer insights from the command line

Introducing the Pizza CLI

"How many humans could screw up my dependency graph?" 

This question, posed by [Jordan Harband](https://app.opensauced.pizza/u/ljharb), provides a different perspective on open source security. In a recent episode of [DevTools FM](https://www.devtools.fm/episode/111), Harband challenges the traditional metrics we use to evaluate open source security, suggesting that we've been looking at the wrong numbers all along. 

[![Jordan Harband Dependency Graph clip](https://cdn.sanity.io/images/r7m53vrk/production/cc794b6154e2ab8ad4290412ddf4aa22352e99d9-944x1238.png?w=450)](https://x.com/DevtoolsFM/status/1828553702862426341) 

We talk a lot about metrics, and what measures success in open source, but we often overlook the human element. Harband reminds us that behind every package, every line of code, there's a human being. When it comes to open source security, it's not about how many packages you're using—it's about how many people could potentially mess them up; it's about the "Human Dependency Graph."

## The Problem with Counting Packages

Our fixation on easily quantifiable metrics like package counts mirrors a broader issue in open source: the tendency to prioritize speed over security. Sometimes we see a project with fewer dependencies and assume it's more secure. But that's not necessarily true. What if there's a high number of [YOLO Coders](https://opensauced.pizza/blog/yolo-coder) pushing code directly to the main branch? What if the [maintainers of those few packages are burnt out](https://opensauced.pizza/blog/problems-with-open-source)? What if those projects aren't following best practices?

Harband likens this obsession to outdated thinking from decades ago—"an absurd thing to care about." After all, what does the number of packages really tell you about the security of your project?

Harband's argument flips traditional understanding on its head. He argues that a company with 10,000 internal developers might actually be at greater risk than a project relying on 100 external open source maintainers. Why? Because each person with access to the code is a potential point of vulnerability, not because they're malicious, but simply because they're human and capable of making mistakes. Instead of simply counting packages or contributors, we need to evaluate the expertise, reliability, and interconnectedness of the human network behind our code.

However, we need to consider another factor here: [the lottery factor](https://opensauced.pizza/blog/Understanding-the-Lottery-Factor). This concept suggests that a project becomes vulnerable if a small number of contributors (typically 2 or fewer) account for more than 50% of the contributions. So while having fewer maintainers might seem safer, it's not that simple. The ideal scenario balances a small group of supported and highly skilled maintainers to prevent over-reliance on any single individual. This view is at the heart of understanding the Human Dependency Graph.


## The Real Threat: Focusing on the Wrong Metrics

Metrics like package size, issue count, and star rating, might seem to tell a clear story, but in reality can mislead us. Harband points out a startling possibility: "Somebody will make a package that's like 1K smaller solely so they can take over your supply chain."

In other words, if we remain laser-focused on reducing package size or maximizing star count, we could be opening ourselves up to security risks rather than mitigating them. The numbers we've been relying on don't just miss the point—they might be actively leading us astray.

## A Call to Action: Focus on the Humans, Not the Packages

So, what can we do with this new understanding? Here are three key actions:

1. **Map Your Human Dependency Graph:** Start identifying who maintains the packages you rely on. Know the people behind the code—their track records, their reputations, and their patterns of contribution. (Check out our [Repo Pages](https://opensauced.pizza/docs/features/repo-pages) for your dependencies to identify maintainers.)
2. **Build Relationships, Not Just Dependencies:** Cultivate connections with the maintainers of your critical packages. Open source survives with community and trust, and being an engaged part of that community can help you reduce your security risks. (Learn how to make that process easier by [creating a Workspace from SBOM](https://opensauced.pizza/blog/security-and-SBOMs).)
3. **Shift Your Focus from Package to Publisher Count:** Instead of worrying about how many packages you're using, think about how many maintainers have access to them. This shift in thinking helps you prioritize real risks and can make your projects more resilient in the face of threats.

## The Big Picture: Evolving Our Thinking on Open Source Security

As the open source ecosystem has grown, the metrics that mattered years ago might no longer apply. Just as we've had to rethink what constitutes valuable contributions in the age of GitHub, we also need to rethink what constitutes security.

Jordan Harband's idea of the Human Dependency Graph challenges us to look beyond what's easy to measure and to think critically about what we should really care about. After all, in a world where a single human can introduce significant vulnerabilities into a project, the numbers that matter most aren't the ones you might think.

Discover the Human Dependency Graph. Learn why focusing on people, not packages, is key to reducing risk in your projects.

The Human Dependency Graph: Why We Need to Rethink Security in Open Source

Hi everyone! 👋

This week we’ve been working on the **List feature** that will allow users to create lists of OSS contributors and get an insights page that tracks their activity, their highlights, and much more.

**This post is a sneak peak of what these lists’ insight pages are going to look like.**

![context for list feature](https://cdn.sanity.io/images/r7m53vrk/production/a5ce4e8fb29ba0e798f2c74d367e9aa9e9503544-3182x1778.png?w=600)

The insight pages will contain 6 different sections:

✅ **Overview:** a quick snapshot of top datapoints to get an idea of the type of contributors in the list (new, active, alumni) and top level activity indicators.

![insight page overview](https://cdn.sanity.io/images/r7m53vrk/production/a29d55696e5cdde9fde583d2075dbec460ec0947-2880x2026.png?w=600)

✅ **Activity:** a deeper dive into the work the contributors are doing, showing what orgs and projects they are contributing to, the type of contributions they are making, and more.

![contributor graphs](https://cdn.sanity.io/images/r7m53vrk/production/1eef22732e56a951b82c98ddc70658d7fe711ec5-2880x2846.png?w=600)

![treemap drilldown](https://cdn.sanity.io/images/r7m53vrk/production/e6b6b3adc4ec4ab2ef6fd87f81996d1f5255f06c-4272x2468.png?w=450)

🔜 **Highlights (coming soon):** will show a feed of highlights the contributors have uploaded, with the ability to filter and sort them.

🔜 **Connections (coming soon):** will give the user the ability to understand how the contributors in the list are connected based on the projects they’ve worked on.

🔜 **Contributor Profile (coming soon):** will display demographic data to provide a deeper understanding of the people behind the contributions, their location, where they work, what languages they code with, and more.

🔜 **Contributors (coming soon):** a table featuring the contributors within the list, giving the user the ability to edit, filter, sort and perform bulk actions.

Some **key** features that we want to build for these and all other insight pages in the platform are:

- Bite-sized insights for charts — showing the most important takeaway of each chart for quick insights.
- Easy Sharing — to be able to share charts, insights and comments with the rest of your team.
- Easy filters — to filter the data on the charts by time frame, types of contributors, and more.

🚀 **What’s coming**

This next week, we will be working on the remaining sections of the List Insight Pages (Highlights, Connections, Contributor Profile, and Contributors tabs) and some potential AI explorations (👀).

Stay tuned!

Access insights on lists of contributors!

Product Update: List Feature

If you’ve been in open source long enough, you’ve most likely seen xkcd’s meme about how all of the internet’s infrastructure depends on a project some random person has been maintaining for years. You know the one.


![xkcd’s meme about how all of the internet’s infrastructure depends on a project some random person has been maintaining for years. ](https://cdn.sanity.io/images/r7m53vrk/production/7b8fea52e50a46203677c15362d28d01f291df0b-722x912.png?w=500)

But the issue is: it’s just as hilarious as it is scary, because what happens when the random person in Nebraska is gone? Take [core-js’s story](https://www.izoukhai.com/blog/the-sad-story-of-denis-pushkarev-zloirock-the-creator-of-core-js) as an example: a JavaScript library with 9B downloads and a maintainer that went through one-too-many struggles with no support from the community (including jail!). When he eventually decided that he wouldn’t work on the project anymore the repository was left to die slowly, leaving billions of users to fend for themselves.

This same story could be repeated with any of the hundreds of projects in your software supply chain, but there is no way to know until it’s too late… or at least that’s what we kept hearing from our users and members of the open source community. 

We even got specific feedback from engineering managers on our network that have had teams make "poor dependencies choices" for packages that are ill maintained or completely abandoned,

And so, with this pain point in mind we set out to build a solution.


## **The problem**

If a project has a strong contributor base and the knowledge is distributed among different people, then one person leaving won’t pose a serious threat to its sustainability. But if a project’s livelihood depends on only one or two people, this makes it very risky to consume it.

The problem is that there is no easy way of identifying how much a project depends on its maintainers or top contributors. 

Of course, we knew Bus Factor was already a thing (which answers the awful question of “what is the number of contributors that, if run over by a bus, would mean the end of this project?”), but there was no straightforward way to calculate it. The contribution data was hard to obtain without writing custom code and hitting the Github API, and doing a manual calculation meant getting deep into a repository’s PRs list. 

Plus the whole concept of a maintainer being run over by a bus just didn’t sit well with us.


## **Our solution: the Lottery Factor**

After conducting research on the topic and speaking to many maintainers and developers, we decided to take over the concept of Bus Factor and revamp it. Instead of being a niche, hard to get metric, we wanted to make it accessible, approachable and easy to find.

We started by renaming it to “Lottery Factor”, so instead of being run over by a bus, a maintainer’s decision to leave would be made by winning the lottery – and our maintainer friends seemed to like it much better. 


## **Our goal**

We wanted to keep the basis of the metric the same (the smallest number of people that make 50% of contributions) but we knew just a number wasn’t enough context for a user to really understand the concept at a glance.

The goal when designing the chart was to allow users to:

- Be able to easily identify a project’s Lottery Factor
- Quickly understand how risky a project’s Lottery Factor is
- Identify contributors that make up the Lottery Factor
- Visualize how work is distributed among these contributors
- Find information and guidance on the topic

## **The result**

The final design of the Lottery Factor chart included a mix of visual cues, data and written context to communicate the metric to users:

![anatomy of the lottery factor chart](https://cdn.sanity.io/images/r7m53vrk/production/fbcb8b7755cecf71cdc3680232a064ba5d82ba4c-3034x1625.png)


![states of the lottery factor](https://cdn.sanity.io/images/r7m53vrk/production/d6326fa785e73a114bfb34f138d24608f1547e4c-3034x1625.png)


## **Lottery Factor 🤝 Repo Pages**

In the context of Repo Pages, the Lottery Factor helps paint the full picture on any specific repository. As useful as it is by itself, the real value of this chart is brought out by the other data points and context in Repo Pages, such as meta tags, number of contributors, activity indicators (Issue and PR charts) and the Contributor Confidence metric.

As an example, a repository with a very low number of contributors, a recent creation date, and low number of issues, PRs and stars could signal that this is a small, personal repository. In this case a high lottery factor is expected and considered normal.

But a project with a high number of contributors and consistent levels of high activity could mean that this is indeed a large project with an extensive community and potentially a lot of usage and adoption. Within that context, a very high lottery factor could very easily pose a high risk, giving users another data point when deciding whether to contribute or incorporate that project as a dependency.

![kubernetes repo page with lottery factor chart highlighted](https://cdn.sanity.io/images/r7m53vrk/production/fef039d4d97c7d3f61eba5fb0baf19d97c9e4a43-3034x1625.png)





Here's a breakdown of the process behind building one of our most acclaimed charts.

How we built our Lottery Factor chart

GitHub recently claimed the top spot in [Gartner's inaugural Magic Quadrant for AI Code Assistants](https://github.blog/news-insights/company-news/github-named-a-leader-in-the-gartner-first-ever-magic-quadrant-for-ai-code-assistants/). In mid-2021, GitHub made waves by entering the AI-powered code completion market. While competitors had already offered similar solutions, GitHub's strategic partnership with OpenAI proved highly successful. This move not only positioned GitHub as a leader in AI-assisted development but also led to the company redefining its core focus around AI technologies.

Today we have seen the projects like [Cursor](https://www.cursor.com/), [Magic](https://magic.dev/), and [Sourcegraph’s Cody](https://sourcegraph.com/) enter the space to compete in providing developers with the best AI coding companion. With GitHub being the leader among so many competitors, what's next in the space to stay competitive? 

Interestingly, while these AI coding assistants focus on code completion and generation, there seems to be a missed opportunity in leveraging the contextual information available in GitHub issues and discussions. GitHub repositories contain a wealth of knowledge about problem-solving approaches, best practices, and domain-specific insights. **Why aren't AI companies exploring ways to collect and share this valuable context?** Incorporating this information could significantly enhance the AI assistant's understanding of real-world development challenges and provide more nuanced, project-specific assistance to developers. This missed opportunity could be the key to unlocking the next level of AI-assisted development.

## The Untapped Potential of Repository Data

Every GitHub repository is more than just lines of code. It's a rich ecosystem of issues, discussions, pull requests, comments, and documentation. These elements collectively tell the story of a project's evolution, capture the reasoning behind decisions, and document the collective knowledge of contributors. 

By leveraging this contextual data, AI assistants could provide more nuanced, project-specific insights and suggestions. Imagine an AI coding assistant that doesn't just complete your code, but understands the history of your project, the rationale behind previous decisions, and the unique challenges your team has faced. 

Consider this example: When asked about the top contributors to [ArgoCD](https://app.opensauced.pizza/s/argoproj/argo-cd), ChatGPT provides a general response:

> "The top contributors to the Argo CD project frequently change as it is an active and collaborative open-source community. Currently, some of the most significant contributors include individuals from Intuit and other active community members. However, the specific top contributor at any given time can vary depending on recent contributions and involvement in the project."

While this answer is not incorrect, it lacks specificity and real-time accuracy. But if we add ArgoCD to an OpenSauced Workspace, we can ask StarSearch, OpenSauced's AI, the same question and get a more detailed response:

![StarSearch Gif](https://cdn.sanity.io/images/r7m53vrk/production/4392e06fa1f0f329518e6f2c586df8f1438c6bc8-468x720.gif)

Not only do we see the top contributors, but we get a breakdown of the number of contributions and more context about the lottery factor - the number of contributors that would need to suddenly leave to cause an impact on the project. 

## The Vision: Every GitHub Repository as an AI-Ready Dataset

Extending the Workspace concept to all GitHub repositories means that every repository could become a rich, context-aware dataset ready for AI analysis. For many projects, repositories are living records of the software development lifecycle. From the first commit to debugging and refactoring, repositories capture a wealth of information. By treating these repositories as comprehensive datasets, we unlock a new possibilities for AI-assisted development.

### Knowledge Transfer

AI models trained on repository data can learn not just how to generate code, but why certain decisions were made. With access to issues and discussion, context about how problems were solved in the past and what trade-offs were considered allows for more informed answers to queries. This deep learning allows AI to transfer knowledge across projects and teams, potentially accelerating problem-solving and innovation.

For instance, if an AI assistant could analyze commit messages, pull request discussions, and issue threads to understand the reasoning behind architectural decisions, it could apply this knowledge to suggest solutions for similar challenges in new projects or adjacent domains.

### Contextual Understanding

By incorporating context from issues, discussions, and code reviews, AI assistants can provide more nuanced recommendations that go beyond syntax to understand intent. This context-aware AI could offer suggestions that align with project goals, coding standards, and team preferences.

Imagine an AI assistant that, before suggesting a code change, considers the project's performance requirements, security policies, and even the team's preferred coding style - all extracted from the repository's history and documentation.

## Practical Use Case: AI and Repository Context

Let's revisit our earlier example of asking about top contributors to a project like ArgoCD. While current AI models provide generalized responses, a context-aware AI could deliver far more insightful information.

Imagine asking, "Who are the top contributors to ArgoCD, and what areas do they focus on?"  This is what we get when we ask StarSearch on the ArgoCD Workspace:

![workspace gif](https://cdn.sanity.io/images/r7m53vrk/production/cc5c31718d19e1a7a3d3a8e9bbfcbd6216e273df-468x720.gif)

We see a more detailed breakdown of the types of contributions and who was responsible for key changes. 

## Multi-Repository Workspaces: A Unique Dataset for AI

But an even more powerful approach to treating repositories as a dataset happens when we group multiple repositories together - something you can do today in a Workspace. This approach creates a unique, interconnected dataset that provides a broader context for AI analysis.

### Creating a Comprehensive Dataset

By aggregating multiple repositories into a single workspace, we create a dataset that captures not just isolated project information, but the relationships and patterns across different projects. This comprehensive view would allow for:

1. Identifying cross-project patterns and best practices
2. Understanding dependencies and interactions between different repositories
3. Analyzing how different teams or projects approach similar problems

### Benefits of Multi-Repository Datasets

Multi-repository workspaces provide a comprehensive view of complex projects, revealing interactions between different components and enabling deeper insights into system-wide patterns. This comprehensive view encourages the cross-pollination of ideas, allowing AI assistants to suggest improvements or solutions from one project that could benefit another. Additionally, by analyzing multiple repositories simultaneously, you could identify inconsistencies in coding standards or practices across projects, presenting opportunities for standardization and overall code quality improvement. 

Using multi-repository workspaces as datasets also allows us to learn:

• **Organizational Patterns:** How different teams within an organization approach problem-solving, code organization, and collaboration.

• **Technology Adoption Trends:** How new technologies or methodologies spread across different projects within an organization.

• **Knowledge Flow:** How information and best practices propagate between different repositories and teams.

• **Project Health Indicators:** By comparing metrics across repositories, we can identify what factors contribute to project success or struggle.

AI assistants could suggest collaborations by understanding the expertise demonstrated across different repositories, recommending potential partnerships between team members or projects. There's also potential to predict integration challenges, based on historical data. And lastly, security analysis could be enhanced, with AI assistants identifying vulnerabilities. For instance, this could be done by [creating an SBOM from your Workspace](https://opensauced.pizza/blog/security-and-SBOMs) to understand the dependencies and vulnerabilities across your projects.

## The Next Competitive Edge in AI Development

As AI tools for software development continue to advance, the ability to capture the collective knowledge embedded in GitHub repositories will become an important differentiator. The future of AI in this space isn't just in generating code, but in understanding the rich context surrounding that code.

Companies that can effectively implement this repository-as-dataset approach will have a significant competitive advantage. Their AI tools won'y just be faster at generating code, but smarter at understanding the *why* behind the code, leading to more valuable and contextually appropriate assistance.

You can build your own AI-ready dataset by [creating a Workspace](https://app.opensauced.pizza/) today. You can also check out my [ArgoCD Workspace](https://app.opensauced.pizza/workspaces/5aa680dd-9449-4ccf-adb6-74f595dd8a83/activity?range=30&page=1) or, for a multi-repository example, [The TanStack Workspace](https://app.opensauced.pizza/workspaces/9b919527-1ea7-41eb-8892-7fc6eedaaf58).

Ever wonder what your GitHub repos could teach AI? Learn how turning repositories into smart datasets could supercharge organizations. From multi-repo insights to AI that understands your project's history, discover  what we think should be the  next big thing in AI assistants.

Every GitHub Repository Should Be A Dataset

In his book "The Second Mountain," David Brooks talks about the journey from a life focused on personal success to one dedicated to community and service -  our deepest fulfillment comes not from individual achievement, but from connection and commitment to others. It struck me that this concept also resonates deeply with the growth and adoption we're seeing — and need to continue cultivating — in the open source world.

## The Two Mountains of Open Source

For many of us, we've defined open source as the first mountain. The first mountain is focused on personal achievement, recognition, and career advancement. It's about building a impressive GitHub profile, gaining stars on your repositories, or using open source contributions to land your dream job.

But there's a second mountain to climb — one that's about commitment to the community and shared progress. It's where the real magic of open source happens, and it's where we need to set our sights.

Connection in open source goes beyond collaboration. It's about creating a shared sense of purpose, building trust, and supporting a community where contributors are recognized for positive contributions. It's about having context and understanding the people behind the code. 

In fact, in *[Evidence for a Collective Intelligence Factor in the Performance of Human Groups](https://pubmed.ncbi.nlm.nih.gov/20929725/)*, the researchers concluded that connection creates a collective intelligence, where the groups's combined knowledge and problem-solving capabilities exceed individual efforts.

Extending this to tech, when developers connect, they don't just share code — they share ideas, challenges, and visions. This exchange sparks creativity and leads to breakthrough solutions that likely wouldn't happen in isolation. A connected community is more likely to engage in meaningful discussions about the implications of their work, and identify areas for improvement or growth. They're also more likely to resolve issues, know where to ask questions, and to be more productive.

Open source has the power to affect lives globally. But sometimes it can be hard to find that connection, to know the people behind the pull requests.

Despite the clear benefits of connection, the distributed nature of open source development can make it challenging to build these relationships. Contributors often work across different time zones, cultures, and backgrounds, rarely meeting face-to-face. The anonymity of usernames and the focus on code can sometimes obscure the human element that's needed to build collective intelligence.

## Contributors as Connectors

This is where intentional effort from contributors becomes necessary. It's not enough to simply submit pull requests or report issues. To truly harness the power of collective intelligence and create impactful open source projects, contributors need to actively invest in understanding and connecting with the community they're part of.
This could involve:

- Taking time to read and understand the project's history, goals, and culture
- Actively participating in community discussions beyond just code-related topics
- Reaching out to other contributors to learn about their experiences and perspectives
- Offering help and support to new contributors, sharing knowledge gained from their own journey
- Initiating or participating in community events and collaborative problem-solving sessions

Through these efforts, contributors can help create an environment where everyone feels valued not just for their code, but for their unique perspectives and experiences. This approach also helps address some of the long-standing challenges in open source, such as contributor retention. When people take the initiative to connect and create a sense of belonging, they're more likely to stick around. They're also more likely to invite others in.

A contributor-driven approach to connection can lead to more sustainable and resilient open source communities. Rather than relying solely on maintainers to facilitate connections, it distributes the responsibility across the entire community, creating a stronger, interconnected open source ecosystem.

Essentially, by taking the initiative to connect and understand, contributors aren't just improving code — they're actively shaping and strengthening the foundation of what makes open source projects. This shift from passive participation to active community building is can unlock more of the potential of open source collaboration.

## The "See a Need, Fill a Need" Approach

But how does a contributor get started? One way contributors can engage more deeply is by adopting a "see a need, fill a need" mindset. This approach encourages proactive problem-solving and creates a culture of initiative and responsibility.

Consider how [React's](https://app.opensauced.pizza/s/facebook/react) reconciliation algorithm came about — developers saw a need for more efficient DOM updates and filled it, significantly improving the library's performance. Or how [Webpack](https://app.opensauced.pizza/s/webpack/webpack) was created to solve module bundling issues that many developers were facing.

But contributing effectively goes beyond just solving technical problems. It's about understanding the project's philosophy and aligning with its vision. [Evan You](https://app.opensauced.pizza/u/yyx990803), the creator of [Vue.js](https://app.opensauced.pizza/s/vuejs/core) and [Vite](https://app.opensauced.pizza/s/vitejs/vite), emphasizes this point in a [recent Secret Sauce Episode](https://www.youtube.com/watch?v=4_uYqae42uc):

> So for example, we have a current core team member on Vue's side where he's super young, but the pull requests that he makes, the quality of the code, the way he organizes stuff, and the way he makes the certain decisions makes me feel like, okay, this is probably how I would do it if I were to do it myself. And that kind of just naturally builds trust. And if he keeps doing, you know, if the person repeats this pattern a few times, then the trust just kind of compounds. I'm like, okay, this guy knows what he's doing and I can trust him to make the right decisions, even if I'm not directly paying attention to it. And that's important, right? And I think it's, if you're a maintainer, you will, like different maintainers have different style of working on their projects, right? Like we would have different code preferences. We have different design philosophies on how the project should work. So usually a good contributor understands your preference, your philosophy very instinctively, intuitively. I think that alignment is very key, right? Some people can be really technically brilliant, but maybe they just disagree on almost everything with you. And they wouldn't become good contributors or team members, right? So it's like technical skill is not really the only factor here. 

This approach shifts the focus from "What can I get out of this?" to "What can I contribute that the community needs?" This deeper level of engagement goes beyond technical proficiency, and creates a sense of alignment and trust within the community. When contributors invest time in understanding a project's ethos, they're not just writing code — they're becoming integral parts of the project's ecosystem. This approach leads to more meaningful contributions, smoother collaborations, and a stronger, more cohesive open source community. It exemplifies the "see a need, fill a need" philosophy in a broader sense, where the "need" isn't just a technical problem, but also includes the need for contributors who truly understand and align with the project's vision and values.

## Building Trust Capital: The Currency of Open Source

While the "see a need, fill a need" approach is a great starting point, sustained and impactful contribution to open source projects requires more. It requires building what we call "trust capital" — a asset that's accumulated over time through consistent, quality interactions, and a deep understanding of the project's context.

Trust capital in open source communities is the confidence and credibility you earn through your contributions and interactions. It's not just about the code you write or the issues you solve; it's about how you engage with the community, respect its processes, and align with its goals. As Evan You pointed out, when a contributor consistently makes decisions that align with the project's philosophy, trust naturally builds and compounds over time. In a previous post, [The Compound Interest of Open Source](https://opensauced.pizza/blog/open-source-network-effects), we explored how contributions can have a compounding effect, leading to increased trust and recognition within the community.

But how do you build this trust capital? It starts with understanding the project's context:

- Project History: Dive into past issues and pull requests to understand the project's evolution. (We're currently building a tool to connect you more granularly to the codeowners of a project to help you understand the project's history, so keep your eyes on our [pizza-cli](https://github.com/open-sauced/pizza-cli).)
- Current Direction: Familiarize yourself with the project's roadmap and immediate goals.
- Community Dynamics: Observe how decisions are made and who the key contributors are.
- Maintainer Preferences: Understand the maintainers' coding style, design philosophy, and communication preferences.

As you work to understand a project's context and build trust capital:

- Listen Actively: Pay attention to discussions, even on issues you're not directly involved in.
- Ask Thoughtful Questions: Show your engagement and desire to understand.
- Start Small: Begin with minor contributions as you build your understanding.
- Respect Processes: Follow the project's contribution guidelines meticulously.

Every interaction is an opportunity to both learn and demonstrate your commitment to the project. This approach aligns perfectly with the "see a need, fill a need" philosophy we discussed earlier. You're not just filling technical needs, but also the need for contributors who truly understand and align with the project's vision and values.

## Ascending the Second Mountain: The Summit of Open Source

The first mountain of open source might be about personal achievement: the thrill of seeing your code merged, the pride in solving a complex problem, or the boost to your resume. But the second mountain? That's where the true magic of open source happens.

This second mountain is about connection — not just to code, but to people, to purpose, and to a larger understanding of the projects, maintainers, and contributors. It's about understanding that every line of code is part of a larger story, a narrative written by a experts in different areas, with knowledge bases that shouldn't be siloed. 

Remember Evan You's anecdote about the young Vue contributor? That contributor didn't just write good code — they demonstrated an intuitive understanding of the project's philosophy and the maintainers' preferences. They proved themselves to those who had already proven themselves.

This approach is far more effective than trying to brute-force your way into a community. It's not about making the loudest noise or the biggest splash. It's about thoughtful, respectful integration into an existing ecosystem.

Explore the art of open source success. Learn how to build trust, understand project philosophies, and become a valued community member as an open source contributor.

Unlocking Open Source Success: The Art of Effective Open Source Contribution

Recently, Congressman Maxwell Alejandro Frost and Congressman Don Beyer introduced new legislation called ["The Spacecraft Cybersecurity Act"](https://frost.house.gov/media/press-releases/congressman-maxwell-frost-defends-us-assets-from-china-russia-cyberattacks-introduces-new-bill-toenhance-cybersecurity-of-american-spacecrafts) that will require NASA to secure a cybersecurity protection plan from manufacturers applying to use federal dollars to build NASA spacecrafts. This legislation is a response to "thousands of cyberattacks from malicious actors, including state-sponsored threats from China and Russia, [that] have been launched against NASA, threatening the safety of Americans, including astronauts."

> "As we enter a new era of cyber threats, establishing a reasonable timeline for NASA to incorporate cybersecurity measures into their acquisition process is more important than ever. The Spacecraft Cybersecurity Act would safeguard NASA's space missions and continue to advance our country's leadership in space exploration that contributes to our economy, security, and understanding of space." -Congressman Frost

This Act requires NASA to finalize a plan within 270 days of the law’s enactment to revise its spacecraft acquisition standards to incorporate important cybersecurity requirements. Recognizing the technical complexities of this task, the bill allows NASA’s experts time to develop this plan. 

NASA's recent actions are not occurring in isolation. They're part of a broader trend of increased scrutiny on software supply chains, particularly in government and critical infrastructure sectors. As governments worldwide deal with increasing cyber threats, they're turning their attention to the backbone of modern software - open source. This shift is creating both challenges and opportunities for the open source community.

## The Cyber Resilience Act (CRA)

While NASA's actions have brought immediate attention to the issue of software supply chain security, the European Union's proposed [Cyber Resilience Act (CRA)](https://en.wikipedia.org/wiki/Cyber_Resilience_Act) represents a more comprehensive and far-reaching shift in the regulatory landscape. The CRA, first proposed in September 2022, aims to establish "common cybersecurity standards for products with digital elements across the EU."

### Key Points of the CRA:

- **Scope**: The CRA applies to all products with "digital elements," which includes software and potentially impacts a high number of open source projects.
- **Requirements**: Manufacturers would need to implement security measures, conduct risk assessments, and provide ongoing support and updates for their products.
- **Reporting Obligations**: The Act mandates reporting of actively exploited vulnerabilities and incidents to EU authorities within 24 hours.
- **Penalties**: Non-compliance could result in fines of up to €15 million or 2.5% of "global annual turnover."

### Why the CRA Matters for Open Source:

- **Global Impact**: Although an EU regulation, the CRA's effects will be felt globally because of the interconnected nature of software supply chains.
- **SBOM (Software Bill of Material) Adoption**:  SBOMs may become more of a standard practice due to the CRA's requirements.
- **Open Source Implications**: Initially, the open source community raised concerns about the CRA's potential to create a "chilling effect" on open source development. However, recent amendments have introduced the concept of an "open source steward" and provided some exceptions for open source software.
- **Preparation Time**: With the CRA expected to come into effect within the next two years, the open source community has a limited window to prepare and adapt.

### The CRA and SBOMs

The CRA doesn't explicitly mandate the use of SBOMs, but its requirements for security measures and transparency align closely with SBOM principles. 

> An SBOM, or Software Bill of Materials, is a detailed list of the software components and dependencies that make up a software application. It’s like an inventory or a “recipe” that outlines the different parts that have been used to create the software. SBOMs are useful for understanding the software supply chain, tracking vulnerabilities, and ensuring compliance with regulations like the CRA.

In OpenSauced, you can create SBOMS from a Repository Page. This feature allows you to generate a Software Bill of Materials (SBOM) for your open source project, providing a detailed inventory of all the software components and dependencies used in your application. For example, if I create an SBOM for [Microsoft/TypeScript](https://app.opensauced.pizza/s/microsoft/typescript), I can see a list of 34 of it's dependencies, making it easier to track and manage the software supply chain.

![SBOM gif](https://cdn.sanity.io/images/r7m53vrk/production/95e9538a3fbd64f395c4b6e22a69c837561c9454-1060x720.gif)


[Link to TypeScript SBOM](https://app.opensauced.pizza/workspaces/3bffb2ab-a9fb-421d-a68b-fd711fa52e49?limit=40)


Implementing comprehensive SBOMs could help organizations as the CRA is enforced by allowing for:

- Risk assessment of software components
- Ongoing vulnerability management
- Transparency in software composition
- Facilitating incident reporting and response


## Last Thoughts

The tightening focus on software supply chain security mark a crossroad for the open source community. This shift isn’t just a challenge — it’s a chance to lead in strengthening the security and transparency of open source projects. We need to find ways to build greater trust with users, understand regulatory demands, and ensure the continued success of our projects.

[Generate and review the SBOMs](https://opensauced.pizza/docs/features/repo-pages/#create-a-workspace-from-sbom) for your projects to see how secure the projects you depend on are. When we understand the software supply chain, we can better prepare for the changing regulations and find ways to improve our projects security.

Discover the benefits of tracking SBOMs in your projects and learn how it can boost your software’s security and compliance.

Maximizing Software Security: The Benefits of Tracking SBOMs in Your Projects

I've always appreciated that when you go to [Astro's Community Page](https://community.astro.build/), they show you a list of Astro Community Award Winners. 

![Astro Community Award Winners
Recognizing outstanding contributors, supported by Astro's Open Collective funding. Celebrating bug fixes, new features, docs, translations, support, and community involvement!](https://cdn.sanity.io/images/r7m53vrk/production/c8023f3b4b79abb6f8e361cc31aa896aedf77539-2708x982.png?w=1080)

They point out that it's not just code, but also documentation, community support, and more.

One of the most powerful actions we can take is recognizing the contributions of others. 58% of maintainers have either quit or considered quitting their projects, according to a [2023 Tidelift survey](https://tidelift.com/open-source-maintainer-survey-2023). 

But how can we recognize the contributions of others if we don't know what they are doing? It's not just the [loudest projects in the room that get the most recognition](https://opensauced.pizza/blog/open-source-success); it's often the loudest and most visible contributors and maintainers that are getting noticed. We celebrate the most starred repos, the viral projects, and the contributors who are speaking in public about their work. But what about the contributors working quietly behind the scenes? How can we recognize contributions when they're not always visible? One way to do this is to look at the broader impact of contributors across the open source ecosystem by using the [Open Source Contribution Rating (OSCR)](https://opensauced.pizza/docs/features/contributor-insights/#open-source-contributor-rating-oscr) score.

> The OSCR score is a metric that measures the impact of a contributor's work across all the open source projects they contribute to over a period of 90 days. It takes into account not just the quantity of contributions but also their quality, ability to create and maintain impactful conversations, and their impact on the open source ecosystem. By looking at contributors through the lens of OSCR scores, we can gain a more nuanced understanding of their value and impact.

This invisibility problem has real consequences. Consider this:

**1. Recognition Goes Beyond Code**
   
   That contributor who always clarifies issues? They're improving your project's accessibility. The person who consistently reviews PRs? They're maintaining code quality. We don't want valuable contributors to go unnoticed and unrewarded.

**2. Context is King**
   
   Understanding the context of contributions can reveal surprising insights. Maybe that sporadic contributor is actually a key maintainer of a critical dependency. Or perhaps that newcomer with small but frequent commits is a rising star in a niche technology your project uses.

**3. Sponsorship: Supporting the Ecosystem**
   
   Many of us rely on open source projects we don't directly contribute to. Identifying key contributors in these projects for sponsorship isn't just generous—it's an investment in the health of our entire ecosystem.

What if we could peel back the layers and see more of the full picture of contribution in our projects? If you could understand who's pushing code, who's sparking important conversations, who's improving documentation, and who's maintaining the heartbeat of the community? This isn't just about satisfying curiosity. It's about understanding the true pillars of our projects. It's about recognizing that the person consistently clarifying issues might be just as important for project health as the top code contributor. It's about acknowledging that the community member who always leaves thoughtful, constructive reviews is helping maintain code quality in ways that don't show up in commit logs.

## Case Study: [ollama/ollama](https://app.opensauced.pizza/s/ollama/ollama/)

Let's take a closer look at Ollama, an open-source project for running large language models locally. When we look at Ollama's contributor list, we see a variety of contributors, including - but not limited to - developers who are working fulltime on the project. 


[![ollama contributor chart](https://cdn.sanity.io/images/r7m53vrk/production/83c6b0935c9f941c8d4d2dd47fbf8f5847a594bf-2766x1188.png?w=1080)](https://app.opensauced.pizza/s/ollama/ollama/contributors?range=30&display=list)

The high impact contributors aren't just contributing to Ollama. They're also contributing to other projects. This is a key insight that can help us understand the broader impact of these contributors on the open source ecosystem. 

For example, [sammcj](https://app.opensauced.pizza/u/sammcj) has a high OSCR score of 254, indicating that they're making significant contributions not just to Ollama, but to other projects as well. When we look at his profile, we see a variety of contributions, including driving conversations, writing issues, and creating PRs in different projects.


![sammcj's contribution graph](https://cdn.sanity.io/images/r7m53vrk/production/3fd770467229b4929ce89c75a0b85817a498066b-1094x394.png?w=1080)

This kind of insight can help us identify key contributors who are shaping the open source landscape beyond their immediate projects.

## Open Source Excellence: The [Vercel/Next.js](https://app.opensauced.pizza/s/vercel/next.js/) Example

To truly appreciate the significance of these OSCR scores, let's look at a standout example: Next.js. 

[![next contributor chart](https://cdn.sanity.io/images/r7m53vrk/production/3e936273432afd404a95a8ea0aa4996af0046023-1620x1150.png?w=1080)](https://app.opensauced.pizza/s/vercel/next.js/contributors?range=30&display=list)

Next.js showcases the power of cultivating high-impact contributors, and they're contributor base is nothing short of remarkable: their top 16 contributors all fall within the top 5% of OSCR scores across the entire open source ecosystem. But what does this really mean?

- **Concentration of Talent**: Next.js has managed to attract and retain some of the most impactful contributors in open source. These aren't just good developers; they're shaping the future of web development across multiple projects and communities.
- **Culture of Open Source**: This concentration of high-scoring contributors suggests that Next.js has cultivated a culture that not only values open source contributions but actively encourages impactful engagement with the broader community.
- **Ripple Effects**: The influence of these top contributors likely extends beyond Vercel's projects. Their high OSCR scores indicate they're making waves across the open source ecosystem, contributing to a wide range of projects and discussions.
- **Attracting Talent**: Such a concentration of top contributors can create a snowball effect, attracting other talented developers who want to work alongside the best in the field.
- **Industry Leadership**: This data point cements Vercel's position as a leader not just in their product offerings, but in their approach to open source collaboration and community building.

For other companies and projects, Next.js's contributor profile serves as both an inspiration and a challenge. It raises important questions:

1. How can we create an environment that encourages this level of open source engagement?
2. What can we learn from Next.js's approach to attracting and retaining high-impact contributors?
3. How might this level of open source engagement translate to product quality, innovation, and community trust?

By understanding and valuing these high-impact contributors, measured not just in lines of code but in their broader influence across open source, we gain a new perspective on what it means to be a leader in open source. 

## The Ecosystem Perspective: Why Your Contributors' Outside Work Matters

When we talk about open source contributors, it's easy to focus solely on their work within our own projects. But this view misses a key point: the open source world is an interconnected ecosystem, and understanding your contributors' impact across this ecosystem can be just as valuable as tracking their contributions to your project.

### Why should we care about our contributors' work beyond our repository?

1. **Cross-Pollination of Ideas**:
      Contributors active in multiple projects can bring fresh perspectives and interesting solutions. They've seen problems solved in different ways and can apply that knowledge to your project. By recognizing their broader contributions, you're tapping into a wealth of diverse experiences.
2. **Community Connections**:
      High-impact contributors often have larger networks in the open source world. Their connections can lead to valuable collaborations, increased project visibility, and a broader pool of potential contributors. A contributor might play a minor role in your project but be a major influencer in a related technology. Understanding their broader impact helps you leverage their expertise more effectively.
3. **Predicting Long-Term Commitment**:
      Contributors who are deeply engaged in the open source ecosystem are often more likely to remain committed to open source work long-term, potentially leading to more sustained contributions to your project.
4. **Reputation by Association**:
      Having well-respected open source contributors associated with your project can enhance its credibility and attract more attention from the wider community.    
5. ** Ecosystem Health**:
      By valuing and recognizing broader contributions, you're encouraging a healthier open source ecosystem overall, which ultimately benefits all projects, including yours.  Understanding the diverse contributions of your community members opens up opportunities for mutual learning and mentorship within your project.

Consider the case of a contributor who infrequently commits to your project but has a high OSCR score. This person might be a key maintainer of a critical dependency, an influential voice in relevant technical discussions, or a mentor to new contributors. Their seemingly small contributions to your project might be a small part of the story of their open source impact.

By adopting this ecosystem perspective, we shift from a transactional view of contributions to a more holistic understanding of value. It's not just about what a contributor does for your project, but how their involvement in your project fits into their broader open source story – and how that story enriches your project's journey.

This approach allows for a more interconnected, collaborative open source community. It encourages projects to see themselves not as isolated entities, but as part of a larger, interdependent ecosystem.

Here's my challenge to you: Take a fresh look at your project's contributors. Who are the unsung heroes? Whose contributions, beyond code, are making a real difference? And in the projects you depend on, who are the key contributors you might consider supporting?

Want to explore more projects and contributors? Check out these other projects on OpenSauced:

- [Nuxt](https://app.opensauced.pizza/s/nuxt/nuxt/contributors?range=30&display=list)
- [React](https://app.opensauced.pizza/s/facebook/react/contributors?range=30&display=list)
- [Vue](https://app.opensauced.pizza/s/vuejs/vue/contributors?range=30&display=list)
- [Astro](https://app.opensauced.pizza/s/withastro/astro/contributors?range=30&display=list)
- [laravel](https://app.opensauced.pizza/s/laravel/laravel/contributors?range=30&display=list)

Or explore the [top 5% of all OSCRs](https://oss.fyi/oscr-top-5) across the entire open source ecosystem.


Unlock the full potential of your open source community by understanding and valuing well-rounded contributors. Learn how the OSCR can highlight unseen impacts.

Unseen Impact: A Holistic View of Open Source Contributions

A while back, I came across this [LinkedIn post](https://www.linkedin.com/posts/ashvardanian_opensource-python-rust-activity-7157617068287086592-yne-?utm_source=share&utm_medium=member_desktop).


![LI post: nice to be recognized (as trending in GH)](https://cdn.sanity.io/images/r7m53vrk/production/83db114c192452286eebc49573df3ee4df02d79a-978x234.png?w=1080)


It got me thinking about ranking and trending in open source. If you don't have a reference for how you're doing, how can you measure your growth or understand *why* you're trending?

Progress can often feel intangible. Contributors pour hours into projects, submitting pull requests, reviewing code, and engaging in discussions, but how can they truly measure their growth and impact? This question isn't just about personal satisfaction – it's about understanding the value we bring to the community and identifying areas for improvement.

## #100DaysOfOSS: A Journey of Growth

Every day, we hear from people who want to make an impact in open source but don't know where to start. They ask, "How can I contribute?" and "How will my contributions matter?" These are tough questions, especially when you're just starting out. Last week, we started off our [#100DaysOfOSS Challenge](https://github.com/orgs/open-sauced/discussions/36) to help answer these questions and guide you through your open source journey. 

[![image](https://cdn.sanity.io/images/r7m53vrk/production/5d6af8819a35dba6f2a61b4feca29cf0ac641d1d-1446x262.png?w=1080)](https://dev.to/rafaeljohn9/comment/2h5mh)

The #100DaysOfOSS Challenge is a structured way to dive into open source, with weekly tasks designed to help contributors learn, connect, and contribute in meaningful ways--[we'll never promote drive-by contributions or practices that put stress on maintainers](https://opensauced.pizza/blog/stop-burning-out-maintainers:-an-empathetic-guide-for-contributors). We want to see contributors grow and make progress, not just check off boxes.

It's not about coding for 100 days straight. It's about understanding the power of community to transform hesitation into action. Progress isn't just about lines of code or number of commits. It's both about quantifiable metrics and personal narratives. And a big part of this transformation? Tracking your progress.

## The Dual Approach: Numbers and Narratives

To have a better understanding of progress in open source, we need to embrace a dual approach: quantitative metrics and qualitative narratives. Each offers unique insights that, when combined, provide a comprehensive view of a contributor's journey.

### Why does tracking open source contributions matter?

What gets measured, gets improved. When you can see your contributions adding up, when you can quantify your growing influence in the community, it becomes a powerful motivator. At the end of #100DaysOfOSS or whatever period of time you're tracking, you should have a tangible way to see how far you've come *and* you should have a story to tell about what you did to get there.

### Quantitative Metrics: The Power of Numbers

Metrics like the OSCR (Open Source Contributor Rating) [offer a tangible way to track contribution impact, quality, and influence](https://opensauced.pizza/blog/introducing-OSCR). The OSCR is a metric developed by OpenSauced to quantify a contributor's impact and engagement in open source projects by looking at PRs, your engagement in discussions, issues, and more, and looking at the frequency you contribute. It's a metric that goes beyond simple contribution counts, factoring in your overall influence and impact in the open source ecosystem.

By regularly checking these metrics, contributors can:

- Set baselines and track improvements over time
- Identify trends in their contribution patterns
- Set concrete goals for improvement
- Celebrate quantifiable milestones

Here's the crucial part: while the OSCR score provides a tangible measure of growth, it's only half the story.

## Qualitative Narratives: The Human Element

When you combine your numbers with personal narratives you bring your contributions to life, showing the learning, the connections made, the challenges overcome.

### Example: Brian's Story

Imagine Sarah, a new contributor participating in #100DaysOfOSS. On day one of the challenge, her OSCR score is 10. By day 50, it's risen to 35. That's impressive growth, but what does it really mean?

This is where the storytelling becomes important. In [Introducing the OSCR](https://oss.fyi/oscr) we shared both Luca and Tyler's stories. 
Your story, if you're a beginner might be something more like [@bdougie's](https://app.opensauced.pizza/u/bdougie/) that he shared on [this episode of The Secret Sauce](https://www.youtube.com/watch?v=IjujjSU_cOA&list=PLHyZ0Wz_A44VR4BXl_JOWSecQeWcZ-kS3&index=35): 

"[W]hen I first did my first contribution to open source project, I actually emailed the maintainer the same way this person did to me because I didn't know how to use GitHub. I had an account. I found the repo, but I didn't know about issues because at the company I worked for, my first junior developer job, we use JIRA for everything. Like everything, everything. So I never opened up issues. And I was like, Oh, issues. Oh, I've heard about these." 

bdougie's story would continue to reveal his growth at Netlify, then on the GitHub DevRel team, and eventually founding OpenSauced. It didn't happen overnight. He had to learn to write an issue first. Hearing that story connects us to his journey and growth. 

![bdougies devcard](https://cdn.sanity.io/images/r7m53vrk/production/a19db58ad9330a674a1c4d9423a4bf69fe9a70ed-358x484.png?w=1080)

With this much experience, you might ask why his OSCR score isn't higher. That's part of the story. As the founder of OpenSauced, he spends less time on coding, interacting in GitHub, and day-to-day repository-level tasks, and more time focusing on CEO responsibilities. 

See the difference? The numbers show contributions, but the story paints the full picture. 

## Why This Matters: Strengthening the Open Source Ecosystem

The dual approach of tracking progress through numbers and narratives isn't just about individual growth – it's a tool for strengthening the entire open source ecosystem. Here's why this approach is so impactful:

- **Motivation and Retention**: Seeing tangible progress, both in numbers and personal growth stories, encourages contributors to stay engaged long-term. The OSCR score provides a concrete measure of growth, while narratives offer a sense of achievement that numbers alone can't capture.
- **Community Health and Connection**: When individuals can share their value through both data and stories, it leads to more meaningful recognition and a healthier, more supportive community. Sharing both metrics and narratives can inspire others, creating a sense of belonging and creating a culture of continuous improvement.
- **Project Improvement**: Understanding individual and collective progress through metrics helps project maintainers make informed decisions about project direction and resource allocation. Complementing this with narrative insights provides context and depth to these decisions.
- **Career Advancement**: In professional settings, such as job interviews, contributors can present both data (like OSCR scores) and anecdotes to demonstrate their open source experience comprehensively. This dual approach offers a powerful narrative for career development.
- **Holistic Progress Tracking**: While metrics provide a quick snapshot of growth, narratives fill in the gaps, explaining the 'how' and 'why' behind the numbers. This combination offers a more complete picture of a contributor's journey and impact.

Progress is gradual. OSCR scores won't skyrocket overnight - in fact, they are on a rolling 90-day basis - and that's okay. Tracking work and OSCRs isn't about comparing yourself to others when you're learning. It's about tracking your own growth and telling your unique story.

## Join the Journey

Open source thrives because of people like you - people willing to learn, to contribute, to share. Your contributions, no matter how small they might seem, make a difference.

So, are you ready to start learn what your OSCR score is? Head over to your profile page and share your DevCard today or check [mine](https://app.opensauced.pizza/u/bekahhw) out to see what they look like.

Remember, open source contribution is about quality over quantity. A small increase in your OSCR could represent significant learning and growth on your part. It's not just about the number, but the skills and connections you're building along the way.

Explore the dual power of metrics and storytelling in open source contribution. Learn how tracking numbers and crafting narratives together can help you identify your progress, showcase your impact, and grow within the open source community.

Numbers and Narratives: The Dual Power of Tracking Your Open Source Journey

In the 1920s, Louis B. Mayer, co-founder of Metro-Goldwyn-Mayer (MGM), envisioned the Academy Awards - also know as the Oscars -  as a way to recognize excellence and achievements in Hollywood, and encourage higher standards in the production and presentation of motion pictures. Mayer played a key role in establishing the Academy of Motion Picture Arts and Sciences (AMPAS) and launching the first Academy Awards ceremony on May 16, 1929 at the Hollywood Roosevelt Hotel. It wasn't just a glitzy affair; it was a paradigm shift in how we recognize and value creative work. 

Today, open source stands at a similar crossroads. Enter the OSCR - the Open Source Contributor Rating - our attempt at OpenSauced to rethink how we value contributions today.

But let's be clear: OSCR isn't just another vanity metric. It's a provocation to an industry that's often complacent in its approach to recognition. Just as the Oscars shine a light on the best in film, our OSCRs will spotlight the top and upcoming contributors in the open source community.


## What is the OSCR?

The OSCR is a rating system that evaluates a contributor's engagement, influence, and impact across the entire open source ecosystem. But it's not just about counting commits or pull requests. The OSCR looks at the quality of contributions, the sway a contributor holds in discussions, and their overall impact on projects.

Calculated on a rolling 90-day basis, OSCR provides a current snapshot of a contributor's involvement and quantifies them based on a total of 300 points. It's not about lifetime achievements; it's about what you're doing *now* in open source.

You might argue that quantifying contributions could lead to a new form of elitism in open source. You're not entirely wrong. Any system of measurement can be gamed or misused. But the alternative - the status quo of overlooking critical work - is worse. It's driving maintainers to burnout and new contributors away from the community.

Others will say that open source should be about passion, not recognition. To them, I ask: why not both? As I explored in [The Need for Recognition in Open Source](https://opensauced.pizza/blog/the-need-for-recognition-in-open-source), recognition isn't just a feel-good factor; it's a fundamental human need. Ignoring this is not just naive; it's detrimental to the health of the open source ecosystem.


## The OSCR in Action

Let's be clear: the OSCR is a number, but it's not *just* a number. It's a conversation starter, a spotlight, and sometimes, a reality check. But here's the thing - behind every OSCR, there's a story. And that story is just as important as the number itself.

Let's pull back the curtain on two contributors with different OSCR scores. But remember, we're not just looking at the score here - we're getting into the complex reality of open source contribution.

### High OSCR: The Well-Rounded Contributor (Score: 297/300)


Meet [Luca Forst](https://app.opensauced.pizza/u/lforst). With an OSCR of 297 out of 300, Luca is an open source powerhouse. But what's the story behind his score?

![Lforst devCard](https://cdn.sanity.io/images/r7m53vrk/production/4a5bc639368b7ee630f6a1bc3e5fa8781b153fd2-249x338.png?w=450)

If we check out Luca's profile we see deep, multifaceted engagement. There's a solid chart of Pull Requests - 60 PRs opened across 9 different repositories in just 30 days. But here's where it gets interesting: Luca isn't just pushing code and walking away.

![gif of luca's profile](https://cdn.sanity.io/images/r7m53vrk/production/f37ecf7a480daea75f57a6e39d0f041483947495-1300x720.gif?w=450)

The abundance of issue comments on Luca's profile shows a contributor who's deeply involved in the development process. He's not just coding in isolation; he's actively participating in discussions, clarifying points for others, and helping to shape the direction of the projects he's involved in.

This combination of quality code contributions and community sway is what pushes Luca's OSCR so high. He's demonstrating that open source isn't just about committing code - it's about committing to the project and its community.

Luca's story reminds us that the highest OSCR scores often belong to those who understand that open source is a collaborative effort. They're not just writing code; they're influencing the development of software through their interactions and engagement.

When I talked to Luca about what made a good open source contribution, he said, 

> "It's not hard to make meaningful contributions to open source! Contributions don't even have to be in the form of code. A thoughtful consideration for an API change, a bug investigation, or simply a new perspective on a discussion are all super valid and helpful. If you coherently articulate your thought process, you’re contributing to the success of the project."


### The Impactful Maintainer (OSCR: 68/300)

Now, let's look at [Tyler](https://app.opensauced.pizza/u/coolsoftwaretyler), a maintainer of [mobx-state-tree](https://app.opensauced.pizza/s/mobxjs/mobx-state-tree?hideBots=false&range=90). With an OSCR of 68, you might assume Tyler's not making a big open source impact. But hold that thought – this is where the story behind the score becomes important.

![Tyler's profile](https://cdn.sanity.io/images/r7m53vrk/production/fe9ebdcad5ce2ea7e8568b823ffb4af513198945-1103x467.png?w=450)

Tyler's low OSCR doesn't expose some of the behind-the-scenes work happening in the project. As Tyler explains, "We haven't merged a PR for a while, but our internal maintainer discord has been busier this month than the whole year. We even brought on a new maintainer."

This shows a disconnect between public activity and private effort. Tyler's work isn't showing up in commit logs or public discussions, but it's happening in private channels, shaping the future of the project.

There are other factors at play too:

- Project Maturity: mobx-state-tree is a stable, established library. It doesn't need constant updates or changes, which can affect Tyler's OSCR.
- Seasonal Demands: Tyler's day job in the NFL industry means August-October is his busy season, affecting his open source availability.

Tyler's story is a reminder that the OSCR, like any metric, is part of the story. A lower score doesn't always mean less value; it might indicate a shift in focus or responsibilities. It's a call to look at the numbers while understanding the context behind them.

## Why OSCR Matters

For too long, we've [reduced open source contributions to a game of green squares on GitHub](https://opensauced.pizza/blog/hacktoberfest-2023-beyond-green-squares). We've celebrated code commits while ignoring the investment contributors make in projects, the sway they have in conversations, and the quality of their contributions. 

The OSCR is more than just a rating system. It's a call to action. It's asking us to reimagine what open source could be if we valued commitment, sway, and quality as much as commits.

We know the current open source system is failing those who give most to the community (see [The Lonely Journey of Open Source Maintainers](https://opensauced.pizza/blog/the-lonely-journey-of-open-source-maintainers)). We want to change that narrative.

## Join the OSCR Conversation

Now, we want to hear from you. Your OSCR is more than just a number – it's a story of your open source journey. We invite you to share your OSCR and the story behind it.

- What does your OSCR say about your open source contributions?
- How does it reflect (or not reflect) your experience in open source?
- What has been your most impactful contribution, and how did it shape your journey?

Share your OSCR and your story and tag us so we can continue the conversation about the multifaceted nature of open source contributions and how we can better recognize and value them.

By sharing your story, you're not just talking about yourself – you're contributing to a broader dialogue about recognition in open source and helping shape the future of how we value contributions in our community.

## Last Thoughts

The way we recognize and value contributions needs to evolve. The OSCR is our proposal for that evolution, but it's just the beginning.

So, here's our challenge to the open source community: Engage with OSCR. [Give us feedback](https://github.com/orgs/open-sauced/discussions/categories/general-feedback-or-bugs). Tell us how you'd use it or what would make it more valuable to you. Help us refine and improve the system. Use it as a starting point to have the difficult conversations we've been avoiding about value, recognition, and the future of open source.

Because one thing is clear: the status quo isn't working. It's time for open source to have its own Academy Awards moment. 

Introducing OSCR: The new standard for measuring open source contributions. Explore how this new metric goes beyond code commits to measure true impact in the open source ecosystem.

Introducing the OSCR: Celebrating Open Source Stars

[We recently released integrations with the OpenSSF Scorecard](https://opensauced.pizza/blog/introducing-openssf-scorecard-for-opensauced) on the OpenSauced platform. The OpenSSF Scorecard is a powerful Go command line interface that anyone can use to begin understanding the security posture of their projects and dependencies. It runs several checks for dangerous workflows, CICD best practices, if the project is still maintained, and much more. This enables software builders and consumers to understand their overall security picture, deduce if a project is safe to use, and where improvements to security practices need to be made.

But one of our goals with integrating the OpenSSF Scorecard into the OpenSauced platform was to make this available to the broader open source ecosystem at large. If it’s a repository on GitHub, we wanted to be able to display a score for it. This meant scaling the Scorecard CLI to target nearly any repository on GitHub. Much easier said than done!

In this blog post, let’s dive into how we did that using Kubernetes and what technical decisions we made with implementing this integration.

We knew that we would need to build a cron type microservice that would frequently update scores across a myriad of repositories: the true question was how we would do that. It wouldn’t make sense to run the scorecard CLI ad-hoc: the platform could too easily get overwhelmed and we wanted to be able to do deeper analysis on scores across the open source ecosystem, even if the OpenSauced repo page hasn’t been visited recently. Initially, we looked at using the Scorecard Go library as direct dependent code and running scorecard checks within a single, monolithic microservice. We also considered using serverless jobs to run one off scorecard containers that would give back the results for individual repositories.

The approach we ended up landing on, which marries simplicity, flexibility, and power, is to use Kubernetes Jobs at scale, all managed by a “scheduler” Kubernetes controller microservice. Instead of building a deeper code integration with scorecard, running one off Kubernetes Jobs gives us the same benefits of using a serverless approach, but with reduced cost since we’re managing it all directly on our Kubernetes cluster. Jobs also offer alot of flexibility in how they run: they can have long, extended timeouts, they can use disk, and like any other Kubernetes paradigm, they can have multiple pods doing different tasks. 

Let’s break down the individual components of this system and see how they work in depth:

The first and biggest part of this system is the “scorecard-k8s-scheduler”; a Kubernetes controller-like microservice that kicks off new jobs on-cluster. While this microservice follows many of the principles, patterns, and methods used when [building a traditional Kubernetes controller or operator](https://kubernetes.io/docs/concepts/architecture/controller/), it does not watch for or mutate custom resources on the cluster. Its function is to simply kick off Kubernetes Jobs that run the Scorecard CLI and gather finished job results.

Let’s look first at the main control loop in the Go code. This microservice uses the Kubernetes Client-Go library to interface directly with the cluster the microservice is running on: this is often referred to as an on-cluster config and client. Within the code, after bootstrapping the on-cluster client, we poll for repositories in our database that need updating. Once some repos are found, we kick off Kubernetes jobs on individual worker “threads” that will wait for each job to finish.

```go
// buffered channel, sort of like semaphores, for threaded working
sem := make(chan bool, numConcurrentJobs)

// continuous control loop
for {
    // blocks on getting semaphore off buffered channel
    sem <- true

    go func() {
        // release the hold on the channel for this Go routine when done
        defer func() {
            <-sem
        }()

        // grab repo needing update, start scorecard Kubernetes Job on-cluster,
        // wait for results, etc. etc.

        // sleep the configured amount of time to relieve backpressure
        time.Sleep(backoff)
    }()
}
```

This “infinite control loop” method, with a buffered channel, is a common way in Go to continuously do something but only using a configured number of threads. The number of concurrent Go funcs that are running at any one given time depends on what configured value the “numConcurrentJobs” variable has. This sets up the buffered channel to act as a worker pool or semaphore which denotes the number of concurrent Go funcs running at any one given time. Since the buffered channel is a shared resource that all threads can use and inspect, I often like to think of this as a semaphore: a resource, much like a mutex, that multiple threads can attempt to lock on and access. In our production environment, we’ve scaled the number of threads in this scheduler all running at once. Since the actual scheduler isn’t very computationally heavy and will just kick off jobs and wait for results to eventually surface, we can push the envelope of what this scheduler can manage. We also have a built-in backoff system that attempts to relieve pressure when needed: this system will increment the configured “backoff” value if there are errors or if there are no repos found to go calculate the score for. This ensures we’re not continuously slamming our database with queries and the scorecard scheduler itself can remain in a “waiting” state, not taking up precious compute resources on the cluster.

Within the control loop, we do a few things: first, we query our database for repositories needing their scorecard updated. This is a simple database query that is based on some timestamp metadata we watch for and have indexes on. Once a configured amount of time passes since the last score was calculated for a repo, it will bubble up to be crunched by a Kubernetes Job running the Scorecard CLI.

Next, once we have a repo to get the score for, we kick off a Kubernetes Job using the “gcr.io/openssf/scorecard” image. Bootstrapping this job in Go code using Client-Go looks very similar to how it would look with yaml, just using the various libraries and apis available via “k8s.io” imports and doing it programmatically:

```go
// defines the Kubernetes Job and its spec
job := &batchv1.Job{
	// structs and details for the actual Job
	// including metav1.ObjectMeta and batchv1.JobSpec
}

// create the actual Job on cluster
// using the in-cluster config and client
return s.clientset.BatchV1().Jobs(ScorecardNamespace).Create(ctx, job, metav1.CreateOptions{})
```

After the job is created, we wait for it to signal it has completed or errored. Much like with kubectl, Client-Go offers a helpful way to “watch” resources and observe their state when they change:

```
// watch selector for the job name on cluster
watch, err := s.clientset.BatchV1().Jobs(ScorecardNamespace).Watch(ctx, metav1.ListOptions{
    FieldSelector: "metadata.name=" + jobName,
})

// continuously pop off the watch results channel for job status
for event := range watch.ResultChan() {
    	// wait for job success, error, or other states
}
```

Finally, once we have a successful job completion, we can grab the results from the Job’s pod logs which will have the actual json results from the scorecard CLI! Once we have those results, we can upsert the scores back into the database and mutate any necessary metadata to signal to our other microservices or the OpenSauced API that there’s a new score!

As mentioned before, the scorecard-k8s-scheduler can have any number of concurrent jobs running at once: in our production setting we have a large number of jobs running at once, all managed by this microservice. The intent is to be able to update scores every 2 weeks across all repositories on GitHub. With this kind of scale, we hope to be able to provide powerful tooling and insights to any open source maintainer or consumer!

The “scheduler” microservice ends up being a small part of this whole system: anyone familiar with Kubernetes controllers knows that there are additional pieces of Kubernetes infrastructure that are needed to make the system work. In our case, we needed some role-based access control (RBAC) to enable our microservice to create Jobs on the cluster.

First, we need a service account: this is the account that will be used by the scheduler and have access controls bound to it:

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: scorecard-sa
  namespace: scorecard-ns
```

We place this service account in our “scorecard-ns” namespace where all this runs.

Next, we need to have a role and role binding for the service account. This includes the actual access controls (including being able to create Jobs, view pod logs, etc.)

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: scorecard-scheduler-role
  namespace: scorecard-ns
rules:
- apiGroups: ["batch"]
  resources: ["jobs"]
  verbs: ["create", "delete", "get", "list", "watch", "patch", "update"]
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

—

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: scorecard-scheduler-role-binding
  namespace: scorecard-ns
subjects:
- kind: ServiceAccount
  name: scorecard-sa
  namespace: scorecard-ns
roleRef:
  kind: Role
  name: scorecard-scheduler-role
  apiGroup: rbac.authorization.k8s.io
```

You might be asking yourself “Why do I need to give this service account access to get pods and pod logs? Isn’t that an over extension of the access controls?” Remember! Jobs have pods and in order to get the pod logs that have the actual results of the scorecard CLI, we must be able to list the pods from a job and then read their logs!

The second part of this, the “RoleBinding”, is where we actually attach the Role to the service account. This service account can then be used when kicking off new jobs on the cluster.

—

Huge shout out to [Alex Ellis](https://github.com/alexellis) and his excellent [run-job](https://github.com/alexellis/run-job) controller: this was a huge inspiration and reference for correctly using Client-Go with Jobs!

Stay saucy everyone!

Learn how the OpenSauced engineering team built Kubernetes infrastructure to scale the OpenSSF Scorecard for all GitHub repositories

How we use Kubernetes jobs to scale OpenSSF Scorecard


In 2006, Graydon Hoare, a 29-year-old programmer at Mozilla, opened his laptop and began designing a new computer language. His goal: to make it possible to write small, fast code without the memory bugs that plague languages like C and C++, the lead to many software crashes. He named it [Rust](https://app.opensauced.pizza/s/rust-lang/rust).

Fast forward to today. Rust has become a programming phenomenon, ranking as the "most loved" language in Stack Overflow's developer survey for seven years running (as of 2023). But Hoare didn't do it alone. It was the result of thousands of contributors worldwide, each bringing their unique perspectives, use cases, and new ideas to the table. 

When Mozilla sponsored and open sourced Rust in 2009, the project rapidly evolved through contributions from developers worldwide.
Its welcoming culture, combined with Rust's technical innovations, created a perfect situation for open source success.

But Rust's success wasn't inevitable. Its ascent was fueled by a perfect alchemy of technical innovation and community engagement. The Rust team created an environment where contributions were valued and new contributors were welcomed. 

This approach created a positive feedback loop: more contributors led to better documentation and tooling, which in turn attracted more contributors.


## Comparing Open Source Approaches: TypeScript vs. Kubernetes

### The TypeScript Paradox: Controlled Evolution in an Open Source World

Not all successful open source projects follow Rust's wide-open approach. Consider [TypeScript](https://app.opensauced.pizza/s/microsoft/typescript?range=360), Microsoft's strongly-typed superset of JavaScript. TypeScript has become an essential part of how the modern web is built. but its development model stands in contrast to Rust's.

Microsoft maintains tight control over TypeScript's core design. While the project is open source and accepts community contributions, major decisions are typically made internally. 

This approach has advantages: it ensures a consistent vision and allows for rapid, coordinated evolution of the language.

But it also has drawbacks. TypeScript's more controlled model means it might miss out on innovations that come from a more diverse contributor base. It's a trade-off between consistency and the potential for unexpected breakthroughs. We can see in the last year, they've had only 125 outside contributors.

[![contributor graph](https://cdn.sanity.io/images/r7m53vrk/production/63731b60c137eaef7c953188cf6c6c64955e7503-1884x500.png?w=450)](https://app.opensauced.pizza/s/microsoft/TypeScript?range=360&hideBots=false)

Despite these limitations, TypeScript's success is undeniable. Its adoption has skyrocketed, and it's become the de facto standard for large-scale JavaScript projects. 

### Kubernetes: The Art of Scaling Community

If Rust represents the power of community-driven development and TypeScript showcases the strengths of controlled evolution, [Kubernetes](https://app.opensauced.pizza/s/kubernetes/kubernetes?hideBots=false&range=360) exemplifies how to scale an open source community.

Created inside Google but now under the Cloud Native Computing Foundation, Kubernetes has grown from a container orchestration tool into a comprehensive platform for cloud-native computing. Its success stems from an ability to balance rapid growth with stability, and to coordinate contributions from a vast, diverse community.

In the last year, we can continue to see this reflected with 870 outside contributors.

[![contributor chart](https://cdn.sanity.io/images/r7m53vrk/production/3d1296ac6408f95f9389c99865cf099c76b22ada-1886x490.png?w=450)](https://app.opensauced.pizza/s/kubernetes/kubernetes?hideBots=false&range=360)

Kubernetes has a system of special interest groups (SIGs) to focus development efforts, while a steering committee ensures overall coherence. This structure allows for both specialized innovation and overall consistency.


As more people started using Kubernetes, they also built tools for it, making Kubernetes even more useful. This created a positive loop: more users led to more tools, which led to even more users. It's not just a project; it's a platform that enables thousands of developers to build and share their own tools.

## The Self-Selection Factor: The Hidden Engine of Open Source

Underlying these success stories is something we need to talk about: the rate of self-selection. This open source metric measures how eagerly and frequently developers choose to contribute to a project voluntarily.

A high rate of self-selection can be a strong indication of a thriving open source project. It brings in fresh perspectives, drives innovation, and ensures the project's longevity beyond its original creators. But cultivating this isn't just about opening up a GitHub repository and hoping for the best.

Successful projects create an environment that not only allows for contribution but actively encourages it. They provide clear documentation, maintain welcoming communication channels, and find ways to encourage new contributors. 

They often celebrate and recognize contributions, and create an environment that allows for a sense of ownership and community.

The impact of self-selection varies across our projects. Rust and Kubernetes have high rates, fueling their rapid evolution and diverse ecosystems. TypeScript, with its more controlled approach, has a lower but still significant rate, attracting deeply invested contributors from the JavaScript community.

## The Impact of Different Open Source Strategies

The contrasting approaches of TypeScript and Kubernetes reveal several key differences in open source development. While these differences highlight various aspects of project health, it's important to remember that no single metric tells the whole story. Let's explore some of these factors:

1. Innovation Velocity: Diverse contributor bases can lead to rapid adaptation and innovation, while a controlled approach may move at a more measured pace. However, a more measured pace may allow for more thorough vetting of changes, potentially leading to fewer breaking changes.
2. Ecosystem Growth: A thriving ecosystem means developers are creating a wide range of add-ons and complementary software that work with the main project. A strong ecosystem can be an indicator of a project's health and adoption.
3. Project Sustainability: Distributed leadership and/or contributions ensures a projects continuity even if key contributors leave, creating a low [lottery factor](https://opensauced.pizza/docs/welcome/glossary/#lottery-factor). Specifically, we see this reflected in kubernetes:

[![kubernetes lottery factor](https://cdn.sanity.io/images/r7m53vrk/production/eb626b1b3fb5373316fa4c4b71221de7f3b439b9-924x774.png?w=450)](https://app.opensauced.pizza/s/kubernetes/kubernetes?hideBots=false&range=360)


## The Rate of Self-Selection: One Open Source Metric Among Many

Among these factors, the "rate of self-selection" - how eagerly and frequently developers choose to contribute to a project voluntarily - is one important metric to consider. Here's why it matters:

1. It can indicate a project's attractiveness to developers.
2. It often brings in fresh perspectives and innovations.
3. It can contribute to a project's long-term sustainability.
4. It tends to increase the diversity of skills in the project.
5. It often correlates with a strong, engaged community.

It's always worth noting that a high rate of self-selection doesn't automatically mean a project is healthy or successful. TypeScript, for instance, has a moderate rate of self-selection but is highly successful and influential. It attracts fewer but often high-quality contributions from developers deeply invested in improving the JavaScript ecosystem.

## Last Thoughts

What works for one project may not work for another. The goal should be to create an environment where good ideas can flourish. As we look to the future of open source, the projects that will thrive are those that can balance innovation with stability, individual brilliance with collective wisdom, and technical excellence with community engagement. They'll be the ones that not only write great code but also build bridges between developers, contributors, companies, and communities.

In open source, every contribution is a catalyst, every pull request a possibility. As we continue to see contributions, who knows what digital gold we might create next?

Discover how open source projects like Rust and Kubernetes thrive through community contributions, while others like TypeScript take a different approach. Learn the key factors in successful open source development.

Open Source Alchemy: How Open Source Community Contributions Turn Code into Gold

In September of 2022, the European Parliament introduced the [“Cyber Resilience Act”](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act), commonly called the CRA: a new piece of legislation that requires anyone providing digital products in the EU to meet certain security and compliance requirements.

But there’s a catch: before the CRA, companies providing or distributing software would often need to take on much of the risk when ensuring safe and reliable software was being shipped to end users. Now, software maintainers further down the supply chain will have to carry more of that weight. Not only may certain open source maintainers need to meet certain requirements, but they may have to provide an up to date security profile of their project.

[As the Linux Foundation puts it](https://www.linuxfoundation.org/blog/understanding-the-cyber-resilience-act):

> "The Act shifts much of the security burden onto those who develop software, as opposed to the users of software. This can be justified by two assumptions: first, software developers know best how to mitigate vulnerabilities and distribute patches; and second, it’s easier to mitigate vulnerabilities at the source than requiring users to do so."

There’s a lot to unpack in the CRA. And it’s still not clear how individual open source projects, maintainers, foundations, or companies will be directly impacted. But, it’s clear that the broader open source ecosystem needs easier ways to understand the security risk of projects deep within dependency chains. With all that in mind, we are very excited to introduce the OpenSSF Scorecard ratings within the OpenSauced platform. 

## What is the OpenSSF Scorecard?

The OpenSSF is [the Open Source Security Foundation](https://openssf.org/): a multidisciplinary group of software developers, industry leaders, security professionals, researchers, and government liaisons. The OpenSSF aims to enable the broader open source ecosystem “to secure open source software for the greater public good.” They interface with critical personnel across the software industry to fight for a safer technological future.

[The OpenSSF Scorecard project](https://github.com/ossf/scorecard) is an effort to unify what best practices open source maintainers and consumers should use to judge if their code, practices, and dependencies are safe. Ultimately, the “scorecard” command line interface gives any the capability to inspect repositories, run “checks” against those repos, and derive an overall score for the risk profile of that project. It’s a very powerful software tool that gives you a general picture of where a piece of software is considered risky. It can also be a great starting point for any open source maintainer to develop better practices and find out where they may need to make improvements. By providing a standardized approach to assessing open source security and compliance, the Scorecard helps organizations more easily identify supply chain risks and regulatory requirements.

## OpenSauced OpenOSSF Scorecards

Using the scorecard command line interface as a cornerstone, we’ve built infrastructure and tooling to enable OpenSauced to capture scores for nearly all repositories on GitHub. Anything over a 6 or a 7 is generally considered safe to use with no blaring issues. Scores of 9 or 10 are doing phenomenally well. And projects with lower scores should be inspected closely to understand what’s gone wrong.

Scorecards are enabled across all repositories. With this integration, we aim to make it easier for software maintainers to understand the security posture of their project and for software consumers to be assured that their dependencies are safe to use.

Starting today, you can see the score for any project within individual [Repository Pages](https://opensauced.pizza/docs/features/repo-pages/). For example, in [kubernetes/kubernetes](https://app.opensauced.pizza/s/ kubernetes/kubernetes), we can see the project is safe for use:

![image](https://gist.github.com/user-attachments/assets/268078b3-4315-4354-a98b-835660f30023)

Let’s look at another example: [crossplane/crossplane](https://app.opensauced.pizza/s/crossplane/crossplane). These maintainers are doing an awesome job of ensuring they are following best practices for open source security and compliance!!

![image](https://gist.github.com/user-attachments/assets/c9c6c47c-ab2e-40e4-b884-4bd330f2c72e)

The checks that the OpenSSF Scorecard looks for involves a wide range of common open source security practices, both “in code” and with the maintenance of the project: e.g. checking for code review best practices, if there are “dangerous workflows” present (like untrusted code being run and checked out during CI/CD runs), if the project is actively maintained, the use of signed releases, and many more.

## The Future of OpenSSF Scorecards at OpenSauced

We plan to bring the OpenSSF Scorecard to more of the OpenSauced platform, as we aim to be the definitive place for open source security and compliance for maintainers and consumers. As part of that, we’ll be bringing more details to the OpenSSF Scorecard with how individual checks are ranked:

![image](https://cdn.sanity.io/images/r7m53vrk/production/c2362e76a4d6f9a2beb5f3628ad38e381ed70f2d-808x790.png?w=450)

We’ll also be bringing OpenSSF Scorecard to our premium offering, [Workspaces](https://opensauced.pizza/docs/features/workspaces/):

![image](https://gist.github.com/user-attachments/assets/c3f16287-ada5-4354-ac3f-532f1a7dbf1e)

Within a Workspace, you’ll soon be able to get an idea of how each of the projects you are tracking stack up alongside each other's score for open source security and compliance. You can use the OpenSSF Score together with all the Workspace insights and metrics, all in one single dashboard, to get a good idea of what’s happening within a set of repositories and what their security posture is. In this example, I’m tracking all the repositories within the bottlerocket-os org on GitHub, a security focused Linux based operating system: I can see that each of the repositories has a good rating which gives me greater confidence in the maintenance status and security posture of this ecosystem. This also enables stakeholders and maintainers of Bottlerocket to have a birds eye snapshot of the compliance and maintenance status of the  entire org.

As the CRA and similar regulations push more of the security burden onto developers, tools like the OpenSSF Scorecard become invaluable. They offer a standardized, accessible way to assess and improve the security of open source projects, helping maintainers meet new compliance requirements and giving software consumers confidence in their choices. 

Looking ahead, we're committed to expanding these capabilities at OpenSauced. By providing comprehensive security insights, from individual repository scores to organization-wide overviews in Workspaces, we're working to create a more secure and transparent open source ecosystem, to enable anyone in the open source community to better understand their software dependencies, feel empowered to make a meaningful change if needed, and provide helpful tools to open source maintainers to better maintain their projects.

Stay saucy!

Learn how OpenSauced integrates OpenSSF Scorecard to enhance open source security and compliance.

Introducing OpenSSF Scorecard for OpenSauced

I recently came across this post, and it got me thinking about open source in terms of compound interest - open source contributions can lead to exponential growth in project value, creating opportunities for growth and collaboration that transcend individual efforts. 

[![tweet about why meta is open sourcing llama](https://cdn.sanity.io/images/r7m53vrk/production/c5c573c5cef1b443439c022bee44fe5cbde5b3a7-786x328.png?w=450)](https://x.com/balajis/status/1815875704049000858)

Each contribution to an open source project, then, no matter how small, compounds over time. Let's think about this as an analogy to compound interest in finance, but instead of money, we're dealing with knowledge and connection.

Here's how it plays out:

- **Initial Contribution**: A developer contributes a piece of code or an idea (bug or feature issue).
- **Iteration**: Another contributor builds upon or refines this initial input. They might refine the code, optimize it for better performance, or extend its functionality.
- **Expansion and Integration**: Another contributor, building on the work of the first two, expands on their ideas or integrates them with other concepts. This step is about taking existing work and pushing it further, sometimes in ways the original contributors didn't anticipate.
- **Scale**: This process doesn't stop here – it repeats thousands of times across a global open source ecosystem. Each iteration builds on the collective knowledge and work of the community. A small UI fix might evolve into a comprehensive design system or even inspire new tools and libraries.
- **Cross-pollination**: As contributors work on different projects, ideas and solutions from one project influence another.

The result? We can move faster than if we rely solely on individual efforts. Even small contributions can have a significant impact over time, thanks to the compound effect of collaboration.

## The Numbers Behind the Network

To understand the scale of this effect, let's look at some open source metrics:

- The Linux kernel has had over 20,000 contributors since its creation.
- Each new [Linux](https://app.opensauced.pizza/s/torvalds/linux?hideBots=false&range=360) release typically has contributions from more than 1,000 developers.
- According to the [Linux Kernal Report from 2020](https://linuxclass.heinz.cmu.edu/doc/LinuxKernelReport_2020.pdf), "From 2007 to 2019, there were 780,048 commits accepted into the Linux kernel from 1730 organizations." That's close to averaging 90 organizations per year.

This diversity of contributors is key here. Research shows that more diverse contributor bases lead to more innovative outcomes, because each unique perspective adds a new perspective to problem-solving.


> "No matter who you are, most of the smartest people work for someone else." - Bill Joy, Co-founder of Sun Microsystems

## Cross-Pollination of Ideas

This compound knowledge effect isn't just additive — it's multiplicative. When ideas from different fields intersect, we often see breakthroughs that transcend their origins. A prime example is how GPU technology, initially developed for gaming, has become necessary for AI development and cryptocurrency mining.

## The Compound Interest of Open Source: Gains and Risks

Just as compound interest can rapidly grow wealth in finance, the compound effect in open source can lead to growth in project value. However, like any investment, open source projects can face challenges that mirror financial risks.

### Positive Compound Effect

When a project has a healthy, active community, the benefits compound:

- Each contribution builds on previous work
- New contributors bring fresh perspectives
- Cross-pollination of ideas leads to innovative solutions
- The project's value to the community grows 

We can look at open source metrics to better understand when this will happen.

### The Reverse Compound Effect

However, the compound effect works both ways. When contributions to a project slow down or stop entirely, we see a reverse compound effect:

- The project loses momentum
- It becomes outdated
- Eventually, it may become obsolete

This is similar to how inflation can erode the value of money that's not earning interest.

While having dedicated core contributors is valuable, an over-reliance on a small group can be risky for a project's long-term health - you don't want to have all your investments in one or two stocks; it leaves the project vulnerable to sudden changes or loss of these key contributors.

For instance, we can see a shift in [solidjs/solid](https://app.opensauced.pizza/s/solidjs/solid?hideBots=false) where the project has not only seen a decline in contributions, but we also see an increase in the lottery factor in the last thirty days. 

![solidjs side by side comparison](https://cdn.sanity.io/images/r7m53vrk/production/85f1338d798331f7091812e19b38afbc8d474cee-1920x1080.svg?w=450)

Over a period of one year, there were 34 contributors, but in the last thirty days, there were 5 contributors with the top contributor making 40% of the total PRs. This shift in contribution dynamics can be a sign of a reverse compound effect.

You can read more about this impact in [The Silent Crisis in Open Source: When Maintainers Walk Away](https://opensauced.pizza/blog/when-open-source-maintainers-leave)

## Balancing Contribution Dynamics

The ideal scenario for open source projects is a healthy mix of consistent core contributors and a steady influx of new contributors. This balance ensures both stability and fresh perspectives, maximizing the compound interest effect of collaborative innovation.

[Next.js](https://app.opensauced.pizza/s/vercel/next.js), for example, has a healthy balance of [internal and external contributors](https://opensauced.pizza/changelog/contributor-filters), with a consistent flow of new contributors joining the project. This can also lead to a more sustainable project in the long run, as it's not dependent on a single source of contributions and has a low lottery factor.

[![next.js](https://cdn.sanity.io/images/r7m53vrk/production/751172d19f21efccc46648acd85d76a0331bd678-1804x990.png?w=450)](https://app.opensauced.pizza/s/vercel/next.js?hideBots=false)

## Case Study: Meta's Open Source AI Strategy

The power of open source's network effects isn't lost on major tech companies. A prime example of this is Meta's approach to AI development, particularly with their [Llama model](https://app.opensauced.pizza/s/meta-llama/llama). This strategy shows how open sourcing can create a sustainable and mutually beneficial ecosystem.

Meta backs open source AI for several strategic reasons:

- **Talent Attraction**: By open sourcing their AI models, Meta positions itself to attract top talent in the field. Developers and researchers are often drawn to companies that contribute significantly to open source projects.
- **Ecosystem Development**: As Balaji points out, open sourcing Llama allows for "an entire ecosystem built around Llama" to develop around it. This ecosystem grows far more rapidly and robustly than if Llama were a closed system.
- **Competitive Strategy**: By open sourcing their AI model, Meta can "hit the margins of closed AI competitors." This approach leverages the power of the open source community to compete with companies that keep their AI models proprietary.
- **Sustainable Business Model**: This approach aligns with Meta's business model. As the [Facebook announcement](https://about.fb.com/news/2024/07/open-source-ai-is-the-path-forward/) notes, "openly releasing Llama doesn't undercut our revenue, sustainability, or ability to invest in research like it does for closed model providers." This is because Meta's primary business isn't selling access to AI models.
- **Long-term Vision**: The goal is for Llama to become an industry standard "by being consistently competitive, efficient, and open generation after generation." This long-term vision capitalizes on the compound interest effect of open source contributions.

This strategy exemplifies how open sourcing can be a win-win scenario. Meta benefits from the collective improvements made to Llama, while the wider tech community gains access to a powerful AI model they can build upon and adapt for various use cases.

Yesterday, Meta release [SAM 2](https://app.opensauced.pizza/s/facebookresearch/segment-anything-2?hideBots=false) and although stars, forks, issues, and pull requests have shot up, it hasn't been enough time to see the impact, but we hope to revisit this once more time has passed.

## Coming Soon: Quantifying the Compound Effect

As open source ecosystems grow, so does the need to understand and measure the impact of individual contributions. Just as financial investors track the performance of their investments, we're developing a way to quantify the value of a contributor's contributions.

Imagine a system where each contribution isn't just counted, but weighted based on its quality, impact, and the contributor's track record, allowing you to:

- Highlight high-impact contributors, helping maintainers identify key collaborators.
- Provide contributors with tangible metrics of their influence, potentially aiding in career advancement.
- Help companies identify talent for collaboration or sponsorship opportunities.
- Guide project maintainers in allocating resources and attention more effectively.

Not only do contributions build upon each other over time, but the "interest rate" of each contribution could vary based on its quality and the contributor's history. Open source metrics help us understand and quantify this impact.

For example, a bug fix from a consistently high-performing contributor might be fast-tracked for review, speeding up the project's overall progress. Or, a feature suggestion from a contributor with a history of high-impact ideas might receive more immediate attention. [Here's a sneak peak](https://oss.fyi/oscr-docs) at what we've been working on. 

## The Last Word: Sponsoring Open Source is Like Reinvesting Dividends

To keep the compound interest of open source growing, you have to support the ecosystem. Sponsoring and submitting meaningful contributions to open source projects and maintainers is like reinvesting dividends – it fuels growth. By contributing to the sustainability of open source, organizations and individuals can ensure the continued health and vitality of the projects they rely on.

See how the compound interest analogy explains the power of open source contributions and the role of open source metrics in quantifying their impact.

The Compound Interest of Open Source: How Collaboration Leads to Growth

What if the primary value of open source isn't in producing software, but in producing better developers?

Think about it. When you contribute to an open source project, you're essentially learning in public. Every mistake, every breakthrough, every half-baked idea is out there for the world to see. It's terrifying. It's vulnerable. And it's **incredibly** powerful.

Learning in public does several things:

1.**It accelerates skill development**: When you work in public, you get feedback faster. Your code is reviewed by experts. Your ideas are challenged and refined. It's like having a personal mentor, or even, hundreds of mentors. (See: [You Don't Need a Mentor: Embracing the Power of Community](https://opensauced.pizza/blog/you-don%E2%80%99t-need-a-mentor).)

2. **It builds resilience**: In private development, mistakes are hidden. In open source, they're exposed. This builds a  skill that, honestly, we all need: the ability to fail publicly and keep going.

3. **It creates a living portfolio**: Your OpenSauced profile becomes more than a code repository; it's a record of your growth, your problem-solving skills, and your ability to collaborate.

As [Fred K. Schott of Astro puts it on The Secret Sauce Podcast](
https://www.youtube.com/embed/IjujjSU_cOA?si=VIrPbNRzFrtlVeqh&amp;clip=UgkxckZswAWLUaXA6k7fOiOuhyhMj-Rfyfa4&amp;clipt=EOj7hgEYp4eJAQ
):

> "It's like you can see me working through a product like you don't need to. Like maybe you should still interview me but like you can see how I communicate. You can see how I work with people. You can see I respond to feedback and take feedback like it's not even about the green square at that point. It's about you see me at like doing work. You see me doing engineering work. You can get a peek into my life if I joined your company. And that was what I always thought I could kind of communicate with that work."


This transparency changes how we evaluate talent, how we learn, and ultimately, how we work.

## The New Networkscape: How Open Source is Expanding Professional Relationships

In traditional career paths, your network is often limited by geography, education, and chance encounters. In open source, *your network is limited only by your willingness to contribute and engage*.

This new "networkscape" opens up new opportunities:

1. **Global Talent Pool**: Companies have access to a worldwide talent pool, identifying top performers regardless of their location or background.

2. **Reputation Economy**: Your reputation in the open source community becomes a new kind of currency. It's not about where you went to school or who you know; it's about what you can do and how well you collaborate.

3. **Distributed Mentorship**: Junior developers can learn from experts simply by engaging in project discussions, reading through issue and pull request comments, or submitting quality pull requests.

[Matt Schrage's observation in the Secret Sauce](https://www.youtube.com/watch?v=UUvhwB29NMk&list=PLHyZ0Wz_A44VR4BXl_JOWSecQeWcZ-kS3&index=34) becomes even more powerful in this context:

> "We've managed to find really talented engineers that probably would not have been easy to find if we didn't have this community."

This isn't just about finding talent; it's about reimagining how professional relationships are formed and maintained in the open source age.



## The Collaboration Laboratory

While open source undoubtedly opens up new professional opportunities, its true power lies in developing meaningful, long-lasting connections rather than transactional relationships. Maybe the most overlooked benefit of these relationships are their role as an experiment in human collaboration. In open source, we're learning how to coordinate complex tasks across time zones, cultures, and competing interests, which requires trust.

These lessons have value far beyond software development:

1. **Asynchronous Communication**: Open source projects have demonstrated the art and value of asynchronous collaboration, a skill that's we all need in our increasingly distributed work world.

2. **Conflict Resolution**: Public disagreements in open source projects provide opportunities to learn more about constructive conflict resolution and consensus-building.

3. **Governance Models**: Different open source projects experiment with various governance models, providing insights into managing large, diverse groups of contributors.

4. **Incentive Structures**: There's no right way to motivate and reward (the *right*) contributors in the absence of traditional financial incentives. Open source projects are a living experiment for exploring new incentive structures. (See more on the power of recognition [here](https://opensauced.pizza/blog/the-need-for-recognition-in-open-source).)

With increased globalization, we're also faced with new challenges. Sometimes, open source collaboration reveals that we're not as good at working together as we thought. But that's the point: open source is a great space for learning how to collaborate better.

## The Unforgiving Mirror: When Open Source Exposes Weaknesses

Open source contributions can be unforgiving. It doesn't just showcase strengths; it exposes weaknesses.

### The Harsh Reality of Public Performance

In open source, there's nowhere to hide. Every contribution, comment, and interaction is public and permanent. This level of exposure quickly reveals:

- **Effort Level**: When contributors consistently submit high-effort work, it becomes obvious and maintainers notice. The opposite is also true: if you're not putting in the effort, it shows -- if you're just going for the green squares, maintainers can tell.
- **Skill Level**: Good/poor code quality, understanding of best practices (or lack of), or inability to grasp project guidelines become evident through pull requests and issue discussions.
- **Communication**: Polite and respectful responses, openness to constructive criticism, and clear explanations of ideas are there for the community to appreciate. On the opposite side, so are rude responses, inability to accept criticism, or poor explanation of ideas.

Why is this important? Because it creates a natural filtering mechanism. In traditional work environments, these issues might be hidden or slow to surface. In open source, they're immediately apparent.

The flip side of this statement is equally true: it's also a way to showcase your lack of skills or dedication.

## Beyond Star-gazing: The Currency of Meaningful Contribution

[We've said it before](https://opensauced.pizza/blog/growth-hacking-killed-github-stars): a project's star count on GitHub is not a meaningful metric of success or importance. But what does star-gazing mean for contributors?

### The Illusion of Passive Engagement

Star-gazing - the act of simply starring a repository without engaging with it - is the equivalent of a social media like. It's a low-effort show of appreciation that doesn't contribute to the project's development or success.

### The True Measure of Success: Quality Contributions

In contrast to passive star-gazing, meaningful contributions lead to successful open source projects. 

As Matt Schrage points out:

> "Anyone who's excited by what you're working on can contribute to the project."

The key word here is "contribute." Passive excitement doesn't move a project forward; active, quality contributions do.

#### Why Quality Contributions Matter

The focus on quality contributions over vanity metrics has several important implications:

- **Project Health**: Active, quality contributions are a much better indicator of a project's health and longevity than star counts.
- **Community Building**: Quality contributions allow for a supportive community of contributors and promote progress in open source projects, creating a more productive and rewarding environment for all involved.
- **Real-world Impact**: Meaningful contributions solve actual problems and create value for users, which is ultimately what open source is about.

When we combine the unforgiving transparency of open source with the emphasis on meaningful contributions, we create a crucible for developing both individual skills and project quality.

In this light, open source becomes more than just a way to produce software. It's a path for creating better developers, more resilient projects, and a more transparent, meritocratic tech ecosystem.

The question for aspiring contributors then becomes not "[How Can I Find Open Source Projects to Contribute to?](https://opensauced.pizza/docs/community-resources/how-to-find-open-source-projects-to-contribute-to/)" but "What meaningful value can I add?" It's in answering this question through action that both contributors and projects find true success in the open source world. In a couple of weeks, we're launching a feature that helps to showcase these meaningful contributions. Stay tuned!



Open Source can be a catalyst for building better developers through public learning and development, accelerating skills, building resilience, and creating new professional opportunities.

Building Better Developers

Recently, while looking at [pgvector](https://app.opensauced.pizza/s/pgvector/pgvector?hideBots=false&range=360), a popular PostgreSQL extension for handling vector embeddings in machine learning, we were surprised to see that [Andrew Kane](https://app.opensauced.pizza/u/ankane) (@ankane), the creator of pgvector, wasn't among the top five contributors to the project in its [Lottery Factor](https://opensauced.pizza/docs/welcome/glossary/#lottery-factor) chart.

This seemed counterintuitive—how could the project's creator not be a top contributor? A little background on lottery factor: we look at the top contributors based on Pull Requests (PRs) to the project to determine how at risk a project is if a top contributor were to leave. The higher the lottery factor, the more at risk the project is. In the case of Andrew Kane, rather than following the typical pull request workflow, which involves proposing changes, getting feedback, and iterating before merging, he was committing his changes directly to the main branch—a prime example of YOLO coding.

![YOLO Coder - lottery factor gif](https://cdn.sanity.io/images/r7m53vrk/production/28510e91209c4d48736442032615d3820a52deba-704x480.gif?w=450)

[YOLO coding](https://opensauced.pizza/docs/features/repo-pages/#insights-into-yolo-coders), or "You Only Live Once," is when developers commit changes directly to a project's main branch without going through the conventional pull request and code review process. While Kane's direct commits might allow for faster development, they bypass the code review and testing stages. 

## The Risks of YOLO Coding

Let's be clear: pushing directly to main is a risky practice, regardless of who you are or what you're changing. Here's why:

### Catastrophic Data Loss Risk

One bad force push to main could erase your entire project's history. This isn't hyperbole - it's a real risk that has affected even experienced developers. Your project's history isn't just a log; it's a valuable resource for understanding decisions, tracking changes, and maintaining the codebase.

### Bypassing Critical Safeguards

Code reviews aren't just bureaucratic red tape. They're essential safeguards against errors, style inconsistencies, and potential security vulnerabilities. By pushing directly to main, you're skipping this key step.

### Context and Continuity Loss

Pull requests (PRs) provide valuable context for changes. They allow for discussion, explanation, and documentation of why certain decisions were made. This context is invaluable for future developers (including your future self) trying to understand the codebase and is another way to decrease the [challenges of losing a maintainer](https://opensauced.pizza/blog/when-open-source-maintainers-leave).

Now, you might be thinking, "But what about small changes? Do I really need a PR for a typo fix in the docs?"

Yes, you do. Here's why:

### Consistency is Key

By treating all changes with the same level of caution, you build good habits and maintain a consistent workflow. This reduces the chance of accidentally pushing a more significant change directly to main.

### Even Small Changes Can Have Big Impacts

A misplaced character in documentation could lead to confusion or misuse of your software. A seemingly innocent change could have unforeseen consequences.

### It's Not Just About the Code

PRs aren't solely for catching bugs. They're opportunities for knowledge sharing, mentoring, and improving overall code quality.

## The Power of Pull Requests

Popularized by GitHub, pull requests provide a structured way for contributors to propose changes to a project, allowing for review, discussion, and iteration before merging the changes into the main branch. It's like having a safety net for your codebase.

### A Pull Request Culture

When you have a pull request culture, you decrease the risks brought on by YOLO coding. It's not just about avoiding disasters; it's about fostering collaboration and ensuring the long-term health of your project. Here are some key steps to achieve this:

- **Establish Clear Guidelines**: Don't leave your contributors guessing. Define and document the project's contribution process, emphasizing the importance of pull requests. Provide step-by-step instructions on how to create a pull request and what information should be included. 
- **Encourage Code Reviews**: Code reviews aren't just a formality; they're a lifeline. Make code reviews a key part of the development process. Assign reviewers to each pull request and encourage thorough, constructive feedback. This not only helps catch potential issues but also promotes knowledge sharing and collaboration.
- **Automate Testing**: Don't leave testing to chance. Implement continuous integration and automated testing to catch potential issues early in the development process. This reduces the reliance on manual testing and ensures that changes are thoroughly vetted before merging. 
- **Recognize and Reward Contributors**: Don't be stingy with praise. Acknowledge and appreciate contributors who follow the pull request process and provide valuable feedback. Celebrate their contributions and make them feel valued within the community. A little recognition goes a long way in keeping your contributors motivated and engaged.
- **Lead by Example**: Practice what you preach. As project maintainers and core contributors, you have to lead by example. Always use pull requests for your own changes and actively participate in code reviews. This sets the tone for the entire community and reinforces the importance of the pull request process. 

For small personal projects, the risks of YOLO Coding might not be a big deal. While it might seem tempting to bypass the PR process for quick fixes or when you're confident in your changes for projects with users that collaborate with others, the risks outweigh the minimal time saved. By treating every change, no matter how small, with the respect it deserves, you're not just protecting your codebase - you're creating a culture of quality, collaboration, and continuous improvement.

Remember, in software development, we don't just code for today - we code for the future. We're building something that will outlive us, and we have a responsibility to do it right. Make pull requests a non-negotiable part of your workflow. Your future self (and your team) will thank you.

YOLO Coding - the process of committing directly to main - leaves projects at unnecessary risk.

YOLO Coding: The Good, the Bad, and the Risky

In May 2022, [Dane Springmeyer](https://app.opensauced.pizza/u/springmeyer), the primary maintainer of [node-pre-gyp](https://app.opensauced.pizza/s/mapbox/node-pre-gyp?range=360), a critical tool in the Node.js ecosystem, [announced his decision to step down](https://github.com/mapbox/node-pre-gyp/issues/657). This wasn't just another developer moving on; for nearly a decade he had been maintaining the project. 

Despite outlining the urgency and the need for community involvement to keep the project maintained, proposing several options for the future of the project, and emphasizing the importance of maintaining or gracefully deprecating `node-pre-gyp` to avoid disruptions, it wasn't resolved until very recently.

This situation is just one that captures the challenges of maintainer transitions in open source projects. The departure of a key maintainer can have far-reaching implications, affecting the project's sustainability, security, and overall health. 

## The Impact of a Maintainer's Departure

Unaddressed pull requests and unresolved issues start piling up, creating a backlog and uncertainty for the contributor community. The lack of regular updates can expose the project to security vulnerabilities, quickly decreasing trust among users and contributors. For `node-pre-gyp`, this scenario unfolded as community members scrambled to find a way forward. **Single points of failure can have widespread repercussions.**

There's another type of loss that we forget about: the loss of institutional knowledge and context. Maintainers often possess critical insights into the project's history, design decisions, and future roadmap. Without this knowledge, new maintainers may struggle to navigate the project effectively. This loss of continuity can disrupt the project's development and direction, impacting its long-term viability.

This is one of the reasons, we make the [lottery factor](https://opensauced.pizza/docs/welcome/glossary/#lottery-factor) visible on repository pages on OpenSauced. 

> The Lottery Factor is a metric that identifies how at risk a project is if a key contributor leaves. It is calculated by the percentage of pull request (PR) contributions made by the top contributors. If 50% of the PR contributions come from two or fewer contributors, the lottery factor is high.

Understanding how at risk a project is if a key contributor leaves can help contributors and maintainers prepare for potential transitions and ensure the project's sustainability. 

### The Invisible Maintainer: A Hidden Threat

One often overlooked aspect of the maintainer crisis is the difficulty in identifying who actually maintains a project. This lack of transparency can lead to communication breakdowns, unclear decision-making processes, hidden lottery factor, and accountability issues.

Understanding who the maintainers are is key to project health. If you take a look at the [node-pre-gyp contributors dashboard](https://app.opensauced.pizza/s/mapbox/node-pre-gyp/contributors), you'll see that they were able to make the transition to a new maintainer. 

![cclauss with a maintainer label](https://cdn.sanity.io/images/r7m53vrk/production/752169df8e4312f3f6be443137b77071a089c9c0-1080x598.png?w=450)

This isn't just about giving credit where it's due. It's about supporting the community with necessary intelligence. 

When we know who the maintainers are, we:

- Know who's behind our dependencies.
- Can target our open source support. Find the overworked maintainers and back them up.
- Can actively support the next generation of project leaders.

It's one step in the right direction, but it's not enough. We need to make maintainer transitions more transparent, predictable, and manageable.

## The Ticking Time Bomb of Maintainer Burnout

Springmeyer's case is far from unique. Across the open source ecosystem, projects are vulnerable to maintainer abandonment for a variety of reasons, including [burnout](https://opensauced.pizza/blog/stop-burning-out-maintainers:-an-empathetic-guide-for-contributors), [lonliness](https://opensauced.pizza/blog/the-lonely-journey-of-open-source-maintainers), or lack of support. In the case of springmeyer, he cited personal and professional shifts, such as parental leave and changing priorities at Mapbox. Marak, the Faker.js creator, intentionally deleted Faker.js to highlight the pressures and lack of open source support maintainers often face. These situations emphasize the need for a supportive infrastructure that recognizes and alleviates the burden on maintainers.

This current unsustainable model is a ticking time bomb. When key maintainers leave, projects can quickly become outdated, insecure, or completely non-functional. The ripple effects can be catastrophic, potentially impacting thousands of dependent projects and millions of users.

## The Trust Paradox: The Hidden Challenge of Maintainer Succession

Finding new maintainers isn't just about identifying skilled developers. It's about trust. Handing over the keys to a project with millions of downloads to someone else can be risky. This trust paradox creates a dilemma:

> "[If] you are maintaining a project, you're kind of a gatekeeper. If you oftentimes you don't want to be, but also you don't have the time to onboard some random people, because you're afraid that like the millions of downloads this package has will fall into the hands of someone you don't know, and they could really cause damage, right? So how to do that?" - Gregor Martynus on [The Secret Sauce](https://www.youtube.com/watch?v=Gu_jWAjviLs&list=PLHyZ0Wz_A44VR4BXl_JOWSecQeWcZ-kS3&index=10)

This quote identifies a critical dilemma:

- Maintainers may find themselves reluctant guardians of widely-used projects.
- The time investment required to properly vet and onboard new maintainers is substantial.
- Giving someone maintainer access to a project can carry enormous risk.

This creates a vicious cycle: overworked maintainers struggle to find time to onboard help, leading to further burnout and increasing the risk of sudden project abandonment.

### Quantifying the Risk: New Metrics for Project Health

To address this problem, we need better ways to assess the health and sustainability of open source projects. Two emerging metrics offer valuable insights:

1. **Lottery Factor**: This metric highlights the dependency on key contributors. A project is considered vulnerable if 2 or fewer contributors account for 50% or more of the project's contributions. It's essentially measuring the "bus factor" - how many people could the project lose before it's in serious trouble?
2. **Contributor Confidence**: This metric predicts the likelihood that users who star or fork a repository will return to make contributions. A higher score (typically 30-40%) indicates a healthy, active project where contributions are valued.

These metrics offer a data-driven approach to assessing project health. A high Lottery Factor combined with low Contributor Confidence could be a red flag, indicating a project overly reliant on a small number of contributors and struggling to attract new ones.

### Preventing the Exodus: A Call to Action

1. **Sustainable Funding Models**: We need to move beyond the "free labor" mindset. Companies benefiting from open source projects should contribute financially, either through direct sponsorship or by allocating paid developer time to maintenance to prove open source support.
2. **Succession Planning**: Projects should actively cultivate a bench of potential maintainers. This means documenting processes, sharing knowledge, and actively supporting new contributors. Aim to lower that Lottery Factor!
3. **Community Health Metrics**: Regularly track metrics like Contributor Confidence. If it starts to dip, it may be time to invest in community outreach or simplify the contribution process. Healthy communities attract and retain contributors.

These approaches don't just make maintainer succession safer—they make it more achievable. By reducing the cognitive load of vetting new maintainers, we lower the barrier to expanding the maintainer pool.

## Redefining Open Source Insights

The departure of Dane Springmeyer from `node-pre-gyp` wasn't just a personal decision — it was a reminder of the hidden fragility of our digital infrastructure. 

We need to move into a new era in open source; one where gut feelings and GitHub stars aren't seen as metrics of project health. One where the true pulse of a project — its maintainer dedication, community activity, and sustainability — can be quantified and understood.

We should strive to:

- See beyond commit counts to understand the real dynamics of contributor engagement and open source support
- Identify the unsung heroes holding projects together
- Predict potential maintainer burnout before it happens
- Understand the true lottery factor of your essential dependencies

This should be the reality of open source intelligence. When we adopt this mindset, we can: 

- Make informed decisions about which projects to rely on and support
- Focus contributor efforts where they'll have the most impact
- Proactively address project vulnerabilities
- Rally around projects in need before they reach crisis point

This vision requires a shift in mindset. We have to move beyond simple metrics and anecdotal evidence and embrace data-driven insights that reveal the true health of our open source ecosystem. It's time to truly see the human element that drives open source forward.

It's about making the invisible visible. It's about transforming raw data into actionable intelligence that ensures open source software support and sustainability.


Maintainer transitions can create a lot of challenges. That's why open source support through proactive measures like knowledge transfer and community engagement is so important. 

 The Silent Crisis in Open Source: When Maintainers Walk Away

There’s no doubt that in tech, success is assumed based on the loudest voices or the spiciest headlines. But that doesn’t mean that those people and projects are actually the most successful. What truly defines the best open source projects, and why should we care? Although the recent[State of JavaScript Awards](https://2023.stateofjs.com/en-US/awards/) isn’t specifically for open source, it can still provide more context into this question.

Consider [Vite](https://app.opensauced.pizza/s/vitejs/vite?range=360), a build tool that swept multiple categories in the State of JavaScript awards, including “Most Adopted Technology.” If we’re to look at any open source project as successful, I think that taking as many awards as it did, would qualify Vite as successful. Beyond that, in the last year alone, it’s seen 860 contributors, 9,232 Stars, and 1,258 forks. However, it is worth noting that their top four contributors made 46% of all their commits and only 20% of their stargazers and forkers come back to make a meaningful contribution. All of these metrics together tell a story of a healthy, growing project that has captured the attention of the JavaScript community.

> To learn more about why Vite is everywhere, check out [Evan You’s episode of The Secret Sauce](https://youtu.be/4_uYqae42uc?feature=shared)

But the story of top open source projects isn’t always about the most visible or hyped technologies. Take [Selenium](https://app.opensauced.pizza/s/SeleniumHQ/selenium?range=360), for instance. As Jason Huggins, its creator, recently pointed out:

> “Selenium is the biggest open source success story never told. We’re now at exactly 20 years since the first lines of code were written. Since then, it has launched countless careers and companies. Did you know the Selenium Test Automation User Group on LinkedIn alone has almost 250K users?!”

Selenium’s journey shows that the best open source projects aren’t always the ones grabbing headlines. They can be the ones that demonstrate remarkable longevity, sustaining their relevance over years, and providing paths to success for individual contributors as well. The long-term success of a project like Selenium, which has remained vital for over two decades, highlights the importance of durability and consistent value in the open source ecosystem. This kind of sustained impact is a testament to the project’s adaptability and the community’s continuous support and improvement efforts, demonstrating that longevity is an important metric of success in open source.

In the last year, we’ve seen 560 total contributors to Selenium, with 3,631 stars and 743 forks as well. It might not have the same explosiveness as Vite, but it clearly shows success with its consistency and staying power.


## What Makes a Top Open Source Project?

In the last couple of weeks, I’ve started most of my mornings checking out the [top new stars](https://app.opensauced.pizza/workspaces/8691fd9d-4cfc-4fa5-8c40-85da76a229b8)  and [top new forks](https://app.opensauced.pizza/workspaces/46eb2b34-7622-462c-93a2-55b5fa34aa76) over the last 24 hours and adding them to my (linked above) workspaces. We know that [starred repositories aren’t a great indicator of project success](https://opensauced.pizza/blog/growth-hacking-killed-github-stars) and a sudden spike in forks often indicates some sort of spam project, but they can still be useful for identifying trends, understanding project engagement, and spotting rising stars. It’s important to recognize that stars or forks or any other metric alone cannot provide a complete picture of a project’s long-term viability or community support.

Understanding these metrics in the context of other qualitative and quantitative data helps provide a more comprehensive view of a project’s health and trajectory. They are pieces of a larger puzzle that, when combined with insights into awareness, retention, and community engagement, can help paint a fuller picture of what makes an open source project successful. The truth is, the best open source projects often share several key characteristics:
- **Solve Real Problems**: Top open source projects address genuine pain points in the developer community.
- **Active Community**: The best open source projects create engaged communities that contribute to their growth and evolution, with a high [contributor confidence](https://opensauced.pizza/docs/features/repo-pages/#insights-into-contributor-confidence), and a variety of contributors, including recurring, new, and internal. 
- **Sustainability:** Long-term viability is key for top open source projects, ensuring they can be trusted for years to come. There should be clear trends that indicate a healthy project, including a variety of committers to the project, reducing the [lottery factor](https://opensauced.pizza/docs/welcome/glossary/#lottery-factor).
- **Innovation**: The best open source projects often push the boundaries of what’s possible, driving the entire industry forward.

### How do the Projects in the State of JS Awards Compare?

So how does the State of JS look, when we get up close? Let’s take a look at [the workspace I created with all the winners and runners-ups](https://app.opensauced.pizza/workspaces/fb774fa9-a4a8-4f49-a0af-a8a955f10069?limit=20&range=360).

[![state of js repo stats](https://cdn.sanity.io/images/r7m53vrk/production/5bfdbb13156e0b6c04b37e419079ff1b69e791c3-1213x280.png?w=450)]((https://app.opensauced.pizza/workspaces/fb774fa9-a4a8-4f49-a0af-a8a955f10069?limit=20&range=360))

#### Pull Requests and Issues: Indicators of Activity and Engagement

This workspace shows impressive numbers for all the projects over the last year: 

- 14.5k PRs opened 
- 14.2k merged 
- 7.7k issues opened
- 15.6k closed issues 

Every single project has a high activity level. [Next.js](https://app.opensauced.pizza/s/vercel/next.js) alone has an astonishing 3,367 PRs with a velocity of 4 days and a high engagement ratio. This high velocity indicates a well-managed project where contributions are reviewed and merged promptly, reflecting an active and responsive maintainer team.

The velocity of issue closure, averaging 209 days across projects, also provides insight into the project’s responsiveness to user feedback and bugs. While a high number of closed issues indicates healthy problem-solving, the velocity can highlight areas where improvements are needed. Projects with lower closure times are likely more efficient in handling user concerns, contributing to higher user satisfaction and retention.

#### Contributor Diversity and Sustained Engagement


The data reveals significant contributions from across projects. For example, [React](https://app.opensauced.pizza/s/facebook/react) boasts 503 contributors, showcasing a broad base of active participants. This diversity reduces the “lottery factor,” ensuring that the project does not overly depend on a few key individuals.

![React stats](https://cdn.sanity.io/images/r7m53vrk/production/ddcd926ba2fd2c234e8785093a4b3eb3ba68a372-935x101.png?w=450)

Additionally, the consistency in contributor activity over the last 360 days, shows ongoing interest and sustained participation. Projects like [Vitest](https://app.opensauced.pizza/s/vitest-dev/vitest) and [Astro](https://app.opensauced.pizza/s/withastro/astro) show steady contributor activity, suggesting that these projects have successfully maintained their community’s interest and involvement over time.

#### Engagement Metrics: Stars and Forks

Projects like [Storybook](https://app.opensauced.pizza/s/storybookjs/storybook) and [Bun](https://app.opensauced.pizza/s/oven-sh/bun) also show high levels of new forks and stars, suggesting they are gaining traction and interest. This can be particularly telling of projects that are on the rise, capturing the attention of developers looking for new tools and frameworks to integrate into their workflows.

#### High-Performance and High-Velocity Projects

The workspace highlights several projects with both high performance and high velocity in managing PRs and issues. Projects like [Playwright](https://app.opensauced.pizza/s/microsoft/playwright) and Bun demonstrate a remarkable balance between high PR activity and low velocity, indicating a streamlined contribution process and a responsive maintainer team.

#### Bonus: Going Deeper with the Lottery Factor

I wanted to learn a little more about these projects, so I asked [StarSearch](https://opensauced.pizza/docs/features/star-search/) to tell me more about their Lottery Feature. I was genuinely surprised at what’s happening in some of the repositories. Here’s what I learned:

![lottery factor](https://cdn.sanity.io/images/r7m53vrk/production/01970ef9d17ad213955876650a179444d8d6afea-464x546.png?w=450)


## Looking Into the Future of Open Source Success

In the conclusion of the State of JavaScript Report, Cassidy Williams notes an interesting shift in sentiment: “The fact that so many ‘smaller’ libraries like [Preact](https://app.opensauced.pizza/s/preactjs/preact), [Solid](https://app.opensauced.pizza/s/solidjs/solid), and [htmx](https://app.opensauced.pizza/s/bigskysoftware/htmx) are climbing in positive sentiment over something massive like [Next.js](https://app.opensauced.pizza/s/vercel/next.js) is fascinating. We’re starting to see [Angular](https://app.opensauced.pizza/s/angular/angular) make a bit of a comeback, and we’ll see if that trend continues next year. We’re seeing people fall out of love with some of the industry darlings. We’re seeing very Rusty systems grow. [Astro](https://app.opensauced.pizza/s/withastro/astro) feels like it’s off to the races in developer support.”

Cassidy underscores an important observation about the open source ecosystem: success isn’t solely determined by size or initial popularity. Smaller, more focused projects can gain significant traction and developer loyalty by addressing specific needs effectively.

Understanding these metrics helps provide a more nuanced view of what makes an open source project successful. It's not just about the initial burst of popularity but about building a sustainable, engaged community that can support and grow the project over the long term.

In Huggins' words, "Good thing we didn't do it for the fame and glory, huh?" Perhaps it's time we started giving projects like Selenium the glory they deserve.





Explore the stories of Vite and Selenium, and learn about the key metrics and community factors that contribute to lasting impact and growth in the open source ecosystem.

From Vite’s Popularity to Selenium’s Legacy: What Defines Open Source Success?


In December 2021, the software world faced a crisis that would later be known as the “Log4Shell” vulnerability. The critical security flaw was found in Log4j, an open-source Java-based logging utility widely used across various applications and services. This vulnerability allowed remote code execution and exposed millions of systems to potential exploitation. Despite extensive efforts to patch and mitigate the issue, the Log4j vulnerability continues to plague the software industry, highlighting both the strengths and vulnerabilities of the open-source model.

## The Enduring Impact of Log4Shell

[According to a 2023 article by Connor Jones](https://www.theregister.com/2023/12/11/log4j_vulnerabilities/), even two years after the Log4Shell vulnerability was disclosed, nearly 25% of apps may not have updated their Log4j library after the vulnerability was fixed. The issue isn’t just the vulnerability, though; it’s also the ongoing challenge of maintaining up-to-date and secure dependencies within the open source ecosystem. There’s a broader problem of dependency management and the need for more awareness within the development community to effectively decrease these risks.

If we look at [Apache Log4j 2](https://app.opensauced.pizza/s/apache/logging-log4j2?range=360), in the last year, for example, we see that majority of the commits are coming from two contributors, [ppkarwasz](https://app.opensauced.pizza/u/ppkarwasz) and [vy](https://app.opensauced.pizza/u/vy).  While we couldn’t say for sure what would happen if ppkarwasz left the project, we can confidently say that the project would feel the impact for a while.   

 ![lottery factor](https://cdn.sanity.io/images/r7m53vrk/production/b732aca20977c5cecf0edd2ce72ca8c3c7bd57a4-576x786.png?w=450)


### The Fragility of Dependencies

Our entire digital infrastructure is a house of cards built on good faith. One burned-out maintainer, one vulnerable dependency, one "I'm taking my ball and going home" moment, and suddenly we're all scrambling.

Jana Iris brings up another perspective in the problems with open source in her episode of [The Secret Sauce](https://www.youtube.com/watch?v=vwkyCbfKqB4&list=PLHyZ0Wz_A44VR4BXl_JOWSecQeWcZ-kS3&index=17), "it's actually the biggest thing I always talk about is building developer trust, but also building trust in the enterprise. The biggest thing is like, they don't want to start adopting a solution and then all of a sudden you're not here in a year."

Companies are in a constant state of digital FOMO - they want to innovate, but they don’t want to bet on the wrong project. Imagine adopting a solution only to find out a year later that the maintainer has decided to become a goat farmer in the Andes. 
It’s like the xkcd comic that haunts every developer's dreams - the entire world relies on a project maintained by a single volunteer. It's funny because it's true, and it's terrifying because it's true.

![image of a bunch of structures held up by a tiny piece](https://cdn.sanity.io/images/r7m53vrk/production/04ad2563be8edb72bddafd2d1f3bd6719ab72119-632x802.png?w=450)


But here's where it gets really interesting: this isn't just about managing risk. It's about shaping the future. The projects we choose to support today are the innovations we'll be using tomorrow. It's like we're all time travelers, using pull requests and commits to shape the future.

So, what's the solution? It's not simple, but it starts with dialogue. We need to be talking about this - not just after a major outage, but openly and constantly. We need to rethink how we understand, value, and support open source projects, contributors, and maintainers. 
Because here's the truth: in the world of open source, we're all maintainers now. Every line of code we use is a responsibility we inherit. It's time we started acting like it.

But it goes beyond the dependencies we’re using. It’s also about looking to the future and the projects that are driving innovation. This is another one of the problems with open source software : redundancy in efforts and lack of visibility into past projects. We often rebuild solutions because we don’t know similar efforts were made before. Tools like [StarSearch](https://app.opensauced.pizza/star-search) can help by providing a comprehensive view of past and present contributions, preventing redundant work and saving valuable time and resources.

## The Promise of Informed Engagement: the Open Source AI Landscape

While we see these challenges across the open source landscape, they are significant in open source AI because it’s moving incredibly quickly and they represent a frontier. Addressing these issues will impact the whole landscape, including AI.

[![support open source AI LI post](https://cdn.sanity.io/images/r7m53vrk/production/84f927ed295294d013f4aec01eae1ff1a63cba50-808x334.png?w=450)](https://www.linkedin.com/posts/collin-wallace_opensource-ai-activity-7207906901576015872-W8Br?utm_source=share&utm_medium=member_desktop)

Supporting open source AI promotes transparency and accountability in AI development, allowing for greater examination of algorithms and models to address concerns about bias and ethical considerations. This openness is incredibly important as AI increasingly impacts our daily lives and decision-making processes.

Because researchers and developers worldwide can contribute to and build on existing projects, we’ll see benefits for the entire field. This collaborative approach also facilitates cross-domain applications, bringing AI to a variety of sectors.

Open source AI isn't just another tech trend. It's our best shot at democratizing one of the most powerful technologies of our time.

Take a look at the [Open Source AI workspace](https://app.opensauced.pizza/workspaces/79f026cd-4a32-43e7-a8b7-ea6e2b67333). Projects like [PyTorch](https://app.opensauced.pizza/s/pytorch/pytorch), [scikit-learn](https://app.opensauced.pizza/s/scikit-learn/scikit-learn), and [llama_index](https://app.opensauced.pizza/s/run-llama/llama_index) have high activity and low lottery factors. 

By focusing on open source AI, we can tackle key open source issues and drive innovation by increasing contributor confidence, providing clear growth pathways, and ensuring project sustainability.

### The Sustainability Problem

One of the most pressing problems with open source software is the long-term sustainability of projects. To be a sustainable project, you need returning contributors and viewers who are willing to engage and support the project as a contributor. What does that mean? That means going beyond looking at stars and forks as metrics of success and understanding if those actions translate to contributions in the open source ecosystem and your own project. 

At OpenSauced, we call this [Contributor Confidence](https://opensauced.pizza/docs/features/repo-pages/#insights-into-contributor-confidence). For instance, if your project has a lot of stars and forks, but not a lot of those translate to contributions, then it indicates the project isn’t effectively converting initial interest into contributions. 

![low contributor confidence](https://cdn.sanity.io/images/r7m53vrk/production/13026b73c25cc4335e7a358345f8522ae268544c-1102x338.png?w=450)

 
In a conversation from [The Secret Sauce podcast](https://youtu.be/xno59bpro50?feature=shared), Jordan Harband discusses the sustainability problem and highlights a potential solution. He mentions that while companies have resources like money and people, individual maintainers often lack these, leading to project stagnation:

> “I get a lot of complaints from people and companies about where we're blocked. We can't, well, companies have money and people and people have time. And that's, those are things that I don't really have at the moment. So if anybody showed up and was able to come up with enough money that I could justify, like at the moment, not looking for a new job for a month so I can work on this instead, I would be happy to do it. And similarly, if any company showed up –  one tried and then ended up bailing on it –  If any company showed up and said, we have people to put on this. Can you help them? Like you have my axe, like I'm here. I will jump on video calls.” 


There’s a disconnect between individual contributors and corporate resources. Companies have the means to support open source projects but often lack the commitment or follow-through to sustain them. Maintainers shouldn’t have to wait until the point of complete burnout to receive the support they deserve from users. 

### The Contributor Experience Hurdle

Another one of the issues with open source software is the new contributor experience. [@bdougie](https://app.opensauced.pizza/u/bdougie?range=180) captures some of the challenges that we don’t talk about enough in [the Secret Sauce](https://www.youtube.com/watch?v=xno59bpro50&list=PLHyZ0Wz_A44VR4BXl_JOWSecQeWcZ-kS3&index=30):

>  "sometimes we need like way more context and intro conversations around that, which is like how to be a good beginner.” The open source community has traditionally focused on initiatives like "good first issue" and "first-timers" to encourage new contributors. However, as the ecosystem continues to grow, the sheer volume of projects and contributors can be overwhelming for new contributors and maintainers alike. "There needs to be like a step before, which is like, this is cause as you mentioned before, like when you got an open source and same when I got an open source, it was a smaller ecosystem."

This lack of introductory guidance and often experience on the part of first-time contributors creates a contributor confidence gap. They might struggle to navigate the open source ecosystem, understand complex codebases, or feel unwelcome within established communities. The result? Potential contributors leaving before they can even begin to contribute. This ultimately weakens the foundation of open source.

But what if the contributors aren’t ready to contribute? What if they need more experience? Encouraging contributors to dive into projects before they are adequately prepared can be counterproductive. Instead of creating a supportive environment, we risk overwhelming them, leading to frustration and disengagement. Additionally, pushing unprepared contributors into active development roles can result in low-quality contributions that require extensive revisions or even rejection, hurting their confidence and willingness to participate.

This premature push not only affects the individual contributor’s experience but also the health of the project. Experienced maintainers may find themselves spending more time than they have correcting errors or providing basic guidance. 

If we want to [manage successful communities in open source](https://opensauced.pizza/blog/managing-successful-communities-in-open-source), ultimately, the goal should be to nurture new contributors, providing them with the tools, guidance, and gradual introduction they need to build their skills and confidence. 

To be a good contributor, you have to understand [how to be a maintainer](https://opensauced.pizza/blog/maintainer-course), so you can appreciate the challenges and responsibilities maintainers face. This will allow contributors to have a sense of self-awareness about their role in the project’s ecosystem and how their contributions can best support its long-term success.

## Embracing the Open Source Paradox: A Call to Action

Open source is messy, complicated, and absolutely essential. It's a beautiful contradiction - a system built on freely shared code that powers trillion-dollar industries. But here's the kicker: this paradox isn't a bug, it's a feature.

The very qualities that make open source so powerful - its openness, its collaborative nature, its ability to evolve rapidly - are the same ones that create its biggest challenges. It's like trying to build a rocket while it's already in flight. Exciting? Absolutely. Easy? Definitely not.

By leaning into these challenges - sustainability, contributor experience, dependency management - we're not just fixing problems. We're unlocking the next level of innovation. It's like we're collectively leveling up the entire tech ecosystem.

And let's talk about companies for a second. If you're still treating open source like a free buffet, you're doing it wrong. It's time to step up, get strategic, and start actively nurturing the communities you depend on. The future of tech isn't just open - it's wide open. And it's waiting for us all to make our mark.




The problems with open source software highlight the need for sustainable project management, addressing vulnerabilities, ensuring long-term security, and fostering innovation.

The Open Source Paradox: Fragility and Promise

We all *need* community. Open source *needs* community. It’s the space where we collaborate and grow together by working to create something greater than the sum of its parts. When we look at the dynamics of open source communities, we see that the sense of mutual belonging and support is a key part of its success. Just as [Kelly-Ann Allen from The Psychology of Belonging](https://api.taylorfrancis.com/content/books/mono/download?identifierName=doi&identifierValue=10.4324/9780429327681&type=googlepdf) notes, our sense of belonging to groups—whether they are families, social groups, or professional communities—plays a significant role in our well-being and motivation:

> We find much of our meaning, identity, relevance and satisfaction in life through our sense of belonging to groups. At family, community and societal levels, we rely on others for support, validation and understanding. Belonging to groups, whether these be families, groups of friends, social groups, schools, workplaces or communities more broadly, has a positive effect on several key factors that contribute to our successful healthy functioning as human beings in a society.

In many ways, this is why open source community becomes such a vital part of the open source ecosystem. When we find belonging in a community, we’re more likely to grow, find meaning in challenges, and to feel a deeper sense of satisfaction. 

## Shifting Sands of Motivation

When people stay in a community, it’s because they’re motivated to be there and there are opportunities to contribute. Ideally, contributors are motivated by the success and sustainability of the project. This requires a community that trusts the maintainers and their vision, creating a space for meaningful connections.

For example, [Tyler Williams](https://app.opensauced.pizza/u/coolsoftwaretyler) became a contributor to [mobx-state-tree](https://app.opensauced.pizza/s/mobxjs/mobx-state-tree?range=180) because his company was actively using it. Maintainer [Jamon Holmgren](https://app.opensauced.pizza/u/jamonholmgren) noticed and invited Tyler to become a maintainer. Tyler’s investment was motivated by using the project.

Other motivations include learning new technologies and enhancing resumes. 
Depending on the contributor, this may mean fewer meaningful and sustained contributions and more work for the maintainers because their motivation isn’t tied to the project. Ideally, maintainers could encourage these contributors to stay involved and grow through a contributor ladder or other motivators. 

### Contributor Confidence

To understand evolving motivations requires regularly engaging with your contributors and creating space and flexibility for their continued contributions. Creating feedback loops and regular check-ins with your active contributors can help to gauge their continued participation in your project, but also understanding the [Contributor Confidence](https://opensauced.pizza/docs/features/repo-pages/#insights-into-contributor-confidence) of the project can be a good way to understand if the contributors motivations are impacting whether or not they’re contributing or if the approachability of the project is an issue.

Contributor Confidence is a metric that helps us understand the likelihood of someone who interacts with a repository (by starring or forking it) coming back to actually contribute code or other content. For example, a high Contributor Confidence score (e.g., 37-50%) suggests a welcoming and active repository where your contributions are likely to be seen and valued, while a low score (e.g., 1-3%) might indicate it’s harder for outside contributors to get involved.

![Contributor Confidence Gauge](https://cdn.sanity.io/images/r7m53vrk/production/62649f55cae10623d2bd18b2dcd741675849de44-348x176.png?w=450)

Motivations will change over time. Understanding these shifts and adapting is necessary for sustaining active participation. 

## Fostering a Sense of Belonging

I recently caught up with Dave Kiss, on an [X Space about monetizing your open source project](https://x.com/saucedopen/status/1798777358180335883), and he talked about how important it was for him to be a part of the open source community, “A community isn't just a one-way approach. We have to sort of lean on each other and give back in ways that we can.” We see this sort of horizontal mentorship all the time in healthy open source communities.

Open source communities are a hidden gem of mentorship and learning. When we create a space where community members support each other, the community is more likely to thrive and help each other. In our recent episode of [The Secret Sauce with Kelsey Hightower](https://www.youtube.com/watch?v=MQbkN99eBD8&t=1519s), he points this out as well, “You can come in [to an open source community] and say, hey, I want to understand how operating systems work. And someone will be patient with you. It's like, all right, let's walk through the code. Let's walk through your contribution. Let's walk through the potential fix that moves this forward. I think that's the thing that a lot of people that have never contributed to open source don't understand what's so powerful about this particular segment of our industry.” 

This support system is necessary for the growth and sustainability of open source projects and for cultivating a culture of continuous learning and growth. New contributors bring fresh perspectives and ideas, while experienced members guide and mentor them. This symbiotic relationship ensures individuals and projects continue to grow and adapt to new challenges.

### The Open Source AI Community: A Case Study in Innovation and Collaboration

The open source AI community is a great example of how collaborative efforts can lead to innovation. This community not only thrives on contributions from individual developers but also benefits from the involvement of large organizations and research institutions. 

#### [PyTorch](https://app.opensauced.pizza/s/pytorch/pytorch?range=180): Driven by Community Engagement

Initially developed by [Facebook’s AI Research lab](https://app.opensauced.pizza/workspaces/d35ff03b-13e2-43d8-9423-82f01db8200b), PyTorch is a machine learning library that can be used for things like image recognition and natural language processing. Its active community contributes to its development and supports each other through forums and collaborative projects.

![stars and forks for pytorch](https://cdn.sanity.io/images/r7m53vrk/production/b317643f2350d1eb338e360bf104157b980b5a4b-973x378.png?w=450)


The PyTorch community organizes regular events, workshops, and hackathons, which not only help in spreading knowledge but also in building a strong network of AI practitioners. This collaborative environment has led to rapid advancements and extensions and libraries that build on the core capabilities of PyTorch. Their daily increase in Stars and Forks also indicates sustained community engagement and interest.


#### The Impact of Community in Open Source AI

The open source AI community exemplifies the core principles of open source: transparency, collaboration, and shared growth. By involving the community and encouraging contributions, projects have not only advanced the field of AI but have also created an inclusive environment where we see continued innovation and growth.


## The Balancing Act: Governance vs. Openness

In Drive: The Surprising Truth about What Motivates Us, DH Pink identifies purpose as an intrinsic motivator. This means if we feel that our opinions and work matter, we’re more likely to be motivated. When we allow our community to contribute to the decision-making process, they feel a sense of belonging to the open source community. 

Transparent decision-making and shared project roadmaps create psychological safety. Regular updates, open processes, and a common vision drive collective progress and innovation.

In [Evan You’s episode of the Secret Sauce](https://youtu.be/4_uYqae42uc?si=HUyoesl5jfY8KCcM), he talks about the responsibility of listening to the community and accounting for their feedback when making decisions: “So I am the BDFL [[Benevolent Dictator for Life](https://en.wikipedia.org/wiki/Benevolent_dictator_for_life)]. That's actually publicly stated in the governance documents in Vue. So I make the final calls. And if I want to, I can just say, this is the way we're going to go with. But if you look at our governance document, it's laid out in a way that says, okay, Evan is the project lead, Evan is the BDFL. He has the final call, but he has responsibility in listening to the feedback from community members and team members. I basically have the responsibility to make my best effort to take into account all the feedback from people who are stakeholders in the ecosystem. ”

Creating an environment where members feel safe to voice their opinions can build trust and cohesion. Request for Comments, or RFCs, are a great way to get the community involved. 

### What is an RFC?

An RFC is a formal document - or more likely in the case of open source communities, an open issue or repository devoted to RFCs - that outlines proposed changes, features, or enhancements to a project. RFCs invite feedback, suggestions, and discussions from the community on significant changes before any final decisions are made.


#### Why RFCs are Important for Open Source Communities

1. Transparency: RFCs make the decision-making process open and visible, building trust as members see their input valued.
2. Collaboration: RFCs encourage community members to contribute ideas, leading to better solutions and implementations.
3. Inclusivity: RFCs create a sense of ownership and belonging, motivating members to contribute when their feedback has a tangible impact.
4. Quality Assurance: RFCs facilitate thorough review and discussion, identifying potential issues and improvements.

You can check out [Rust-langs RFC Repo](https://github.com/rust-lang/rfcs) to see their well-documented and thorough process for an RFC.


## Collaborative Decision-Making and Forking in Open Source

An empowered community also always has the option to leave a project if they feel the vision of the project has changed or they’re not being heard.This is a strength of open source: the option to take what you love and leave.

Kelsey Hightower discusses this in his Secret Sauce Episode as well: “So when you say, hey, add this feature, add this thing that doesn't make financial sense for us, we can say no. And now you have somewhere to go. There's forks. There's [a fork of Terraform](https://app.opensauced.pizza/s/opentofu/opentofu). There's [a fork of Vault](https://app.opensauced.pizza/s/openbao/openbao). And the community can choose to go that way ... The other part, though, is when we say open source, that little fourth button that's at the top of GitHub, that's what a community has got to put their money where their mouth is. So if you're complaining about the license change, That means you're willing to step up, right? Fork the project, rename it, and keep contributing in a way that adds value for 10 years. And if you're not going to be doing that, then the price and the license change is justified.”


### The Power of Forking

Forking is a fundamental part of open source that empowers communities to take control of their open source participation. When a significant portion of the community disagrees with the direction of a project, they have the option to fork the repository. Forking allows developers to implement their own vision and address issues they find critical, which might not align with the original project.


### The Balance of Community and Governance

While forking is a powerful tool, it also underscores the importance of balanced governance in open source projects. Effective governance structures that prioritize transparency, inclusivity, and responsiveness can decrease the need for forks by addressing community concerns proactively. Projects that successfully balance strong leadership with active community involvement tend to maintain cohesion and attract long-term contributors.

The option to fork a project reflects the strength and dynamic nature of open source communities. It ensures that the voices of contributors are heard and that the evolution of the project can continue even with disagreements.

## Final Thoughts

Open source communities are more than just a collection of contributors; they are dynamic ecosystems driven by shared goals, mutual support, and evolving motivations. These communities thrive on the principles of transparency, collaboration, and inclusivity, creating spaces where innovation happens and learning never stops.

But we have to acknowledge that these communities are not without their challenges. As we’ve seen, maintaining engagement, balancing governance with openness, and managing the diverse motivations of contributors are ongoing struggles. These challenges, however, are also opportunities. They push us to rethink how we create space for belonging, how we communicate, and how we make decisions.

The stories of contributors like Tyler Williams and the insights from Dave Kiss and Kelsey Hightower remind us that the strength of open source lies in its people. It’s in the willingness to mentor, the courage to fork a project, and the drive to contribute to something larger than yourself. These elements create the unseen currents that push open source forward.

As we look to the future, we must continue to invest in these communities—not just in terms of code, but in terms of human connection. We need to create environments where contributors feel valued, where their voices are heard, and where their contributions matter. This requires a delicate balance of governance and openness, a commitment to transparency, and a focus on building strong, supportive networks.

In the end, the true power of open source is not in the software itself, but in the community that builds it. By embracing this, we can navigate the challenges and cultivate thriving, resilient open source communities that drive innovation and make a lasting impact on the world.







Learn about the importance of belonging, motivation, and collaboration in open source community.

Cultivating Open Source Community

OpenSauced is strategically positioned for what I call generational shift happening in open source right now. Open source is no longer just nights and weekends, but rather critical pieces of our infrastructure and data pipelines. Not to mention the rate at which AI is accelerating, the industry is now more concerned than ever about trust, safety, and compliance in open source. 

I am excited to announce a round of funding led by [boldstart ventures](https://boldstart.vc/) with participation from the [GitHub Fund](https://m12.vc/news/announcing-the-m12-github-fund/), [Precursor Ventures](https://precursorvc.com/), [basecase capital](https://basecase.vc/), Nat Friedman, Guillermo Rauch, Matt Biilmann, Chris Bach, Tom Preston-Werner. Very Special thanks to [Ellen Chisa](https://boldstart.vc/team/ellen-chisa/), who has not only become our day-one partner, but became my advocate for the OpenSauced vision even before our first check. 

## Why now?

I had the privilege of working at GitHub supporting the largest open source projects by building relationships with the maintainers and getting their feature requests in the GitHub public roadmap. I remember sitting in a meeting with members from a Kubernetes SIG requesting access to more data. They built their own dashboard for the consumption of actionable devstats. Kubnernetes was not an overnight success, as I learned from [Brendan Burns](https://www.youtube.com/watch?v=0MeGKxjv3P4&) and [Kelsey Hightower](https://www.youtube.com/watch?v=MQbkN99eBD8); instead it was a group of data-driven contributors that could identify trends in their adoption.

## Here is a trend I see 

[pgvector](https://app.opensauced.pizza/s/pgvector/pgvector?range=180) is single-handedly adding multiples to the valuations of database startups, but who is actually maintaining? Looking at the last 6 months, 60% of the contributions that landed on main have come from the co-founder of Neon database.    

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

We built OpenSauced to make it easier to find insightful trends like these, but our next mission it to make them even more discoverable and actionable with AI

## Introducing StarSearch

Back in the '90s, I sat on my grandma's couch watching the show with the same name discover Beyoncé before she was famous. 

[StarSearch](http://oss.fyi/starsearch) comes from that same idea of discovering developers using clear trends and inflection points in open-source contributions while sitting on your grandma's couch. I shared a brief demo on stage at React Miami last month as a response to a tweet from Adam Wathan, who was looking to connect to Tailwind devs with a passion for Rust performance. Below is a brief demo of it, which shares a list of developers who met Adams's criteria.

[![star search example](https://gist.github.com/assets/5713670/0fc5b396-acda-4873-bf1d-fd4f5169720e)](https://www.youtube.com/watch?v=gbkiekEbdE8)

Our secret sauce on [how we do this using vLLMs](https://opensauced.pizza/blog/how-we-saved-thousands-of-dollars-deploying-low-cost-open-source-ai-technologies) is shared in a recent blog post from our John McBride, and excited to open sourcing more of this journey.

So far our customers are really excited about what StarSearch unlocks for them.

“I'm loving how the @saucedopen team are using tons of unstructured GitHub data and helping orgs to start to unveil the nuances within open-source communities. And [how OpenSauced helps to] discover developers using clear trends and inflection points via their open-source contributions.”

[Dees, Mozilla Ventures]

"This is such a fantastic idea and execution. Being able to discover open-source projects and contributors is a potential game changer. This would be super useful for open source startups looking to find contributors, or partnerships in the OSS community. Really super stuff. Well done!”

[Jian, Snaplet]

What’s Next?
We are now actively having conversations with Startups and Enterprises about how we can solve the pain point of actionable insights powered by this groundbreaking AI innovation. 

If you are interested in seeing a demo on what we are working on cal.com/opensauced

Stay Saucy.


OpenSauced raised funding to further develop your AI technology that provides actionable insights for the open source community.

OpenSauced raises 3.5 million from Boldstart, GitHub and more 


As it stands today, the open source ecosystem can feel disconnected. Theoretically, we know that there are maintainers, contributors, and projects out there that are incredibly talented and innovative, but finding them can feel like searching for stars in a cloudy night sky. Sometimes you need to have that information – and fast – to be able to maintain your own projects. 

## The Challenge of Open Source Connections

Imagine you're at a tech company using cutting-edge technology. You need to upstream some important changes to ensure future compatibility but you find yourself hitting a wall. Who exactly should you reach out to? Who are the key contributors with the right expertise? Traditionally, this process would involve a lot of guesswork and detective work, looking through commit histories or issue discussions. Enter [StarSearch](https://app.opensauced.pizza/star-search), designed to change how we discover and connect with others in the open-source universe. With StarSearch, in just a few clicks, you’re able to identify key contributors skilled in that technology and maintainers who may have the answers you need. StarSearch isn’t just a tool; it’s your entry point into a more intimate, interconnected open-source community. 


## Introducing StarSearch

StarSearch leverages advanced analytics and AI, all fueled by real-time data from GitHub Events. StarSearch isn’t just about identifying who committed what; it’s about understanding the dynamics and interactions within the open source community. 

> **We’re live on [Product Hunt](https://www.producthunt.com/products/opensauced)! Join the conversation and share your thoughts.**

### Connecting with StarSearch

Here’s how StarSearch addresses some of the common queries and needs within the community:

- What type of pull requests has {username} worked on?
- Who are the best developers that know {technology} and are interested in {technology}?
- Who are the most prevalent contributors to the {technology} ecosystem?
- Show me the lottery factor for contributors in the {repository} project?

These questions can be the starting point for building stronger projects and communities, allowing us to find people with passion and expertise that we may have never connected with before. 

## Learn More About StarSearch

You can check out more about our approach and process, as well as the resources:

- [Building a Copilot for Git History with pgvector and Timescale](https://www.timescale.com/blog/how-opensauced-is-building-a-copilot-for-git-history-with-pgvector-and-timescale/)
- [How We Saved Thousands with Open Source AI Technologies](https://opensauced.pizza/blog/how-we-saved-thousands-of-dollars-deploying-low-cost-open-source-ai-technologies)
- [Meet StarSearch: Your New Open Source Navigator](https://opensauced.pizza/blog/meet-starsearch)
- [StarSearch Docs](https://docs.opensauced.pizza/features/star-search/)

#### Watch our "What is StarSearch" Video
[![what is starsearch](https://cdn.sanity.io/images/r7m53vrk/production/4e056c9d8482c034f03615093788099611ee8757-256x141.png?w=450)](https://www.youtube.com/watch?v=I3cS-u_gmDE)

## The Future of StarSearch

StarSearch provides a nuanced view of the open-source landscape. It’s more than a tool; it’s a new way to navigate the open-source ecosystem, bringing clarity, connections, and community to our tooling and making the open source ecosystem feel more like a tightly knit community where everyone knows your name – and your code. And we're just getting started. We have big plans for the future of StarSearch.

If you’re ready to find a new way to connect, [sign up for OpenSauced](https://app.opensauced.pizza/) and be among the first to explore the future of open-source collaboration with StarSearch today.



Explore how StarSearch revolutionizes open source collaboration by connecting projects with top talent using AI-driven insights into GitHub events and contributor activities.

StarSearch: Creating Open Source Connections

It’s 2:36am on a Sunday morning. You’re on-call and your pager is going off with a critical alert. You flip a light on, roll out of bed, and groggily open your laptop. Maybe it’s nothing and you can go back to bed, addressing whatever it is in the morning. You log on, silence the alert, and start digging into whatever’s going on. Something’s obviously not right: clients don’t seem to be connecting to your databases correctly. Or there’s some problem with the schema, but that wouldn’t make sense since no one should have pushed changes this late at night on a weekend. You start sifting through logs. You feel your pulse pick up as you notice strange logs from the databases. Really strange logs. Connection logs from IP addresses that you don’t recognize and aren’t within your VPC. Clients still aren’t able to connect so you decide to use the “break-glass” service account to investigate what’s going on inside one of your production databases and debug further. Maybe there’s a weird configuration that needs updating or something needs to be hard-reset to start working again.

What you see startles you: every single row of your production database has garbled up messes of data, not the textual data you were expecting. Digging further in, you find a recent change to the schema and pushes from the database root account. One change in particular catches your attention: a new table called “ransom_note”. You pause, shocked, waiting to see if you’ll suddenly wake up from a bad dream. You cautiously begin to inspect the new table: _“SELECT COUNT(*) FROM ransom\_note”_ returns only 1 row. _“SELECT * FROM ransom\_note”_ reveals your worst suspicions: “*all your data has been encrypted, pay us 10 BTC to have the decryption key*”.

___

This is a nightmare scenario of almost every technology business owner, Chief Information Security Officer, and security red-team: a sudden and unexpected attack orchestrated through some unknown means that completely cripples your operations. Maybe it was a well orchestrated social engineering attack. Maybe it was an extremely unfortunate misconfiguration that let some bad actors into your networks. Or maybe it was a sophisticated supply-chain attack from one of the many hundreds of open source dependencies you have within your product’s stack.

Supply-chain attacks have become very popular among nefarious actors for a few reasons: open source software is used nearly everywhere and many open source maintainers are spread incredibly thin. Open source software has become the critical infrastructure of the commons that we all depend on today. But it’s not unlikely to find solo-maintained or completely abandoned projects that have millions of downloads and sit in the critical dependency path within the software-supply-chain of many large enterprise products.

A good example of this is the recent [xz supply-chain attack against ssh](https://en.wikipedia.org/wiki/XZ_Utils_backdoor): a malicious actor was able to inject a backdoor into ssh, a secure way to connect to other computers through a network, by adding nefarious code to the xz library, a lossless data compression library. In theory, if this had not been detected as early as it was, this would have given the nefarious actors a way to remotely execute code or gain access to any affected Linux computer. One thing that stands out in this example, like so many other supply-chain attacks, is the maintenance status of xz: it went relatively untouched with only a few people around to maintain it. Burned out, with no other volunteers, and very few resources to dedicate to the project, the attacker was easily able to slip in malicious code. Because of how burned out the maintainers were, the attacker automatically “inherits trust built up by the original maintainer”, using that good will to make nefarious changes.

For further reading and analysis on the tragedy of the xz attack, I highly recommend [this piece from Rob Mensching](https://robmensching.com/blog/posts/2024/03/30/a-microcosm-of-the-interactions-in-open-source-projects/).

While there’s no one catch-all solution for preventing these kinds of problems in open source, one piece of the bigger puzzle is the “Lottery Factor”: a metric that looks at open source communities and the weight and distribution of work being done by individuals within a project.

The way we at OpenSauced are defining the Lottery Factor is a follows:

> The minimum number of team members that have to suddenly disappear from a project (they won the lottery!) before the project stalls due to lack of knowledgeable or competent personnel. If 1 contributor makes over 50% of commits: Very high risk. 2 contributors make over 50% of commits: High risk. 3 to 5 contributors make over 50% of commits: Moderate risk. And over 5 contributors make over 50% of commits: Low risk.

The Lottery Factor can help uncover this sort of burnout and identify projects that need an injection of critical engineering resources. This can begin to give you an idea of how catastrophic it would be if someone who makes the majority of contributions in a project suddenly disappeared (because they won the lottery and went off to live their best life on the beach!). This may happen for any number of reasons and it’s important to note that the Lottery Factor is unique to each individual project: it’s not a hard and fast rule, but rather, another important metric in understanding the full story of a project.

With all that in mind, we are very excited to unveil the inclusion of the Lottery Factor in [OpenSauced Repo Pages](https://docs.opensauced.pizza/features/repo-pages/) as an additional metric and insight you can inspect!!

![analog repo page](https://gist.github.com/assets/23109390/f5fd4768-6b20-42a5-a763-6af69a32c6a1)

Through the lens of the Lottery Factor, we can begin to look at projects with a better understanding of where the critical “human” links in the secure software supply chain are, where funding resources need to be spent, and where to allocate crucial engineering resources.

In the [analogjs/analog](https://app.opensauced.pizza/s/analogjs/analog) example above, we can see that in the last 30 days, about 50% of contributions were made by ~2 contributors, 50% of that being [Brandon](https://app.opensauced.pizza/user/brandonroberts). This gives the overall Lottery factor as “High” and would start to unveil critical personnel in the Analog and Angular ecosystem.

An example of a project where the lottery factor is critically high is [core-js](https://app.opensauced.pizza/s/zloirock/core-js?range=90), a widely used JavaScript standards library in use by Amazon, Netflix, and many other Fortune 500 companies across the web:

![core-js repo page](https://gist.github.com/assets/23109390/329fc200-892f-4044-a6ed-fd0ef85be275)

Over the last 90 days, the core maintainer “[zloirock](https://beta.app.opensauced.pizza/user/zloirock)” has made the majority of the contributions. And, because of the wide adoption of core-js, this library could be a good candidate for an injection of critical resources to ensure the good standing and governance of the library.

Now, let’s look at a project with a “Low” Lottery Factor over the last year where there are no single individuals with the majority of the commits, [kubernetes/kubernetes](https://app.opensauced.pizza/s/kubernetes/kubernetes):

![kubernetes repo page](https://gist.github.com/assets/23109390/2d79b5b4-0f62-42be-a24e-3ccdaf8a593c)

Because there are so many different people from so many different companies invested in the success of the Kubernetes platform and the cloud-native ecosystem, it makes sense that there are no single critical individuals that would be the sole point of failure if they were no longer working on the project.

The Lottery Factor can help tell a story unique to each individual community and project. And it can help open source project offices, small teams, or individual contributors better understand the landscape of any open source project or piece of technology they depend on.

We at OpenSauced hope this can start to help you understand where the critical human factor is within projects you contribute to and depend on! Make sure to [check-out OpenSauced Repo Pages](https://docs.opensauced.pizza/features/repo-pages/) and stay saucey everyone!

Discover how the Lottery Factor identifies project risk by analyzing top contributors in popular open source projects, using insights from our newly designed Repository Pages.

Understanding the Lottery Factor

Many open-source projects, like [Facebook's Create React App (CRA)](https://app.opensauced.pizza/s/facebook/create-react-app), experience a familiar arc – a rapid rise followed by a perceived decline. In the last thirty days, CRA hasn’t had any merged pull requests. This begs the question: what happened to CRA?

[![pour one out for CRA](https://cdn.sanity.io/images/r7m53vrk/production/8b6ba3109f6a8d048e0ee9ac66a7ea93d2db79ca-590x411.png?w=450)](https://x.com/bdougieYO/status/1790796316773335135)

## Do we need Open Source Insights into Issues and Pull Requests?

While GitHub provides a wealth of data on issues and PRs (pull requests), a high-level overview can give us a better understanding of what’s happening. Let’s take a closer look at what’s been happening at CRA.

### Understanding Issues

With a high-level overview of the recent issues, we can get a better idea of how to triage and prioritize. Let’s take CRA, for example. 

[![PR Table](https://cdn.sanity.io/images/r7m53vrk/production/89d84b97c63cb39fe8e17dcbf2103473ac0cf4b4-1011x904.png?w=450)](https://oss.fyi/LVeBSCV)

*A couple of things stand out:*

#### Variety and Volume of Issues

The issues within CRA range from security vulnerabilities to user experience complaints. The recent security issues identified (tagged with CVE identifiers) point to a critical need for security updates, with user experience issues like configuration problems that might be solved by improved documentation.

#### Frequency of Issues

 A high frequency of new issues can be a double-edged sword—it might show an active and thriving community, or it could indicate problems with user experience and documentation. Likewise, a low frequency of issues could indicate a stable project or a dying project. In the last 30 days, CRA has had a total of 9 open issues and 10 closed issues. 

![issues](https://cdn.sanity.io/images/r7m53vrk/production/9cc14b87769ffe7fd0a294b9df73b6084673d971-430x157.png?w=450)

#### Community Interaction

The level of interaction within issue discussions can reveal a lot about the community’s health and the project's transparency. Sure, stars and forks can help us understand the activity level of the project, but they’re not always the most telling.

![engagement](https://cdn.sanity.io/images/r7m53vrk/production/9c946dde5b64f9aa6288d8088e131c3d8ec08eb1-407x138.png?w=450)

How are contributors interacting with the maintainers, and how are maintainers communicating to them? Sometimes the most revealing issues are the ones asking if a project is still supported, like this one from almost a year ago.

[![image](https://cdn.sanity.io/images/r7m53vrk/production/b1bb4b3d4e091ed582cf51494d8625890369d4b4-980x90.png?w=450)](https://app.opensauced.pizza/workspaces/1cb08c8f-1744-4a9a-8078-633fd588a6e0/issues?page=4&limit=50&range=360)

Taking a closer look at the variety and volume of issues, how often they pop up, and how everyone's talking things through really tells us what needs immediate attention and what can wait. This overview can help maintainers figure out the best steps forward—whether it’s jumping on a hot issue, scheduling something for a later fix, or just keeping the lines of communication open with the community on the status of your project. 

### Understanding Pull Requests

Issues don’t tell the whole story though. PRs help us to understand the vision of the project, the maintainers priorities, and the time that’s being put into the project. 

![PR Table](https://cdn.sanity.io/images/r7m53vrk/production/b4d2637cc2d2c23f0e08e0efd33bc98db225d6e1-999x754.png?w=450)

Here are some of the things we learn about CRA:

#### Look at the State

Over the last year, there have been 113 opened PRs and 2 merged.  In fact, to find when the last PR was merged, we have to go back to almost a year ago, with all other PRs "Open" or "Closed" (without merge).

[![PRs](https://cdn.sanity.io/images/r7m53vrk/production/87956af014ca226d593eaddf5dd72ee6b86507d2-310x105.png?w=450)](https://app.opensauced.pizza/workspaces/1cb08c8f-1744-4a9a-8078-633fd588a6e0?range=360)

#### Size and Scope

Pay attention to the number of changed files and the number of lines added/deleted. In healthy open-source projects, large PRs likely introduce new features or substantial changes, while smaller PRs might be bug fixes or documentation updates. Ideally, you’ll have a mix of sizes and give you a sense of the project's priorities and development lifecycle. Recently, with CRA, we see mostly very small fixes with under ten changes. In other words, there’s low activity on the repository when looking at PRs.

#### Freshness

Another indicator of project health is how recently PRs were updated, created or closed. For a hugely popular project like CRA ( 102k stars, 26.6k forks, 1.9k watching), we’d expect a lot of activity, but, instead, we’re seeing little to no changes, even with simple fixes like updating a broken link. 

### Leveraging Open Source Insights for Strategic Decisions

The real power in these insights is that it allows us to be more strategic about our decisions, ultimately increasing our productivity, allowing us to:

- Allocate resources more efficiently, prioritizing high-impact tasks.
- Enhance the community’s involvement by addressing the most pressing concerns promptly.
- Predict potential bottlenecks and prepare solutions in advance.

We've explored how PRs and Issues can unlock a deeper understanding of Create React App. But maybe the real question is: Can this approach be applied to predict future trends in the React ecosystem itself? Think about it. By analyzing the types of feature requests and bug fixes, can we get a glimpse into the challenges and pain points that developers are facing? Can we use what we see in our own projects and compare that to the ecosystem to get a better understanding of how we can succeed? There's no answer yet, but the future is there.

[![CRA - 6 months](https://cdn.sanity.io/images/r7m53vrk/production/0c323088fe3663d37e01c3a6ec06bf6d7c0f2589-1002x468.png?w=450)](https://app.opensauced.pizza/workspaces/1cb08c8f-1744-4a9a-8078-633fd588a6e0?range=180)

I think it’s safe to say we can pour one out for Create React App, but what’s next, then? 

Like most things in tech, I think the answer is *it depends*. The closest replacement might be using Vite with a React Template, but there are more options to consider [on this list](https://oss.fyi/CRA-Alts). None are an exact replacement for CRA, but they are options that can get you up and running for simple single page apps to more complex full-stack projects. 

What would you add to this list? Laravel, maybe 😉

If you are interested in better metrics for measuring open-source success, consider creating [a workspace](http://app.opensauced.pizza/start) or explore the [CRA Workspace](https://oss.fyi/LVeBSCV) I used to write this post.



Explore the lifecycle of Facebook's Create React App (CRA) and understand the significance of open-source insights into issues and pull requests.

Pour One Out for create-react-app - What's Next?

The world runs on open source, but we know the [challenges of burnout](https://opensauced.pizza/blog/stop-burning-out-maintainers:-an-empathetic-guide-for-contributors), the [need for support](https://opensauced.pizza/blog/enhancing-support-for-open-source-maintainers), and [loneliness](https://opensauced.pizza/blog/the-lonely-journey-of-open-source-maintainers). Despite all those challenges, new open source projects are appearing every day. We need to support new maintainers as they learn to maintain in the fast-paced open source ecosystem experienced maintainers are accustomed to. If we want growth, innovation, and solutions to our problems, we’ll need to have a supportive environment for new maintainers. And this is why we need to educate and support new maintainers.

> If you want to learn more about becoming an open source maintainer, best practices, and tips and tricks for enhanced productivity and community collaboration, check out our new [“Becoming a Maintainer” Course](https://oss.fyi/new-maintainer) 

## The Maintainer Learning Curve

When I started maintaining my first project, it wasn’t super popular, but I had enough contributors to feel overwhelmed. I didn’t have all the answers, my issues weren’t perfect, and I wasn’t sure what direction the project was going. Don’t get me wrong, it was a great experience and I formed bonds that I couldn’t have otherwise, but I could have been better prepared. I could’ve thought about how I would showcase the roadmap that was in my head. I could have written clearer issues. And I’m sure I could have made things easier on myself as I supported a lot of brand new contributors to a React Native repository. 

This isn’t a unique story. There are many new open source projects popping up every day. Some maintainers have prepared for that launch, others are just trying something new, and others suddenly find their personal project gaining interest beyond what they ever imagined. But if you’re not prepared, you can feel overwhelmed by the responsibilities really quickly especially with a lack of structure support and without mentorship. The good news is that it’s ok, and you can still succeed. Take Liyas Thomas, the founder of [Hoppscotch](https://app.opensauced.pizza/s/hoppscotch/hoppscotch) who started the project as a way to solve a problem he was facing and to enhance his resume. Not only is his project still going, but he’s now the CEO of that passion project. 

We don’t want you to feel alone. We want you to have a success story too and to make sure new maintainers feel supported and understand the nuances of being a maintainer. This is why we created our [“Becoming a Maintainer” Course](https://oss.fyi/new-maintainer) and have a channel in [Discord](https://discord.gg/opensauced) for folks who have taken our courses. We want you to be supported and to be able to network with contributors. We want to make sure if you have questions, we can find you answers.

## Growing as a New Maintainer

It can feel like a big leap from contributor to maintainer, but it doesn’t have to be. One of the top challenges is realizing that as a maintainer, your role is utility player: you’re often writing code, creating issues, managing projects, engaging with your growing community, and leading a whole project. In essence, you’re nurturing a project, ensuring the code and quality, supporting the community, and providing direction.

There’s a difference between becoming a maintainer for an existing project, and becoming a maintainer for a new project. You’re more likely to have support, mentorship, and some sort of strategy or map if you’re coming into an existing project. But when you’re coming into or starting a new project, you’re developing your own map, finding the tools that you’ll need for the journey, and navigating through unknown terrain. But you don’t have to be on that journey alone. 

Utilize the resources available to you, reach out to other maintainers, and find seasoned contributors who are willing to provide you with feedback. You’re never alone in the open source ecosystem. Understanding what it takes to manage the technical and social aspects of open source projects can help you be more successful. Learning the tools and tricks whether from resources or other maintainers can decrease the barrier to entry, help you to create a stable project, and help you to create momentum.

By cultivating your own community and having a growth mindset when it comes to your project will help you to avoid loneliness that can come with maintaining a project. It will also help you to have a good understanding of how to support your potentially growing community. You’ll learn how to establish clear paths of communication and to create a welcoming environment. You’ll learn how to interact with and support external contributors. You’ll learn how to cultivate a community that maintains high standards of code quality and documentation. What I’m trying to say is, you’ll learn a lot through this experience. You might even find your project growing. And when that happens, you’ll learn new things too.

You’ll learn how to identify potential contributors and team members who can help to drive your project forward within the goals and community needs you've set. You’ll understand how to identify potential contributors who bring value to the project, mentor them as collaborations, and you may even find that they become maintainers themselves.

### The Power of Positivity (and Maybe a Cat Video Break)

Maintaining a project can also require a healthy dose of optimism and resilience. There will be days that test your patience, but remember, with each roadblock you overcome, you're making the project stronger and more reliable. And hey, when things get tough, don't underestimate the power of a well-timed cat video break.

### Becoming a Thought Leader: Share Your Wisdom

As you gain experience and insight into open source maintenance, share your knowledge with others. Write blog posts, create tutorials, or answer questions on forums. Not only will you be helping others, but you'll also be solidifying your own understanding and enhancing your credibility in open source. 

Becoming a maintainer is a challenging but incredibly rewarding journey. Embrace the learning, connect with other maintainers, and remember, a positive attitude (and maybe a cat video stash) can go a long way. 


## Ready to Level Up Your Maintainer Skills?

Are you interested in starting your open source project but want more support? We've got you covered! Check out our comprehensive [Becoming a Maintainer Course](https://oss.fyi/new-maintainer), packed with expert tips, tricks, and best practices to support you on your journey. Plus, once you've completed the course, head over to the maintainer guestbook and add your project so we can amplify the hard work you’ve done and connect you to more of the open source community!


 Feeling overwhelmed as a new open-source maintainer? Learn the skills and gain the support you need to succeed with our "Becoming a Maintainer" Course.

Nurturing the Future of Open Source: Maintainers

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://app.opensauced.pizza/u/shanselman) and [Kent C. Dodds](https://app.opensauced.pizza/u/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://app.opensauced.pizza

[![image](https://cdn.sanity.io/images/r7m53vrk/production/55f4006192a184bac60a13aaa3031abe1be10b4f-2464x1390.png)](https://app.opensauced.pizza/explore/topic/javascript/dashboard/filter/recent?range=7)


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](https://app.opensauced.pizza/) - learn more about how to use OpenSauced to grow your contributor journey [here](https://oss.fyi/contributors-guide). And, of course, if you are looking for new contributors to your project, do not hesitate to share your repository page (like ours [here](https://app.opensauced.pizza/s/open-sauced/app) in our [community show-and-tell](https://github.com/orgs/open-sauced/discussions/categories/show-and-tell).



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.

Product Update: List Feature

Isa Bensusan