Github used to have an awesome and public way to explore projects (http://web.archive.org/web/20130730125837/https://github.com...) - I remember using it a lot to look for projects to learn to read code because it allowed me to easily find projects by language. They replaced it with a flashier, but in my experience, much less useful tool that you have no control over - https://github.com/explore .

I know I'm not the only one thinking of moving my repos to another provider or perhaps a self-hosted solution because of this direction.

Not quite sure if I understand which specific thing you are mentioning, but does https://github.com/trending happen to be what you want?

But if gitlab jumps the shark like github is doing we can always have anyone in the ecosystem selfhost a clone, albeit we would need to reimplement all the enterprise features people want.

Secondly, they do have proprietary features, embrace, extend, extinguish style.

see also https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

The only thing I can think of is patches via email, but that's just using no repository at all.

But apart from sending changes via email (which is actually a very good way to go for small(ish) changes--actually, it is so good, the Linux kernel developers use exactly that: git can generate emails that are both human-readable, so you can easily review and comment on patches, but also can be imported automatically into a repository by the recipient), you can just send pull requests via email? You simply put into an email the URI of your git repository, wherever it is hosted, and the recipient can pull from it. That is the power of an open distributed system like the internet.

And to spin this a bit further: Actual "hosting" isn't even necessary technically. Especially once we get rid of IPv4 and NAT, it should be trivial to spin up a git server instance on your workstation (or maybe your smartphone, as that probably is online 24/7) so people can pull from there. Whether that is practical? It well might be--but my point is more to show what is technically possible.

And yes, all of that was possible with a "previously popular solution"--git existed before github, obviously, and its popularity is what caused github. Also, all of that applies just the same for other distributed SCMs, of course.

DDOS scripts create new sessions on every attack request. It's a very hard problem to solve without blocking legitimate traffic too.

Simply sign your session ids with an HMAC, to verify the id without any I/O! And require something expensive to create a session (such as a hash-based challenge request). Sessions are usually not needed for static sites, so by the time the person searches, their browser will have earned one session. A spammer on the other hand wouldn't have the computational power to create the various sessions. Also, if a spammer's IP is detected, the computational complexity can be increased for that IP.

I don't understand why one would DDOS Github. What is the reason for that?

http://arstechnica.com/security/2015/03/github-battles-large...

http://fiatjaf.alhur.es/gh-browser/

It adds links directly to GitHub source code (to other GitHub repos or external documentation) whenever it finds import/require statements.