Gamify Open Source Contributions

What's oss.gg 🕹️, why we need it and how you can become a part of it

The concept of oss.gg 🕹️ emerged from a common challenge faced by many open source founders and maintainers: the struggle to balance community contributions while fully focusing on developing the core product. In this write-up, we'll walk you through the most common problems around community contributions, what has been tried to solve them, what worked well and how oss.gg 🕹️ tries to innovate in this space. Grab a coffee, get comfy and and dive in ☕

Around 18 months ago, we released snoopForms - the Open Source Typeform alternative. Within days, we had people request features and offer contributions to make snoopForms better. While we loved the spirit, we quickly experienced the challenges that come along with running an open source community.

Our experience isn't unique. As we are building Formbricks, we got to know many more open source founders and all of them have a similar experience. These are 8 problems we all face, in some variation:

This is a slide from a talk Johannes gave at the Open Core Summit in San Francisco. Here is the talk:

If you prefer watching a video, the talk give you a good understanding of what oss.gg 🕹️ is meant to become.

If you like reading, this article walks you through the concept as well:

1. Open source communities have changed and need new tools
2. The problem(s) of open source communities
3. What's been tried (and what we've learned)
4. oss.gg 🕹️ - the concept
5. oss.gg 🕹️ - the tech
6. How can you become a part of it?

What's the purpose of this blog post?

We want to convey what we have and mind and why we're building it. And we want you to join us!

There is something in the air right now, lots of people work on different ideas to one or several of these problems. Most do it as a side project, which likely won't work out, because community stuff is hard. The idea is to bring everyone onto the same page so we can move forward with a joint understanding and build something that works together. Evrything laid out in this article is up for discussion, it's supposed to get you involved 😉

The Open Source Renaissance and what it did to communities

With the rise of hugely popular app-based open source tools like Supabase, Appflowy, Cal.com (and Formbricks obviously 😋) Open Source Software (OSS) experiences a renaissance. And it seems that this significantly impacts the composition of open source communities:

Five years ago, open source contributions were mostly done by experienced engineers with domain expertise who wanted to bring a new technology to the world.

Today, this cohort is outnumbered by young, aspiring engineers predominantly from India, Pakistan, Nigeria, Kenia and several other countries throughout Africa. They are mostly interested in working on a product with real users, learn new technologies, learn from more experienced product people and engineers and build a portfolio of contributions to land a job in tech.

When the community changes, a new set of issues arises. These issues call for a new set of tools, one of which is oss.gg 🕹️ - but let's look at what we're solving first:

The problem(s)

With a new set of community members contributing to open source, we see a new problems:

1. Handholding required: Many of the engineers wanting to contribute have little experience in software engineering or web development. They ask a lot of questions, get stuck, need help. While maintainers are usually happy to help the first set of contributors, it quickly gets out of hand. We've referred juniors to ChatGPT a lot, but some things need to be explained. While it's fun to teach, we have to make sure the efforts are not in vain because the contributor does not stick around.
2. Seniors leaving: Every now and then, a more senior engineer gets excited by a project and contributes. That's obviously really cool and valuable. The issue? They usually don't stick around. While it's not an issue that a company with a commercialisation interest maintains a project (vs. a completely free and community-run project) these seniors make 1, 2, 3 contributions and then ask themselves, why they are spending their evenings and weekends creating value which will be harvest by someone else. Curiosity and altruism only go so far. So why not pay them?
3. Incentive dilemma: Incentives are a funny thing because they can shift the mental model for looking at something. There is lots of research proving that a financial incentive can lower the motivation for a specific task, because it takes the aspects of reciprocity and signalling out of the picture: If I receive money for it, I won't get a favour back nor can I tell myself I worked for the greater good and feel good about it. This, and the short-term thinking attached to doing the minimum to get the financial reward make it difficult to just hang a price tag to an issue and wait for someone to fix it properly. In most cases, it's a quick and dirty patch.
4. Review overhead: Most tools of the Open Source Renaissance are maintained by small teams. These teams are busy shipping features requested by their design partners or large clients because after all, they are who keep the project alive. Reviewing community contributions generally and submitted by junior devs unfamiliar with the code base is verrry time-consuming. We have to minimize the effort reviews take to make the whole effort worthwhile.
5. Manual recognition: People keep coming back when they feel recognized. It not only feels good to be appreciated for the time invested but is also an important signal, for both side: Contributors can showcase their work publicly (and share it) and projects show that their project is actively contributed to. Win win. The only issue? It's time-consuming to keep track, write content and find the social handles of contributors to tag them. This can be semi-automated.
6. Hard to flex: Along with the projects effort to recognize contributors, these contributors have a hard time flexing with their contributions. There isn't really a good plaform to do that. Important contributions on GitHub profiles get lost in other activity. CVs are outdated. Contributors want a publicly accessible page where they can collect contributions like stickers.
7. Assignment overhead & redundant work: Keeping track of who works on which issue can get messy with an active community. We ran a hackathon with a Macbook prize and for every issue we released we had 5 people who wanted to work on it. First come, first assigned works well, until people claim issues and don't deliver. This can be solved by automating the enforcement of rules such as “If you don't open a draft PR within 48h, we will assign the issue to the next developer in line”.
8. Unfinished PRs: Along the lines of the previous problem: If contributors drop out, maintainers have to notice. To be able to do that we have to monitor all issues manually. It'd be much easier if a GitHub app would do that for us.

