Link: https://concord.polarisocial.xyz/projects/concord

A spec for a forge where users file complaints (not feature requests), competing solutions are ranked head-to-head, and you can search for existing projects before building a new one. Looking for holes in it.

Quick disclosure first: this is a proof of concept with a demo. I won't be hosting a site for many users. And I'm not selling anything. I'm posting because I want people who build or maintain open source to find the holes before they write anything.

The itch

I keep running into two problems:

1. Deciding what to build is broken. Feature requests are noisy, "+1" and 👍 counts reward whoever is loudest, roadmaps are opaque, and maintainers burn out saying no.
2. Finding what already exists is also broken. People rebuild things they never found, adopt abandoned projects, and can't compare options honestly. Search is keywords and stars, and awesome-lists are markdown files that get stuck in merge wars.

I think both have the same fix: structured community judgment with the algorithm visible.

The core ideas

• Complaints, not feature requests. You file a structured problem report (who's affected, how often, severity, workaround, environment). A feature has to trace back to at least one validated complaint. "Add dark mode" gets reframed as "I can't use this at night."
• Features say what, solutions say how. Each feature has several competing solutions: build new, extend existing, integrate an external project, docs-only, workaround. Every solution arena has a permanent "do nothing" baseline, so a solution only matters if it beats that.
• Everything is ranked pairwise. Features, solutions, list entries, and "alternatives to X" all use head-to-head comparison (Glicko-2), not raw upvotes. Every ranking is recomputable from a public vote log, and every score has a "why this rank?" breakdown.
• Ranking sets the agenda, consensus decides. The top solution triggers a formal consent call (consent, abstain, stand aside, or block). A block needs a principle, a violation, and a concrete remedy, and "adopt solution #2" is a valid remedy. So the ranking doubles as the fallback chain, and nobody restarts from scratch.
• Collective by default. Collaborators steer. Maintainers handle housekeeping and safety, and can't unilaterally accept features or merge without quorum. Maintainer-led mode is opt-in, and switching requires a consensus vote. Silence can't decide anything: no quorum means the window extends.
• Admin-light. Instance admins keep the servers running and have no content authority. Their actions go in a public ledger.

The discovery half

I think this is the bigger wedge. The catalog indexes external repos and packages (GitHub, GitLab, Codeberg, npm, PyPI, crates, and so on), so it's useful before any project migrates.

• Hybrid lexical and semantic search with a real query language (cap:wip-limits=yes platform:arm64 license:(MIT OR Apache-2.0) health>=70). Natural-language input turns into editable filter chips, so you can see how it interpreted you.
• Scout: describe an idea or paste a package.json and get a build-vs-adopt analysis. It classifies each match as adopt, base on, extend, inspire, or avoid. It shows a coverage heatmap, known unresolved pain per candidate, prior art (including dead projects and why they died), and open features in existing projects that would cover your idea.
• Field reports: structured "I used X for Y, here's what happened" records with an outcome, instead of "does anyone use X?" threads.
• Capability matrix, ranked alternatives per use case, dependency and reverse-dependency intelligence, and an "opportunity radar" for unmet needs and abandoned-but-depended-on projects.
• Every recommendation is explainable. No engagement-optimized feed.

Where I expect pushback (and want it)

• Gaming. Reputation-weighted, capped votes plus Glicko-2 uncertainty help, but is that enough? What would you attack first?
• Cold start. Most arenas will have a handful of voters. Is a content-based prior good enough, or does it just feel like fake rankings?
• Process overhead. There are decision tiers (trivial changes get lazy consensus), but will this still feel like too much ceremony for a 3-person project?
• Third-party field reports. If a maintainer never joined the platform, is an owner-response right plus quorum moderation enough to prevent harassment?
• Who funds it when admins are deliberately denied content power?
• Does anyone actually want a forge to be opinionated about governance, or would this only work as a layer on top of Forgejo? (The MVP plan is the layer, not a rewrite of Git.)

Feedback is welcome.