Most maintainers already run feature requests through GitHub issues and a thumbs up reaction, and that is a real feedback system, not a missing one. A separate board earns its place only in specific conditions: duplicate issues piling up, users who will never open a GitHub account, or sponsors whose requests should carry more weight than a drive by reaction. VoteFirst is the hosted board this page is written to sell, at nine dollars a month for one project, and the comparison below says plainly when it is not worth adding.
When GitHub issues and reactions are already enough
If your feature requests fit inside a dozen or so open issues, a reaction count sorts them well enough, and a pinned "Roadmap" issue or a GitHub Discussions poll gives people a place to pile on. Every one of your users already has a GitHub account, because they are developers who installed your package, so asking them to click a thumbs up costs nothing extra. In that shape, a board is a second place to check for no real gain, and the answer is to skip it.
Reactions also already sort by count, issues already thread into comments, and closing an issue already tells its subscribers the thing shipped. A board only replaces that sort of mechanism and that is not a reason to add one on its own.
The largest project run this way is VS Code, which takes every feature request as an issue and uses the thumbs up count as a gate: a request the team does not plan for is closed unless it reaches 20 upvotes in 60 days. Across 28,886 of its feature requests, one filed by someone outside the project was closed by that rule 54.3 percent of the time and built 12.0 percent of the time. Across the 1,000 most starred repositories, 877 of the 935 with issues on mark feature requests with a label or issue type, and 479 also keep an Ideas category in Discussions.
When a separate board earns its place
The signal to add one is not a user count, it is a specific friction GitHub does not solve.
Duplicate issues keep arriving for the same request. GitHub has no built in merge for two issues into one vote total, so each duplicate starts at zero reactions and the real demand for one feature is split across three or four open issues nobody thinks to search for first.
Some of your users will never open a GitHub account. A plugin, a SaaS product, or a desktop app with a non developer audience gets feature requests from people who do not know what a pull request is and are not going to sign up to one just to react to an issue.
You sell a hosted product next to the open source project, and the requests from paying customers matter more than the requests from a free self hosted install, in a way a plain reaction count cannot show.
Sponsors fund the project and their requests should carry weight. A one time sponsor and a recurring one are not asking with the same amount behind them, and a thumbs up treats both the same as a reaction from someone who has never paid anything.
GitHub issues, Discussions, a self hosted board, or VoteFirst
| GitHub issues with reactions | GitHub Discussions | A self hosted open source board | VoteFirst | |
|---|---|---|---|---|
| Cost | Free | Free | No licence fee, plus a server, a database and the hour you spend on the upgrade that does not go smoothly | $9 a month, one project |
| Who can vote without a GitHub account | Nobody, a reaction needs a GitHub login | Nobody, a poll vote needs a GitHub login | Depends on the install, and you carry the moderation and the uptime either way | Anyone, voting is open to a visitor with no account by default, and a board can be set to require sign in instead |
| Duplicate requests | Manual, the maintainer closes the duplicate and links it by hand, each one starting its count at zero | Manual, same as issues | Varies by the project running it | Merged on the roadmap, and the votes move with the merge instead of starting over |
| Telling voters a thing shipped | Closing the issue notifies subscribers who are watching that issue | A reply in the thread notifies subscribers | Varies by the project running it | A release sends one email, to every signed in voter whose own vote is in that release, and to nobody else. An anonymous vote leaves no address, so it gets no email |
| Upkeep | None beyond the repository you already run | None beyond the repository you already run | A server, a database, backups and upgrades you run yourself | Hosted, no server to operate, and no sync back to GitHub issues |
Fider is the open source board most often named alongside this comparison. It runs under the AGPL licence, every feature is available in a self hosted install with no licence to pay, and the project also runs a hosted tier that is free under a fair use policy of two hundred and fifty feedback items, read from Fider's own site on 2 October 2026. Running it yourself still means operating the server, the database and the upgrades yourself, the same cost that applies to any self hosted open source board.
Running a board next to the issue tracker without splitting the conversation
A board and an issue tracker both trying to be the one true list is how a project ends up with the same feature requested in two places and neither count meaning anything. The way to avoid that is to pick which one is authoritative and send the other one there, consistently.
Point the README and the issue template at the board for feature requests, and keep the issue tracker for bugs and pull requests. A maintainer who gets a feature request as an issue can close it with a link to the board instead of letting it sit open with three reactions that will never be compared against the board's own count.
The board itself takes anonymous votes by default, so pointing a non developer user there costs them nothing. A developer user who already has a GitHub account loses nothing either, since voting on the board takes less than reacting to an issue does.
If sponsors are the reason a board earns its place, a sponsor's weight does not arrive automatically. VoteFirst imports revenue from Stripe, Paddle or a CSV and multiplies a voter's future votes by a whole number tier set from that import. GitHub Sponsors is not one of the connected sources, so a sponsor's amount has to be added by CSV or matched by hand against your own sponsor list, not pulled in from GitHub directly.
What VoteFirst does not do
No GitHub integration of any kind. Issues do not sync to the board, votes on the board do not sync to issues, and there is no GitHub login, GitHub Sponsors import, or GitHub Discussions import. A public Canny or Featurebase board can be pasted in and its posts and vote counts come across, but GitHub issues cannot.
No Slack, Zapier or outgoing webhooks, so a new request on the board does not post anywhere else. No SAML or OIDC, JWT only. No AI features anywhere. No Android SDK, the native option is a Swift package for iOS and macOS. No open source or non profit discount of any kind, the price is the same nine or thirty nine dollars a month whatever the project behind it is. No free plan, the trial is fourteen days with a card asked at signup.
Questions a maintainer actually asks
Can existing GitHub issues be imported into the board? No. The board import reads a public Canny or Featurebase board, not a GitHub repository, so moving existing requests across means re-entering them by hand or leaving the old ones in the issue tracker and starting the board fresh.
Do people need an account to vote? Not by default. A board can be read and voted on by a visitor with no account, identified by a cookie rather than a login. A project can turn on a setting that requires sign in instead, if an anonymous vote count is not trustworthy enough for that project.
Does VoteFirst merge duplicate requests the way issues cannot? Yes. A maintainer can merge one request into another on the roadmap side, and the votes move with the merge rather than starting again at zero, which is the one mechanical gap GitHub issues have no equivalent for.
Is there a discount for open source projects? No. Nothing in the pricing or the signup path checks for a licence file or a GitHub organization, and the price is the same for every project.
What happens to GitHub Sponsors money? Nothing automatically. VoteFirst reads Stripe, Paddle or a CSV for revenue, not GitHub Sponsors, so weighting a sponsor's vote means exporting that list and importing it as a CSV.
Try it against your own board
Reading a public Canny or Featurebase board before moving anything needs no account. How weighting a vote by revenue actually works is a separate page, since sponsors are only one reason to use it.
What this costs
Lite
$9 /mo
Pro
$39 /mo
Lifetime
$999 once
Fourteen day trial of Pro, card asked for at signup. Nothing here counts the people who vote, so the bill does not move when the board starts working. The long version, with what happens if you stop paying.
Other use cases
Feedback board for indie hackers, for the solo founder shape of the same question. Anonymous voting, on the default setting this page relies on. Public roadmap, the five column board a GitHub issue has no equivalent of.