The method is published in full under Apache-2.0. Nothing here is a black box. This page summarises how an appraisal is produced and defines every term of art it uses.
The complete method, including the scoring code and the commitment scheme, is published at github.com/Scottcjn/github-portfolio-appraisal under the Apache License 2.0. You can read it, run it, disagree with it, and fork it.
RepoAppraisal borrows the structure of a real-property appraisal. Three independent approaches are run, and the reconciliation explains which one carries the most weight and why.
Every appraisal ships with its limiting conditions stated. An appraisal without disclosed limitations is marketing.
Adjustments are always disclosed, never silently applied. The recurring ones are: detached forks that inherit a parent repository's stars; curated “awesome” list repositories that accrue stars with no engineering; related-party contributions between accounts under common control; bot and CI traffic inflating clone counts; and incentivized acquisition under the terms-of-sale adjustment.
Reports state a range with stated confidence, or they state that the evidence is insufficient. We do not publish a single leaderboard number. A single score is easy to market and easy to game. Where the evidence does not support a figure, the report says so — see the sophiaeagent-beep case study, where the appraisal declines to state a range at all.
Two full appraisals are published in the case studies, both of accounts belonging to the operator, both leading with their adverse findings:
The method describes how a portfolio is measured. For what to do about a poor measurement — the levers behind each adverse signal — see the guide on getting open-source work noticed honestly, which works through the same signals in the other direction.
The same five steps run on every subject, in order. Each one is a place where a naive valuation goes wrong.
Percentiles are computed from GitHub’s own search totals rather than estimated. A query of the
form search/users?q=followers:>=N returns the count of accounts at or above that
threshold, and that count is the rank. No sampling, no modelling.
Which denominator you divide by decides the answer. The three used, with their values on the effective date of the published worked example (2026-08-04):
| Population | Count |
|---|---|
| Indexed GitHub accounts | 155,571,951 |
| Accounts with at least one public repository | 81,480,831 |
| Public repositories with at least one star | 31,239,012 |
Comparing a repository against all public repositories — a population that includes empty repositories and forks — inflates every percentile by roughly an order of magnitude. Use the starred-repository denominator. Most “top 1% of GitHub” claims fail here and nowhere else.
Sales comparison, cost / replacement, and income capitalization are run independently, then reconciled. A subject that looks strong under one approach and weak under the other two is a subject whose value is concentrated in a single fragile place, and the reconciliation should say so.
An unadjusted comparable is malpractice. Three distortions recur often enough to be checked every time:
| Distortion | Effect | How it is detected |
|---|---|---|
| Inherited star base | Comparables overstated | A detached fork is counted by GitHub as an original source and carries the parent project’s accumulated stars. |
| List-driven inventory | Comparables overstated | High stars alongside near-zero contribution activity; curated “awesome-list” repositories accrue stars with no engineering content. |
| Incentivized acquisition | Classify, do not discount | A star-to-fork ratio near 1:1, or forks exceeding stars. Reported as its own class under the terms-of-sale adjustment. |
Appraisal practice does not accept a sale between related parties as a comparable. A transaction between affiliates is not arm’s-length; it is disclosed and excluded. Merge credit gets the same treatment: any pull request merged into a repository controlled by the same operator, organization, or affiliate as the subject is excluded from independent merge credit.
Relatedness is detected from the same owner account or an organization the subject belongs to; repositories cross-linked as products of one operator in a README, site, or package metadata; a reviewer and PR author who are the same identity, or a self-merge; and accounts sharing a verified email domain, funding link, or declared affiliation.
The adjustment is not cosmetic. In the two worked examples published on this site, one account showed 21 merges outside its own namespace and fell to 1 once same-operator repositories were removed; the other showed 72 externally merged pull requests and fell to 69. A methodology that exempts its own author is not a methodology.
Every fact used becomes one BLAKE2b-256 leaf and the leaves fold into a Merkle root. Publishing the root lets a counterparty verify any single fact by inclusion proof, and proves the report was not back-edited after it was shared — which matters because GitHub metrics drift and repositories get deleted, so a figure is not recoverable from GitHub after the fact.
This method does not classify stars as fake. It classifies how they were acquired, which is a question the evidence can actually answer.
Purchased-bot activity and incentivized-program activity look superficially similar and are not the same thing, and calling either one fraud without evidence is both wrong and defamatory. What is observable is whether the subject offered consideration — a bounty, a token, a reward, access — in exchange for the attention. That is a terms-of-sale question, and appraisal practice already knows how to handle it: disclose the consideration and adjust for terms, the same way a sale closed with seller concessions is disclosed rather than discarded.
Five heuristics point at incentivized acquisition. None is conclusive alone — they are used together, and a single hit is not a finding:
The finding that results is a classification, not an accusation. Incentivized attention can be worth more per unit than organic attention, because a participant who forked a repository, provisioned a wallet, and submitted work completed a far deeper conversion than a visitor who clicked a star. What it cannot substitute for is evidence of demand from people who were offered nothing, so the two classes are always reported separately rather than blended into one headline number.
Independent merge credit — pull requests merged into repositories the subject does not control — is the only widely available public signal that is expensive to fake, because it requires a stranger’s consent. It cannot be purchased, farmed, or inherited from a fork. But the naive measurement is wrong in two directions at once.
It over-counts unless the related-party adjustment in Step 4 is applied. An operator running two accounts can merge one account’s pull requests into the other’s repositories and manufacture credit that looks arm’s-length.
It also under-counts. Some projects land contributions by cherry-picking the commit to master and closing the pull request — OpenSSL works this way. A scraper reading PR state alone records those as rejections. Correct measurement checks commit authorship in the target repository, not the state of the pull request.
A Merkle root is only worth something if the tree underneath it is sound, and two standard implementation defects void the commitment entirely. The reference implementation’s own first commit contained both, which is why they are documented here rather than quietly fixed:
| Defect | Consequence | Fix |
|---|---|---|
| No domain separation — hashing a leaf and hashing a pair of children use the same function | A 64-byte “leaf” can be forged that is actually an interior node, and proofs replay at the wrong depth — a second-preimage attack | RFC 6962 prefixes: 0x00 for leaves, 0x01 for interior nodes |
| Odd-node duplication — promoting a copy of the last node to pair it off | CVE-2012-2459. Two distinct leaf sets produce an identical root, so “this root commits to this fact set” is simply false | RFC 6962 splits at the largest power of two below n and promotes the unpaired node unchanged |
The published commitment additionally binds the leaf count, so a root cannot be reinterpreted under a different tree shape:
Two further conditions apply to anchoring. Anchoring to a chain the issuer controls proves nothing to a counterparty who distrusts the issuer, so the primary record is an independent timestamp authority such as OpenTimestamps/Bitcoin; any self-operated chain is supplementary, and if the two disagree the independent authority wins. And anchoring the facts alone is insufficient — an issuer accused of moving the goalposts could show unchanged inputs while having silently changed the scoring rule, so the hash of the scoring profile is committed as its own leaf alongside the facts.
The terms of art used throughout this site, defined precisely.
Independent merge credit counts pull requests merged into repositories the subject does not own or control. It requires another maintainer's consent, so it cannot be self-issued, farmed, purchased, or inherited from a fork. Pull requests merged into repositories owned by the subject or by a related party are excluded from the count and disclosed separately.
The terms-of-sale adjustment discloses and adjusts for attention acquired through a bounty program, airdrop, or paid contributor funnel, instead of discarding it. A real-estate appraiser does not throw out a sale that closed with seller concessions; they disclose the consideration and adjust for terms. Incentivized attention is a real transaction with a known price attached, so it is reported as its own class rather than blended into organic demand.
Organic acquisition is attention from people who were offered nothing. Incentivized acquisition is attention from people who were offered a reward. Incentivized acquisition still evidences conversion depth, because the participant took a costly action such as forking, provisioning a wallet, and submitting work. It does not evidence unpaid market demand. The two classes are always reported separately.
Every fact used in an appraisal becomes a leaf in an RFC 6962 Merkle tree, hashed with BLAKE2b-256. The report publishes the root hash. A counterparty can verify any single claim with an inclusion proof, and can detect whether a report was edited after it was shared, because any edit changes the root.
No. It is an illustrative valuation framework. It is not prepared under USPAP, Elyan Labs LLC is not a licensed appraisal firm, and it must not be used for lending, tax, employment, or litigation purposes.
It means nearly every unit of attention converted into a build action rather than a bookmark. It is a strong signal of an incentivized funnel, and it is disclosed under the terms-of-sale adjustment. It is not evidence of fraud and is never reported as such.
Clone counts include continuous-integration runners, mirrors, package indexes, and scrapers. When clones substantially exceed page views, or when repositories show clones with zero page views, the clone figure is rejected as an adoption proxy and unique visitors are used instead.
Yes. Any developer may request removal from a comparable set, case study, or any published page at any time, with no reason required, and the request is honoured promptly. See the Removal and Correction Policy.
Three approaches are run independently and then reconciled: sales comparison against an adjusted set of comparable accounts, cost of replacement for the tracked output and the physical plant needed to produce it, and income capitalization of revenue actually attributable to the portfolio. Before any of that the subject is positioned against a real denominator taken from GitHub's own search totals, and every comparable is adjusted for inherited stars, curated-list inflation, and related-party activity. The output is a range with stated confidence, or a statement that the evidence is insufficient.
The population of public repositories with at least one star, which stood at 31,239,012 on 2026-08-04. Comparing against all public repositories includes empty repositories and forks, and inflates every percentile by roughly an order of magnitude. Percentiles are read from GitHub search totals rather than estimated: a query for accounts at or above a follower threshold returns a count that is itself the rank.
This method does not classify stars as fake. It classifies how the attention was acquired, using five heuristics that are only meaningful together: a star-to-fork ratio at or below roughly two to one, star accrual arriving in bursts aligned to programme announcements, the documented presence of a bounty or reward programme, the ratio of forks carrying divergent commits to forks carrying none, and contributor accounts created shortly before their first interaction. The result is a terms-of-sale classification, never a fraud finding.
Any pull request merged into a repository controlled by the same operator, organization, or affiliate as the subject is excluded from independent merge credit and disclosed separately. Appraisal practice does not accept a sale between related parties as a comparable, and a merge between accounts under common control is the same thing. In the worked examples published on this site the adjustment took one account from 21 apparently independent merges down to 1, and another from 72 down to 69.
Over-counting is prevented by the related-party adjustment. Under-counting is prevented by checking commit authorship in the target repository rather than the state of the pull request, because some projects, OpenSSL among them, land a contribution by cherry-picking the commit to master and closing the pull request. A scraper reading pull request state alone records those as rejections.