Wachstumsauthentizität — inspect.software-Wiki

Ein GitHub-Star ist das meistgelesene Vertrauenssignal in Open Source. Er ist zugleich das einzige ohne Aussteller. Stars werden offen und in großen Mengen für wenige Cent das Stück verkauft, ebenso wie Forks, Watcher und Follower, und nichts an der Zahl selbst unterscheidet das Gekaufte vom Verdienten.

Jede Bewertung, die Stars zählt, erbt dieses Problem. Wachstumsauthentizität ist der Teil der Methodik, der sich seiner annimmt: Der für jeden Bericht erhobene Tagesverlauf von Stars und Forks wird auf Wachstum gelesen, dessen Form organische Aufmerksamkeit nicht hervorbringt; wo solches Wachstum bestätigt ist, werden die käuflichen Eingangsdaten abgewertet statt geglaubt.

Das Ergebnis beantwortet eine eng gefasste Frage:

Sieht der Popularitätsverlauf dieses Repositorys danach aus, als sei er geschehen — oder als sei er geliefert worden?

Es beantwortet nicht, wer gehandelt hat oder ob jemand dafür bezahlt hat. Jeder Befund hier ist eine Aussage über den zeitlichen Verlauf öffentlicher Ereignisse, und nicht mehr.

Warum der zeitliche Verlauf es verrät

Aufmerksamkeit, die ein Projekt sich erarbeitet, kommt über Menschen zustande, und Menschen sind unregelmäßig. Ein Launch, eine Titelseite auf Hacker News, ein Konferenzvortrag oder eine Erwähnung in einem Newsletter erzeugt einen Ausschlag, der von Stunde zu Stunde ungleichmäßig ausfällt, der neben Stars auch Forks mit sich bringt, weil manche Leser den Code öffnen, und der über die folgende Woche abklingt, während der Link zirkuliert und dann nicht mehr.

Gelieferte Aufmerksamkeit hat keine dieser Eigenschaften. Sie kommt nach Zeitplan, von Konten, die das Repository nie ansehen, und sie endet in dem Moment, in dem der Auftrag abgearbeitet ist. Der Zähler kann den Unterschied nicht erkennen. Der Verlauf schon.

Was gemessen wird

Der Bericht sucht zunächst nach Ausschlagstagen — Tagen, an denen das Repository sowohl mindestens 25 Stars als auch mindestens das Zwölffache seiner eigenen medianen Rate an aktiven Tagen hinzugewonnen hat. Aufeinanderfolgende Ausschlagstage werden zu einem Fenster zusammengefasst.

Ein Ausschlag für sich genommen ist nie ein Befund. Reale Projekte haben Ausschläge, und eine Methodik, die jeden Schub für verdächtig hielte, würde jeden erfolgreichen Launch markieren. Ein Fenster gilt erst dann als bestätigt, wenn mindestens zwei unabhängige Signale es erhärten:

Signal	Was es beobachtet
Star-Konzentration	Auf die fünf stärksten Tage entfallen 80% oder mehr aller erfassten Stars. Über 502 gewöhnliche Repositories gemessen, legt der Median 6,9% seiner Stars in seine fünf stärksten Tage, und keines erreichte 80%. Dieses Signal betrifft den gesamten Verlauf statt eines einzelnen Schubs und erhärtet daher jedes Fenster.
Gleichförmige Taktung	Über drei oder mehr Tage hinweg variierten die täglichen Zugänge kaum. Ein Publikum ist ungleichmäßig, ein Lieferplan nicht.
Keine Fork-Reaktion	Das Verhältnis von Forks zu Stars im Fenster fiel unter ein Viertel des langfristigen Verhältnisses des Repositorys — Aufmerksamkeit, die den Code nie berührt hat.
Kein Abklingen	Die sieben Tage nach dem Schub summierten sich auf 5% davon oder weniger. Reale Ausschläge haben einen Ausläufer; ein abgearbeiteter Auftrag hört schlagartig auf.
Keine Releases veröffentlicht	Das Projekt hat überhaupt nie ein Release veröffentlicht. Bewusst schwach: Zahlreiche legitime Projekte veröffentlichen nichts. Eine frühere Form dieses Signals wertete einen Schub, der vor dem ersten Release eines Projekts eintraf, als Beleg — und erzeugte damit in der ersten Kontrollmessung sämtliche Fehlalarme: veröffentlichen, Aufmerksamkeit gewinnen, später ein Release herausgeben, so arbeiten gewöhnliche Projekte.

