We're forking Flutter

Original Article ↗ Hacker News Discussion ↗

Fork goals and motivation

  • Fork (“Flock”, under “Flutter Foundation”) is presented as a community-led Flutter+ that:
    • Stays close to upstream while accepting bug fixes and features more readily.
    • Targets long‑standing issues, especially on desktop and web.
    • Aims to reduce dependence on Google’s priorities and internal processes.
  • Rationale given: small Google team (estimated ~50 people) vs ~1M Flutter developers; slow or non‑existent responses on some serious bugs; hard path for external contributors.

Skepticism about the fork

  • Many are confused who “we” is; GitHub org shows no public members; outreach runs through social accounts rather than open processes. This reduces perceived seriousness.
  • Some see the launch as thin: essentially a mirrored repo with no clearly surfaced fixes yet.
  • Others think the author underestimates the difficulty of:
    • Recruiting qualified reviewers for a large, complex codebase.
    • Maintaining test quality and compatibility.
    • Merging upstream changes after divergence.

Branding, naming, and legal concerns

  • Multiple comments call the “Flutter Foundation” name and the use of “Flutter” in the branding misleading, since Google owns the trademark.
  • Expectation that Google Legal may eventually force a rename, as in other OSS trademark disputes.
  • “Flock” also collides with existing products, raising further confusion.

Google, governance, and OSS process

  • Several developers report frustration with Google‑led OSS:
    • Google’s internal monorepo and “one version” rules can block or delay external changes.
    • Priorities are driven by internal users; desktop and some web issues appear deprioritized.
  • Others counter that:
    • 50 engineers is large by OSS standards and many major projects run with fewer.
    • 1,500 external contributors over a decade is high, not low.
    • The main bottleneck is safe review and testing at scale, not writing patches.

Flutter’s health and adoption

  • Strong disagreement over “1M Flutter developers”:
    • Pro side: historical opt‑out analytics, IDE extension counts, survey data, and big‑name adopters; some phone scans show many installed Flutter apps.
    • Skeptical side: app‑store counts seem too low; many counted “users” are students, hobbyists, CI, or partial integrations.
  • Many practitioners praise Flutter’s DX, performance, and multi‑platform reach compared to React Native, Electron, and MAUI; others insist cross‑platform UI is fundamentally the wrong tradeoff versus native.

Likely impact

  • Some expect the fork to be a net positive, analogous to io.js vs Node: competitive pressure that may improve Flutter or eventually be reconciled.
  • Others fear community fragmentation, added uncertainty for adopters, and a fork that cannot realistically keep up with Google’s engine and platform work.