DEV Community: Tanbir Hossain Ramim

Open Source Radar is looking for contributors: 11 small issues for your first PR

Tanbir Hossain Ramim — Sun, 27 Sep 2026 15:42:56 +0000

I maintain Open Source Radar, a free tool that lists open, unclaimed, beginner-friendly issues from about 1,200 active open source projects and flags each project's CLA, DCO and AI rules before you start. It's refreshed twice a day by a small Python pipeline on GitHub Actions.

The radar itself is also a good place for a first pull request. This week the first outside feature landed: RSS feeds for every language, built by a contributor I'd never met before. So I've opened a batch of small, well-scoped issues for Hacktoberfest and beyond.

Issues you can pick up

Python (the pipeline, scripts/radar.py)

#17 Add an atom:link self reference to the RSS feeds: a few lines with ElementTree plus a test.
#19 Add a smoke test that runs render() end to end: would have caught a real crash we hit last week.
#20 A test fails on Windows: if you're on Windows, even just the traceback helps.

Website (plain HTML, CSS and JavaScript)

#21 Show the RSS feed for the selected language

Writing, no coding needed

Each quickstart is a short page on how projects in one language are usually built and tested:

#26 Shell, #27 Julia, #28 OCaml, #2 Elixir, #3 Haskell, #4 Scala, #5 Lua
#7 Translate the guide into your language (Hindi is already in progress).

How it works here

Comment on the issue you want, and I'll assign it to you.
Read CONTRIBUTING.md. The pipeline tests run with python3 -m unittest discover scripts.
Open a pull request. Every PR gets a review, usually within a day, and a friendly one.
Once it's merged, your name goes into the Contributors list in the README.

And if you're looking for issues in other projects, that's what the radar is for: pick a language and start.

Questions or ideas? The Discussions are open, and I read everything there.

How I Built VoiceMax: Reading Emotion From a Voice Recording With Three Small AI Flows

Tanbir Hossain Ramim — Fri, 25 Sep 2026 13:53:15 +0000

By Tanbir Hossain Ramim. Project page: VoiceMax. Source: github.com/TanbirRamim/VoiceMax.

VoiceMax started at Hackaburg 2025, where I built it with my team (the footer still says "Team 2.1"). The idea was simple: your voice carries a lot of emotional information you do not consciously notice, so let people record a few seconds of speech and get a short, honest reading of how they sound, followed by something supportive.

It is a Next.js app with TypeScript, shadcn/ui and Tailwind on the front, and Genkit with a Gemini model doing the analysis. This post walks through how it is put together and the decisions I would keep.

One model, three narrow jobs

The whole AI layer is configured in seven lines:

import {genkit} from 'genkit';
import {googleAI} from '@genkit-ai/googleai';

export const ai = genkit({
  plugins: [googleAI()],
  model: 'googleai/gemini-2.0-flash',
});

The temptation at a hackathon is to write one giant prompt that returns everything at once. I split it into three flows instead:

analyzeAudioEmotion listens to the recording and describes it.
suggestAdditionalEmotions takes that description and proposes up to three secondary emotions.
providePersonalizedFeedback takes only the primary emotion and writes feedback, calling a tool when the emotion is negative.

Each flow has one job, one input schema and one output schema. That made prompts much easier to iterate on, because when the feedback was off I knew exactly which prompt to change, and I could run each flow on its own in the Genkit developer UI (npm run genkit:dev).

Getting structured answers out of audio

The first flow is the only one that sees audio. The recording goes in as a base64 data URI, and the output is a Zod schema with five fields:

const AnalyzeAudioEmotionOutputSchema = z.object({
  primaryEmotion: z.string().describe('The primary emotion expressed in the audio.'),
  perceivedStressLevel: z.string().describe('A qualitative description of the perceived stress level in the voice (e.g., calm, moderate stress, high tension).'),
  speechCharacteristics: z.string().describe('Observations about speech patterns like pace, pauses, or fluency (e.g., fluid and confident, some hesitation, frequent pauses, rapid pace).'),
  perceivedConfidence: z.string().describe("Description of the speaker's perceived confidence (e.g., confident and assertive, somewhat hesitant, appears unsure)."),
  vocalEnergy: z.string().describe("Qualitative assessment of the vocal energy or enthusiasm conveyed (e.g., high energy, moderate, low energy/flat)."),
});

