This is kind of what I was thinking. Most of these sound useful, but they also sound like situations where the primary end goal was a paper, not a polished, wid

This is kind of what I was thinking. Most of these sound useful, but they also sound like situations where the primary end goal was a paper, not a polished, widely usable software product. The practical realities of what it takes for enterprise devs to adopt tools at a large-enough scale to make the tool sustainable are just too much for a single academic paper to overcome. In particular, these sort of tools feel too specialized to really catch on as a FOSS community project. For developers with limited free to time to 'volunteer,' they usually want to spend that time making "primary" contributions -- the actual systems and end-products -- rather than secondary contributions in the form of tooling. Hence we see the tools that survive are tools that we first recognize as products, even if they're free. VS Code is a good example, I think. Or, if they're not free, they're paid for (e.g. Jetbrains), and the money makes maintaining/developing the tool sustainable. Not to wax too poetic but it has the feel of academia trying to start a fire with a flint and not understanding that they have to properly construct the rest of the firestarting kit -- clear space, get kindling, arrange the rest of the wood, make sure it's all dry. They just see the sparks coming off the stone and keep asking "Why isn't this fire starting?" Let me put it this way. Instead of saying, "Wow, this tool had promise, but it didn't catch on because (??) and because it didn't catch on it hasn't been maintained," the observation should be more like, "Hmm, maybe if this tool had been properly maintained it would have caught on by now."