Problem
OpenCut has 69k+ stars and opencut.app has real users — but the team currently has no signal on how the product is actually being used. Without this, every architectural and prioritisation decision in the rewrite is made blind:
- Which features do users actually reach (vs. which do they open and never touch)?
- Where do sessions drop off?
- What export formats and resolutions are most common?
- Are users hitting errors silently and churning without filing issues?
- Is the editor being used for short-form (15s) or long-form (5min+) content?
This matters most right now, during the rewrite, while architectural decisions are still open. Building the new Editor API and plugin system without usage data means optimising for assumptions, not reality.
Solution
Add opt-in, anonymous, aggregated telemetry — off by default, with a clear prompt on first load and a permanent toggle in settings.
What to track (events only, no content)
| Event |
Why it matters |
| Session start / duration |
Active usage vs. install-and-abandon |
| Feature touched (timeline, trim, audio, captions, effects) |
Which features have real adoption |
| Export triggered + format + resolution |
What output workflows matter |
| Export success / failure + error type |
Silent failure rate |
| Number of clips on timeline |
Simple vs. complex edit patterns |
| Plugin installed (once plugin system ships) |
Which plugin categories drive adoption |
What to explicitly NOT track
- Video content, file names, or any media metadata
- User identifiers, IPs, or anything linkable to an individual
- Keystroke or mouse patterns
Privacy constraints (non-negotiable)
Given that privacy is a stated reason OpenCut exists ("your videos stay on your device"), this must be:
- Off by default. Opt-in only, surfaced once on first launch with a plain-language explanation.
- Self-hostable. Enterprise/self-hosted users should be able to route telemetry to their own collector or disable entirely via config flag.
- Auditable. The full event schema should be documented in
/docs and kept in sync with the code. No dark patterns.
- Killable at runtime. A single env var (
OPENCUT_TELEMETRY=false) should fully disable all collection.
Acceptance criteria
Alternative
Alternative
Do nothing and rely on GitHub issues + Discord signals.
The downside: issues are filed by the vocal minority. Most users who hit a bug or find a feature confusing just leave. Passive telemetry is the only way to see what the silent majority is actually doing.
Periodic opt-in surveys instead of telemetry.
Lower engineering lift, but surveys capture stated preference, not actual behaviour. A user might say captions are important but never use them. Event data shows the truth.
Wait until after the rewrite to add this.
The worst option. The rewrite's biggest decisions — what goes into core vs. plugins, which features need to be first-class — are being made now. Telemetry added after the architecture locks in can inform iteration but can't shape the foundation.
Anything else?
Why this timing matters: The rewrite introduces a plugin-first architecture. If the team doesn't know which core features are actually used, they risk moving things into plugins that should stay in core (and vice versa). Usage data collected even from the classic version at opencut.app would directly inform these decisions while there's still time to act.
Suggested implementation: PostHog has an open-source self-hosted option used by several OS projects for exactly this pattern. Alternatively, a simple HTTP beacon to a maintainer-controlled endpoint avoids any third-party dependency entirely. Events should be batched and sent on session end — not in real-time — to avoid any inference of live activity.
Related: This pairs well with the planned headless/batch rendering mode — distinguishing interactive sessions from automated ones would itself be valuable signal for understanding how the Editor API gets used once it ships.
Problem
OpenCut has 69k+ stars and opencut.app has real users — but the team currently has no signal on how the product is actually being used. Without this, every architectural and prioritisation decision in the rewrite is made blind:
This matters most right now, during the rewrite, while architectural decisions are still open. Building the new Editor API and plugin system without usage data means optimising for assumptions, not reality.
Solution
Add opt-in, anonymous, aggregated telemetry — off by default, with a clear prompt on first load and a permanent toggle in settings.
What to track (events only, no content)
What to explicitly NOT track
Privacy constraints (non-negotiable)
Given that privacy is a stated reason OpenCut exists ("your videos stay on your device"), this must be:
/docsand kept in sync with the code. No dark patterns.OPENCUT_TELEMETRY=false) should fully disable all collection.Acceptance criteria
/docsand kept in syncOPENCUT_TELEMETRY=falsefully disables all collectionAlternative
Alternative
Do nothing and rely on GitHub issues + Discord signals.
The downside: issues are filed by the vocal minority. Most users who hit a bug or find a feature confusing just leave. Passive telemetry is the only way to see what the silent majority is actually doing.
Periodic opt-in surveys instead of telemetry.
Lower engineering lift, but surveys capture stated preference, not actual behaviour. A user might say captions are important but never use them. Event data shows the truth.
Wait until after the rewrite to add this.
The worst option. The rewrite's biggest decisions — what goes into core vs. plugins, which features need to be first-class — are being made now. Telemetry added after the architecture locks in can inform iteration but can't shape the foundation.
Anything else?
Why this timing matters: The rewrite introduces a plugin-first architecture. If the team doesn't know which core features are actually used, they risk moving things into plugins that should stay in core (and vice versa). Usage data collected even from the classic version at opencut.app would directly inform these decisions while there's still time to act.
Suggested implementation: PostHog has an open-source self-hosted option used by several OS projects for exactly this pattern. Alternatively, a simple HTTP beacon to a maintainer-controlled endpoint avoids any third-party dependency entirely. Events should be batched and sent on session end — not in real-time — to avoid any inference of live activity.
Related: This pairs well with the planned headless/batch rendering mode — distinguishing interactive sessions from automated ones would itself be valuable signal for understanding how the Editor API gets used once it ships.