Posts on Antonin Delpeuch

The forgotten features of Sourceforge

Fri, 18 Sep 2026 00:00:00 +0200

Remember Sourceforge, where you’d download software in the 2000s? It’s now mostly dead, and the company running it has been trying to squeeze out as much profit from it as they can using questionable practices.

But despite that, it’s a software forge, and I think some aspects of its design remain interesting and could even be an inspiration for today’s forges. Let’s have a look at a sample FOSS project hosted on Sourceforge, Code::Blocks, with which I made my first programming steps some decades ago.

Wikimania 2026 Team Challenges: experience report

Sat, 29 Aug 2026 00:00:00 +0200

At this year’s Wikimania (the annual conference of the Wikimedia movement), a new sub-event was introduced: the Team Challenges. This post summarizes my experience of it as a participant.

Traditionally, the Wikimania hosts a rather loosely structured “hackathon”, which mostly consists in making a big room available for people who want to hack on things throughout the conference. There is an opening ceremony for it, where participants are able to pitch the projects they intend to work on, and a closing ceremony where they present what they did.

Cloning large repositories

Tue, 26 May 2026 00:00:00 +0200

When you want to clone a large git repository locally, consider using:

git clone --filter blob:none <the_remote_repository>

This is so much better than --depth 1! Instead, this method still gives you the full commit history but only downloads the file contents on demand, as they are needed. Initially, only the files appearing in the last revision of the default branch are downloaded (to make the first checkout).

You can checkout any other revision and Git will download the necessary files from the origin on demand. Or run any other Git command, like git diff between commits you haven’t checked out yet.

Improving organization management in Forgejo

Tue, 19 May 2026 00:00:00 +0200

In January, I started a 2-year research project on the governance of FOSS projects. I do this as part of the ACES team at Télécom Paris, where I am hosted by Théo Zimmermann and Stefano Zacchiroli. The project is part of the CONGRATS area of the eNSEMBLE funding programme, which looks at the dynamics of online collaboration more broadly.

One part of my project consists in looking into the existing governance dynamics in those projects, trying to identify patterns that work better than others. This involves collecting data from large collections of FOSS projects (via the Software Heritage archive), interviewing people, and analyzing those results. I’ll write more about this later.

The puzzle of tree-sitter parser maintenance and distribution

Thu, 16 Apr 2026 00:00:00 +0200

Lately I’ve been thinking about a problem which feels like an interesting governance one. (Yet another, yes!) The recent abandonment of the nvim-treesitter repository made quite some waves, so it feels a fitting occasion to expose this problem here.

Tree-sitter is a parser generator. You specify a grammar for a language (say, Java or CSS) and it generates pretty efficient parsing code for it in C. This parser can then be used in all sorts of applications, such as for syntax highlighting in text editors (Neovim, Helix, Zed, Emacs…). It’s also used in GitHub to list function definitions in files, for instance. We also rely on it in Mergiraf, our resolution tool for git conflicts.

Is there a better word for 'hackathon'?

Wed, 04 Feb 2026 00:00:00 +0200

In a recent event where a hackathon was organized, the organizer felt the need to emphasize multiple times that the hackathon wasn’t just “for crazy programmers who code all night long” but was more broadly open to all forms of co-creation between the attendees. It reminded me that I have some problems with this word, which I want to summarize here.

To me, the word “hackathon” suggests sitting down to program something during an in-person event. The goal would be to have a prototype of a system, that would be presented at the end of the event, in some sort of final showcase.

Too much time on your hands

Tue, 18 Nov 2025 00:00:00 +0200

What if the main thing your FOSS project needed was that you work less on it? It has definitely been the case for me, and I think I am not the only one.

We regularly hear stories of heroic volunteer open source maintainers single-handedly sustaining critical cornerstones of our digital infrastructure. We often hear how those selfless workers have been in that position for decades, tirelessly fixing bugs after work in late night hacking sessions. Many of them are role models in our movement. They define what it is to be successful as a FOSS maintainer.

Move your FOSS project to an org!

Tue, 14 Oct 2025 00:00:00 +0200

By default, forges like GitHub make you create new repositories under your own account. But most open source projects should rather be in an “organization”, even if there isn’t a corresponding legal entity for them.

In this post, we’ll assume your repository is on GitHub, but most of it applies to other forges like GitLab or Codeberg.

The downsides of personal repos #

If you’re interested in attracting contributors to your project, personal repositories are not very well suited for that. To onboard trusted contributors, your only option is to add them as “Collaborators”. This gives them write access to the repository, but not much more than that: they cannot onboard more people themselves, nor can they access most other repository settings.

The Pull Request Hack is not enough

Fri, 01 Aug 2025 00:00:00 +0200

Years ago, I read The Pull Request Hack, a blog post advocating for a radical way of collaborating on FOSS: “Whenever somebody sends you a pull request, give them commit access to your project.” The post is really worth a read. More than a decade later, I think it aged well: a lot of FOSS projects would benefit from granting permissions to contributors more proactively.

