Useful Forks: Finding Active Work in GitHub Forks

The fork-discovery problem Useful Forks addresses

GitHub's fork list can place many repositories ahead of alternatives that deserve attention. Useful Forks was created for the case where a project appears abandoned, its maintainer has stopped responding, or contributors pursued a different implementation and left that work in a fork. Its stated filter removes forks that have never received a commit pushed to the main branch since they were created.

That rule targets a specific kind of dead end: a repository that exists mainly as a fork, with no subsequent development on its main branch. It does not try to judge code quality, maintenance intent, or compatibility. This distinction matters because a fork with useful code can still be omitted if its commits landed on another branch, and a fork with one main-branch commit can pass the filter regardless of what that commit changed.

The intended audience includes open-source maintainers looking for surviving implementations, contributors searching for prior design work, and users who want to inspect alternative forks without manually opening large numbers of entries. The project offers three delivery paths: the online GitHub Pages tool, a Chrome extension and Firefox add-on, and a bookmarklet for other browsers. Each browser integration opens the online application with the current GitHub repository encoded in the query.

Useful Forks repository and query architecture

The repository separates the web application from its browser integration. According to the README, `website` contains the website and `plugin` contains the Chrome extension. The Firefox package is built from `plugin`, so the browser integration is not a separate implementation of the filtering logic. The web application performs the actual repository scan.

The filtering model recursively searches sub-forks. That is more involved than checking only the first page of forks, because another fork can itself have forks containing the work a maintainer is looking for. The README also notes that the GitHub API watcher value was removed because it was considered bugged. The current screen should therefore not be interpreted as a ranking based on watchers.

GitHub API traffic is part of the design rather than an incidental implementation detail. The repository credits include authenticated API requests as an improvement because they increase the available call limit, and the UML activity diagram is specifically presented as an explanation for why some scans may require many API calls. The documentation does not explain authentication setup, rate-limit handling, pagination details, or the exact order in which branches and sub-forks are evaluated.

Based on the repository layout and README, a typical flow begins when the online page receives an owner and repository name. The application queries GitHub for fork relationships, recursively expands relevant forks, inspects commit history on each candidate's main branch, and excludes candidates that have never had a post-creation commit on that branch. The extension does not replace this flow. It adds a Useful button on GitHub repository pages and opens the website in another tab.

Running the website locally for the first query

The README recommends NodeJS v20+ and NPM v8+ for local development. Run the following commands from the repository's `website` directory. `npm install` installs the website dependencies, and `npm run dev` starts the development process documented by the project.

npm install
npm run dev

The README does not state the development server URL, port, or terminal output to expect, so the article cannot prescribe a specific local address. Use the address reported by the development process.

For the first real use, open the hosted application and pass a repository through the documented `repo` query parameter. The README uses `payne911/PieMenu` as its example. Select this complete URL, with owner and repository separated by a slash:

https://useful-forks.github.io/?repo=payne911/PieMenu

The page should scan that repository and present forks that meet the documented main-branch commit rule. The same query structure is used by the bookmarklet and browser integrations. This route is especially useful for checking behavior without changing the repository's default branch or adding files.

The README states that changes to `website/src/queries-logic.js` require re-executing `npm run dev` so that `dist/main.js` recompiles. That detail indicates an active build step between the query source and the served JavaScript, although the repository details do not identify the bundler configuration.

Adding a bookmarklet to open the current GitHub repository

The online tool is usable through the published Chrome extension and Firefox add-on, but the bookmarklet offers a browser-independent route. The README instructs users to press `Ctrl+D`, create a bookmark, and put a JavaScript expression in its URL field. The expression extracts the owner and repository from a GitHub URL and opens the corresponding Useful Forks query.

javascript:!function(){if(m=window.location.href.match(/github\.com\/([\w.-]+)\/([\w.-]+)/),m){window.open(`https://useful-forks.github.io/?repo=${m[1]}/${m[2]}`)}else window.alert("Not a GitHub repo")}();

Invoke the saved bookmarklet while viewing a GitHub repository. The online service should open in a new tab with the current repository name in the `repo` parameter. If the current URL does not match the expected GitHub repository form, the script displays a `Not a GitHub repo` alert. This is a small convenience integration rather than an offline analyzer, because its result is still produced by the hosted website.

For Chrome and Firefox, the README directs users to the respective extension stores. Once activated, the add-on or extension places a Useful button on GitHub repository pages, and selecting it opens the online tool. The GitHub Releases page is no longer the project's publishing route; the README says updates will pass through Chrome Web Store and Firefox Add-ons instead.

Packaging the browser integration for Firefox

