That's wrong. Every civic engineer I know, for example, would prefer standard, and lacking that, popular nuts, bolts, construction parts, materials etc, over niche ones, unless there's some very pressing reason not to. They are cheaper and available in greater volumes, you can find skilled workers easier, their properties are more studied, etc.
That's even more important in programming, where ecosystem, availability of libraries, continued support on the language and compiler, availability of skilled programmers, existing codebase support, etc, matter even more than pure language level issues.
Popularity in a language is crucial, to the point that other attributes, like expressiveness, or even speed, can be inconsequential compared to that.
And while engineering can be a pop culture (e.g. Mongo or the latest fad), popularity is important for aspects that are totally counter to pop culture too: namely, pragmatism.
Programming is not about using what's "best", it's about using "what's best given business constraints" (which is something else altogether).
Besides, the hipster figure who listens to obscure music because it's "best" is also a pop culture phenomenon -- not to dissimilar to certain programming cults.
We're already allergic to frameworks where I work and we're slowly moving away from libraries as well given how low quality the average open-source library is. Once you realize you spend more time debugging open-source libraries than your own codebase, you stop caring about popularity.
If you hire developers for what they know right now, of course you'll limit yourself to only the popular languages/frameworks. Its much more lucrative to hire developers for their potential to learn and grow; these people will make the best of any language/library/situation.
Of course, like you said, economics come into play but my point is that the popular choices often lead you to a path where you end up with a lot of mediocre developers, terrible architectures and endless conceptual debt. At the end of the day this is much, much more costly and doesn't even yield quality software.
See, the problem is, you still need to use frameworks and libraries, you just end up rolling your own, and now you are responsible for supporting and documenting all the different use cases your developers have. If I have an issue with, say, React.js, I can tap into the pool of the thousands of Stack Overflow questions and discussions, whereas I can't do that with a home-grown framework. Unless I'm doing something really low-level, I'll take the thing that has had thousands of man hours poured into it and an entire ecosystem built around it over the thing that you made because you're "allergic" to open source. You're going to be debugging someone else's code anyway, but the time spent doing that with open source frameworks is offset by the time saved because you don't have to build everything from scratch.
I won't have to write my own framework by not using one, while it may be easier to use one, its far simpler not to use any. You spend so much time trying to fit your use-cases into the framework's paradigm that its usually much faster to just write from scratch. Every single framework I've seen so far had huge scalability issues, they're easy to get started with but you end up crippling your agility as the codebase scales.
As for rolling our own libraries, we can make them specifically for the use-case at hand without anything extra. What's the point of using a few dozen libraries when you only use a fraction of each and now your bundle is megabytes in size? And that's not even counting all the extra code required to wire them all together. There's a reason why we say the web is bloated.
Also, isn't the alternative of debugging open-source libraries writing the functionalities you need yourself? Working with faulty open source library is tedious, but that work can be seen as way to contributing your time to make open source library better for everyone.
Most libraries out there will do a LOT of things I couldn't care less about, making them harder to integrate and debug and reason about, on top of bloating your executable.
I do agree there are a lot of amazing libraries out there and we do use a lot of them. But that's after analyzing them and figuring out they solve our problems and actually will save us time. For the vast majority of libraries we look at, its usually faster and better to roll our own.
"I don't get why people chase popularity in programming languages"
I am forced to do this simply because I consult at companies where the managers do exactly this. They will not let me use a language unless it is a top language. If I say "Clojure would be excellent for the project that you have in mind" they will reply "We can not use Clojure because it is not popular enough. We have to use a language where there is a large pool of developers that I can hire, and there is no risk that the language will disappear in 5 years."
I've seen companies of 300-500 employees struggle to keep even a single senior programmer over half a decade. They'd get far more talent by actually embracing an engineering culture. What I always see is that the juniors start getting experience, realize the place they work at is a huge pop culture and leave for an engineering one, thus lowering the talent pool of said company.
Basically they don't want smart engineers, they want replaceable code monkeys. They have yet to realize there's a few orders of magnitude worth of quality and productivity between the two.
I used to work in such an environment until I had enough of this cancer and decided to move to a small studio with less than 30 employees but with a very strong engineering culture.
I recall reading about someone (was it Spolsky? IDR) who looked for candidates with certain niche languages on their resumes, because it served as a quality signal. If they're interested in learning Clojure, for example, they may just be more generally curious and/or have a desire and interest in learning about different paradigms.
That said, at a practical level one has to balance competing demands. If you have someone on your team working on a project in X and they're the only X developer you have, you're at risk because if they leave, you may be screwed. Plus, they won't be getting quality feedback on their work because no one else can understand X.
And yeah, Spolsky did talk about the perils of Java schools here: http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool... Great article!
Having a single guy work in X can be bad indeed, but if you want to try something new its much safer than switching entire departments overnight.
According to Alan Kay, the whole computer industry is a pop culture.
https://news.ycombinator.com/item?id=4956430
http://queue.acm.org/detail.cfm?id=1039523
http://www.drdobbs.com/architecture-and-design/interview-wit...
Consider the corners in the graph off the line. E.g. - SQL: "nobody" is making voluntary github projects with it, but it generates a lot of questions (the legacy code quadrant). Alternately, there are fewer things below the line, but those would be the things that people are using, and NOT being regularly confounded by WTF they do :-)
If you trim out all the worthless SO questions/anwsers you'll get radically different rankings on redmonk. JavaScript could very easily drop from its first place doing just that.
I don't get why people chase popularity in programming languages. That's what you do in a pop culture, not in an engineering one.