Do they explain the recent change to require login for code search?
Again you could disagree but it is a decision that can be rooted in sound logic.
Or, maybe this is all value-destroying nonsense that only makes the service worse.
In any case, the performance of the new search system is supposed to be better, not worse. [1]
[1] https://github.blog/2023-05-08-github-code-search-is-general...
What makes you think that logged out users aren't adding any value?
The behaviour of github here is consistent with them assuming that logged out users provide a small but non-zero amount of value for them.
The link you provided seems to suggest that the code search is supposed to be faster for users, but I can't see anything in it that suggests that it's less taxing on the backend?
I'm curious because I'm not sure of the answer myself: what value do you think anonymous users provide to them?
I suspect gating it behind a login is a simple way to rate limit, and prevent abuse with a cheap and effective way to mitigate false positives. As someone who's had to make similar decisions in the past (albeit smaller scale), I can sympathise with them turning off a computationally expensive feature that's not at the core of their product, but just an add-on.
Also network effects of those users since GitHub is not just a git repo host but a social media and community for code.
I think product needs to strike the right balance of free and paid features to maximize their profits.
Some of the things you highlighted (ie the social network effects) are best experienced when logged in, and other than "just" browsing, there's not much in interaction for logged out users already (can't host code, open issues, comment, star, etc). I think allowing people to browse code and its history, alongside other parts of the platform for logged out users already feels pretty open to me
I think a service should focus on how it provides value to users, not the other way around. People use it because of what it provides to them, not because they desire to support the company's bottom line.
GitHub built a remarkably valuable product, which attracted 100M users and $1B in revenue. It has tons of public features that never required login. They could have put search, or any number of other things, behind a login at any point in the last 15 year. But they didn't, because that's not actually a good thing to do. Doing that can only ever make the feature less usable.
What drives them to do it now is unclear. Perhaps just wanting to juice their login numbers or whatever. But, performing little bait-and-switches on random features isn't going to make people use them more or spend more money. It's going to make them seek hedges against the destruction of the features they enjoy.
As for my link, the search result speed for users is directly related to cost per query, unless you believe that all of this is fake and the new search system is secretly just a bunch of expensive new hardware.
In principle they could make it all login only, but hosting open source repositories is one of the main charters of GitHub or at least it was. So it makes sense and is consistent with that vision to keep code browsing free without login. Not to mention the requirement to be available on search engines.
Code search however doesn’t seem like it’s some mandatory part of that mission, I mean all they’re asking is that you login. People in this thread seem to have a chip on their shoulder believing corporations should just give them compute for free. No they don’t!
If the goal is openness, i.e. why GitHub has the prestige it does, allying itself with open software development goals, then you should be able to do most things without having to sign up for the service. That includes browsing and searching. Neither of these need your identity.
On the other hand, if GitHub really just wants a walled garden with paying customers (either directly or the money to be made from datamining their identity and activity), it ought to shut itself off completely and get no benefit from being associated with openness.
What they've done is insidious. They're open, they're the trusted custodians of open source, but ah ah not really. For a preem experience you gotta pay up, choob! They let you search for 15 years but now they don't. And here you are cheering them rather than questioning them.
What's next? The certificate transparency project requires sign-up and logins, it's just too expensive to let anonymous users see the transparency logs you see, and by some amazing co-incidence, everyone signed in @google.com sees no results for mis-issued GMail certificates?
I guess that is why Microsoft acquired them.
1. Effectively serves as a walled garden for copilot to make sure that competitors can't use their data (your code) in coding assistants, knowledge discovery, etc.
2. Ensure that competitors who are using github are maximally mineable so they can easily discover and implement their solutions to eat their lunch (much like OpenAI's strategy here)
This is covered up by the excuse of performance, but it's fundamentally no different than the loginwalls we saw go up around twitter and reddit
... except this time done by a big industry player who LARPs as part of the open source community but is positioned to cannibalize it from within.
IMO It's much less about the legacy code (there exist already terabyte size datasets that take in a lot of things on github) and MUCH more about how up-to-date your LLM/AI is with new repos, "best practices" (or most common practices), etc.
Plus you often get "LLM Code poisoning" from older training data as it attempts to use functionality which has experienced breaking changes versus the current stable release. Current is King.
Also there's the whole goldmine of github discussions, issues, etc that a repo just.. doesn't have.
Right now you can still easily index those (though iirc they sometimes ban datacenter IPs), but they may also fall victim to the loginwall.
For reference, about 99.5% of the search queries that goes toward my search engine is demonstrably bot traffic (excluding the traffic that goes to the free and public API endpoint I offer).
A capable search functionality isn't exactly cheap to run, so requiring a login is the obvious way to be able to rate limit searches, which is otherwise impossible against a botnet.