Don't forget to look at industries where maybe there already exists large solutions or organizations, but aren't doing as much as can be done to help those that need it most. Education and Healthcare are a few of these. You might not make billions of dollars improving Kindergarten classes in North America, but you could "change" the world.
I wish there was more information about "where" they're going now. They imply that it's not Ember that's broken rather Ember isn't done and the problems are hard that Ember is trying to solve. So I'd ask - why not stay with Ember and help solve the hard problems? Or did you find another technology that "solved" it?
Those are both good questions. Currently, we're a team of two trying to maintain and evolve a production application. Believe me, we'd both love to have spent more time pushing the ball forward on Ember Data, but it just wasn't feasible. Besides, it's already on a maturation path that will resolve all of the issues before long - it just needs a little more time.
In the meantime, we're just keeping it simple and making magic with D3 and plain jQuery. We pushed all of the CRUD back to Rails, which is probably where it should have been in the first place.
Regardless, it was a great learning experience. I still highly recommend giving Ember a shot on something that's not on a tight deadline to get deployed to production.
Your day job is to build a piece of web software and you can’t take a few days to learn the ins and outs?
This is the opinion I had when all of the previous Ember flare ups happened. My thoughts were exactly this. It would behoove so many of us to simply spend more time with new technology and ideas before we simply throw our hands up and say "it confuses me".
You have a new-fangled thing for everyone to use. Scratch that, everyone who's been in your shoes, with your particular pains. Great, you solved a problem. Take some time to explain on your blog or in your GitHub README.md the context of your solution. "Because I can!" is a fine reason, but I don't spend time exploring something that was built because it was possible to build it.
So your new-fangled thing looks like it's a solution to a problem I'm having. I start to implement it and ... oh dear $DEITY, it's a mess. I don't mean it's ugly, I mean it's completely inextensible. It's a specific solution where a generic one would suffice. Or worse, you didn't think outside your little box to discover that this "fix" will debilitate 95% of the web servers on the planet if they were to try this solution.
My advice: if you build it, A) explain why, B) learn to build it well.
Fair. I'm only suggesting that before we collectively steam roll an open source project and its volunteers with "I don't get it, so it sucks" mobs, that maybe we spend a weekend with it. Maybe over that weekend we learn "oh dear $DEITY". And maybe, just maybe we contribute back to it in an effort to "help".