My Journey: Contributing to Open Source AI as a Non-Committer

Hey everyone, Kai Nakamura here from clawdev.net. Today is May 17, 2026, and I’m buzzing about something that’s been a constant source of both frustration and immense satisfaction in my own AI dev journey: contributing to open source projects, especially when you’re not a core committer (yet!).

We all talk about open source like it’s this magical, self-organizing utopia where code just flows. And in many ways, it is. But for newcomers, or even seasoned devs looking to branch out into a new library or framework, the path to making your first meaningful contribution can feel like trying to find a specific grain of sand on a vast beach. It’s not always about grand new features; sometimes it’s about that tiny, annoying bug you hit repeatedly, or a documentation typo that throws you off for an hour.

I’ve been there. My first real dive into contributing to an AI-related library was a couple of years ago. I was using a less popular but really elegant reinforcement learning library – let’s call it `AIEngineX`. I kept hitting this weird edge case where the environment reset wasn’t quite clearing the previous state in a multi-agent setup, leading to some bizarre, unexplainable agent behavior. I spent days debugging my own code, thinking I was just bad at RL, only to finally trace it back to a subtle bug in `AIEngineX`’s `reset()` method. My initial thought? “Ugh, this library is broken.” My second thought, after cooling down? “Okay, Kai, you found it. Now fix it.”

That experience, which started with irritation, ended up being incredibly empowering. It taught me that contributing isn’t just for the gurus; it’s for anyone who uses the software and cares enough to make it better. And that’s what I want to talk about today: practical strategies for making your mark on open source AI projects, even if you feel like an outsider.

Finding Your First Open Source Contribution: Beyond “Good First Issues”

Everyone says, “look for good first issues.” And sure, that’s a decent starting point. But let’s be real, those issues are often snapped up fast, or they’re so trivial they don’t really teach you much about the project’s internal workings. My approach has become a bit more organic, rooted in my daily development work.

1. The “Scratch Your Own Itch” Method

This is my favorite. If you’re using an open source AI library or framework, you *will* encounter friction. Maybe it’s a bug, a confusing error message, an missing feature that would make your life so much easier, or documentation that’s just plain wrong or incomplete for your use case. These are goldmines for contributions.

Think about it: you’ve already invested time in understanding the problem because it directly impacts your work. You have a real-world use case for the fix or improvement. This gives you context and motivation that a generic “good first issue” might lack. For me, that `AIEngineX` bug was exactly this. I needed it fixed for my own project, so the drive to understand the codebase and implement a solution was strong.

Example: I was recently building a custom data loader for a PyTorch-based vision model. The `torchvision.transforms` module is fantastic, but I needed a very specific augmentation that involved dynamic cropping based on object detection bounding boxes, which wasn’t directly available. Instead of just writing a standalone utility for my project, I took the time to wrap it as a `torch.nn.Module` and considered how it might fit into the existing `transforms` API. I then opened a discussion on the PyTorch forums, not with a full PR, but with a proposal and a small code example of my custom transform. The feedback was great, and it’s now a potential candidate for a future contribution.

import torch
from torchvision import transforms
from PIL import Image

class DynamicBBoxCrop(object):
 """
 Crops the image based on provided bounding box coordinates, with optional padding.
 """
 def __init__(self, output_size, padding_factor=1.2):
 assert isinstance(output_size, (int, tuple))
 if isinstance(output_size, int):
 self.output_size = (output_size, output_size)
 else:
 self.output_size = output_size
 self.padding_factor = padding_factor

 def __call__(self, img, bboxes):
 # bboxes expected as [x_min, y_min, x_max, y_max] for a single object
 if not bboxes or len(bboxes) == 0:
 # If no bbox, return center crop or original image
 return transforms.CenterCrop(self.output_size)(img)

 bbox = bboxes[0] # Assuming one primary bbox for simplicity
 x_min, y_min, x_max, y_max = bbox

 # Calculate center and dimensions
 center_x = (x_min + x_max) / 2
 center_y = (y_min + y_max) / 2
 width = x_max - x_min
 height = y_max - y_min

 # Apply padding factor
 padded_width = width * self.padding_factor
 padded_height = height * self.padding_factor

 # Determine crop coordinates
 crop_x_min = int(max(0, center_x - padded_width / 2))
 crop_y_min = int(max(0, center_y - padded_height / 2))
 crop_x_max = int(min(img.width, center_x + padded_width / 2))
 crop_y_max = int(min(img.height, center_y + padded_height / 2))

 cropped_img = img.crop((crop_x_min, crop_y_min, crop_x_max, crop_y_max))
 return transforms.Resize(self.output_size)(cropped_img)

