A note on inheriting thicket
This library parses and re-emits iCalendar files and has done since 2013. The person who wrote it stopped answering in early 2024. In October I asked for the commit bit on a project I had contributed to exactly twice. This is the note I wanted to read before I said yes.
How This Happened
There was no handover. There was an issue titled "is this project still maintained?" with fourteen thumbs up and no reply, and underneath it a comment from somebody offering to help that was also unanswered. I emailed the address in the gemspec and got nothing. Six weeks later I emailed again saying I intended to ask the registry about adopting it, and that one got a two line reply: yes, go ahead, sorry, I have not had the energy for a long time.
What I Found Underneath
Better than I expected and worse than it looked. The parser is genuinely good, carefully written, and clearly the work of someone who had read the RFC properly rather than guessed. Around it were 340 open issues, a test suite that had not run on a supported Ruby in two years, and four dependency advisories that were all trivially fixable and had simply been sitting there because nobody had the keys.
Public repositories depending on this
about 11,000
Open issues when I took over
340
Open issues now
180
Months without a release before I started
15
Other maintainers
0
About The Person Who Wrote It
They gave eleven years to something they were not paid for, and then they stopped, which is allowed. The reason there was no handover is that there is no mechanism for one. Nobody asks a volunteer to write a succession plan, and by the time it is needed the person who would have written it has already run out of the energy required to write it. This page exists partly so that the next transfer of this library is less improvised than mine was.
"Sorry, I have not had the energy for a long time. I kept meaning to write something and then it was easier to not open the tab.
"from the reply that transferred the project
What I have actually fixed
Four dependency advisories, in the first release after taking over
CI running again, on every supported Ruby rather than the one from 2022
The timezone handling for all-day events, which caused about 40 of the 340 issues
Triage on every issue older than a year. Most were closed. Some were just answered
A CONTRIBUTING file that says what I will and will not merge
What I have not fixed and probably will not
The recurrence rule engine. It is correct for common cases and wrong for exotic ones
Streaming for very large files. Requested since 2018. It needs a rewrite I do not have time for
Windows path handling in the file loader. I have no Windows machine and will not guess
Anything requiring me to break the API. That decision is not mine to make alone
The 180 issues still open. Realistically most will stay open
What I Will Not Do
I will not pretend this is a thriving project. I will not add features to make it look active. I will not accept a pull request I do not understand well enough to fix at midnight when it breaks, no matter how good it looks, because merging code you cannot maintain is how a project gets abandoned twice. Everything I have merged in eighteen months, I could rewrite from scratch.
If I Stop
Somebody should be able to take this over without the eight months of silence I sat through. So: the gem is owned by two accounts rather than one, the second belonging to a person who has agreed to hand it on rather than to maintain it. The CONTRIBUTING file names them. It is not a succession plan. It is a phone number, which is one more than I had.
If you are considering taking on an abandoned project
Read the last two years of issues before the code. That is the real workload
Check whether the original author is unreachable or just tired. Ask twice, kindly
Fix security and CI first. It buys goodwill and it is finite work you can finish
Write down what you will not do, publicly, in the first month
Find one other person for the registry account before you need them
