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

Hacker News Discussion ↗

An idea to build an “IMDb for open source projects” prompts wide debate over whether a standalone directory can add real value beyond GitHub stars, search engines, and existing catalogs like awesome-lists, alternativeto.net, and former sites such as Freshmeat or OpenHub. Commenters highlight that movies are static while software changes constantly, making ratings, curation, and abuse much harder to manage, and question who the target is: users seeking trustworthy tools, or contributors hunting for issues. Many see potential if it focuses on discovery, comparisons, rich filtering, and network-style navigation across projects and contributors, but stress the challenges of content acquisition, spam control, and sustainability—and advise starting with a focused MVP rather than a grand all-encompassing platform.

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.