Long live DJB.
If you run dnscache on the tubes, a PSA: one should apply patches to suppress duplicate outbound queries, which DJB's original code did not perform. This made dnscache vulnerable to birthday paradox attacks. Details: http://www.your.org/dnscache/djbdns.pdf
Also, you should apply patches to increase MAXUDP queue size to 1024 or much more for modern "web2.0" query demands, and to prevent induced flush attacks. Your distro might or might not do this patching (usually just IPv6 support), depending on the port maintainer's chosen balance between helpfulness and code purity. This issue seems oddly pronounced in dnscache port commit logs, compared to others ports, so you are advised to check what patches the maintainer thought were cool, and which were just for haters.
DJB's response was to abandon dnscache, saying the protocol was flawed. While Curve25519-based solutions offer a new approach to DNS (one oblivious to e2e DNSSEC applications), many users just run legacy dnscache based largely on its enduring reputation.
This is not shade, just a clinical statement: Stock dnscache must be patched to be more secure than stock BIND wrt duplicate queries; your distro may vary. That's simply a factual statement, not an attack on DJB, or anyone who likes DJB and/or his code. As the kids say, "fight me".
I don’t really see too much worth in it though. Of course requirements change and people make useful commits to the code. That’s to be found in any lasting open source project.
In a strange way, I find that your comment almost amplifies what I’m trying to say. Perhaps I wasn’t too clear, mea culpa.
So, with 2 - 5 patches all that projects are still production ready ?
In other words: pls imagine git repo with such djb-originated project... So, such repo with ~5 commits (since ~1997) is current state of the art ?
And if there are some bugs there they certainly are in NSA secret-bugs collection ? :>