The first time I tried this experiment was last year, when I made my source code public on GitHub after many years of keeping repositories private. At the time, their Insights page (where repository traffic and cloning stats are displayed) was updating the analytics roughly every couple of hours. I noticed when I would make a commit and then have it broadcasted on my public feed, I would receive views and clones regardless of what I published. Here are a handful of tests I tried during this period:

  • Posting legitimate public code with an AGPL v3 license.
  • Posting only a plain file with no extension and some conversational or nonsensical text.
  • Writing commit messages that played on the idea of breaking the fourth wall
  • Injecting images that linked back to my server so I could see if they loaded the file or just blindly cloned the repository.
  • Adding deep links inside of nested markdown files back to my server to an interactive system to see if they would engage
  • Rebasing changes on most commits.
  • Setting repositories private for a week and making them public again to see how the data changed.
  • Using the GitHub API to track changes every hour to line up with commits, clones, views.

At the time, I didn’t keep controlled tests in a consistent way, so I consider the observations in traffic more of an odd amusement rather than intentional measurement.

At the end of 2025, GitHub changed their Insights process and web interface, substantially altering measurement flexibility. They started updating data only daily rather than multiple times per day. That limited my ability to see fine-grained details, such as hourly estimated views and clones. The only output now would be the previous day’s total data. This meant I had to reset all the parts of the GitHub “stage” and think of more controlled and intentional tests. Let’s call GitHub “Stage C” from this point forward, as the new game will be to explore this presumably bot-like activity.

The Stage C repositories will consist of a series of five tests, being updated at varying times with varying strategies. Each repository will be opened to the public in a staggered release, roughly two hours apart. The tests are as follows:

  • Alpha: Normal edits on code with a standard license file; one commit per day.
  • Beta: Embedding a link into a nested Markdown file; one commit per day.
  • Gamma: Whitespace changes only, modifying the exact same code initially used in Alpha; fifteen commits per day in varying strategies.
  • Delta: One extensionless file containing only newline changes with emoji-based commit messages; one commit per day.
  • Epsilon: One empty file containing white-space or small text changes and fourth-wall commit messages; one commit per day.

I’ll be keeping logs of these tests for a week before we can look at the results. In particular, it will give more clarity of how automated systems scrape and whether there are patterns depending on context, content, timing and frequency.