Where I work, there’s concern about ecosystem lock-in. Using Meteor feels like building a Meteor app, not a Node app that uses Meteor as its framework. We already use Vue as our frontend, so Meteor is really only supplying the data layer and build tool; I tell people that it’s more appropriate to say it’s a Vue/Node app as Meteor-specific code makes up < 10% of the app. But still, the perception persists.
I think Meteor is an excellent choice for companies building internal apps, and I suspect that that’s a large segment of its usage. There’s no concern about scaling (though I disagree with the folks who still argue that Meteor can’t scale) and speed of development is often much more important than limitless flexibility. What would make Meteor an easier sell where I work would be:
Finish the job of splitting out all of Meteor’s parts into NPM packages that can be used with or without the monolith. This was already started with accounts-js, I think the next biggest target is LiveQuery, possibly depending on Apollo (discussed here). Then I truly can say I’m building a Vue/Node app, just adding LiveQuery the same way today I could just add Apollo.
Decouple the data layer from the databases, and support multiple databases with reactivity. So just as the client-side has a primary framework (Blaze) but other supported frameworks (React, Angular, Vue), the data layer could have a primary database (Mongo) but other supported databases (MySQL via binlog tailing, as shown by vlasky:mysql; Redis via oplog tailing, as shown by cultofcoders:redis-oplog; Postgres via triggers/listeners/other magic as shown by tozd/node-reactive-postgres). Supporting SQL databases is important for enterprise customers not just because of the mindshare that SQL still commands but also because hosting SQL databases is cheap and maintenance-free via Amazon’s RDS (Relational Database Service). Amazon supports RDS-like Mongo 3.6 via a service they call DocumentDB, but it’s very expensive (at least $200/mo) and therefore inappropriate for internal apps with only a handful of users.
Both of these suggestions have been on the Meteor roadmap for years. SQL support has been on the to-do list since the earliest days of development, back when it was a Trello board. Moving away from Atmosphere into NPM has been in progress for the last few years but progress has slowed as resources have dwindled. But both efforts are still good ideas, and completing them would breathe new life into the framework by making Meteor an option for those who currently wouldn’t consider it, and by making Meteor (or parts of it) an option for adding onto an existing Node app.