Forking an open source project | Jon Skeet's coding blog

Search for:

Introduction and motivation

Some of the projects I work on – notably V-Drum Explorer and At Your Service – use MIDI to interact with hardware devices.

I use a couple of packages for this depending on the nature of the interaction, but the one I use most often is managed-midi, which currently has its "source of truth" at https://github.com/atsushieno/managed-midi. This is a cross-platform library using the NuGet "bait-and-switch" approach to allow a single package with multiple implementations within it. Note that unlike the use of the term in commerce etc, "bait-and-switch" is not a derogatory term when it comes to NuGet packages. There’s no deception involved. (Do let me know if you have a more recent source of documentation for bait-and-switch; the current link is from 2014, back in the dark days of PCL.)

A few months ago, managed-midi stopped working properly on Windows 11 installations that were fully updated, due to aspects of Windows MIDI Services either changing or being introduced for the first time. (I haven’t dived into exactly what the change involved.) This

has broken other apps as well as the managed-midi library.

The author of managed-midi, Atsushi Eno, has accepted patches which I believe will fix the issue – but he doesn’t have any plans to work on the .NET stack any more, so it’s unlikely that there’ll be a new release of managed-midi without someone else getting involved. (Note: I’ve assumed he/him pronouns for Atsushi, but I’m happy to edit this blog post if that turns out to be wrong.)

And that’s where I’m possibly going to come in. This blog post is going to lay out my current plans and outline a few alternatives. This helps me just in terms of making my thoughts concrete, as well as providing an opportunity for feedback. (There’s no great way of getting feedback from all existing managed-midi users, but I’m hoping my readership can provide useful thoughts without necessarily having used the package directly.)

Possible forking and next steps

I’ve already created a fork of the repo, but just forking the repo itself doesn’t signify much. The big questions are whether I’m going to publish a fork of the code to NuGet, and what happens after that.

I should state up-front that I’ve been in touch with Atsushi on BlueSky, and he’s been very open and constructive. He’s happy for a wholesale fork to happen, and he’d then expect to effectively redirect traffic to the fork. This is in no way one of those community bust-ups we sometimes read about.

Now, I’m not going to claim I have huge amounts of time to take on another open source project. Right now, while I’m between jobs, I have more time than normal, but I’m hoping and expecting to be employed again soonish, at which point I naturally expect the new job to take most of my focus. I’d like to get the project into a state where it’s easy enough to update dependencies, publish new versions etc – but without spending a lot of time on new features etc.

Things get slightly difficult due to the current state of the project. It hasn’t been worked on very significantly for quite a while (just the first page of the commit history goes back to October 2019). To be really clear, I’m not in any way attacking Atsushi for this. I’ve got plenty of open source projects I haven’t updated for ages – I’m sure many of us have. I’m incredibly grateful to Atsushi for the updates that managed-midi has received over the years; it’s been a very valuable library to me. However, it does mean that the solution doesn’t even build for me after a simple clone.

Fork location

For most public projects, I like having a "core" repo and then my own personal fork. For example, Noda Time has https://github.com/nodatime/nodatime, and I create branches within https://github.com/jskeet/nodatime for PRs. Given that there isn’t already a suitable GitHub organization, I plan to stick with just my fork in https://github.com/jskeet/managed-midi.

Dropping some platforms

Several of the platforms being targeted are either out of date or at least being deprecated. I don’t like the idea of trying to maintain code that I can’t test, or which targets platforms or toolchains which are no longer supported. It’s really easy to get into that situation, trying to avoid breaking existing users.

But if I’m creating a new NuGet package anyway, I don’t have any existing users – even if the codebase itself is forked. Where there are platforms which are out of date, I’ll bump them to more recent versions. Where there are platforms which are no longer supported at all (or are already deprecated) I’ll drop them entirely – at least to start with.

At first glance, I think this means the following changes from the current targets:

netstandard2.0: keep; this is the "bait" target

net45: update to net48; used as the implementation for .NET Framework

netcoreapp2.1: update to net10; used as the implementation for...