Then one should get a couple of elastic search clusters, one for the guest users to hammer and DDoS and one for the authenticated users. Not only does this mak

Then one should get a couple of elastic search clusters, one for the guest users to hammer and DDoS and one for the authenticated users. Not only does this make the search cheaper and easier for the guests (just an index of public repos, so no permissions involved), it makes it easier to continue offering search to authenticated users whilst being able to mitigate L7 DDoS on the authenticated search (just block the users involved in the attack). Besides, there is a huge SEO benefit to having a searchable and discoverable interface, and a huge attention retention benefit to keeping users on your site to search once they have arrived there. On top of that, Github understand their data structures better than a search engine so it's easier to tune complex searches just for a codebase, or blog, or issue. There's really no benefit to hiding search, and having written many community generated content sites the only reason I would hide search is as a stepping-stone to making the content part of a walled garden. It's fairly inevitable Github will want to do this, I imagine they're looking at the number of users who are not signed-in or on free accounts as yet to be monetised. They would want more activity data to make arguments for advertising, or recruitment monetisation, or plan up-sell, etc. That's where this makes sense, as a way to gather more user habit data.