Thank you for asking! That depends on the role - some of them have specific subject matter requirements listed in the job descriptions (for instance a deep knowledge of computational geometry), though not all.
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.
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).
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.
They can also lean towards rejecting almost any challenge entered by a system like this one. Conveniently, where I live, if you enter your argument by mail you are waiving your right to a trial, and they won't even reply to you unless you win (in which case you get some money back and it's obvious you won).
You are technically right but you're missing one thing: The parking authority here has an easy time to prove that you've ostensibly parked against the rules. Say, if the curb paint was faded, all they have to show is a map showing where you parked and how that's a special area. Done.
Suddenly it's up to you as the defendant to prove that that wasn't the case.
Outside of completely bogus tickets, proving that they were technically allowed to write the ticket is a trivial affair for the authorities.
I think you are on the right path: If you're making an app exclusively for Firefox OS, wrapping it in Cordova is not the path I would take.
However, if you're also planning on submitting it to the iOS app store, then making a Cordova app is useful.
Similarly, if you already have a Cordova app that you submitted to iOS and Android's stores, then you are now able to turn it also into a Firefox OS app fairly easily without having to fork your entire project.
S3 is actually not that cheap. I have well over 100 GB of data to back up (and that's not even a full backup by any means, just the stuff I don't want to lose and can't get back by redownloading and reinstalling things), which racks up a significant bill on S3. CrashPlan isn't cheap either but the cheapest ones of the bunch, so I use them instead. Actually getting the data back in the case of disaster would take a while but I could certainly restore the most important things first, then backfill the rest as I go.