The .describe() strings matter more than they look. Genkit passes the schema to the model, so the descriptions double as instructions, and giving example values ("calm, moderate stress, high tension") keeps the answers short and comparable instead of turning into paragraphs.

All five fields are qualitative strings on purpose. A model listening to ten seconds of audio has no business producing "stress: 73%". A phrase like "some hesitation noted" is closer to what it can actually tell, and it reads better to the person on the other side.

The prompt itself passes the audio through Handlebars media syntax:

Audio: {{media url=audioDataUri}}

Chaining the flows without a second audio upload

Only the first flow gets the audio. The second one gets a text summary built from the first flow's output:

const suggestionsInput: SuggestAdditionalEmotionsInput = {
  primaryEmotion,
  audioAnalysisContext: `The primary emotion detected is "${primaryEmotion}". The voice also showed signs of "${perceivedStressLevel}" stress, speech characteristics were noted as "${speechCharacteristics}", perceived confidence as "${perceivedConfidence}", and vocal energy as "${vocalEnergy}". Consider nuances.`,
};

This keeps the audio payload to a single request, and it means the secondary emotions are reasoned from the same observations the user sees on screen, so the two parts of the result cannot contradict each other in obvious ways.

Letting a tool, not the model, write the exercise

The feedback flow was the one I cared most about getting right. If someone sounds anxious, I did not want the model improvising breathing instructions. So the exercise text comes from a Genkit tool with fixed answers:

async (input) => {
    const emotion = input.emotion.toLowerCase();

    if (['anxious', 'anxiety', 'stressed', 'stress', 'worried', 'nervous', 'fear'].some(e => emotion.includes(e))) {
      return 'Try Box Breathing: Inhale for 4 seconds, hold your breath for 4 seconds, exhale for 4 seconds, and then hold your breath again for 4 seconds. Repeat this cycle several times to calm your nervous system.';
    }
    // ... sad and angry branches, then a mindful-breathing default
}

The prompt then tells the model that for negative emotions it must call breathingExerciseSuggestion and put the tool's output in the suggestion field verbatim, with no "Here is the exercise:" wrapper. For positive emotions it writes a short tip itself and must not call the tool.

The split is deliberate. The model is good at the empathetic sentence in feedback. The deterministic part, the thing someone might actually follow, is plain code I can read and test. The matching uses includes, so "slightly anxious" or "stressed out" still land in the right branch.

Recording audio in the browser

The recorder is the most defensive code in the project, because microphone handling is where things break across browsers. Before creating a MediaRecorder it negotiates a format:

let options = { mimeType: 'audio/webm' };
if (MediaRecorder.isTypeSupported && !MediaRecorder.isTypeSupported(options.mimeType)) {
  options.mimeType = 'audio/ogg';
  if (!MediaRecorder.isTypeSupported(options.mimeType)) {
    (options as any).mimeType = '';
  }
}

WebM first, Ogg second, and otherwise an empty string so the browser picks its own default. When recording stops, the chunks become a Blob, the file name takes its extension from the real MIME type, and a FileReader turns it into the data URI the first flow expects.

Permission errors get their own messages: NotAllowedError explains how to re-enable the microphone, NotFoundError says no microphone was found. Every path that acquires a stream also stops its tracks on reset, so the browser's recording indicator actually goes away when the user starts over. That cleanup is spread over four steps in a useEffect, and every one of them was added after the indicator stayed on in testing.

Errors a person can act on

The three flows run one after another inside a single try. When something fails, the raw error is mapped to a sentence a user can do something with:

if (err.message.includes('429 Too Many Requests') || err.message.includes('QuotaFailure') || err.message.includes('rate limit')) {
  userFriendlyError = 'Analysis failed due to API rate limits. ...';
} else if (err.message.includes('400 Bad Request') || err.message.toLowerCase().includes('invalid argument')) {
  userFriendlyError = 'Analysis failed: The recorded audio might be too short, silent, corrupted, or in a format the AI could not process. ...';
}

A 400 from the model almost always meant the recording was too short or silent, so the message says that instead of "Bad Request". Anything else is trimmed and capped at 200 characters so a stack trace never ends up on screen.

What I would change

