FlutterFlow
Flutter Fund
We’ve pledged $1 million to support open-source projects and contributors helping Flutter thrive.
💜 FlutterFlow is built on Flutter, and we're committed to helping the ecosystem thrive. From fixing core bugs to modernizing essential packages, we're here to support the tools developers rely on every day.
How We Fund Community Contributions
Offering bounties on high-impact public issues
Contracting work to trusted vendors and contributors
Supporting maintainers of top-used packages for updates
Areas We're Actively Funding
Enhancing package compatibility for emerging platforms like WebAssembly
Improving core developer tools (media players, editors, UI components, and more)
Strengthening widely used packages in the FlutterFlow and broader Flutter community
Rules & Information
Eligibility Rules
- Must be Flutter-related: Submissions must clearly relate to Flutter, Dart, or top-used packages in the ecosystem.
- Fix must be concrete: The submission should describe a specific issue (with a link to a GitHub issue or reproducible example) and a proposed or completed fix.
- Fix must be open-source: Fixes must be submitted to a public repository under an OSI-approved license.
- Submitter must not be sole maintainer (or must disclose if so): To avoid self-funding pet projects, contributors must disclose their relationship to the package.
Integrity & Quality Rules
- No funding for trivial changes: Submissions that propose fixing typos, formatting, or minor docs changes without clear user impact will be rejected.
- Fix must address real user pain: Submissions should demonstrate value to the broader community—either by linking to existing user reports, upvotes, or usage metrics.
- One issue per submission: No bundling of unrelated issues to inflate value.
- Support request must match effort: Suggested funding amounts should be in line with complexity (e.g., no $500 requests for one-line fixes).
Abuse Prevention
- No spam or SEO-driven submissions: Submissions must not promote unrelated products or include promotional links.
- No hostile forks or duplicative PRs: Fixes must not be in conflict with upstream maintainers or duplicate existing work just to claim support.
- No “fixing” fake issues: Submitters cannot create and resolve fake issues to collect support.
Transparency & Attribution
- Credit must go to the right contributor: If someone is nominating a fix by another person, the author must be informed and agree.
- Must link to issue + fix PR: Every submission should include links to both the issue and the pull request or proposed fix.