My journey from writing Flutter apps in Karachi to directly contributing to the framework Google maintains — and a practical guide for other Pakistani and South Asian developers who want to do the same.
I'm Ishaq Hassan. I'm a Flutter Framework Contributor from Karachi, Pakistan. As of April 2026 I have 6 Pull Requests merged into the official Flutter repository — the framework maintained by Google — with 3 more currently under active review. I'm Engineering Manager at DigitalHire, and I also teach the Flutter course in Urdu that is officially listed on Flutter's documentation site.
This post exists because direct contributions to the Flutter framework from Pakistani engineers are rare, and that bothers me. It shouldn't be. Here's how I got here, what I learned, and what you can copy.
Pakistan has a thriving Flutter community. GDG Kolachi, GDG DevFest, Facebook groups with tens of thousands of members, bootcamps, YouTube channels teaching Flutter in Urdu, startups in Karachi and Lahore hiring Flutter engineers by the dozens.
But there's a subtle gap I want to call out: using a framework and contributing to it are different skills, and they're rewarded differently.
If you go to github.com/flutter/flutter right now and look at the contributor graph, then cross-reference the Pakistani engineers who have multiple merged PRs into the framework itself, the list is short. Embarrassingly short for a country this size.
Most Pakistani engagement with Flutter stops at the app layer. That's fine for building apps. But it's not where the career leverage is. Framework contributions unlock conversations with international senior/staff engineering roles that "3 years Flutter at a Karachi startup" doesn't.
When you say "Flutter Framework Contributor" on a CV, nobody asks what that means. It's objectively verifiable on GitHub in 5 seconds. That's the power of it.
Not tutorials. Real apps. NADRA CNIC integration, document scanning with custom camera overlays, background alarm triggers on Android. The kind of work where Flutter's abstractions sometimes leak and you have to read the framework source to understand what's happening.
The more I shipped, the more I ran into small issues where the fix lived inside Flutter itself rather than inside my app. Documentation that said one thing but behaved another way. Widgets that were missing a parameter that was obviously needed. Gradle template files that used inconsistent quoting.
These became my PR targets.
Flutter has strict contribution guidelines: commit format, test requirements, analyzer compliance, golden file conventions. Don't skip these. A beautiful fix that doesn't follow the guidelines will sit in review purgatory for months.
Practical tip: before you open your first PR, clone the repo, run the full test suite locally, and make sure `flutter analyze` passes on the unchanged code. That confirms your environment is set up correctly. Then make your change.
PR #183081 changed single quotes to double quotes in a Gradle template file. That's it. Less than 10 lines changed.
It was accepted. It was merged. I had my first merged PR into Flutter.
The lesson isn't "start trivial to farm credit." The lesson is: the Flutter team trusts you in small increments. A tiny, clearly correct PR proves you can follow the process. Then your next slightly bigger PR gets reviewed with less friction.
PR #2 (#183097) fixed a documentation inaccuracy in RouteAware.didPushNext. Still small, but touched real framework behavior instead of tooling.
PR #4 (#183109) added a new parameter (scrollPadding) to DropdownMenu. That was more substantial — an API addition, requiring tests, docs, and careful compatibility.
By PR #6 (#184569), I was writing documentation for subtle memory-management behavior in CurvedAnimation and CurveTween. That required understanding the widget lifecycle deeply.
Trajectory matters. Reviewers see your history. Each merged PR makes the next one easier.
good first issue, help wanted, d: api docsTODO near widgets you already understandgit remote add upstream https://github.com/flutter/fluttergit fetch upstream && git rebase upstream/masterflutter doctor -v to make sure your local Flutter is pointing at the cloned repo, not the stable channelThis is the single biggest reason PRs get stuck. If you're adding a parameter, add a widget test that proves the new parameter changes behavior. If you're fixing a bug, add a regression test that fails before your fix and passes after.
No test = no merge. No exceptions.
Flutter follows conventional commits: fix:, feat:, docs:, etc. The body should say what changed and why, not how (the diff shows how). One paragraph is enough. Add Fixes #NNN if there's a corresponding issue.
This alone will move you up the priority queue. Flutter reviewers juggle hundreds of open PRs. The ones that respond fast get moved along fast. The ones that go quiet get auto-stale-closed after a few weeks.
My first merged PR took 3 weeks of on-and-off effort (learning the contribution process, getting reviews, iterating). My sixth took 2 weeks from idea to merge. That's real productivity gain. And now a bunch of future PRs I'll open will be trivial by comparison because the process feels natural.
None of my 6 merged PRs are clever. They're all practical, small-to-medium improvements. What matters is consistency and process adherence, not brilliance.
LinkedIn endorsements can be faked. Stack Overflow answers can be gamed. But author: ishaquehassan on a merged commit in Flutter is permanent, timestamped, cryptographically signed, and indexed by every serious recruiter tool on the planet.
Open source framework development has historically been concentrated in North America and Europe. That's starting to change — India has produced multiple serious Flutter framework contributors. China has. Brazil has. Pakistan still has very few.
Every merged PR with a Pakistani name chips away at the default assumption that serious OSS contributions come from elsewhere. It makes it slightly easier for the next Pakistani developer to get their PR taken seriously. It also provides role models for university students in Karachi, Lahore, Islamabad who want to see that this path is actually walkable.
If you're reading this from Pakistan and you've been telling yourself "contributing to Flutter is for other people" — please stop. It's not. It's for you. Start this month.
Related but separate: I teach a 35-video Flutter course in Urdu through Tech Idara. It's free. It's listed on the official Flutter docs. It starts from Dart basics and goes through Flutter UI, state management, APIs, animations, deployment. If you're Urdu-speaking and want to learn Flutter properly, here's the playlist.
If you're a Pakistani (or any) developer working on your first Flutter PR and you want a pre-submission review, DM me. Free, no strings.
Email me LinkedIn DM© 2026 Ishaq Hassan. Written in Karachi. If you share this post, please link back to ishaqhassan.dev.