Reading the code again, there is one thing I would fix first. After each flow the page calls setAnalysisResult with a partial result, with a comment saying it is to "show partial results sooner". But the results section only renders when !isLoading, and loading stays true until all three flows finish. So the progressive rendering is written but never visible. The fix is small: render each card as soon as its field exists and keep the spinner only for the parts still pending.

The other change is running flows two and three in parallel. The feedback flow only needs primaryEmotion, so it does not have to wait for the secondary emotions.

The pattern I would reuse everywhere, though, is the shape of the AI layer: small flows with typed inputs and outputs, and plain code for anything that must be exactly right.

If you want to read the whole thing, the source is on GitHub, and there is a short summary on the VoiceMax project page.

Originally published on tanbirramim.com.

How to Find Good First Issues That Are Still Open in 2026

Tanbir Hossain Ramim — Fri, 25 Sep 2026 13:50:25 +0000

"Look for issues labeled good first issue" is the advice everyone gets when they want to start contributing to open source. It is also why so many first attempts stall.

Here is what usually happens. You find an issue labeled good first issue. Someone claimed it three weeks ago. The next one already has two open pull requests. The third looks free, so you spend a weekend on it, and then a bot closes your pull request because the project requires a signed agreement, or does not accept AI-assisted code, or closes pull requests from accounts it does not recognise.

None of that is about your code. It is about finding the right issue and knowing the rules before you start. This guide covers both, with the exact searches I use.

Why most good first issue lists do not work

A label is a snapshot of a maintainer's opinion on the day they added it. It does not change when the issue gets claimed, when a pull request appears, or when the project stops merging outside contributions.

Popular issues also go fast. When I built Open Source Radar, a tool that tracks newcomer-friendly issues across more than 1,200 active projects, the pattern was obvious: in well-known repositories, a clearly described beginner issue often has a pull request within days of being labeled. A list compiled last month is mostly a list of work other people have already done.

So the goal is not to find issues with the right label. It is to find issues with the right label that nobody is working on, in a project that still reviews outside contributions.

The label is only the first of five checks. The next two can be done in the search bar, the last two need a minute of reading.

Search GitHub for issues nobody has claimed

GitHub's issue search can filter out most taken issues if you use the right qualifiers. Paste this into the search bar on github.com:

is:issue is:open no:assignee -linked:pr label:"good first issue" language:python updated:>2026-07-01

What each part does:

is:issue is:open limits results to open issues.
no:assignee hides issues that someone has been assigned to.
-linked:pr hides issues that already have a pull request connected to them. This single qualifier removes a large share of "available" issues.
label:"good first issue" finds issues maintainers marked as suitable for newcomers. Try label:"help wanted" too; those are often less contested.
language:python narrows to one language. Replace it with the language you know best.
updated:>2026-07-01 skips issues nobody has touched in months. Use a date about two months ago.

The same qualifiers inside one repository. When this was captured 29 issues matched, but look at the labels: several also carry To-be-closed, which is exactly the kind of detail a label-only list never shows you.

Then open each result and read the comments. A comment from last week saying "I'd like to work on this" means it is taken, even without an assignee.

Check that the project still merges outside contributions

The project matters more than the issue. An active, welcoming project reviews your pull request in days. An overloaded one may never look at it.

Before committing to an issue, spend two minutes on the project:

Recent commits. Look at the commit history. Nothing in the last month is a warning sign.
Merged pull requests from outsiders. Open the pull requests tab, filter by is:pr is:merged, and look at the authors. If every merged pull request comes from the same two maintainers, outside contributions are not a priority right now.
Response time. Open a few recently merged pull requests from outside contributors and look at how long the first review took.
Tone. Read a couple of issue threads. Patient, specific maintainers are a good sign even when they say no.

Read the rules before you write code

This is the step most guides skip, and the one that costs people the most time. Every project has its own rules for contributions, and some of them decide whether your pull request can be merged at all.

Look for these files: CONTRIBUTING.md, the pull request template in .github/, AI_POLICY.md, and AGENTS.md.

The rules that matter most:

Contributor License Agreements (CLA). A legal agreement some projects require, usually signed through a bot on your first pull request. Of the 1,210 active projects Open Source Radar tracked in September 2026, 155 mentioned a CLA in their contribution files.
DCO sign-off. A lighter alternative where every commit needs a Signed-off-by line. You add it with git commit -s. 97 of those projects mentioned it.
AI contribution policies. This is new and changing quickly. 127 projects asked contributors to disclose AI assistance, and 38 restricted or banned AI-generated contributions outright. If you use AI tools, follow the project's rule exactly.

