What was missing
When I started building Fluera, I looked for a Flutter canvas library that could do four things at once: infinite pan/zoom with real physics, pressure-sensitive input that didn't lie about tilt and predicted strokes, a scene graph that scaled past a thousand elements, and rendering that stayed at 60 FPS on a mid-range Android. I couldn't find one.
What exists is excellent for its scope. perfect_freehand
gives you a beautiful stroke algorithm. scribble gives you
a clean signature pad. flutter_painter gives you simple
vector tools on a bounded surface. None of them were built to be the
drawing layer of a real production app with years of use ahead.
So I wrote one from scratch. Vulkan renderer on Android, Metal on iOS/macOS, OpenGL fallback on Linux, Direct3D on Windows, WebGPU on the web. Scene graph with R-tree indexing. One-Euro filter for input smoothing. Apple Pencil prediction on iOS. Stylus hover on iPadOS. Palm rejection that actually rejects palms. It took months.
Why give it away
The moment you write infrastructure good enough for your own product, you're sitting on a second product whether you want to or not. Keeping it private has three real costs:
- It rots alone. Bugs I don't hit, someone else does. Private code gets feedback from one developer. Public code gets feedback from everyone who touches it.
- It wastes the Flutter community's time. Somewhere right now, another solo dev or small team is writing pieces of this from scratch, worse than they could. Every hour they spend on infrastructure is an hour they don't spend on their actual product.
- It's a worse moat than the app. My moat is Fluera the app — the pedagogy, the UX, the brand. Not the canvas engine. Giving the canvas away costs me nothing and builds a secondary audience of developers who trust my work.
Why MIT, not "source-available"
I considered BSL 1.1 with a change date, Elastic License 2.0, and dual MIT+commercial. I picked plain MIT for the core package because:
- The Flutter community is allergic to non-standard licenses. A non-MIT package doesn't get installed — people click the license field on pub.dev and close the tab.
-
The things worth charging for aren't in the core. Native GPU live-stroke,
16 Photoshop blend modes, real-time CRDT collaboration, time-travel replay,
vector export, brush textures + paper grain, BYO-database cloud sync —
those live in
fluera_canvas_gpu, shipped under a normal commercial license (€399/year Indie, €1,499/year Team). Keeping the split clean is easier than legally licensing every line. - MIT removes every question a company lawyer could raise about shipping the core in a commercial product. That friction kills adoption; adoption is what I need.
What you can expect
fluera_canvas will ship on pub.dev when the API stabilises
a little further. Until then the signals to watch:
- Versioning is honest. Until
1.0anything can change. Pin to a specific pre-release in production and upgrade deliberately. - Issues get read. I'm the only maintainer right now. Your bug report is my roadmap.
- Pro is always optional. Core stays a complete, working canvas. No crippleware.
If this is useful
Star the repo, kick the tires, tell me what breaks. If you're building something serious on top, reach out — the first design partners get priority on bugs and heavily discounted Pro licenses.
— Lorenco