# Example Usage (conceptual, assuming 'img' is PIL Image and 'bboxes' is a list of lists)
# img = Image.open("my_image.jpg")
# sample_bboxes = [[50, 60, 150, 180]] # Example bbox
# dynamic_cropper = DynamicBBoxCrop(output_size=224, padding_factor=1.5)
# transformed_img = dynamic_cropper(img, sample_bboxes)

This transform, while specific, solves a real problem for me. And by thinking about its broader application, I’ve laid the groundwork for a potential contribution.

2. Documentation is Code Too (and Often Easier)

Seriously, don’t underestimate the power of documentation. AI libraries are complex. Their APIs can be intricate, their examples might not cover every edge case, and installation instructions can quickly become outdated. Fixing a typo, clarifying a confusing paragraph, adding a missing parameter description, or even writing a small example for a less-used function can be incredibly valuable.

My first official merge into a major library wasn’t a code change. It was a fix to an example in the `TensorFlow Probability` documentation. The example had a subtle error in how it initialized a `tfp.distributions.TransformedDistribution` that would lead to incorrect sampling if you followed it literally. I had spent an hour trying to figure out why my model wasn’t learning, only to find the doc example was the culprit. I opened a PR, it got reviewed quickly, and merged within a day. It felt great, and it helped me understand the project’s PR workflow without the pressure of a complex code change.

Actionable Tip: The next time you’re reading documentation and something isn’t clear, or you find yourself searching external sources for an answer that *should* be in the official docs, consider opening a PR to add that clarity. It’s often a lower barrier to entry than a code fix, and highly appreciated by maintainers.

3. Explore the Issues, Even Without “Good First Issue” Labels

Go to the project’s GitHub issues page. Filter by bugs. Sort by “oldest.” You might find some ancient, overlooked bug reports that are still relevant. Or, filter by “recently updated” and see what discussions are happening. Read through them. Often, maintainers will ask for more information, or suggest a potential fix. If you’ve encountered a similar problem or have an idea, jump in.

I once picked up an issue for `Hugging Face Transformers` that involved a specific model’s tokenizer not handling a particular type of special character correctly during pre-tokenization. It wasn’t labeled “good first issue,” but the discussion outlined the problem pretty clearly. I spent a weekend digging into the tokenizer’s C++ backend (it was intimidating, I won’t lie), and eventually traced it to an encoding mismatch. I didn’t fix it myself in C++, but I wrote a detailed analysis and proposed a Python-level workaround that could be integrated. The maintainers loved the analysis and built on my findings to implement a proper fix. Even though my code wasn’t merged directly, my contribution was crucial.

Making Your First PR: The Nitty-Gritty

Okay, so you’ve found something to work on. Now what?

1. Set Up Your Dev Environment Properly

This sounds basic, but it’s where many people stumble. Fork the repo, clone your fork, create a new branch. Then, critically, set up the project’s development environment. Most AI projects use `pip install -e .` or `conda env create -f environment.yml`. Read their `CONTRIBUTING.md` or `DEVELOPMENT.md` files carefully. They usually contain instructions for running tests, linters, and formatters. Seriously, running the tests *before* you even start coding is a good sanity check.

2. Write Tests (Even for Docs!)

