A Thousand Forks and No Code Changes

Every career journey is different, but they all have one thing in common: the résumé. So it’s no surprise that my own career journey has me looking for tools to improve my own résumé. I had a vague memory of a post on Hacker News that someone had developed an open source tool that allowed you to input structured data, and it would spit out a beautiful résumé. A quick search led me to RenderCV which works exactly as described

I made an account, filled out some of my information, and hit export and got a great PDF. Then I went back to tweak something, hit export again, and hit a paywall. Subsequent exports require a subscription — something I didn’t notice until after I’d already done it.

Fair enough. The tool is clearly well-made and the developers deserve to be paid. But the whole thing is also open source, so I did what open source people do, found the GitHub repo to see if I could run it myself. As expected, it looks great: 16.6k stars, 39 watching 1.2k forks, multiple contributors, consistent contributions over the past few years, including one in the past few weeks. Right there in the README is what I was looking for

Get Started

Install RenderCV (Requires Python 3.12+):

pip install "rendercv[full]"

So that is what I did, I installed it locally and kept going. And this is not unusual for an open source project, the easy way is limited or costs a few bucks, and if you want to run it a lot you need to do it on your own hardware or tweak the options to get something useful. So I didn’t think much of it once I got it dialed in and generated my résumé.

But those 1,200 forks started nagging at me. Why were there so many?

So I went back and started poking through a few of them. Most of them made no changes to the code or the resume.yaml file at all, which is not what one typically does with a fork of a repo. I also found users adding their personal resume.yaml directly into a subdirectory of the rendercv source repo — treating the fork as both the tool and the storage for their personal data — meaning their phone number and email and entire work history are sitting in a public repository indexed by search engines. Another had edited the README to add a note about how to invoke the renderer with python -m rendercv render, but never actually produced a PDF.

My hypothesis: a lot of these people hit the same paywall I did. They saw the GitHub link, figured they could get more out of it if they forked it, and then had no idea what to do next. Forking is the most visible “make this mine” button on GitHub. It’s just not the right one here. What they were actually looking for was a way to run the tool without setting up a local environment; they wanted to produce a PDF and own the output.

So I built rendercv-template which is a GitHub template repository. This just a thin wrapper around RenderCV. Click “Use this template,” give your repo a name, make it private, and edit resume.yaml in the GitHub web editor. Once your information is in there, you can go to Actions, click Run Workflow, and download your PDF from the Releases page. It’s convenient because everything runs on the GitHub website - you don’t have to install anything.

But even after building the template, I had this feeling there was some important factor I was missing. So just before publishing this post, I posed the question to Gemini 3 Flash to see if it might help me find something I missed.

Me: Help me solve a mystery. Why this repo has so many forks. I have suspicion, but I want to see what you come up with. The vast majority of forks I looked at have no code changes https://github.com/rendercv/rendercv

Gemini:

  1. Cloud Rendering via GitHub Actions (The “No Install” Trick) - By clicking “Fork” on the main repository, users bypass local installation entirely. They can simply edit the YAML file directly in the GitHub web interface, commit the change, and let the repository’s built-in GitHub Actions pipeline automatically compile and spit out their newly updated PDF.
  2. Treating Data as Code (The YAML Edits) - Because RenderCV strictly separates the engine from the content , users have no reason to touch the source code. The forks have “no code changes” because the users are only modifying the John_Doe_CV.yaml example files with their own personal job history.
  3. The “Bookmark” Fork - Many developers use the Fork button as an aggressive form of “Starring” a repository

Me: I’m looking at RenderCV’s GitHub actions and I don’t see a way to get it to actually render the pdf. Am I missing something?

Gemini: You are completely right, and you caught me in a mistake! You aren’t missing anything at all—I was conflating the main repository with its templates.

The main rendercv/rendercv repository does not have a GitHub Action to render PDFs. If you look at its .github/workflows directory, the actions are strictly for the software’s own CI/CD lifecycle: running tests, deploying the documentation website, creating executable binaries, and publishing releases.

The actual automated PDF generation is meant to happen in completely separate template repositories (like rendercv-template or other user-created pipeline repos). Those templates are the ones equipped with the specific GitHub Actions to download the RenderCV CLI, process a YAML file, and output a PDF. Users who fork the main repository missed the memo that they were supposed to use a template repo instead.

My first thought was ‘Wow, I only posted this project a week ago and Gemini has already recommended it independently!’ and then I thought ‘Did I check to see if the RenderCV dev made a his own template…’ It turns out he did. In fact, he did it years ago. So does that mean my template won’t actually solve the problem? With a closer look, I realized that, while our projects are similar, there are a few important decisions in implementation. The main difference is documentation, my project assumes no familiarity with RenderCV and walks you through the process. The other is a little more subtle: my project generates a pdf when the user chooses, rather than every time a change is made to the repo. I think this is clearer and it behaves more like the user expects. Either way, I enjoyed going down this user behavior rabbit hole, and I have a feeling I haven’t even seen the rabbit yet.