The `plugin` directory contains the browser integration source. For Chrome, the README says its contents must be placed in a `.zip`, not zipped as the enclosing folder. For Firefox, the documented build command uses `web-ext` and targets the `plugin/` directory from the repository root.

Run this command from the repository root when preparing a Firefox package:

npx web-ext build --source-dir=plugin/ --overwrite-dest

The README does not give the generated filename, signing process, review process, or exact Chrome Web Store submission procedure. It only identifies the archive layout for Chrome and supplies the Firefox build command. Those omissions make packaging straightforward for a familiar extension workflow, but they leave store-specific validation and publication outside what the project documents.

The repository's browser integration is best viewed as a launcher. Its Useful button appears only on GitHub repository pages, then opens the online service with repository information. Keeping scanning logic in the website means users of Chrome, Firefox, and the bookmarklet reach the same application, but it also means their results depend on access to the hosted site and the GitHub API requests made during a scan.

Limits of the main-branch commit filter

Useful Forks has a clear boundary: it excludes forks without a commit pushed to the main branch after creation. That behavior is useful for finding repositories where development continued, but it is not equivalent to identifying every viable alternative implementation.

The most direct false-negative case is a fork whose useful changes live on a branch other than the main branch. The README does not say that such branches are searched. Another case is a repository whose main branch changed through merges, rebases, or commits with little implementation value. Passing the commit condition does not establish that the code works, is current, or matches the upstream project's license and security requirements.

Recursive exploration also means that large fork graphs can require many API calls. The README explicitly warns that this may happen, and it credits authenticated requests with increasing the API call limit. It does not document behavior when unauthenticated limits are reached, whether failed requests are retried, or whether a scan can complete partially. Maintainers evaluating the tool for a large repository should not assume that every fork will always be returned.

This is why the project is better suited to exploratory fork discovery than compliance inventory. If the objective is a complete audit of every descendant, including dormant branches, the documented filter and its reliance on GitHub API results need direct review before adoption.

Useful Forks compared with manual fork inspection

The practical alternative is GitHub's normal fork list combined with manual inspection. GitHub provides the raw relationship between a repository and its forks, while Useful Forks adds recursive traversal, commit-history filtering, and a focused results view. Manual inspection gives the reviewer direct control over branches, commit dates, implementation differences, and activity criteria, but it can require opening a large number of repositories one at a time.

Useful Forks shifts effort from repository-by-repository browsing toward an automated query. Its cost is a narrower decision model. Users receive forks selected by a defined main-branch condition rather than choosing their own inclusion rules. The project documentation does not provide export, filtering by language, comparison, or configuration options beyond the web query and integration routes.

A real comparison therefore depends on the task. Someone looking for a likely place where implementation continued can use the filtered query. Someone performing an exhaustive audit may prefer GitHub's repository graph, API data, or manual branch inspection because a fixed commit rule can exclude exactly the history they need. Useful Forks does not replace those underlying GitHub interfaces; it organizes a subset of their output for one discovery task.

The repository is under the MIT license, which identifies the permission and conditions associated with reuse, modification, and distribution. Anyone incorporating its code or packaged assets should review the repository's `LICENSE` file and retain any required notices. This is a license-handling point, not legal advice.

Maintenance state and release implications for users

The repository is not archived, and its last push was on 2026-09-28. That supports describing the repository as receiving a recent commit, but the listed release history does not itself provide a new release after v2.2 from 2023-01-19. The README also says GitHub Releases will no longer be updated and that browser extension releases will pass through Chrome Web Store and Firefox Add-ons.

For website users, the online application remains the central dependency for all three access methods. For maintainers changing query logic, the documented build process is the main integration point because edits to `website/src/queries-logic.js` require `npm run dev` to recompile `dist/main.js`. For browser packaging, the project supplies two different paths: zip the contents of `plugin` for Chrome, or run the documented `npx web-ext build` command for Firefox.

The available release notes are old enough that operators should not treat the listed versions as current extension package versions. The stores named by the README are the stated publishing channels for browser updates. The documentation does not describe release notes for the website, deployment permissions for GitHub Pages, production monitoring, API failure behavior, or a compatibility matrix, leaving those details outside the confirmed project scope.

Editorial conclusion

Useful Forks is appropriate for maintainers and contributors who suspect that an older GitHub project contains useful work in inactive forks. It is less suitable for teams that need a complete repository inventory, require guaranteed results under GitHub API limits, or consider forks without main-branch commits important. Review the repository LICENSE, inspect the requested API behavior and result filtering in `website/src/queries-logic.js`, then verify one known fork through the online tool before adoption.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. useful-forks/useful-forks.github.io on GitHub