Die vier Zustände

Zustand	Bedeutung	Wirkung
Organisch	Der Verlauf ist mit organischem Zuwachs vereinbar.	keine
Nicht verifiziert	Der erhobene Verlauf kann die Frage nicht beantworten.	keine
Auffällig	Ein bestätigtes Fenster.	Stars und Forks um 40% abgewertet
Stark auffällig	Zwei oder mehr bestätigte Fenster oder eines mit drei Signalen.	Stars und Forks um 70% abgewertet

Die Abwertung gilt den Komponenten Stars und Forks der Popularität — den beiden Eingangsdaten, die ein Anbieter verkaufen kann. Watcher bleiben unberührt, da sie nicht zu dem gehören, was die Auffälligkeit belegt, und keine andere Kategorie bewegt sich überhaupt. Popularität trägt 7,2% des Gesamtindex, der rechnerische Effekt ist also bewusst klein. Der Befund ist das Ergebnis; die Anpassung hält den Bericht lediglich davon ab, etwas zu behaupten, woran zu zweifeln er Anlass hat.

Eine Anpassung nach oben gibt es nicht. Ein sauberer Verlauf kann keinen Wert erhöhen, genauso wenig wie ein sauberes Jurisdiktionsergebnis die Sicherheitslage erhöhen kann.

Was „Nicht verifiziert“ bedeutet — und was nicht

Ein Repository liest sich als nicht verifiziert, wenn kein Star-Verlauf erhoben wurde, wenn es weniger als 100 Stars hält oder wenn das erhobene Fenster weniger als 60 Tage umfasst. Damit ist keinerlei Abzug verbunden.

Das ist der Regelfall, und es ist eine Grenze der Evidenz, kein Urteil. Die Verlaufserhebung ist begrenzt — der Bericht erfasst ein jüngeres Fenster von Star- und Fork-Ereignissen, nicht die gesamte Lebensdauer eines großen Projekts —, sodass Manipulation, die älter ist als dieses Fenster, hier schlicht unsichtbar bleibt. Nicht verifiziert bedeutet, dass die Frage nicht beantwortbar war. Es bedeutet nie, dass die Antwort sauber ausfiel.

Das Ergebnis lesen

Ein Befund betrifft ein Muster, keine Person. Stars können von einem Wettbewerber gekauft werden, von einem Promoter, von einem früheren Eigentümer des Repositorys oder von jemandem, den die Maintainer nie getroffen haben. Nichts in dieser Bewertung benennt, wer gehandelt hat, und nichts darin unterstellt, dass die Maintainer es waren.
Ein Befund macht die Software nicht schlecht. Er macht ein einzelnes Beweisstück über die Software unzuverlässig. Die Belege zu Engineering, Governance und Sicherheit im übrigen Bericht bleiben davon unberührt und stehen für sich.
Das Ausbleiben eines Befunds ist kein Zertifikat. Langsame, über Monate verteilte Zukäufe erzeugen keinen Ausschlag, und diese Bewertung wird sie nicht sehen.

Den Wert verbessern

An einem Repository lässt sich nichts tun, um dieses Ergebnis zu verbessern, und genau das ist der Punkt: Die Bewertung liest einen Verlauf, der bereits stattgefunden hat. Ein Projekt, dessen Wachstum echt war, liest sich bereits als organisch.