There’s a middle-ground, there, where you’re developing something that you intend purely as a personal learning exercise, but you’re doing it in public — or at

There’s a middle-ground, there, where you’re developing something that you intend purely as a personal learning exercise, but you’re doing it in public — or at least not well-hidden enough — and then someone comes along, finds it, and uses it. (There’s an analogy to make with security researchers who develop exploits while practicing bad OPSEC — they don’t intend to create viruses, but their actions predictably lead to the creation of viruses anyway, since virus-writers watch them closely.) Keep in mind that usually, people just hacking on an idea for a few hours (who aren’t coding celebrities who expect all their repos to be well-trafficked just because they’re their repos) don’t bother to put up a huge warning in the README of a slapdash exercise, to point out that it isn’t for production use. This used to be a bigger deal back when GitHub was the code-host but also didn’t offer free private repos; it effectively forced independent developers and students into working in public. But it’s still somewhat of a big deal, because people will still choose to make their repos public in order to more easily collaborate on them in the context of e.g. school exercises. (Because forming a GitHub org and adding ACLs is extremely onerous when you could just make the repo public and share the URL.) IMHO, code-hosting companies would be well-served by adding a checkbox to the repo setup process (sort of like the ones for adding a .gitignore or a LICENSE) to indicate that the repo contains code written as a learning exercise for $thing; such that checking that box would insert a big flashy warning on the page that the repo is not to be used as a reference for the idiomatic way to use $thing. (And maybe, on top of that, make it impossible to clone the repo through HTTP until the username you’re cloning as has pressed a confirmation button on that warning.)