Our initial goal in open sourcing the framework was to get some ideas out there and see what worked well and what didn't. We've learned a lot from this process, and we now have a much better idea of how to build a great system.
We are excited to see all of the innovation coming from Meteor, Firebase, and other new realtime systems. While there are similarities, our teams have different perspectives on what the future of web development looks like, and we believe there is still a great deal to be gained from further development of each of these platforms.
Currently, our changes to Racer will keep a similar API but make Derby apps much more stable and scalable to large production deployments.
(To me, their difference is about productivity vs. flexibility, although IMHO Rails eventually became just as flexible and "won". So it's interesting to see if Meteor achieves the same.)
Meteor, on the other hand, was extremely easy to get started with. The examples worked and the documentation was decent. Both Meteor and Derby.js are far from finished but to me Meteor seems like a much more polished product than Derby. I still hope both will live on because friendly competition is good and Derby has a niche.
Derby, on the other hand, was very buggy from the start and it took a while to get anything working. But once the app was running, it was easy to add anything supported by Node.js/NPM/Express to it. In my case, I added some server-side Express routes (REST APIs) and server-side background processing (game logic). At that time, these seemed difficult to do in Meteor.
During the past few months, Derby has proven occasionally unreliable and the documentation is sketchy (the query section, especially regarding security, is quite incomplete). But it has not been a dead-end. There's always some way to work around the problems, e.g. by using a "real" MongoDB connection to read some data on the server side when Derby's queries fail for some reason.