Currently, those two projects are:
A rewrite of arc_summary.py for OpenZFS in Python 3
ZFS, or more common these days, OpenZFS, is a next-generation file system that puts the emphasis on really, really, really keeping your data safe at the cost of higher hardware requirements (Adam Leventhal claims that it was almost Apple's next file system). I got my initial hands-on experience when I built my first own FreeNAS server -- FreeNAS is based on FreeBSD. ZFS comes with a brutal learning curve, but rewards your pain with seriously advanced features. In FreeBSD Mastery: ZFS, Michael Lucas and Allan Jude famously speculate:
The Enterprise's computer on Star Trek probably runs ZFS.
After a while, the paranoia built into ZFS becomes infectious, and it becomes hard to take file systems seriously that don't checksum every single byte of data. By now, I've moved my Ubuntu home partition over to ZFS.
Now, buried in a far-away corner of OpenZFS in the Linux GitHub tree is small program called arc_summary.py which provides information on the Adjustable Replacement Cache (ARC) of ZFS. The original version was written by Ben Rockwood in Perl for Solaris in 2008, and was later ported to Python and (among other things) Linux. However, the Perl roots kept showing, and Pythonic this wasn't. So I did some cleanups under the hood, which was fun -- not the least because the people in charge of OpenZFS on Linux are enormously helpful and friendly even if you ask really stupid questions.
However, arc_summary.py was written for Python 2, and Python 2 it must remain because ZFS is backwards compatible to various ancient operating systems. This is frustrating, because the only thing worse than Python 2 is old Python 2. So, to finally get to the point, I've started a complete rewrite of arc_summary.py in Python 3. In the grand scheme of ZFS, this is sort of like reorganizing the broom closet in the Sistine Chapel -- but hey, it's the Sistine Chapel. This project should be completed soon.
A rewrite of Tali Forth for the 65c02
Tali Forth was the first Forth I every wrote myself. It, ah, worked. After that, I wrote Liara Forth for the 65816, which was far, far better because I kinda-sorta knew what I was doing. After that (and a whole lot of further reading), the original Tali Forth looked silly, so I'm doing a clean rewrite named, obviously, Tali Forth 2.
Beyond minor technical differences, Tali Forth 2 should be far easier for other people to port their own 65c02 projects to. This time, I'm writing it for the Py65 simulator and trying to strictly isolate all hardware dependencies. A Forth is always fun to code because you can just do a word here, a word there as time allows once the main loop is up and running.
And after that?
We'll see. One thing I'm considering is trying my hand at RISC-V assembler now that there is actual hardware to run it on. Also, there doesn't seem to a modern implementation of Lisp for the 6502, which would be so completely different from Forth that it sounds like fun. And then ...
... nope, only two projects at a time. Because, like, adult.