How I got officially acknowledged as a MusicBrainz Picard contributor

Dipak Tiwari — Thu, 04 Jun 2026 06:57:43 +0000

From a Research Rabbit Hole to an Official Open Source Acknowledgement

A few months ago, my name appeared on the official MusicBrainz Picard acknowledgements page. Not as a user. As a contributor.

This is the story of how that happened — the 15+ merged PRs across two repos, what I learned working with production-grade maintainers, and what the whole thing actually cost me in failed attempts before anything clicked.

What is MusicBrainz Picard?

If you've ever properly tagged your music library, you might have used Picard without knowing it. It's the official MusicBrainz tagger — a cross-platform desktop application that identifies audio files using AcoustID fingerprints, fetches metadata from the MusicBrainz database, and renames/tags your files according to rules you define.

It's not a toy project. Picard has millions of users, a complex file lifecycle engine, and is maintained by professional developers with incredibly high standards for code review. Getting a PR merged here means your code runs on real user machines.

How It Actually Started

None of this was planned.

It began with a research problem — I wanted to save disfluencies in a Whisper speech model. That rabbit hole led me to GailBot, an official Python package for linguistic analysis, which pulled me toward GSoC. I didn't get in. So I pivoted.

MetaBrainz wasn't even on my radar until I started looking for projects where Python actually mattered at the core. I found Picard, read the codebase for a week, identified areas where the file lifecycle logic was fragile, and started filing PRs.

None of the early ones were easy. The first few reviews sent me back to square one. But every rejection taught me something the previous one couldn't.

How I Started Contributing

I wasn't handed a "good first issue" list and told to pick something easy. The approach I took:

Understand the why before touching the what. Picard's file lifecycle is subtle — files move between states (pending, loaded, saved, error), and getting that wrong causes data loss for real users.
Write tests before the maintainers ask for them. Every PR I submitted had pytest coverage using mock objects.
Respect CI/CD strictly. The project enforces formatting and linting via ruff. I treated every pipeline failure as a blocker, not a suggestion.
Keep scope tight. Each PR does exactly one thing. The maintainers will make you split it if you don't.

What I Actually Built

Picard — File Safety & Error Handling

This is where most of my work landed. Picard's file save pipeline is mission-critical — if it fails silently, users lose data. I focused on making failures loud, explicit, and recoverable.

#2933 — Improve error messages for file access errors
The existing error messages when Picard couldn't access a file were vague and unhelpful. This PR made them specific — telling users exactly what failed and why, rather than a generic "something went wrong."

#2954 — Docs: set error docstring
Small but important. Properly documenting the error states in the codebase so future contributors (and future me) understand what each error condition actually means.

#2963 — Detect external file change (Feature — 34 review comments)
This was the hardest one. Picard watches files on disk. If something external modifies a file while Picard has it loaded, the save pipeline could silently overwrite those external changes. This PR added explicit detection of external file changes as a first-class step in the pipeline — not a side effect hidden in unrelated code paths. 34 comments in review. Multiple rewrites. Close collaboration with the lead maintainer zas to get the logic exactly right. Worth every cycle.

#3005 — Add regression test for replaced file with same size and different content
After the external file change detection landed, I wrote regression tests to make sure it stayed correct. This one covers the tricky edge case where a file is replaced with one of the same size — easy to miss with naive change detection.

#3009 — Add regression test for file deleted after identity capture
Another regression test covering the case where a file is deleted between Picard capturing its identity and attempting to process it.

#3010 — Test file deleted after capture
Complementary test to #3009, covering the deletion scenario from a different code path angle.

Picard — Platform & Tag Support

#3044 — macOS: Fix background-only app by disabling console for exe_plugins
Picard was spawning a visible console window on macOS when launching external plugins — a genuine UX bug for Mac users. This PR fixed it by properly disabling console allocation for the exe_plugins subprocess on macOS.

#3047 — Fix: incorrect comment in FileIdentity hash test
The comment in the FileIdentity hash test was wrong — it described behavior that the test wasn't actually testing. Fixed the comment to accurately describe what the assertion was checking.

#3058 — PICARD-2383: Add musicbrainz_composerid tag
MusicBrainz has a composer_id field in its database. Picard wasn't exposing it as a tag. This PR added musicbrainz_composerid as a writable tag, making composer metadata accessible to users who care about attribution at that level of detail because of this contribution maintainer add my name of official acknowledgement page.

mcp-musicbrainz — Building AI Tools on Top of the MusicBrainz API

