Ask HN: I want to create IMDB for open source projects

Hacker News Discussion ↗

Existing and Past Efforts (“You’re Not First”)

  • Many point to prior/ongoing projects: Freshmeat/Freecode, OpenHub, FSF Directory, Freshcode, LibHunt, Ruby Toolbox, Awesome-* lists, AlternativeTo, Ovio, OpenAlternative, various “OSS alternatives to X” sites, selfh.st, OSS directories, and “awesome” curated lists.
  • Several say many similar directories launched and then stagnated or died; OpenHub is cited as an example that now looks “dead.”
  • Conclusion from some: the idea is common; the hard part is sustained curation, differentiation, and adoption.

Debate: Do We Need an IMDB for OSS?

  • Supporters say OSS discoverability is poor, especially outside GitHub and for non-library apps or self‑hosted tools.
  • GitHub stars, search, trending, and awesome lists are seen as partial but not sufficient; they don’t capture quality, suitability, or cross‑platform coverage.
  • Skeptics argue GitHub + Google + existing lists already solve most needs and that another generic directory adds noise.

Limits of the IMDB Analogy

  • Movies are static and consumer‑focused; OSS projects are evolving, often developer tools.
  • Ratings on OSS risk directing abuse at individual volunteers, unlike studios behind films.
  • Some see IMDB’s real value in its graph and lists (“who worked on what,” “more like this”), not just scores, and propose mirroring that for projects/contributors.

Proposed Features and Signals

  • Rich filters: license, activity/“alive”, language, hosting/deployment, OS, self‑hosting, paid tiers, interoperability, complexity, “done but stable,” etc.
  • Time‑aware signals like “recent vs all” reviews (inspired by Steam), and better activity metrics than raw stars.
  • Discovery aids: “people who used this also used…”, similar tech stacks, alternatives, curated lists by domain.
  • Semantic search to bridge poor project documentation.
  • Contributor graph: see what else maintainers worked on across hubs; identity coalescing.
  • Maintainer‑supplied metadata (e.g., oss-info.yaml) and repo‑based verification tokens.

Risks, Scope, and Product Advice

  • Big challenges: inclusion criteria, spam/SEO gaming, low‑quality PRs, supply‑chain trust, curation workload, and lack of revenue model.
  • Several advise: start tiny (a niche, or a GitHub-based feature/extension), build an MVP, prove real use cases, then iterate.
  • Design should prioritize usability over “prettiness”; critical mass and a strong feedback loop matter more than polish early on.