It's usual to just put stuff like this in your own version control. Each time you get an update, delete old version, copy new version on top, then sort it out. Perforce has a "Reconcile Offline Work" for exactly this sort of situation; with git or svn, a simple commit will probably do exactly the right thing. This doesn't give you full history, but you get enough to revisit and bisect old versions.

(With a touch more work, you can also maintain your own changes, and have them 3-way merged in automatically.)

As for not using source control - if they don't use it internally, that's a bit weird, but maybe there's just one person working on the code, and they take a backup every hour, and they're happy. (It's their time, not mine.) But not exposing their source control to the outside world is absolutely standard. I worked as a programmer for software companies for ten years and never once saw 3rd-party code distributed any way other than zipped up source drops. (And this includes times where we were working with the 3rd party on the same project! - we just did the thing I mentioned at the start when they sent us updates, and they did the same thing at their end. It's much less of a bother than you'd think, though the first couple of merges can be a bit painful.)

If you want to claim they're being unhelpful, the insistence that you upgrade at a moment's notice is much worse. Upgrading 3rd party libraries is one thing you never, ever want to do, unless your hands are absolutely tied!

I don't get where the downvotes came from. All the downvotes in the world can't fix the past, sadly.

Some of the arguments may seem plausible in theory, but as soon as I contemplate doing my 9-to-5 dev work without source control (specifically git)-- yeah, no, not happening.

Obviously source control has its benefits, but ironically often tarball-only developers produce very high quality software (the most prominent example is djb at cr.yp.to).

Conversely, GitHub is full of low quality software.

djb's software is pretty low-quality for very many metrics of "quality". Lots of it is not elegantly interoperable with existing UNIX systems, because he has his own idea of how UNIX systems should work. There's the entire qmail backscatter thing. There are pieces of crypto code written in a custom assembler. Curve25519 has its own reimplementation from Chrome's Adam Langley, and all of NaCl its own repackaging in the form of the libsodium project, because the official distributions are difficult to use. NaCl has been promising certain features in the "next release" for years (notably Ed25519 signatures), but no release has been seen. All the downloads are over plaintext HTTP with no cryptographic signatures: I've always interpreted this as implying that if you're not qualified to audit the entire tarball you downloaded, the software isn't for you.

None of this is to claim that he's a bad cryptographer, or even a bad software engineer. But pure code output is far from the only important metric for software. GitHub makes it easy to do release engineering well, or to let other people help you with that if it's not your forte. (libsodium, for instance, is on GitHub.)

You're cherry picking a few example of tarball only developers and then comparing it to the entirety of github? How is that a fair comparison at all?

Wow, -3 for this horrible comment. HN is full of idiots.

Now go on, make it another -10; it will be the only thing in your day that makes you feel that you have any influence.