A feedback portal looks simple - a box where users post ideas and vote - but its real value is the history it accumulates: the votes, comments, status changes, and merge decisions that record why something got built or shelved. That is also what makes a hosted portal hard to leave, because the accumulated context lives in the vendor's system and the portal bends only so far to fit how your team triages. Open source feedback tools let you run the request board and roadmap loop on your own infrastructure, keep votes and comments in a database you own, and reshape moderation, statuses, authentication, and integrations to match how product decisions actually get made in your organization.
Formbricks is a free and open source survey platform and privacy-first experience management tool. It gathers feedback and user insights at every point in the journey through in-app, website, link, and email surveys, and you can either use its built-in analysis or build on top of the data you collect.
Fider is a feedback portal for feature requests and suggestions. It gives customers one place to tell a product team what they need, so teams can collect customer feedback and feature requests without guessing what to build next.
LogChimp is an open source customer feedback tool for tracking user input and using it to build products. It is positioned as an alternative to Canny, ProductBoard, and UserJot, with a focus on collecting customer feedback in a self-hosted setup.
Two shapes of feedback here - public voting boards and embedded surveys - so pick by how your users will actually speak up.
For a focused voting portal: Fider Fider gives customers one place to submit feature requests and suggestions and vote on product direction, which covers the core of what most teams use UserVoice for. It self-hosts on your own servers and infrastructure for free, or runs as Fider Cloud if you would rather not operate it, and it is built in Go with an AGPL license. For a team that mainly needs public intake and prioritization without a lot of extra machinery, it is the straightforward choice.
For boards and roadmaps: LogChimp LogChimp leans toward structured feedback, letting you create posts and organize them by boards and roadmaps, with brand customization and a dashboard for managing incoming requests. It positions itself against tools like Canny and ProductBoard as a self-hosted option, with deployment notes for Ubuntu and one-click cloud hosting. Reach for it when you want feedback grouped into distinct boards and a visible roadmap rather than a single voting list.
For embedded survey feedback: Formbricks Formbricks captures feedback the way UserVoice's embedded widgets did, through in-app, website, link, and email surveys rather than a public voting board. A no-code editor with templates lets you target specific user groups without touching application code, and it self-hosts with Docker under an AGPL core, with a hosted free plan if you prefer. It integrates with Slack, Notion, Zapier, and n8n. Choose it when you want structured, in-context feedback and surveys instead of an open idea board with votes.
UserVoice is more than a comment box; it ties public suggestions, voting, status labels, internal triage, and user identity into one hosted system, so the first decision is which of those behaviors have to survive unchanged. A team that needs a public voting board with duplicate detection wants something different from one that captures private feedback tied to accounts and customer segments. Fider is the most established of the options here, a focused portal for feature requests and voting that self-hosts on your own servers or runs as Fider Cloud, while LogChimp organizes feedback posts into boards and roadmaps with brand customization for teams that want a self-hosted board they can style. Formbricks comes at it from a different angle, an experience-management platform that gathers feedback through in-app, website, link, and email surveys, closer to UserVoice's embedded capture than to its public idea board.
The bigger adjustment is losing UserVoice's packaged product-management opinions. Its managed portal, admin workflows, analytics views, and embedded capture arrive with little infrastructure work; an open source replacement often means assembling moderation, notification rules, SSO, roadmap presentation, and reporting around the core feedback database yourself. The payoff is control over hosting, schema, retention, and customization, but be honest about who will own upgrades, abuse handling, email deliverability, and user support once the vendor is no longer doing it for you.
Plan the move as a data migration, not a fresh start. Inventory the UserVoice objects you rely on - boards, suggestions, comments, votes, labels, statuses, users, and private notes - and map each to the new system before importing anything. Votes need special care because they connect a specific user to an idea rather than a bare count, so migrating totals alone loses the signal. Clean up merged duplicates, stale categories, and old status names before cutover, and keep the old IDs so you can set up redirects and preserve the audit trail.
It is preserving feedback context, not rebuilding a submission form. UserVoice usually holds years of votes, comments, status changes, merged ideas, and internal decisions, and if you migrate only titles and descriptions, product managers lose the evidence behind past prioritization. Plan the switch around data relationships first - which user voted for what, why an idea was merged or declined - then choose the portal and voting experience that fits on top of that history.
Yes, if you move votes as user-to-idea relationships rather than importing bare totals. Supporters should still see the ideas they backed, and your team should be able to filter by voter where permissions allow. Fider and LogChimp both center on voting, so the destination has somewhere to put that data. If privacy rules block full user migration, keep the aggregate counts and store a clear note explaining how the historical signal was preserved.
Only if you plan redirects. Keep a mapping from old UserVoice idea IDs or URLs to the new records during export, then configure redirects at the edge, application, or proxy layer. If you cannot preserve exact mappings, publish a migration landing page and redirect your highest-traffic ideas by hand. Broken feedback links are one of the most common and most visible failures after a rushed portal migration.
Clean duplicates before the final import. Long-running UserVoice instances accumulate merged and near-duplicate suggestions, and moving them blindly recreates the same moderation burden on day one. Export the merge relationships if they are available, pick a canonical idea for each cluster, preserve the combined vote totals or voter links, and add a short note on the surviving record explaining that related suggestions were folded together so the history stays understandable.
Public comments usually import with author, timestamp, and body if you export them cleanly. Internal notes need more caution, because they can contain customer names, account details, or sales context that must not become public. Separate public discussion from private triage before the import, and verify permissions in the target system before exposing any migrated record. Fider and LogChimp differ in how they model private versus public content, so check that first.
Map statuses on purpose instead of copying every old label. UserVoice status names often reflect years of process drift - under review, planned, started, completed, and variants - and the new system usually benefits from a smaller, clearer set that matches how your team communicates now. Keep the historical timestamps where you can, since when an idea changed status is useful for audits and for following up with the people who requested it.
Sometimes, but the details bite. UserVoice widgets may be scattered across marketing pages, web apps, help centers, and authenticated product areas, so replacing them means finding every snippet, matching the user-identity handoff, preserving context fields, and testing mobile layouts. A plain link to a hosted portal can be enough for lighter cases, but in-app capture that knows who the user is usually needs custom integration work.