What has been tried so far

The FormTribe hackathon

The idea of building a large-scale distributed learning game is already a couple of months old. In October, we (the Formbricks team) ran a month-long gamified hackathon. It was great fun and worked really well! We gained:

• 100 contributors 👩‍💻
• Shipped 12 relevant features
• 2.000 GitHub stars ⭐
• 500 new Twitter followers 🐓
• 400 new Discord members 🤖
• 5 engineers became core contributors 🤍
• YouTuber with 60k followers reported due to Hackathon

What have we learned?

Having so many developers pull on our repo led to a few great insights:

• It crystallised our understanding of the problems in the space, as laid out above
• Points work (if they have a value). People really made sure to collect all points they earned
• Non-code contributions are picked up and appreciated
• Manual overhead was unsustainable
• There is enough excitement for it to be worth building a system

Novu's Hero Directory

Novu built a pretty cool directory for their community heroes.

Each contributor automatically gets a page with their contributions with data being pulled from the GitHub API. People really appreciate that, both contributors and other OSS founders - well done 😎

Algora's Bounty System

The Algora team did a great job building a well-functioning GitHub app as well as attracting a community of bounty-hungry contributors. However, tying back to what I wrote above about incentives, I don't think it solves the right problem. In our experience (and what I've heard from other projects) it's not hard to find people who want to contribute. It's much harder to handle the contributions and keep people familiar with the code base engaged over longer periods of time. To some extent, bounties make the situation worse by sending engineers our way who are only looking for a quick buck. They tend to be more spammy and push for a quick review of their half-baked code. This might sound harsh but it has been exactly our experience.

We strongly believe in bounties and they are an essential element of oss.gg 🕹️ but they have to be wrapped in a bigger picture (see below).

Please note: I'm fully aware that many projects are happy with Algora and their success justifies their approach :)

What is oss.gg 🕹️?

So far we looked at the problems and what has been tried to solve some of them. Let's now have a closer look at how we imagine oss.gg 🕹️ solve for all of the problems above.

oss.gg 🕹️ - the concept

To address all of the issues above, we leverage two things: Levels and Automations.

Levels

Levels usually come with a set of abilities and limitations, which comes in really handy. Here are the levels we came up with at Formbricks, but each project will be able to come up with their own levels which align with their brand voice and ideas:

The beauty of levels is that they make it very easy to communicate and understand who is allowed to do what. Here is an overview:

How does this help us? Let's look at the problems:

• Handholding: By limiting who can get assigned to e.g. issues for end-to-end features, we limit the requests for handholding significantly. We know that every “Deploy Deputy” already went through a set of DevRel related tasks so is somewhat familiar with the code base and tech stack. Secondly, we can filter out a lot of the “I can quickly ship this” engineers. Additionally, we as a team don't have to help dozens of engineers set up their development environment by limiting support to GitPod when contributors are getting started.
• Seniors leaving + incentive dilemma: Earning the right to be paid for contributions has a lot of positive side effects. We exclude the “quick-buck-engineers” and reward sticking around our community. Everyone in the Pushmaster Prime level has merged several PRs in our repo so we know they are familiar with the code style and capable. This allows us to pay out high bounties without having to fear a lot of spam in out repo and Discord.

These are only a handful of very basic ideas of what you can do with levels. Super excited to see what other projects will invent and implement 🤓

Leveling up, merch and moments of celebration

A core aspect of building a community people love is sharing moments of celebration with others. As an aspiring open source contributor, there are a few moments we want to celebrate together: The first PR getting merged, the first bounty earned, etc.

