Someone Else's BOM Meets Your Local Reality

Found a motor controller project on GitHub about eight months ago. Well-documented, clean schematic, active maintainer who had actually responded to issues in the last six months — which is better than most. The BOM was 34 line items. I went through it on a Saturday morning expecting to have an order placed by afternoon.

Three hours later I had ordered six components, flagged eight as "check again," identified two that needed substitution, and abandoned four entirely because they were either US/EU distribution only, discontinued across every Indian distributor I could find, or priced in a way that made the project economics fall apart when you added import duties.

This is what I now call the GitHub BOM problem. The person who designed the board is probably based somewhere with next-day Mouser delivery and no import complexity. They didn't think about regional availability because they didn't need to. The BOM is accurate for their context. It's not necessarily accurate for yours.

This isn't a criticism. It's just a structural reality of open-source hardware that rarely gets discussed in the documentation.

The substitution question

The hardest part of working from someone else's BOM isn't finding the components — it's substituting the ones you can't find without inadvertently breaking the design.

Some substitutions are straightforward. An LM7805 is an LM7805 regardless of manufacturer. Most passives are interchangeable within tolerance classes. If the BOM specifies a generic NPN transistor and you have a different brand in the same package with the same gain range, it's probably fine.

The difficult ones are where the designer chose a specific part because of a parameter that isn't obvious from the component category. The BOM says "N-channel MOSFET, 30V, 5A" and there are about forty components fitting that description. Which one did they validate the design with? What gate threshold voltage does the driving circuitry assume? What switching speed is the snubber designed for? The BOM entry doesn't tell you. Sometimes the schematic notes do. Often they don't.

I've had substitutions that worked perfectly and I've had one that worked in most conditions but had thermal issues under sustained load — almost certainly a different RDS(on) than the original. I've had one that destroyed a board because the replacement had the same footprint but a different pinout — physically identical packages, different pin arrangement, not obvious from the outside.

The pinout failure was my fault for not reading the datasheet carefully enough. But it was also a function of substituting at all: when you're buying what you can get rather than what the BOM specifies, you're doing more verification work than the original designer had to do.

Cross-referencing against what you already own

The dimension of the GitHub BOM problem that's easiest to address is the components you might already have. If you've been building for a year or two, you probably own a meaningful fraction of any standard BOM — passives, common regulators, basic ICs, connectors. But knowing which fraction requires having a current, accurate inventory.

I rebuilt my approach to new projects around this step. Before I look at any supplier, I run the BOM against my inventory. Not manually — I have too many items for that — but through search and cross-reference. The results consistently surprise me on the upside. On recent projects I've found 40-60% of standard BOMs already in my collection.

That changes the economics significantly. Instead of ordering 34 components, I'm ordering 14-20. The order is smaller, cheaper, and arrives faster. More importantly, I know exactly which specific items I need, which makes the sourcing decision much more focused.

The gaps — the items I don't have and can't source easily locally — that's where I make substitution decisions early, at planning stage, before they're blocking a build at 10pm.

A practical workflow

What I do now when I pick up a GitHub project:

First pass — flag the exotics. Scan the BOM for anything that looks single-supplier, highly specialised, or clearly from a component ecosystem I'm not familiar with. RF modules requiring certifications, FPGAs that aren't widely distributed, motor drivers from niche robotics suppliers. These are the ones to resolve before spending any time on the rest.

Second pass — inventory cross-reference. What do I already have? Remove those from the sourcing problem.

Third pass — sourcing research. For everything remaining: what's actually available from Indian distributors or via fast domestic shipping? This is where substitutions get made, with explicit notes about why each substitution was chosen.

Fourth pass — design review for risky substitutions. For any component where I'm not confident the substitution is safe, read enough of the design documentation to understand the constraints. This pass takes the longest and requires the most knowledge. Some projects are well-documented enough to make it fast. Others give you just the files and no context, in which case you're reading the schematic itself.

The GitHub BOM problem is fundamentally an information problem — the BOM has information about the designer's context, not yours. Solving it means building information about your own context: what you have, what you can source, what substitutions are safe. That work is worth doing once at the start rather than repeatedly mid-build.