Bram Moolenaar, creator and long-time maintainer of the Vim text editor, died in 2023. His death was a great loss. He left behind a piece of software used and beloved by many, as well as some big questions: Who will keep Vim going now that he is gone? Are there other contributors that can take over? Has anyone been working on Vim since he died?
I recently released an open-source command-line tool called git who that can answer some of these questions. I wanted to build the tool because I’ve long been fascinated by what we can learn about a codebase from the metadata in its commit history. The commit history embeds a lot of information, especially about the people behind the codebase. git who surfaces this information. As a Vim user myself, I’m curious to see what git who can tell me about who is working on Vim now. I also hope this example will show how git who can be useful.
Thanks for the pointer. The update didn't exist when I made the post yesterday. It's always good to be explicit about the assumptions: The tool is using git's author field on every commit. If the...
Reddit user y-c-c pointed out to me that the above analysis of Vim’s commit history is misleading because for many years Moolenaar gave credit to contributors in the commit message of patches he committed. So, during the many years where it looks like Moolenaar was the sole contributor, there were in fact other people contributing to Vim—it’s just that all of their changes were introduced to the repo via a commit from Moolenaar.
Typically, a situation like this would be handled in Git by setting the commit author to the person who wrote the patch and the commit committer to the person actually making the commit. git who uses the author field. Still, everybody is entitled to use their tools their own way; it’s also possible this convention didn’t exist when Moolenaar first migrated Vim to Git. The fault is my own for not spot checking the commit history to see how the Vim project did things. Vim has had more external contributors and for far longer than I represent above.
Thanks for the pointer. The update didn't exist when I made the post yesterday.
It's always good to be explicit about the assumptions:
The tool is using git's author field on every commit. If the repository doesn't use this field according to git who's assumptions the results will be skewed.
I wasn’t aware of git who. This looks like a great way to discover more about a project’s contributors. Of course the next information I want to know is, who are these people exactly? It’s one...
I wasn’t aware of git who. This looks like a great way to discover more about a project’s contributors.
Of course the next information I want to know is, who are these people exactly? It’s one thing to see that Christian Brabandt, zeertzjq, Yegappan Lakshmanan are the current primary drivers of the repository, but none of those names mean anything to me. I wonder what it would take to pipe the git who output to an LLM + search workflow that analyzes the FOSS reputation of each contributor. It would take into account their GitHub (et al.) repos and activity, do some light OSINT to find real names, countries of residence, alternate online handles, mentions in blog posts or news articles, that sort of thing. Hopefully enough to surface any red flags that might be good to know about. Supply-chain attacks are increasingly common in the open-source world so I’m always thinking about ways to get early warning before a beloved package goes bad.
As a lover of both digital privacy and digital security, it’s tricky when the two come into tension with one another. Usually they’re two peas in a pod. But when it comes to making sure the...
As a lover of both digital privacy and digital security, it’s tricky when the two come into tension with one another. Usually they’re two peas in a pod. But when it comes to making sure the software I’m running every day isn’t going to sell my data to the highest bidder, or turn into ransomware, or some other nefarious thing, I think it’s worth getting that the maintainers of said software aren’t random anons with no established credibility. ESPECIALLY if they’re taking over a highly regarded package when the original authors are no longer active, for whatever reason.
Nice article. There's an important correction (but it's all the way at the bottom of the page).
Thanks for the pointer. The update didn't exist when I made the post yesterday.
It's always good to be explicit about the assumptions:
The tool is using git's author field on every commit. If the repository doesn't use this field according to git who's assumptions the results will be skewed.
I wasn’t aware of
git who. This looks like a great way to discover more about a project’s contributors.Of course the next information I want to know is, who are these people exactly? It’s one thing to see that Christian Brabandt, zeertzjq, Yegappan Lakshmanan are the current primary drivers of the repository, but none of those names mean anything to me. I wonder what it would take to pipe the
git whooutput to an LLM + search workflow that analyzes the FOSS reputation of each contributor. It would take into account their GitHub (et al.) repos and activity, do some light OSINT to find real names, countries of residence, alternate online handles, mentions in blog posts or news articles, that sort of thing. Hopefully enough to surface any red flags that might be good to know about. Supply-chain attacks are increasingly common in the open-source world so I’m always thinking about ways to get early warning before a beloved package goes bad.People thinking these kinds of thoughts is why I do basically all of my OSS contributions using multiple pseudonyms.
As a lover of both digital privacy and digital security, it’s tricky when the two come into tension with one another. Usually they’re two peas in a pod. But when it comes to making sure the software I’m running every day isn’t going to sell my data to the highest bidder, or turn into ransomware, or some other nefarious thing, I think it’s worth getting that the maintainers of said software aren’t random anons with no established credibility. ESPECIALLY if they’re taking over a highly regarded package when the original authors are no longer active, for whatever reason.