Secondly, handling merch is kinda annoying: You have to determine who gets merch, when and why. We decided to just tie it to leveling up, so that we can semi-automate it. If a user levels up, we check if their address is added and if not, we ask them to update it. Once this is done, we can order their merch (or even automate that as well).

Automations

The second big advantage of oss.gg 🕹️ is that you can automate many of the tedious tasks - while making sure that the personal touch is not getting lost. The key here is to strike the right balance.

Here is an example for what happens when a new issue is released which is flagged as a community issue:

As you can see, most of the overhead is automated away. We go from Issue → Review without anyone in our team having to touch the issue on GitHub. Especially when the number of issues grows, this will come in super handy.

Here is another one: The Merge Celebration Flow.

It nicely shows how the community management side can get automated without losing the personal touch. You get the idea!

oss.gg 🕹️ - the tech

Now that we have an understanding of what we want to build and why, let's talk about the how. oss.gg 🕹️ consists of 5 different parts:

1. A web app +
2. An API +
3. A GitHub app +
4. A bounty system +
5. An automations interface

Let's go through them one by one:

1. A Web App

The heart of oss.gg 🕹️ is a web app. Both contributors and projects can sign up to preform a set of actions. Here is a preliminary overview of what people can do with the web app:

Contributors

• Sign up
• Add their social handles (to be tagged in shoutouts)
• Add their address (to receive merch)
• View a feed of issues they can work on
• Add their info to receive bounty payouts
• Manage notification settings (alerts for issues they are eligible to work on)

Maintainers

• Manage API keys
• Manage rights for different levels contributors can reach
• Manage players

2. An API

The API provides all oss.gg 🕹️ related info so that the projects can display them on their community pages. Think of it as an enrichment layer over the GitHub API. It serves:

• Points per contributor
• Contributor Level
• Contributor Rank
• Contributor social handles and addresses to build automations

This allows projects to build dynamic community pages like these easily: formbricks.com/community

3. A GitHub App

The GitHub app takes over many of the tasks which currently require manual work. It makes the following things easy:

• Assign first contributor to issue, if eligible (has enough points / level required for this issue)
• Unassign and reassign if contributor doesn't ship
• Follows up with dormant PRs
• Makes awarding points easy “/award 500 points”
• Makes tipping easy “/tip 10$”
• Create new bounty “/bounty $50”

4. A Bounty System

Shoutout to Bailey who built a low-fee bounty system for the OSSHack in NYC. It's a very convenient and inexpensive way to pay out bounties worldwide. We'll leverage that for anyone who wants to open a bounty for an issue.

5. An Automations Interface (later on)

Create automations based on triggers like “Contributor reaches new Level” or “Contributor reaches X points” or “First contribution” etc. These automations help us provide a personalized community experience at scale, because we can e.g. create a new Linear ticket for the Marketing team containing all info needed to write a tweet and send a personal message to the contributor within 60 seconds.

The oss.gg 🕹️ stack

• Next.js (React) + Typescript
• TailwindCss + ui.shadcn.com
• PostgreSQL + Prisma
• trigger.dev for automations
• If you're building something open source which fits in here, please reach out :)

What is the status quo?

We've shipped the core for this launch so that we as a community can pick up the fun stuff right away. Here is a broad plan forward:

Phase 1: To keep iteration cycles short, we limit the number of projects who can participate to 2 (Formbricks and oss.gg). This allows us to build a solution which is somewhat generalizable (vs. Formbricks-specific). And less people involved = faster shipping speed! Once we have figured what works well we move to Phase 2.

Phase 2: We open oss.gg 🕹️ up to a total of 5 select projects. These projects commit to work closely with the community by providing sufficient open issues for the community members to work on.

Phase 3: Opening up to more and more projects. When and how will be determined in the future.

Sounds good? Let's make this happen!

Join our Discord and say Hi 👋Check out FigmaStart playing

Open Key Roles

You want to play a bigger role in this? We love that! Currently, we're looking for:

Design Dude(ette) 🧑‍🎨

Build more UI and master the Figma file (relevant xp required, great oppo to extend portfolio)

Community Magician 🧙

Seed this community well, right from the get go

Automations.dev 🤖

If it needs automation, you'll solve it Chigala ✅

Bounty Bunny 🐰

Build the bounty system and maintain it

Apart from that, we'd love to onboard several PMs and Full-stack Engineers.

oss.gg 🕹️ is a community project, so it is not designed to make money. Nontheless, to take over responsibility, it makes sense for you bring at least a bit relevant experience i.e. you can somehow showcase that you're up for the task 🙌

Sounds fair? Let's get this party started 🪩👇