My Quiet Power: Contributing to Small Open-Source AI Projects

Hey everyone, Kai Nakamura here from clawdev.net, and today I want to talk about something that’s been on my mind a lot lately, especially as the AI space just keeps exploding: open source. Specifically, I want to explore what I’m calling the “Quiet Power” of contributing to smaller, less hyped open-source AI projects. We all hear about the big guns – PyTorch, TensorFlow, Hugging Face Transformers – and for good reason. They’re foundational. But what about the little guys?

I’m talking about those projects with maybe a few hundred stars, a handful of active contributors, often solving a very specific, niche problem. For a long time, my own open-source journey was pretty typical: I’d open issues on popular libraries, maybe fix a typo in the docs, or occasionally send a small bug fix to something widely used. It felt good, sure, but it also felt… a bit like adding a drop to an ocean. My impact, while present, felt diluted.

Then, about eight months ago, I stumbled upon a project called `semantic-search-on-device`. It was a Python library designed to run lightweight, local semantic search models on edge devices, something I was playing with for a personal project involving a Raspberry Pi and a collection of local documents. The project had good bones, a clear vision, but development had slowed down. There were open issues, some marked `help wanted`, and the maintainer seemed a bit overwhelmed.

That’s when I realized the quiet power of these smaller projects. And that’s what this article is about: why contributing to these less-trafficked corners of the open-source AI world isn’t just good for the project, but potentially even better for your own growth and impact as a developer.

The Echo Chamber of Popularity

Think about it. When you contribute to a project with tens of thousands of stars, your pull request (PR) gets lost in a sea of other PRs. Review times can be long, discussions can be terse, and frankly, it’s hard to stand out. Your contribution, no matter how clever, is just one of many. It’s a bit like trying to get your voice heard in a stadium full of screaming fans.

My first attempt to contribute to a major LLM framework involved a complex memory management optimization. I spent weeks on it, ran countless benchmarks, and crafted what I thought was an impeccable PR. It sat for two months. Then, it got a one-line comment from a core maintainer suggesting an alternative approach that, while valid, fundamentally changed my solution. The discussion fizzled out, and I eventually closed it myself. It was deflating, to say the least.

This isn’t a knock on those projects or their maintainers; they’re dealing with immense scale. But it does highlight a challenge for new or even experienced contributors looking to make a meaningful dent.

Finding Your Niche: The `semantic-search-on-device` Story

Back to `semantic-search-on-device`. When I found it, the main issue was that it only supported a very specific type of embedding model. My project needed something more general. I saw an open issue about adding support for Sentence Transformers, which felt like a natural fit. It was marked `difficulty: medium` and `help wanted`. Perfect.

I forked the repo, cloned it, and started digging in. The codebase was clean, but small enough that I could get my head around it in a couple of evenings. The maintainer, let’s call him Alex, had left excellent comments and a clear `CONTRIBUTING.md`.

My first PR added basic Sentence Transformer support. It wasn’t perfect, but it was a start. Here’s a simplified peek at what I added (conceptually, not the exact code):

# Before:
# Only had a custom embedding function
def _embed_custom_model(texts: list[str], model_path: str) -> np.ndarray:
 # ... custom logic ...
 pass

# My initial addition:
from sentence_transformers import SentenceTransformer

def _embed_sentence_transformer(texts: list[str], model_name_or_path: str) -> np.ndarray:
 model = SentenceTransformer(model_name_or_path)
 embeddings = model.encode(texts, convert_to_numpy=True)
 return embeddings

# ... then integrated this into the main search function

Within 24 hours, Alex had reviewed it. Not only did he accept it, but he gave me specific, constructive feedback on how to make it more generic, suggesting a plugin architecture for different embedding providers. He wasn’t just merging my code; he was mentoring me.

Why Smaller Projects Offer More

