Hard to answer that as I lack your exact frame of reference.
Generally, employees of Mozilla Corp. are paid (and managed) to contribute to specific aspects of the Mozilla project. Sounds confusing, but essentially, imagine there is a new feature for Firefox browser's rendering code that needs implemented -- it's open source so technically anyone can submit a patch, but Mozilla-the-legal-entity may opt to hire and pay you to fix it (and many more after that).
You are then a professional software engineer working for someone who would like to reach a certain goal (such as: A new release of Firefox!) and gives you money to help them achieve it.
Edit: For disclosure, I should have mentioned that I work at Mozilla.
But the choice isn't by default. Users must go explicitly choose. If Mozilla wanted to "promote choice", they'd prompt the user to pick a search engine on first use. Or use a default and make noise about changing. Like how FF reminds you about your rights, or asks to join customer feedback program.
I don't see how Yahoo promotes choice over Google, unless by choice you mean promote competition by going against the market leader. Which is fine, and I dislike Google, so good on y'all. But I don't get the point if euphemisms.
Technically, a not-for-profit taxable subsidiary. (That makes a difference because the company purpose of Mozilla Corporation is still not to make money/raise shareholder value, despite the fact this it is fully taxable like any other company).
Isn't the purpose of Mozilla Corporation exactly to make money which inures to the benefit of its sole shareholder (Mozilla Foundation), making it just like any for-profit company except that it happens to be owned by a nonprofit?
There's a time and a place for both. The reasons frameworks (and so many of them) exist is because there are many problems you would otherwise have to solve over and over again, rather than focusing on the actual problems you app is supposed to solve.
However, that's not an excuse to avoid learning about the problems that frameworks and libraries solve, altogether.
recroom uses bower for package management at this point. Like many other parts of the picture, the "market" surrounding package management is in flux (there's also npm, for instance), so we'll monitor what's going on there. But for now, bower seems like a great choice for developers.
Also, it enables the modular aspect of recroom, that you can add/replace pieces you want, so package management is definitely vital.
You're right! recroom works well with WebIDE. You build your app and can then use WebIDE (and even the Ember Inspector Firefox add-on) to debug your app, for instance in the Firefox OS Simulator.
Future plans of ours include having recroom (and really, any toolchain; this is not a privilege we only want Mozilla projects to have) integrate even more smoothly with the WebIDE, with more direct integration points like "pre-push hooks".
That's actually where a large group of developers fall as well. You have the total beginners, who realistically won't build an app that has tests, or use a framework to sort out their models and views etc. They just need a HTML, CSS, JS file and some comments and can throw together something simple.
On the other end of the spectrum, you have the experts, who have evaluated a dozen frameworks of their own, know why they like gulp more than broccoli, and really just need an API reference to know what's possible, and off they go.
And in the middle of all this you have the huge group of developers who would really like to have some more help, even if only to help them make decisions of their own and eventually get them over the hump to expert-level. That's the group this is targeted at.
If you make a client-side app with it and figure out you don't like certain pieces of the toolbelt, you can replace them on the spot (they're loosely coupled). If at some point you're so advanced you want to replace it all, fantastic! You don't need our help anymore :)
Yes the whole space moves quickly. The current choice in tools in the recroom "tool belt" is not meant to be unchangeably set in stone. FWIW, Ember CLI is an interesting piece that would connect well to the core Ember framework as well.
Yeah you're right. The grunt piece is definitely one that is not set in stone. Ember-CLI is exciting and we've started working closely with the Ember folks to monitor it and see if and when this should become another piece of the recroom puzzle.