My First Steps in Open Source AI Development

Hey everyone, Kai Nakamura here from clawdev.net, your friendly neighborhood AI dev blogger. Today, I want to talk about something that’s been on my mind a lot lately, especially as I look at the incredible pace of AI development: contributing to open source.

Now, I know what some of you might be thinking. “Kai, open source? That’s for the grizzled veterans, the core maintainers, the people who wrote Linux in their sleep.” Or maybe, “I’m just starting out, what could I possibly add?” And for a long time, I felt the same way. My contributions were mostly limited to starring repos and maybe a bug report if I was feeling particularly brave. But over the last year, as I’ve been diving deeper into specific AI frameworks and tools, I’ve realized something profound: contributing to open source isn’t just for the gurus. It’s for everyone, and it’s more accessible than you might think, especially in the AI space.

The specific angle I want to explore today isn’t about how to become a core maintainer of PyTorch overnight. It’s about a much more practical, and I’d argue, more impactful approach for the average AI developer: finding and fixing those little “papercuts” in open-source AI projects. These aren’t critical bugs that bring down entire systems. They’re the small, annoying, time-wasting quirks that, when accumulated, make daily development a drag. And fixing them is one of the best ways to get your foot in the door, build real skills, and genuinely improve the tools we all rely on.

My First “Papercut” Contribution: The Great Documentation Omission

Let me tell you a story about my first real contribution. It wasn’t a complex algorithm or a performance optimization. It was a missing line in the documentation for a popular Hugging Face Transformers model. I was trying to fine-tune a new variant of a language model, and I kept running into an error that just said something cryptic about an “unexpected argument.” I spent an entire afternoon debugging my code, checking my data, questioning my life choices. Turns out, the model’s `from_pretrained` method had a new parameter for `trust_remote_code` that was required for this specific model variant, but it wasn’t mentioned anywhere in the official docs for that model. Not in the model card, not in the `Trainer` class docs, nowhere.

I finally stumbled upon the answer in a GitHub issue comment buried three pages deep. My initial reaction was frustration. My second reaction was, “Someone should fix this.” My third reaction, fueled by a healthy dose of caffeine and the lingering annoyance, was, “Why not me?”

So, I forked the `transformers` repo, navigated to the relevant model’s `README.md` (which is often where these model-specific notes go), added a clear note about the `trust_remote_code=True` requirement, and submitted a pull request. It felt like a monumental task at the time, but the process itself was surprisingly straightforward. A few days later, a maintainer reviewed it, suggested a minor wording tweak, and merged it. Boom. My first contribution. It wasn’t glamorous, but it saved countless future developers an afternoon of head-scratching. And honestly, it felt pretty good.

Why Papercuts Matter (Especially in AI)

In AI development, we move fast. New models, frameworks, and techniques pop up almost daily. This rapid pace means that documentation can get outdated quickly, error messages might not be as clear as they could be, or small usability issues can slip through the cracks. These are the papercuts:

• Unclear error messages: That `KeyError` that doesn’t tell you *which* key is missing.
• Missing documentation for new features: Like my `trust_remote_code` incident.
• Suboptimal default parameters: A default value that works for a toy example but fails silently on real data.
• Confusing examples: A script that uses deprecated syntax or doesn’t quite match the latest API.
• Small UI/UX glitches in tools like Gradio or Streamlit: A button that’s not quite aligned, or an input field that’s not intuitive.

These aren’t “critical bugs” in the traditional sense, but they add up to lost time, frustration, and a steeper learning curve for everyone. And for AI, where the learning curve is already pretty steep, anything we can do to smooth it out is a huge win for the entire community.

Finding Your First Papercut: Where to Look

So, you’re convinced. You want to squash some papercuts. But where do you start? Here are a few places I’ve had success:

1. Your Own Daily Workflow

This is the absolute best place. What annoys *you*? What makes you stop and Google something for ten minutes that should be obvious? Keep a small notepad (digital or physical) open when you’re coding. Every time you hit a minor snag, jot it down. It could be:

• “Why isn’t this `Trainer` argument documented here?”
• “This error message for `DataLoader` is completely unhelpful.”
• “The example script for `diffusers` uses an older version of `accelerate`.”

These personal frustrations are gold mines for potential contributions.

2. GitHub Issues (Look for “Good First Issue” or “Documentation” Tags)

Many projects tag issues specifically for newcomers. While “Good First Issue” often implies coding, “Documentation” tags are perfect for papercuts. Even if an issue isn’t tagged, scan through recent issues. You’ll often find users asking questions that reveal gaps in documentation or confusing behavior. If someone asks a question that you yourself struggled with, that’s a prime target.

