Canny supports CSV exports for posts and separate voter exports, creating a bounded migration input.
Mission 01DiscoveryUpstream first
The proving mission
Canny → Fider
Make Fider the easiest credible path away from closed product-feedback software—without fragmenting the project or claiming maintainer approval before it exists.
10qualified builders
01design partner
05Canny interviews
03verified migrations
Why this can work
A bounded exit, not a speculative clone.
The first mission is deliberately a “back” strategy: strengthen the credible open project, make migration legible, and measure adoption.
Fider is an active AGPL project with a current release and an established contribution process.
The mission can prove value through migration and deployment work before proposing broad feature parity.
The mission sequence
Four gates. Every claim earned.
01Now
Align before code
- Share the mission charter with Fider maintainers
- Confirm the correct upstream channel and architectural constraints
- Recruit one Canny design partner with a real export
GateMaintainer direction recorded and one representative export available
02Next
Prove the migration
- Document Canny-to-Fider field and status mapping
- Build a dry-run validator with an explicit loss report
- Test posts, tags, authors, voters, comments, and attachments separately
GateDesign partner approves a dry-run migration report
03Later
Contribute upstream
- Implement only work accepted through Fider's process
- Add regression coverage and operator documentation
- Keep optional migration tooling separable when appropriate
GateAccepted implementation path with named long-term ownership
04Later
Move real teams
- Operate a hosted reference instance
- Complete three reversible, verified migrations
- Publish anonymized migration outcomes and unresolved gaps
GateThree migrations and one paying hosted customer
Migration hypothesis
Preserve what can move. Report what cannot.
This matrix is a discovery artifact, not a compatibility promise. A representative export and maintainer input must validate it.
Data areaSourceProposed pathState
Boards and postsCanny board CSVMap into Fider posts and categoriesMapped
Statuses and tagsCanny post exportNormalize against the destination instanceMapped
AuthorsPost author fieldsPreserve attribution where identity can be verifiedValidate
Votes and votersSeparate voter exports or APIReconcile identities before creating votesNeeds sample
CommentsCanny API or supplemental exportConfirm supported upstream import pathNeeds alignment
Images and attachmentsExported URLs and source filesDownload, verify, and report any lossInvestigate
Hard boundaries
What this mission will not do.
- ×No disconnected Fider fork and no new repository presented as the replacement.
- ×No use of Canny proprietary code, private implementation details, or confusing branding.
- ×No broad roadmap, changelog, or SSO work before Fider maintainers accept the scope.
- ×No migration counted until the adopter verifies its data and can reverse the cutover.
Who is needed now
Bring the export or own a bounded problem.
The discovery gate needs evidence and alignment—not a burst of uncoordinated pull requests.
Design partner
A real Canny workspace
Provide a representative export, define must-keep data, review the loss report, and test a reversible cutover.
Builders
Go, TypeScript, data migration
Map formats, build deterministic validators, improve deployment, and contribute only within accepted upstream scope.
Maintainers
Architecture and ownership
Set boundaries, identify the right proposal channel, and reject work that would add unsustainable maintenance burden.
Apply to Mission 01
Evidence first. Then builders. Then code.
Current and recent Canny users can volunteer for one of five focused interviews. Builders should name the migration or upstream problem they can own.