These numbers come from automatically scanning contribution files, so treat them as a sense of scale rather than an exact count. The point is that a meaningful share of projects has a rule you need to know about before you start.

Rules found across 1,210 active projects tracked by Open Source Radar in September 2026.

Watch out for automation that closes pull requests

Because of the growing volume of low-effort pull requests, some projects now run workflows that close pull requests automatically. Patterns I have seen include closing pull requests from accounts that opened pull requests to many unrelated repositories in the same week, from branches named after AI tools, or that do not reference an issue labeled for outside help.

Two habits keep you clear of all of them: contribute steadily to a small number of projects instead of many at once, and read the files in .github/workflows/ if a project's contributing guide mentions automation.

Claim the issue the right way

Some projects want a comment before you start; others say to just open a pull request. When a comment is expected, make it useful:

I can reproduce this on version 4.2: running the command with an empty username loops forever instead of showing an error. The validation in the login prompt rejects the input without printing why. I plan to print the message and ask again, with a test. Does that approach sound right?

That comment shows you understood the problem, and it gives the maintainer a chance to correct your approach before you spend a weekend on it. Only claim an issue you will start this week.

Make the pull request easy to merge

Maintainers review a lot of pull requests. The easier yours is to understand, the faster it moves.

Reproduce the bug first, on your machine, before changing anything.
Write a test that fails without your change and passes with it.
Keep the diff small. Change only what the issue needs. No drive-by refactoring or reformatting.
Run the project's own checks locally: tests, formatter, linter, type checker.
Follow the commit message convention you see in git log.
Write a short description that says what was wrong, what you changed and how you tested it, and links the issue with Fixes #123.

If nothing happens

Silence usually means busy, not no. After about a week, one friendly follow-up is fine: "This is ready for review whenever someone has time. Happy to make changes." Keep your branch free of merge conflicts in the meantime.

If your pull request is closed, read the reason. Someone may have fixed it first, the maintainers may want a different approach, or the change may be out of scope. None of those are a verdict on you, and a polite reply leaves a good impression for your next contribution.

A shortcut: Open Source Radar

Doing all of the above by hand for every issue takes time, which is why I built Open Source Radar. It runs these checks automatically twice a day and lists only open issues with no assignee and no linked pull request, from projects with commits in the last 60 days, sorted by language and topic. Each project shows badges for CLA, DCO and AI policy requirements, linked to the file they came from.

The Open Source Radar website. Every listed issue already passed the search checks above.

Project rules appear next to each issue, so a CLA or an AI disclosure requirement is visible before you write any code.

It is free and open source, and it includes a full contribution guide covering everything from setting up Git to handling review feedback.

The repository behind it: the data pipeline, the guide and the language quickstarts are all public, so you can check how every issue was selected.

Pick one project you actually use, find one issue nobody has claimed, and start there.

Frequently asked questions

What is a good first issue on GitHub?

It is an issue that maintainers have labeled as suitable for someone new to the project, usually with the label good first issue, beginner or first-timers-only. It is small, clearly described, and does not need deep knowledge of the codebase.

How do I know if someone is already working on an issue?

Check four things: whether anyone is assigned, whether a pull request is linked in the Development sidebar or the timeline, whether a recent comment says someone is working on it, and whether an open pull request mentions the issue number. The GitHub search qualifiers no:assignee and -linked:pr filter out the first two automatically.

Do I need to sign a CLA to contribute to open source?

Only for projects that require one. Many company-backed projects ask for a Contributor License Agreement, usually through a bot that comments on your first pull request. Others ask for a DCO sign-off instead, which you add with git commit -s. The contributing guide says which applies.

Can I use AI tools to contribute to open source?

It depends on the project. Some allow AI assistance with the usual review standards, some require you to disclose it in the pull request, and some do not accept AI-generated contributions at all. Read the contributing guide, AI_POLICY.md or AGENTS.md before you start, and always understand every line you submit.

How long does it take for a first pull request to be reviewed?

Anywhere from hours to weeks. Active projects with several maintainers often respond within a few days. If there is no response after a week, one polite follow-up comment is fine.