In parallel, I contributed to zas/mcp-musicbrainz — an MCP (Model Context Protocol) server that lets AI assistants query the MusicBrainz database directly. Think: Claude or any LLM asking "find me all recordings by this artist" and getting real structured data back.

This was where my LLM tooling interest and my MusicBrainz knowledge intersected directly.

#1 — feat: add get_release_group_cover_art tool and handle 404s
The first PR — added a tool for fetching cover art for release groups, with proper 404 handling so the LLM gets a clean response instead of an error when cover art doesn't exist.

#2 — feat: add detail tools for event, instrument, place, and series
Extended the server's entity coverage. MusicBrainz tracks events, instruments, places, and series — none of these were queryable via the MCP server. This PR added detail lookup tools for all four.

#6 — feat: add industry standard translation tools for ISRC and ISWC
ISRC (International Standard Recording Code) and ISWC (International Standard Musical Work Code) are industry identifiers used by Spotify, Apple Music, and publishers. This PR added tools that translate between these commercial codes and MusicBrainz's open database entities — enabling LLM agents to bridge commercial music APIs and open data.

#7 — add offset parameter to search tools to enable LLM pagination
The MusicBrainz API returns paginated results. Without pagination support, an LLM agent could only see the first page of any search. This PR added offset parameters to the search tools, enabling agents to autonomously crawl through deep result sets without hitting rate limits.

#18 — feat: add SSE transport entry point using native fastmcp
Added Server-Sent Events (SSE) transport support using the native fastmcp implementation — making the server compatible with more MCP client configurations.

The Official Acknowledgement

After the Picard PRs were merged, I found my name listed on the official acknowledgements page:

https://picard-docs.musicbrainz.org/en/latest/about_picard/acknowledgements.html

That URL is not self-reported. It's maintained by the MetaBrainz Foundation and updated by the project maintainers themselves. It means the people who built Picard decided my contributions were worth recognizing.

It's a small thing on one level. On another level, it's the first time a production open source project put my name on something real.

What Working With Production Maintainers Actually Teaches You

There's a gap between "I can write Python" and "I can contribute to a production Python codebase." Here's what narrowed that gap for me:

Code review is a conversation, not a verdict. zas doesn't just comment "fix this" — he explains why the current approach is wrong and what the correct mental model should be. Reading those review comments carefully is like getting a mini-lesson in software engineering every PR. The #2963 PR with 34 comments was the best education I've had this year.

Mock objects are not optional. When you're testing file system operations, you mock the filesystem. When you're testing the save pipeline, you mock the file states. The test suite has to be deterministic and fast, always. If your test touches real disk, you've already failed.

CI/CD is the real gatekeeper. You can write great code, but if your formatting doesn't match ruff or your test coverage drops, the PR isn't moving. Internalize the pipeline, don't fight it.

Scope discipline matters. Each PR should do exactly one thing. I learned this the hard way when early drafts tried to fix related issues I noticed while working on something else. Split it. Always.

The codebase is the documentation. Production projects don't have tutorials for contributors. You read the code, you read the tests, you read the commit history. That's how you learn what the project actually values.

How It All Started (The Real Story)

This journey has been full of ups and downs.

It began with a research problem — saving disfluencies in a Whisper model. That led me to GailBot, an official Python package for linguistic analysis. GailBot led me toward GSoC. GSoC didn't work out. So I pivoted to MetaBrainz.

None of that was linear. There were rejected applications, PRs that sat for weeks, and review comments that felt harsh until I realized they were right. But every pivot taught me something the previous one couldn't. The Whisper research taught me to read academic codebases. GailBot taught me Python packaging. Picard taught me production engineering discipline.

The thread connecting all of it was just showing up and doing the work.

What's Next

I'm currently targeting the CNCF LFX Mentorship September 2026 cohort, specifically KubeEdge/Ianvs — a distributed AI benchmarking platform for edge computing built in pure Python. It sits exactly at the intersection of everything I've been learning: Python, ML pipelines, and cloud-native infrastructure.

I'm also building Repo Maintainer AI — a FastAPI-based GitHub App that automates PR reviews and contributor onboarding for open source projects. The problem I kept running into as a contributor is exactly what this tool solves.

Advice If You're Starting Out

Don't optimize for easy issues. Optimize for understanding.

Find a project you genuinely use or care about. Read the codebase until you understand something that's fragile or missing. Then fix it properly — with tests, with attention to CI, with patience for review cycles that take longer than you'd like.

The acknowledgement comes from the work. Do the work first.

Find me on GitHub at github.com/iron-prog and LinkedIn at linkedin.com/in/deepak-tiwari-dev.

DEV Community: Dipak Tiwari