I Contributed to the AzureRM Terraform Provider Instead of Waiting for Someone Else To

I use the AzureRM Terraform provider constantly. Personal projects, work infrastructure, side experiments. It's one of those tools that becomes so fundamental to how you operate that you stop thinking about it as a tool and just think of it as how things get done.

So when it didn't have what we needed, it caught me off guard.

The Problem

At work, we were provisioning an Azure resource that required a specific Node.js version. We went to define it in Terraform the way we always do, and the version we needed just wasn't there. The AzureRM provider hadn't been updated to include it yet.

The obvious move in that situation is to wait. File a GitHub issue, check back in a few weeks, hope someone picks it up. That's how a lot of these things go. Open source projects are maintained by real people with real workloads, and feature gaps don't always get prioritized quickly.

But waiting had a cost. We were trying to move fast, and being blocked on a missing provider attribute was slowing us down. That's a frustrating position to be in when the underlying platform already supports what you need. The gap was purely in the Terraform layer.

I looked at the problem for a minute and thought: why not just fix it?

Reading the Contribution Guide

I'd never contributed to the AzureRM provider before. It's a large, active project maintained by HashiCorp with hundreds of resources and a lot of moving parts. Walking into a codebase like that without any orientation is a fast way to get lost.

The contribution guide changed that. I went through it carefully before touching a single line of code, and it was genuinely well-written. It explains how the provider is structured, how resources are organized, how to add or modify attributes, and what the testing expectations look like. There's a clear separation between the resource schema definition and the actual API calls, which makes it much easier to understand what you need to change without having to trace through the entire codebase.

The key things I took away from reading it:

• Resources live in their own files under internal/services/
• Each resource has a schema that defines what attributes Terraform exposes
• Adding a new value to an attribute is usually a matter of updating the schema validation and the corresponding API mapping
• Tests are required and the guide explains how to run them locally against a real Azure environment

That last part matters. This isn't a project where you can write a unit test against a mock and call it done. The tests actually provision resources in Azure, which keeps the provider honest but also means you need an Azure subscription to run them properly.

Making the Change

Once I understood the structure, the change itself was straightforward. I located the resource file for the service we were trying to configure, found where the Node.js version was being validated, and added the version we needed to the allowed values list. Then I updated the corresponding logic that maps the Terraform value to the API request.

The provider is written in Go, which is a language I genuinely enjoy working in. That made the experience significantly better than it would have been if I'd had to work in an unfamiliar language under time pressure. Go is explicit, readable, and the tooling is solid. Navigating a large Go codebase is not as intimidating as it might sound if you're comfortable with the language.

After making the change, I ran the relevant tests and verified the resource provisioned correctly with the new version. Everything worked as expected.

Why This Was Worth Doing

The immediate benefit was obvious: we unblocked ourselves. No waiting, no workarounds, no hardcoding values in a way that would become technical debt. We just had what we needed and kept moving.

But the longer benefit is more interesting to me.

Contributing to open source is something a lot of engineers talk about wanting to do but rarely actually get started with. The barrier feels high. Where do you even start? How do you find something meaningful to contribute? How do you navigate someone else's codebase without making a mess of things?

This experience answered all of those questions in a context I already understood. I wasn't picking a random project and guessing at what needed to be done. I was fixing something that directly affected my work, in a tool I already knew deeply from the user side, written in a language I'm comfortable with. The contribution guide did the rest.

That combination made it feel completely manageable. Not a heroic open source contribution, just a practical fix that happened to benefit anyone else who needed that Node.js version.

What Contributing to a Provider Actually Looks Like

In case you've ever wondered what it takes to modify a Terraform provider, here's the short version.

The AzureRM provider is open source on GitHub. You fork it, clone it locally, make your changes, write or update the relevant tests, and submit a pull request. The maintainers review it, run their own checks, and merge it when it meets their standards.

The Go code itself follows consistent patterns throughout the codebase. Resource schemas define what attributes exist and what values are valid. Acceptance tests verify that real infrastructure gets created and destroyed correctly. Documentation is generated from the schema, so updating the schema also updates the docs.

The main investment is in understanding the pattern before you start. Once you've read a few existing resource files and understand how they're structured, adding something new or extending something existing is mostly mechanical. You're following a pattern, not inventing one.

Go Makes This Kind of Work Enjoyable

I want to be honest about how much the language matters here.

Working in Go on a large, well-structured project is a genuinely pleasant experience. The type system catches a lot of mistakes early. The code is readable even when you're new to a specific file. The compiler errors are clear. The tooling (formatting, linting, testing) just works without a lot of configuration.

If the AzureRM provider were written in something I found less enjoyable, I might have still made the change out of necessity, but I probably wouldn't have come away from the experience eager to do it again. Go made it feel like the kind of problem I'd want to pick up on a Saturday afternoon, not just something I pushed through to unblock a work ticket.

That's not a small thing when you're thinking about whether to contribute to open source. Finding a project written in a language you like is a real advantage.

The Takeaway

If you're blocked on a missing feature in an open source tool you use regularly, especially one with a well-documented contribution process, the path forward might be shorter than you think.

Read the contribution guide. Understand the structure. Make the change. Submit the pull request.

You get to unblock yourself, you contribute something useful to everyone who hits the same problem after you, and you build up the experience of navigating a real production codebase that someone else maintains. For me, it also reinforced why I enjoy Go so much.

The AzureRM provider is a good project to start with if you're using it professionally and want to dip into open source contribution. The codebase is large but well-organized, the patterns are consistent, and the maintainers are responsive. You don't have to wait for someone else to fix what's slowing you down.