You might argue that the situation has changed: since that blog post, some pretty traumatizing social engineering attacks have happened, such as the XZ Utils backdoor or the event-stream incident. In both of those examples, malicious actors abused write accesses that maintainers granted them willingly, after seeing a track record of well-intended contributions. It can be tempting to react to those attacks by raising the bar for granting privileges in FOSS projects, but I think it’s misguided. In both cases, the maintainers were particularly vulnerable to social engineering because they were isolated and overworked.¹ Intuitively, growing a project team proactively helps reduce this risk, both by having more eyes to scrutinize things and by those eyes being less strained. In other words:

Wikibase day-dreaming

Mon, 20 Jan 2025 00:00:00 +0200

Some months ago, I saw a job posting for Wikibase.Cloud’s product manager. It piqued my interest and lead me to ask myself what I would do if I were to work at Wikimedia Deutschland, in a position to influence the direction the Wikibase project. I realized I have opinions, so this is an attempt to put them in an understandable format, mostly in the interest of being able to refer to it in discussions with people as those subjects regularly come up.

Off-the-shelf governance models for small FOSS projects?

Fri, 20 Dec 2024 00:00:00 +0200

A one-person open source project with a governance model, is that ridiculous? In this blog post I want to convince you it isn’t, and it could be key to solving widespread problems in the FOSS (Free and Open Source Software) ecosystem.

The problems #

The free software movement is successful in many ways, but there are still annoying aspects to it. There are many situations where I feel like there is no shortage of people with goodwill, but we still fail to work together.

Retrospective of Dissemin and thoughts on the open access movement

Sun, 24 Nov 2024 00:00:00 +0200

At the end of this year, we’ll be discontinuing Dissemin, a web platform designed to help researchers upload their articles to open repositories. I want to take the time to reflect a bit on this journey and what I learned in the process.

Dissemin started at École normale supérieure around 2015, when a bunch of us were motivated to try and do our bit to open up access to scientific publications. The open access movement wasn’t a new thing then, even at ENS. Marie Farge, a researcher at the geosciences department of ENS, had been campaigning for open access for quite some time, and Pablo Rauzy, a fellow computer science student a few years before me, had written a very helpful page in French on the topic and gave many talks on the matter. As I read my first scientific articles and also tried to write some, I discovered the problem of lack of access and got in touch with Marie and Pablo. I also discovered the open access movement online, through many different resources such as those of Richard Poynder, Peter Suber and of course the film The Internet’s Own Boy about Aaron Swartz’s work, which I found very impressive and inspiring.

Mergiraf: a syntax-aware merge driver for Git

Sat, 09 Nov 2024 00:00:00 +0200

A central feature of Git is the ability to merge the contents of diverging revisions. It underpins not just the git merge command, but also rebase, cherry-pick and revert for instance. Without it, no collaboration would be possible. And it generally works great.

One limitation is that it’s line-based. If the two sides touch neighbouring lines, we need to manually resolve a merge conflict. That happens even if the changes are touching independent syntactic elements, because Git’s merging heuristic doesn’t know about syntax. Which begs the question: what if it did?

Contribution experience report: Spork

Fri, 08 Nov 2024 00:00:00 +0200

Welcome to my eighth contribution experience report. See the one about Git for some background about the initiative.

Spork is a tool to merge diverging versions of Java source files. It’s the result of a Masters’ thesis and has a corresponding scientific article published about it, so it clearly identifies as research software.

It’s debatable whether such type of open source project is meant to include external contributions at all. A published research paper is normally treated as a final research output, which isn’t meant to evolve (apart from possible corrections to fix serious issues), so arguably any accompanying software should be equally final. For reproducibility purposes at least, the paper should point to a precise version of the software with which experiments can be reproduced. But there are also many examples of major open source projects which started off as research artifacts and got a life of their own after that.

Contribution experience report: Thunderbird

Thu, 17 Oct 2024 00:00:00 +0200

Welcome to my seventh contribution experience report. I have done others for:

Git, where I give some background about the initiative
Nextcloud’s docker image
Forgejo
JGit
Mattermost
Organic Maps

My motivation to contribute #

Sometimes I forget to join meetings. Generally without being able to offer any good excuse for it. But three years ago I skipped one and I had a genuine reason: it was Thunderbird’s fault! It failed to import an invite in my calendar. When I tried to import it again, it gave me a cryptic error: “Processing message failed. Status: 80004005.” After some digging I found out that it was because the UID field of the ICS file contained some special characters. Frustrating!

Contribution experience report: Organic Maps

Sat, 13 Jul 2024 00:00:00 +0200

Welcome to my sixth contribution experience report. I have done others for:

Git, where I give some background about the initiative
Nextcloud’s docker image
Forgejo
JGit
Mattermost

My motivation to contribute #

In Saxony, many bars allow indoor smoking. As someone who struggles in smoky places, I try to avoid those bars. It’s often not so easy to look up the smoking status of a place, as it is rarely advertised online, so for a while I have been surveying bars and adding this information on OpenStreetMap, so it can be found easily. Well, easily for me, but not that easily for most people around me, because OpenStreetMap.org isn’t user-friendly. So it’s not easy to share the result of my evening walks with them.

