We're forking Flutter

Original Article ↗ Hacker News Discussion ↗

A former Google engineer has launched Flock, a community-driven fork of Google’s Flutter UI toolkit, arguing that Flutter’s small core team, slow bug resolution, and tight internal control leave serious issues unaddressed for its large developer base. Commenters are split: many praise Flutter’s technical quality and widespread use across mobile and desktop, but share concerns about Google’s long‑term commitment, contribution bottlenecks, and de‑prioritized platforms like desktop and web. Others question the fork’s realism, its branding (including potential trademark and “Flutter Foundation” confusion), and whether it can attract enough expert maintainers without fragmenting the ecosystem.

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.