Regardless of what Adobe decides next, the message was clear: animators who depend on proprietary tools are one corporate decision away from losing their workflow.
2D animation deserves an open-source option that isn't a toy. We've been working with a professional animator to guide feature priorities and ensure we're building something that actually fits real production workflows - not just a tech demo.
Github Repo: https://github.com/17twenty/inamate
We're at the stage where community feedback shapes the direction. If you're an animator, motion designer, or just someone who's been frustrated by the state of 2D animation tools — we'd love to hear:
- What features would make you switch from your current tool?
- What's the biggest pain point in your animation workflow?
- Is real-time collaboration actually useful for animation, or is it a gimmick?
Try it out, break it, and tell us what you think.
Built with Go, TS & React, WebAssembly, PostgreSQL, WebSocket, ffmpeg (for video exports).
- Go WASM engineowns the scene graph, evaluates timelines, compiles draw commands
- Canvas2D frontend executes the command buffer (GPU-accelerated by the browser)
- Go backend handles collaboration, persistence, and video encoding via ffmpeg
- Operation-based document model - every mutation is an operation that supports undo/redo and real-time sync
We chose a command buffer architecture (engine emits draw commands, browser rasterizes) over Figma-style pixel rendering in WASM. Canvas2D is already GPU-accelerated, and Go's WASM ecosystem doesn't have a battle-tested software rasterizer. This gives us hardware rendering for free while keeping the engine deterministic.
The attached file doesn't have terms, and references an undefined "change date."
If you want people to understand that it's a real production tool and not a tech demo, your example animation in your readme should show a real production animation. Currently, what you're showing makes it look like a toy.