For example, searching for “documentation” in the PyTorch issues often brings up valuable leads. I once found an issue where someone was confused about the order of dimensions for `torch.nn.Conv3d`. I realized the documentation example used a different convention than a related function, causing confusion. A simple clarification PR fixed it.

3. Project Discord/Slack Channels

These are often buzzing with real-time questions. If you see a common question pop up repeatedly, that’s a strong indicator of a papercut. It could be a missing FAQ entry, an unclear example, or a subtle API behavior that isn’t well-explained.

Squashing the Papercut: A Practical Example (Documentation Fix)

Let’s walk through a hypothetical example. Say you’re working with `fastai` for vision tasks, and you notice that the `ImageBlock` documentation doesn’t clearly explain how to handle images with varying aspect ratios when applying transformations like `Resize`. You’ve seen a few people on forums ask about it.

Step 1: Verify the Papercut

Check the existing documentation. Is it indeed unclear? Does it lack the specific detail you’re thinking of? Sometimes, the information is there, just hard to find. If it’s truly missing or ambiguous, you’re good to go.

Step 2: Fork the Repository

Go to the project’s GitHub page (e.g., `fastai/fastai`). Click the “Fork” button in the top right. This creates a copy of the repository under your GitHub account.

Step 3: Clone Your Fork

Clone your forked repository to your local machine:

git clone https://github.com/your-username/fastai.git
cd fastai

Step 4: Create a New Branch

Always work on a new branch for your changes:

git checkout -b fix/imageblock-resize-docs

Step 5: Make Your Changes

Navigate to the relevant documentation file. For `fastai`, documentation is often in `.ipynb` notebooks in the `docs` folder or directly in docstrings in the code. Let’s assume it’s a docstring in `fastai/vision/core.py` for `ImageBlock`.

You might find something like this:

class ImageBlock(TransformBlock):
 "A `TransformBlock` for images"
 def __init__(self, cls=PILImage): super().__init__(type_tfms=cls.create)

You decide to add a note about `Resize` behavior. You’d edit it to something like:

class ImageBlock(TransformBlock):
 "A `TransformBlock` for images"
 # New addition to the docstring
 "**Note on Resizing:** When using `Resize` with `ImageBlock`, be aware of how different `method` parameters (e.g., `ResizeMethod.Pad`, `ResizeMethod.Squish`) handle aspect ratios. `ResizeMethod.Pad` will add black borders to maintain aspect ratio, while `ResizeMethod.Squish` will distort the image. Choose the method appropriate for your dataset and task."
 def __init__(self, cls=PILImage): super().__init__(type_tfms=cls.create)

If it was a `.md` or `.ipynb` file, you’d edit that directly.

Step 6: Commit Your Changes

git add .
git commit -m "docs: Clarify ImageBlock Resize behavior for aspect ratios"

Use a clear, concise commit message. Many projects follow conventions like `docs:`, `fix:`, `feat:`.

Step 7: Push to Your Fork

git push origin fix/imageblock-resize-docs

Step 8: Open a Pull Request

Go back to your forked repository on GitHub. You should see a banner suggesting you open a Pull Request. Click it, compare your branch to the original project’s `main` or `master` branch, and write a clear description of your changes. Reference any relevant issues if possible.

That’s it! The maintainers will review it, and with a bit of luck, it’ll get merged, and you’ll have made the world a slightly better place for AI developers.

Actionable Takeaways for Aspiring Papercut Squishers

You don’t need to be a senior developer or an algorithm wizard to contribute meaningfully to open source AI. Start small, start practical. Here’s how to get started today:

1. Keep an “Annoyance Journal”: For the next week, every time you hit a minor roadblock, a confusing error, or a missing piece of information while developing, jot it down.
2. Pick One Project You Use Regularly: Don’t try to conquer all of GitHub. Focus on a single AI library or framework that you interact with daily. This familiarity will make finding papercuts and understanding the codebase much easier.
3. Start with Documentation: This is the lowest barrier to entry. Fixing typos, clarifying confusing sentences, adding missing parameters to docstrings, or improving example code are all incredibly valuable.
4. Look for “Good First Issues” (but don’t limit yourself): While these are great, also check recent closed issues or discussion forums for recurring questions that point to documentation gaps.
5. Don’t Be Afraid to Ask: If you’re unsure about how to fix something or where to put a change, open an issue or ask in the project’s community channel. Most open-source communities are incredibly welcoming to new contributors.
6. Celebrate Small Wins: Your first merged PR, no matter how small, is a big deal. It’s a step towards becoming a more engaged and impactful member of the AI development community.

So next time you’re wrestling with a slightly unclear error message or hunting for a missing parameter in the docs, remember: that’s not just a problem for you. It’s an opportunity. Go fix that papercut. The AI world will thank you for it.

Happy squishing!

Kai Nakamura

clawdev.net

🕒 Published: May 10, 2026