We've got a lot more stuff coming over the next few months, and if there are particular things you'd like us to do/prioritize, I'd love to hear about them!
We've got a lot more stuff coming over the next few months, and if there are particular things you'd like us to do/prioritize, I'd love to hear about them!
If I were to use Meteor for a partially closed source app earning around $1000 per month, how much could I expect to pay you? From the FAQ:
> If the GPL doesn't work for your project, get in touch (contact@meteor.com) and we will write you a commercial license to your specifications.
This is no way to answer such an important question that most potential users will have - let's face it, there's a lot of people who will want to use this for open source, but a lot more who will want to use this for commercial apps. To ensure Meteor's wide-spread acceptance, you need to clearly answer this question on FAQ page, and not with "we need to have a conversation".
Their preference is that the library be used under the GPL. That is their choice and it is a fair enough choice. But they also acknowledge that some entities can't accept that for one reason or another, and are willing to be flexible. Very flexible: instead of saying "this is our commercial license, deal with it" they have said "tell us what you need, and we'll see what we can do".
(To be clear, it's not that I begrudge the author's their right to license it how they want. I simply think frameworks like this are too central and important to have any uncertainty about licensing associated with them.)
You guys have done a great job at making a true reactive system that doesn't burden the developer with complex binding/event systems. I also like how you guys have avoided the persistent store impedance mismatch :-)
overall, i'm excited to try this out. great work.
Anyway, thanks much for the support :)
We got pretty comfortable with the commodities the Rails environment provides, so it's understandable some people would rather just add another layer (Backbone/Spine) and avoid the paradigm shift.
The advantages of attacking new problems with a new toolkit can sometimes appear less beneficial, because swapping out the current mega-stack for something slimmer inevitably leads to reduction in features (ie.: You end up making another `view` in place of a collection partial. Mailer, gems/middle-wares, etc..)
That said, despite getting pretty comfortable with Rails/Backbone|Spine, I'm in the pragmatic camp, looking forward to tackling a few side-projects with Meteor.