Contribution experience report: Mattermost

Thu, 02 May 2024 00:00:00 +0200

Welcome to my fifth contribution experience report. I have done others for:

Git, where I give some background about the initiative
Nextcloud’s docker image
Forgejo
JGit

This one is about contributing to Mattermost. Mattermost is a chat application for teams, often seen as a FOSS replacement for Slack as it offers a very similar user experience.

My motivation to contribute #

I identified a small issue in the user interface: a checkbox not being properly associated with the text that describes its function, meaning that clicking on the text would not have any effect on the checkbox itself.

Contribution experience report: JGit

Sat, 20 Apr 2024 00:00:00 +0200

Welcome to my fourth contribution experience report. I have done others for:

Git, where I give some background about the initiative
Nextcloud’s docker image
Forgejo

This episode is the first one about contributing to a library. JGit is a Java implementation of Git, covering many of the features of the original implementation in C. This makes it possible to use Git in Java programs without having to use separate processes and avoids license compatibility issues (Git itself is under GPLv2, JGit uses the Eclipse Distribution License which is similar to the new BSD license). JGit is used in pretty established projects such as the Eclipse IDE or Gerrit.

Contribution experience report: Forgejo

Sun, 21 Jan 2024 00:00:00 +0200

Welcome to my third contribution experience report. I have done others for:

Git, where I give some background about the initiative
Nextcloud’s docker image

My motivation to contribute #

In short: I wanted to fix some bugs I had encountered, and I was curious about contributing to a “soft fork”.

Here is more background. In Kanthaus, we used to rely on GitLab to host about 20 Git repositories for various documents (governance, minutes of meetings), for website sources (such as for https://kanthaus.online or https://handbook.kanthaus.online) or some pieces of software used in the house (such as scripts to steer our heat pump or to gather statistics about the house).

Contribution experience report: NextCloud's Docker image

Tue, 09 Jan 2024 00:00:00 +0200

Welcome to my second contribution experience report. It follows the one for Git which gives some background about the initiative.

My motivation to contribute #

In short: I had been hit by a very annoying bug and I wanted to fix it.

Here is more background. In Kanthaus we have a NextCloud instance that we use for shared documents. I have recently started helping out to maintain it, which means doing regular upgrades.

Contribution experience report: Git

Sun, 17 Dec 2023 11:29:23 +0200

Improving the experience of new contributors in OpenRefine or other projects I maintain is an important topic for me. I think that whether a contributor stays active in a project depends a lot on the experience they have during their first contact. I would generally like to have more feedback about the hurdles people have when trying to contribute to projects where I am active. So I am starting to document my own experience when contributing to other projects. This feels like a useful way to take notes of things I would like to take inspiration from. Perhaps it is interesting to the said projects too. Of course, I don’t claim that this experience is representative. Also, I acknowledge that not every open source project is necessarily seeking new contributors: it can be a deliberate choice not to invest any energy in onboarding people or to refuse any external contributions, for various reasons. It’s not what I wish for the projects I am involved in, though.

Trying out Graal's Native image functionality

Thu, 16 Nov 2023 11:29:23 +0200

In OpenRefine, we have been enforcing a code style for our Java files using a linter, which reformats source files according to a configuration expressed in Eclipse’s internal format.

Because the linter reuses Eclipse’s internal libraries, it is of course written in Java. Also, we invoke it via Maven, meaning that the start up time of the linter is quite long: we need to boot a Java virtual machine (JVM), which then boots Maven, which finally runs the formatter. So that’s not exactly fast. On my laptop it takes about 11 seconds. It’s not the end of the world, but it means it’s a bit annoying to have it as a git pre-commit hook, and it’s definitely not suitable as a git filter driver. Those filter drivers are processes which take the contents of a file on standard input and output a normalized version of it. Given that they are run on the fly for things as basic as doing a git diff or git status, they need to be really quick.

My roadmap for OpenRefine

Sat, 21 Oct 2023 11:29:23 +0200

In OpenRefine we still haven’t got ourselves a clear, public roadmap indicating what we are working towards in the near future. There are various proposals as to how we should get ourselves one.

So I thought I would at least write down what my own priorities are and paint of my vision for the project. I don’t claim that this should be OpenRefine’s roadmap: there is a ton of other efforts that I would really agree with, but which I am less interested in working on myself. Other team members have their own agenda and my own priorities are not set in stone either.

Some missing features in software forges

Fri, 20 Oct 2023 11:29:23 +0200

A lot of my work happens on software forges like GitHub or GitLab. They are very useful platforms, but they are not perfect. In this post I want to describe a few missing features around the transmission of open source projects to new maintainers.

Discovering active forks of a repository #

A lot of projects are maintained by a single person who, after a while, loses interest in the project, or even moves on completely and stops responding to any activity on the repository.