I Got 4 PRs Merged to the Flutter Framework. Here's Exactly How

I never thought I'd contribute to a framework used by millions of developers.

Flutter felt like this massive codebase maintained by Google engineers, way out of my league. But three months ago, I decided to try anyway. Today, I have 4 pull requests merged into the official Flutter repository (flutter/flutter), reviewed and approved by the Flutter team at Google.

Here is exactly how I did it, step by step.

Why I Wanted to Contribute

I have been building Flutter apps for over 5 years across fintech, e-commerce, IoT, real estate, and healthcare products. I use Flutter every single day. But I had never looked under the hood.

Three things pushed me to finally try:

I wanted to understand how Flutter actually works at the framework level, not just how to use it. I wanted to give back to a tool that has been central to my entire career. And I wanted to stand out as a developer, because very few Flutter developers ever contribute back to the framework itself.

So I went looking for a way in.

Step 1: Finding the Right Issue

I went to the Flutter GitHub repository and started filtering issues. The key is not to look for something impressive on your first try. You are looking for something clearly defined, well-scoped, and achievable without deep internal knowledge of the codebase.

I found file in full. Every open source project has different rules about branch naming, commit messages, PR descriptions, and test requirements. Flutter's is thorough and worth reading carefully.

I forked the repository and set up Flutter from source locally. This is different from installing Flutter normally. You are cloning the engine and framework, not just downloading a binary.

I found the specific test files mentioned in the issue and read them to understand what "correct" looked like versus what needed fixing.

The problem in these files was that widget tests were using MaterialApp or CupertinoApp as their test wrapper, which pulled in the entire Material or Cupertino layer unnecessarily. The correct approach was to use framework-level wrappers that do not carry that dependency.

Step 3: Making the First Fix

I started with autofill_group_test.dart for ), a plain description of what I changed and why, and confirmation that I had run the relevant tests locally.

My commit message format was consistent across all four PRs:

Remove Material dependency from [filename]



Part of #177414

Step 5: The Review Process

This is the part most people are afraid of. Google engineers reading your code.

The reality is that Flutter maintainers are professional and constructive. They want contributions to succeed. On I received 12. These were not rejections. They were detailed, specific feedback that made the final code better.

The review on #181951 was particularly educational. The SelectionArea web test needed to move from the widgets test folder to the material test folder because it relied on material-specific behavior. A reviewer caught a subtle dependency I had missed and walked me through the correct fix. That kind of direct feedback from framework engineers is genuinely invaluable.

I addressed every comment, pushed updates, and waited for re-review. The turnaround was faster than I expected.

The 4 Merged PRs

Here is the full list of what got merged:

— Move SelectionArea web test from widgets to material folder

Merged February 19. 17 review comments. Tagged: f:material design, framework.

— Remove Material dependency from semantics_keep_alive_offstage_test.dart

Merged February 13. Tagged: a:accessibility, framework.

Each one built on the last. By the fourth PR I knew exactly what reviewers would look for and I addressed those things proactively in the code before they asked.

What Contributing to Flutter Actually Taught Me

The technical lesson is about dependency management and layered architecture. The Flutter framework is deliberately structured so that lower-level packages do not depend on higher-level ones. When test files break that rule, even accidentally, it signals a coupling problem that could affect how the framework evolves. Understanding this made me a better architect in my own apps.

The broader lesson is about reading a large codebase with confidence. When I started, flutter/flutter felt enormous and intimidating. After four PRs, I navigate it comfortably. That skill transfers directly to joining any large engineering team or contributing to any open source project.

The professional lesson is that open source contributions are not just resume lines. The review conversations, the back-and-forth with maintainers, the process of getting your code to a standard that ships in a framework used by millions, that is real engineering experience that very few developers have.

How to Start Your Own Flutter Contribution

Go to before you touch any code. Set up Flutter from source. Run the tests locally before pushing anything. Write a clear PR description that references the issue.

The Flutter team is genuinely welcoming to new contributors. The codebase is well-documented. And seeing your name in the merged commits of a framework used by millions of developers worldwide is worth every hour of the process.

Let's Connect

If you are working through your first Flutter contribution or have questions about open source in general, reach out. I am happy to help.

GitHub:

Happy contributing.