Presumably the only things that would show up would be things that have a known open source license. It'd be trivial to query based on compatible licenses (e.g. Apache license is compatible with everything, GPL needs to be in GPL code, BSD may need attribution, etc.) Github strongly encourages a license for new repositories, and hopefully most folks are including one if they want their code to be re-used.

I think you and I are picturing things differently. I'm imagining the entirety of the world's code in whatever language I'm working in as my "standard library". It's not "copy-paste coding" to use the standard library; it's using the tools that are available to get the job done effectively and quickly. The library is just much bigger. There needs to be a lot of additional meta-data to make this workable, which is why I said merely searching code isn't the full picture. We need to know how popular a function or library is (so we can choose the most "standard" one, if we don't have compelling reasons to choose a less often used one), we need to know if it's compatible with our versions of stuff, we need to know what its interfaces are, whether it's got good test coverage, what types or kinds of objects it works on or with, whatever. And, we need the machine to be able to weed out inappropriate options for us, and bubble the possible good matches up to the top.

This is stuff we already do every day in an ad hoc fashion. I recently wrote a few hundred lines of Ruby code for the first time in a decade; I had no idea coming into it which testing framework to use, what options parser to use, how to interact with the JSON encoder (it has some weird quirks for advanced use cases, and I needed to do some searching and reading), etc. I figured it all out, but it took a lot of reading code that wasn't really related to what I was doing, just to rule it out as not being relevant. And, I still don't know what popularity looks like for RSpec vs. test-unit, for example. There's a wide variety of metrics you can look at, but number of projects that actually use something would be cool to know.

Another example, I'm currently updating old Perl code to be more modern. It took quite a bit of searching and reading to figure out what to do with bareword file handles (because it's different for STDOUT/STDIN vs. for normal filehandles which can be have lexical scope, for example). If I'd been able to easily search for examples of code that used those idioms in those contexts, it would have been nicer.

I guess if you only work in one language, and you know the ecosystem very, very, well, such a thing might become less useful over time. But, it'd be wonderful for learning, I think.

"There seem to be few unexploited technological productivity "multipliers" which are not within, say, the range of 0 to 1.5. They keep being promised, but they either don't materialize in general practice, or they do not have the promised benefits in general practice."

I'm not sure I agree with you. I've been writing software off and on for most of my life. Rarely big projects, but rarely do I go more than a few months without building something of some sort. I was just thinking back on how much work it took when I started writing code (on a C64) vs. now. Likewise, every step along the way, I can look back and think, the amount of work (where work is not just the lines of code, but the amount of reading, the amount of experimentation, etc.) I would have had to do 5, 10, 15 years ago would have been much higher; and the bar to entry on some projects was so high I wouldn't have even started them, if it weren't my full-time job...now I can pick up and throw together a useful thing in a weekend that would have taken weeks or months without the APIs, the tooling, the resources like Stack Overflow and github, and the massive libraries of re-usable code. I think the force multipliers are all around us...and maybe accelerating in how rapidly they're coming (though staying aware of them gets harder every day because there's so much happening).

Yes, Internet was a huge force multplier all at once, probably the biggest single boost to all sorts of knowledge productivity; and, the Open Source community was another huge one, possibly bigger than the Internet in our particular industry, though requiring the Internet as a pre-requisite.

But, the library ecosystem for damned near every language is vast today. Perl's CPAN was the first truly huge plug-and-play software ecosystem I ever saw, but CPAN of a decade or two ago is a blip on the radar compared to something like npm today (or any other major language ecosystem). Even CPAN itself has grown remarkably with the times, and it would dwarf the CPAN of yesteryear (though it, too, is dwarfed by the likes of npm). I think the missing link is often discoverability.

There's a tremendous body of prior art out there, and we keep reinventing the wheel because we don't know about it, is what I'm trying to say.