If you’re fixing a bug, write a test that *fails* with the bug present and *passes* with your fix. This is non-negotiable for maintainers. It proves your fix works and prevents regressions. If you’re adding a feature, write tests for it. Even for documentation changes, sometimes there are doctests or example snippets that can be run to ensure correctness. My `AIEngineX` bug fix included a new unit test that simulated the multi-agent reset scenario and asserted the environment state was correctly cleared.

# Example: Adding a unit test for AIEngineX reset bug
# This would be in a test file like tests/test_environment.py

import unittest
from aie_enginex.env import MultiAgentEnv # Assuming this is the module

class TestMultiAgentEnv(unittest.TestCase):
 def test_reset_clears_previous_state(self):
 env = MultiAgentEnv(num_agents=2, state_size=5)
 
 # Simulate some interaction
 obs1, _, _, _ = env.step([0, 0]) # Agent 0 takes action 0, Agent 1 takes action 0
 
 # Reset the environment
 obs2, _ = env.reset()

 # Assert that the new observations are fresh and not influenced by previous step
 # This is a simplified check, actual assertion would depend on the bug
 self.assertNotEqual(obs1[0].tolist(), obs2[0].tolist(), 
 "Agent 0's initial obs after reset should not match previous step's obs")
 self.assertNotEqual(obs1[1].tolist(), obs2[1].tolist(),
 "Agent 1's initial obs after reset should not match previous step's obs")
 
 # More specific assertions would check internal environment state variables
 # For instance, if there's an internal 'previous_rewards' buffer, check it's empty
 self.assertTrue(all(val == 0 for val in env._internal_reward_buffer), 
 "Internal reward buffer should be cleared on reset")

if __name__ == '__main__':
 unittest.main()

This test would have failed before my fix, and passed afterwards, giving clear evidence of the problem and its resolution.

3. Follow Their Style Guide

Most projects use Black, Flake8, MyPy, Prettier, or similar tools. Run them. Don’t make maintainers fix your formatting. It’s a quick way to get your PR rejected or languish in review hell. This is why setting up your dev environment and reading the contributing guide is so important.

4. Write a Clear Commit Message and PR Description

Your PR description should explain:

• What problem you’re solving (and why it’s a problem).
• How you solved it.
• Any potential side effects or considerations.
• Reference any related issues (e.g., `Fixes #1234`).

Be concise but thorough. The better your description, the easier it is for maintainers to understand and review your work.

Post-PR: Patience and Persistence

Once you open that PR, the waiting game begins. Don’t get discouraged if it takes a few days or even weeks for a review. Maintainers are often volunteers with limited time. Be responsive to feedback, be willing to make changes, and don’t take criticism personally. It’s about making the code better, not about your ego.

I’ve had PRs sit for a month, then get picked up, go through several rounds of review, and finally get merged. I’ve also had PRs that got rejected because the maintainers had a different vision or were already working on a similar solution. It happens. Learn from it, and move on to the next itch you want to scratch.

Actionable Takeaways for Your Next Open Source AI Contribution:

• Start with your own workflow: The best problems to solve are often the ones you encounter yourself while using an AI library.
• Don’t shy away from documentation: Clarifying docs, adding examples, or fixing typos are incredibly valuable and a great entry point.
• Read the `CONTRIBUTING.md`: Seriously, it’s your map to success. It tells you how to set up, how to test, and what the project expects.
• Write tests: For bug fixes, show the bug failing and then passing. For features, show they work as intended.
• Be clear and concise in your communication: Both in commit messages and PR descriptions.
• Be patient and open to feedback: Open source is a collaborative effort.

Contributing to open source AI projects isn’t just about fixing bugs; it’s about becoming part of a community, learning from experienced developers, and making a tangible impact on tools that many, including yourself, rely on. It’s a bit daunting at first, but the rewards are well worth the effort. Go find that itch, scratch it, and make the AI dev world a little bit better.

Happy coding!

Kai Nakamura

clawdev.net

🕒 Published: May 17, 2026