The road to open source: what happens between now and the October launch

The first post on this feed introduced what Flare is. This one is about where it goes next, and how it gets there.

Two things happened this month worth writing down: the project got a sharper focus, and the open-source launch got a concrete plan instead of a vague “someday”. This is the honest version of both.

A sharper focus

Flare started life described as a game engine. That was never quite right, and this month the whole project stopped pretending otherwise.

Flare is a modular 2D engine written in TypeScript. It runs the same code on the web, through CanvasKit, and on React Native, through react-native-skia: the same Skia renderer under both. What it is actually for is animation, gamification, and interactive UI: the canvas-driven, gesture-rich surfaces that cross-platform teams keep rebuilding twice, once for web and once for mobile.

Games are how the engine gets exercised, not what it sells. Pan Tvardowski, a Polish-folklore vertical shoot-‘em-up (a shmup), is the most demanding way to prove the engine out, so it doubles as the dogfooding showcase. It is not on the app stores, and “the engine ships games” stays aspirational until it lands there.

So: not a competitor to the big general-purpose game engines, and not a general-purpose game framework. A 2D engine that lives inside your web and mobile apps. That reframing drove a rebuild of the whole site you are reading this on.

Where it stands today, honestly

• Version 0.2.1, published to npm with access: restricted. That is a real, versioned publish, but a restricted scoped package returns a 404 to anonymous installs, so you cannot bun add it yet.
• 40 scoped @flare-engine/* packages, all moving in lockstep.
• The engine test suite runs more than 2,200 passing tests across nearly 200 files, and it grows most weeks as the engine hardens. The showcase game, Pan Tvardowski, is a separate repository with more than 2,000 passing tests of its own, across 266 files. Two suites, counted separately, because they are separate things.
• There is now a live web build. Several of the hero animations on this site run real @flare-engine packages in the browser through CanvasKit, not a video and not a mockup. One caveat I want to be precise about: web performance is not measured yet. A build that runs is not the same as a benchmark, and I will not quote web frame rates until there are real ones. The on-device numbers that do exist are from Android.

One maintainer, no public community yet. Early, and saying so.

The road to open source

The public launch is targeted for October 2026. It is one milestone, not a slow trickle, and it has a defined shape:

1. Freeze the API surface and cut a release-candidate version. No new features land after the freeze; only stabilization.
2. Relicense the engine from MIT to Apache-2.0 before anything goes public. Apache-2.0 adds an explicit patent grant, and it reserves the Flare Engine name as a trademark rather than granting it. This is why today’s copy says “Apache-2.0 at the October 2026 launch” while the repository’s own LICENSE file still reads MIT: the relicense is a deliberate pre-launch step, not something already done.
3. Add contribution plumbing (a DCO or CLA) before the first external pull request, so the licensing stays clean from the first contributor onward.
4. Flip the packages from restricted to public, open the source repository, turn on the GitHub links, and open a community space.

The showcase game keeps its own separate, non-commercial license through all of this. Relicensing the engine does not relicense the games built on top of it.

What you can do now

Nothing to install yet, and I would rather say that plainly than pretend otherwise. If you want to be told the moment public packages and source land, the notify list on this site is the whole ask. The next entries here will document the freeze and the relicense as they actually happen, not after.