1. Visibility and Impact: Your contributions are far more noticeable. Alex and I had a direct, back-and-forth conversation. My work genuinely moved the project forward in a tangible way.
2. Faster Feedback Loop: Smaller teams mean quicker reviews. This helps you iterate faster and learn more efficiently.
3. Broader Responsibilities: Once I proved I could contribute, Alex started asking me about other features, even design decisions. I wasn’t just a code monkey; I was becoming a co-designer.
4. Deeper Understanding: With a smaller codebase, you can grasp the entire architecture much faster. This gives you a holistic view of how a project is built, from data structures to deployment, which is invaluable.
5. Mentorship Opportunities: As I experienced, maintainers of smaller projects are often more available and willing to guide new contributors. They’re invested in growing their community.
6. Skill Diversification: I ended up touching everything from CI/CD pipelines to documentation, something I rarely got to do on mega-projects. For instance, I helped set up a simple GitHub Actions workflow for testing my new embedding functions:

name: CI

on: [push, pull_request]

jobs:
 build:
 runs-on: ubuntu-latest
 strategy:
 matrix:
 python-version: ["3.8", "3.9", "3.10"]

 steps:
 - uses: actions/checkout@v3
 - name: Set up Python ${{ matrix.python-version }}
 uses: actions/setup-python@v4
 with:
 python-version: ${{ matrix.python-version }}
 - name: Install dependencies
 run: |
 python -m pip install --upgrade pip
 pip install -e .[dev] # Install editable and dev dependencies
 pip install sentence-transformers
 - name: Run tests
 run: |
 pytest

This was a small step, but it was *my* step in setting up solid CI for the project, something I hadn’t done much of before.

How to Find These Hidden Gems

Okay, so you’re convinced. You want to find your own `semantic-search-on-device`. How do you do it?

• Think Niche: What specific AI problem are you interested in? Edge inference? Federated learning on specific hardware? Explainable AI for a particular model type? Search for libraries addressing these narrow concerns.
• GitHub Advanced Search: Use keywords related to your interest. Filter by language (Python, Rust, C++), and crucially, by star count (e.g., `stars:10..500` or `stars:10..1000`). Look for projects with recent activity but not overwhelming popularity.
• Explore Dependency Trees: When you use a popular library, check its dependencies. Sometimes, a smaller, foundational library that the big one relies on might be a good place to contribute.
• Issues with `help wanted` or `good first issue` tags: Even on smaller projects, these tags are gold. They tell you the maintainer is actively looking for contributions and has thought about how to onboard new people.
• Read Blogs and Papers: Often, academic papers or smaller tech blogs will link to the open-source projects they used or created. These are prime candidates.
• Hackathons (Virtual or Local): Sometimes, smaller projects get kickstarted or gain momentum during hackathons. Keep an eye out.

Actionable Takeaways for Your Next Contribution

Ready to make a splash in a smaller pond? Here’s how to do it effectively:

1. Start Small, but Meaningful: Don’t try to rewrite the whole library on your first PR. Pick an issue that’s well-defined and achievable. A good first issue might be improving documentation, adding a simple test case, or fixing a minor bug.
2. Read the `CONTRIBUTING.md`: Seriously, read it. It’ll save you and the maintainer a lot of time. It usually outlines the coding style, testing procedures, and PR guidelines.
3. Communicate Early and Often: Before you even write a line of code for a new feature, open an issue or comment on an existing one. Briefly explain your proposed solution. This ensures you’re not duplicating effort and that your idea aligns with the project’s direction.
4. Be Patient (but not too patient): While feedback is faster, remember maintainers are often volunteers. Give them a few days, then a polite ping if you haven’t heard back.
5. Embrace the Learning: View every PR, every review comment, and every discussion as a learning opportunity. You’re not just fixing code; you’re learning how to build and maintain a project.
6. Consider Becoming a Core Contributor: If you enjoy the project and your contributions are valued, don’t be afraid to express interest in taking on more responsibility. This is how many maintainers start!

My journey with `semantic-search-on-device` isn’t over. I’ve since become a co-maintainer, helping Alex with reviews, roadmap planning, and even a bit of community management. It’s given me a level of ownership and direct impact that I simply hadn’t found in larger projects. I’ve learned more about project management, API design, and even the subtle art of motivating other contributors than I ever did just sending PRs to huge repos.

So, the next time you’re looking to contribute to open source, consider looking beyond the brightest stars. There’s a whole constellation of smaller, impactful projects out there just waiting for your “quiet power.” You might just find your true north there.

Happy coding!

Kai Nakamura

clawdev.net

🕒 Last updated: March 26, 2026  ·  Originally published: March 12, 2026