Originally published on tanbirramim.com.

I built a small Python library to add retries, caching, fallbacks, budgets, and guardrails around native LLM SDK calls

Tanbir Hossain Ramim — Wed, 16 Sep 2026 12:54:33 +0000

I got tired of writing the same LLM boilerplate in every project, so I made a library

Three lines to call an LLM in a prototype. Then you go to production and suddenly you're writing the same 200 lines you wrote last time:

Retry logic because OpenAI throws 429s at you. Cost tracking because someone left a loop running and burned $40 on a Saturday. Caching because your support bot answers "how do I reset my password?" eight hundred times a day and you're paying for each one. PII scrubbing because customer emails keep showing up in prompts. Output parsing because the model returns markdown when you asked for JSON, and now your frontend is on fire.

I kept copy-pasting this stuff between projects until I finally pulled it into a library: callm.

It's just a decorator

I didn't want to learn a new client or replace the SDK. The whole idea is that you keep writing normal OpenAI/Anthropic code and slap a decorator on top:



python
import openai
from pydantic import BaseModel
from callm import callm

client = openai.OpenAI(max_retries=0)

class Summary(BaseModel):
    title: str
    bullets: list[str]

@callm(
    cache=True,
    retry=3,
    fallback=["anthropic/claude-sonnet-5"],
    max_cost=0.25,
    block_pii=True,
    detect_injection=True,
    output_schema=Summary,
)
def summarize(text: str):
    return client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": text}],
    )

You call summarize(), you get back a validated Summary. That's it. Outside the decorator, your SDK works exactly like before — nothing monkey-patched, nothing weird.

What's actually going on under the hood

When your function runs, the call passes through a stack of middleware:

Security first — prompt injection scoring, then PII gets masked (jane@acme.com → [EMAIL_1]). This happens before anything hits the cache or the network.
Cache check — exact-match lookup based on the masked request, params, and schema.
Validation — response gets parsed into your Pydantic model. If it fails, the model gets called again with the validation errors attached (usually fixes it on the second try).
Fallback — if OpenAI is just not having it today, the request gets translated and sent to Claude instead. Your code still gets back an OpenAI ChatCompletion object, so nothing breaks downstream.
Cost guard — estimated cost is checked against max_cost before the request actually goes out. No more surprise bills.
Retry — exponential backoff with jitter, and it actually reads the provider's rate-limit headers instead of guessing.

Everything gets logged locally (tokens, cost, cache hits, retries — never your actual prompts), and you can run callm stats to see what you're spending per provider, model, or function.

A couple of design choices I want to explain

The cache is exact-match on purpose. I know semantic caching sounds cool, but think about it: "Summarize https://example.com/post-1" and "Summarize https://example.com/post-2" look almost identical to an embedding model. A semantic cache would cheerfully hand you the wrong summary and you wouldn't notice for a while. callm does support semantic matching if you want it, but you have to opt in, and it'll never match across different system prompts or conversation histories.

Fallback won't silently break your request. If you're using tools, images, or a structured response format, callm will only fall back to another model from the same provider. Translating tool schemas across providers is a can of worms, and I'd rather fail loudly than give you a subtly wrong result.

"Cool, but does it add latency?"

The repo has an offline benchmark that runs the real OpenAI SDK against a fake server:

What I measured

Overhead per call (default settings) +0.06 ms
Cost savings with cache, FAQ-style traffic 91% lower
Cost savings with cache, mostly unique prompts 2% lower
Success rate with 20% random 503s: plain SDK → retry=2 → + fallback 79.9% → 99.4% → 100%

The cache numbers are the obvious takeaway: caching is huge if your requests repeat, and basically irrelevant if they don't. Run callm stats on your own traffic before you count on those savings.

Give it a spin
bash
pip install "callm-toolkit[openai,anthropic,validation]"

There's an offline demo in the repo (examples/offline_demo.py) that walks through a retry, a cache hit, a fallback, a blocked expensive call, and a flagged injection — no API key needed.

GitHub: https://github.com/TanbirRamim/callm
Docs: https://tanbirramim.github.io/callm/

Author: Tanbir Hossain Ramim

It's MIT-licensed and pretty new. If you try it on a real workload and something breaks or feels off, open an issue — that kind of feedback is exactly what I need right now.