Hey everyone! The four of us have been working very hard on this for the last six months, and we're excited to finally take the wraps off. Can't wait to hear what you think!
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!
Things seem to go in cycles in computing (and life in general). We had a solid model for developing single user applications, then we dropped that in favor of multi-user (web) applications. Now it's going full circle and we get the nice rapid development tools again. I wonder what the next cycle will look like.
Can you relax server side requirement a little bit ? Lots of people, including me, want to run such app on google app enigne which do not support node.js yet.
I think he was hopeful that the same benefits could be achieved with a different server-side runtime. It's a long-shot, but with good socket-sync and something like the client-side MongoDB adapter, Rails could come pretty close.
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.
I love everything about Meteor so far, except for this.
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".
A great many things are sold this way, and it is sometimes unavoidable. Commercial projects tend to have a wide range of requirements from a licensing point of view so if they spent time drawing up a full commercial license they would end up having to rearrange half or more of it for the first commercial client that came along anyway. They could spend time drawing up many license templates (world wide, X,000 users, X server, ...) and pricing plans with many combinations of support and development agreements to try cover the bases - or they could spend more time coding.
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".
Fair enough - if that's their choice, that's totally understandable. But my point is - if they wish to make it a wide-spread popular platform for web development, this is not the way to go about it. An MIT license like Rails would be a much better choice.
Ugh, I didn't even consider that a (partly) client side framework would have been GPL. Unless they come out with a very clear, simple and friendly commercial license it pretty much kills meteor for all practical purposes.
(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.)
great launch - most of the stuff that was out there just didn't do it for me. I've done lots of app development before and the new JS frameworks were pale in comparision.
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 :-)
Impressive! I was blown away by the fact that you don't need callbacks and events for the DB operations. Can't wait to dig in the code and see how you guys managed to make that work :)
"Currently the client is given full write access to the collection. They can execute arbitrary Mongo update commands. Once we build authentication, you will be able to limit the client's direct access to insert, update, and remove. We are also considering validators and other ORM-like functionality."
So just for toys for the moment. Still, very cool...
Right. But as soon as you have this ability, don't you quickly turn off insert/update? then you throttle/contain reads... So in the end, do we benefit from having a client side database connection? I'm struggling to put together a real-world use case for one that isn't irresponsible.
It seems like standard operating procedure for web apps has been to immediately throw out the user account system of whatever data store is being used and use one account with full CRUD access (or worse), with a (mediocre to disastrous) home-grown permissions system shoehorned into the controller layer.
That may be because of programmer laziness or because of some sort of inherent impedance mismatch between web-scale apps and the user account system of most DBMSes, but it seems like a bad way of doing things.
I think it's high time we had a web-scale data store that actually had decent per-user access control baked into it right at the model level, to the point where a sane person could trust it to live on the open internet. It seems both possible and desirable, but maybe I'm missing something.
Show me a 'web-scale' system that has a single data-store to secure in the first place. Something like much-better-Oracle-row-based-auth or whatever isn't gonna cut it.. cause who watches over Redis, or memcache, or the filesystem?
The filesystem is in pretty much the same situation as databases. Computers have supported multiple user accounts for decades, but every user of a web service typically runs as the same user(s) on the server.
I realize that there are huge scaling/throttling/DoS issues with, say, creating a new UNIX user every time someone signs up for your online meme generator, but that's mostly because UNIX wasn't really designed for millions of users on one box.
On the other hand, as an unprivileged user on a Linux box, you can't really do much damage beyond hogging resources and possibly spying on other people's poorly-secured files. If there's a bug and you do find a way to trash the system or escalate privilege, it's front-page news.
The problem right now is that every two-bit web app implements its own ad-hoc permissions system, often at the wrong layer of their stack. If it could be commoditized into a widely-used and widely-audited system, I think it would do a lot to improve security on the Internet.
(To open up a whole new unsupported argument, on some level the fact that one needs a key-value store, a filesystem, and a hand-optimized in-memory cache to build a reasonably fast web service smells like we're still making humans do a lot of things that a machine could do a much better job of.)
On the "read" side of things, you control what data is exposed to each subscription, and you'll be able to base access on authentication. The client doesn't get a direct database connection, but rather a live-updating subset (or arbitrary function, in the general case) of the database.
The rationale is that clients typically end up doing sorting and filtering on subsets of the database anyway, as they get more sophisticated and start caching data. For example, Gmail starts to need a notion of an email message on the client, to avoid going back to the server for the same message. When I worked on Google Wave I saw firsthand the complicated plumbing you need in order to do this in an ad hoc way. (They used GWT to share the model objects, but synchronized the data manually.)
You can also separate this facility from your database completely, and use it as a way of sending "data feeds" to clients; then use methods as RPCs.
This still doesn't sound like a straight forward answer. I think there is a justifiable cause for trying to minimize the role of the server but controlling the operating environment of the data itself is the essence of modern web security.
There would need to be some sort of public key system for authentication, but in the end you are still compromising your data if the client gets hacked. There would have to be a database control layer for the final say, and thats called a server.
Not sure if Mongo has this feature, but in many classic SQL databases, per-user views can be created which act like tables, but are actually "the user's view into that table".
This would mean creating database user accounts on the fly for people, but it would resolve this problem (as long as the views are secure).
insert/update/remove are actually just "newbie helper" shortcuts on top of the underlying latency-compensated RPC mechanism (which is documented under 'Meteor.methods'.)
Once the auth branch lands, you'll have two choices.
One options is, you can turn off the shortcuts entirely, and write a method for each scenario where the client would be allowed to write to the database. This gives you the same security model as a REST API.
Or, you can register an authorization-check hook with insert/update/remove, so you can vet each write and decide whether to allow it or reject it. This might work well with an ORM where you've marked some fields as writable, and some as protected.
The query-validation-only approach seems scary to me. It'd be like, in rails, relying exclusively on before_save callbacks for authorization. My gut says that would be error-prone in catastrophic way. Also, not all data is public.
I tend to agree with you -- I think the write-validation-only model is probably too error-prone to use directly. But you could have a layer on top of it that that lets you declare a schema for your records, and mark certain fields as writable by certain users (with reasonable defaults.) That would be much less error prone, but might be too cumbersome.
At this stage, we want to give people a choice and see what they do.
Reads are handled in a totally different. You explicitly define what data a given client is allowed to synchronize down to their local cache (by using Meteor.publish to define certain database queries that are available for client subscriptions.) The client can run whatever queries they want against their cache, but the only stuff there is the stuff you explicitly let them subscribe to, so it's OK.
Urm. Yeah. It scares the ba-jesus out of me. The first thought when I heard this "killer feature" was, 'well, there goes security out the window'.
Stupid hypnic jerk question perhaps, but, how's it deal with injection attacks ? is this left upto the javascript programmer to make sure strings are "safe" ? I almost dread the answers.
Shared scratch databases with no thought to security seem to be the hot new thing these days ;P. CloudMine, Firebase, Parse, StackMob... people seriously seem to think it is perfectly normal to throw their public /and/ private API keys into their projects... I mean, check out this tutorial from StackMob:
Parse makes an effort to get security right. You don't use your private API keys in the client. Instead, there is an access key specific to the mobile client, and its access is restricted in several ways.
Interesting (and smart) that they post to Hacker News a couple of days prior to the launch of Firebase (which provided the realtime functionality used by MMO Asteroids and has been active at hackathons.)
I love Firebase. We were in their preview and they were in ours. It would make a lot of sense to use Firebase as the realtime database layer behind a Meteor app. Maybe it could be as easy as "meteor add firebase" :)
Just watched the entire demo. First time I heard two people present a product together - definitely makes it a lot more interesting and much less monotonous. After the first 30seconds, I went "pfft, live reload isn't new." But I'm glad I stayed till the very end because it is indeed so much more. It looks very promising, especially if you offer app hosting of some kind (or make it easy on Heroku etc.)
I am curious about the security aspect of writing to DB directly via the client but I'm sure you've thought of it. I love the 'add less', 'add coffeescript' feature. Can't wait to try this out soon.
Yea, that was my first concern as well. Going around the typical models and straight to DB sounds dirty. :) Can't wait til I get home and try it out. Love the synchronous calls and how it synchronizes between screens, wonder how it scales up though.
Thanks for the feedback about the beginning of the demo. We had a really tough time with the site and the video because the people who are interested in frameworks like Meteor come from a lot of different backgrounds. Some people have written half a dozen Backbone applications and have written their own highly scalable node.js cache invalidation servers, while other people have suggested that we take the word "REST" off the homepage because it's confusing to new developers.
It's tough to find a pace that holds the attention of the experienced people while not losing the people that are new to web development.
Don't shy away from opportunity to teach. Just make sure you show it as a link, perhaps that means a simple popover explaining in simple terms what REST means.
Is there a built-in way to execute different code on the server, such as proprietary business logic, custom authentication, non-cross-domain APIs, etc?
Certainly! Take a look at Meteor.methods. That lets you define a method that the client can call without necessarily having the source. (If you give the client the source it will be able to do predictive latency compensation. But you don't have to. Or you can give the client a "stub" implementation that just inserts some placeholder records, while the server goes off and moves the forklifts around your warehouse over CORBA, or whatever.)
Just to hear it explicitly, does this library allow the client to call a server-side function without the end user ever seeing the source of the server-side function? That's my biggest concern, especially with the emphasis in the video on, "The client can access the DB!"
Lots of smart design choices. I have equivalent bits and pieces scattered all over the place that I've been meaning to put together to get the "wow" that this package delivers. Kudos for actually making it happen.
This looks extremely interesting, and reminds me a bit of Lunascript (http://asana.com/luna/). I'm very interested in who is paying for the development? I notice that there's no big tech company behind this and from the contact page I can see Meteor Development Group has an office in downtown San Francisco. So do you have any info on what the plan is regarding monetization?
Well, I am one of the Meteor devs, and I used to work at Asana :) Luna is an astonishing codebase, and Meteor is a small fraction of it in sophistication and functionality. But we think there's room for a lighter weight framework for the masses.
Monetization: We're still figuring that out. For now, we just want to see what people do with it. We think a lot about companies like redhat and mysql, and how they have been successful while building open ecosystems.
This feels to me a lot like how Rails felt back in 2005. A fundamental leap forward and an understanding of where web technology is going.
I haven't felt that way about Node.js or even its higher-level frameworks like Express or Batman. This feels like "The One", even though I've been absorbing the docs and screencasts only for the last 20 minutes.
Very true. I wasn't very explicit that I didn't mean they were the same thing, apples to apples. I meant "missing piece" in terms of the front-end tool to help me leap a level.
Backbone is almost at the top of the javascript toolkit levels. Let's put it in perspective:
- backbone
- jquery
- meteor <- the low level of the high level :)
You use meteor as a foundation to build your application as backbone is more or less your application itself. Think "CoreFoundation" vs "AppKit" kind of difference.
I somewhat disagree. I want to preface my post by saying I'm smiling ear to ear—I loved the screencast, and I look forward to using this tomorrow on a project I've been thinking about for a while.
Here's my concern: If I use Meteor as it is intended, and I also want a my application to have API, I'll have to re-implement all of my logic server-side[1]. This seems like a step back, unless I'm misreading things.
I'd love for the Meteor team to address this. Does Meteor make writing APIs easier?
[1]: I'm aware that much of the "client-side" code is executed server-side too, but that's due to Meteor's magically transparent client-side framework.
I'm not sure about Meteor, but you may want to look into SocketStream. Last time I checked they were very interested in making web APIs easier to develop.
Hey, one of the Meteor authors here. Meteor's architecture makes it super easy to make an API. It's one of the advantages of building your architecture around sending data around rather than HTML.
We couldn't go into everything in the video (it was already too long!), but the piece you're missing is Meteor.methods(). This lets you define methods, which are functions that the client can invoke on the server by calling Meteor.call(). If you choose to also ship the code for these methods to the client (it's optional) then you'll get full latency compensation like we talk about in the video. (This means that Meteor can latency-compensate arbitrarily complex functions, like "read this record, then add 2 to X if this field is false, else create a new record Y.")
In fact, every Meteor app already has an API :) Your Meteor client can connect to any other Meteor server by calling Meteor.connect(), and can then subscribe to any realtime datasets that that server is publishing, or invoke any methods available on that server. This is done with a protocol called DDP, but we could map DDP to REST fairly easily.
From talking to deberg (matt debergalis) on #meteor, ddp stands for distributed data protocol and in his words "is a combination of remote method invocation and attribute pub sub, tied together in a way that [allows] latency compensation on the client by simulating server methods"
> every Meteor app already has an API :) Your Meteor client can connect to any other Meteor server by calling Meteor.connect()
What about a non-Meteor client connecting to a Meteor server? Does that client have to understand DDP, or is that what you mean by "we could map DDP to REST" - there's no support for non-DDP clients now, but it's planned?
The latency compensation and Meteor.call() interface sound great, but what I understood by the GP's question about an API was "how can other clients besides mine talk to my app?".
From the docs:
"A Meteor application is a mix of JavaScript that runs inside a client web browser, JavaScript that runs on the Meteor server inside a Node.js container..."
I know. I meant that Node.js itself wasn't the fundamental leap that this is. And previous frameworks based on Node haven't attained "The One" status either.
Interested to see how they'll handle file uploads, authentication, etc. Especially authentication, seeing as clients have full access to the database right now.
Great. I'm sure realtime web frameworks will be the future of node.js and the entiry web itself. However, I do have some concerns. Opening my Databse via the web? Neeh, this is one thing not clear in the video.
P.S.: You should provide your cli via npm. Go and register the name before someone else do. (It's not taken currently http://search.npmjs.org/#/meteor)
Cool stuff! Really like the template handler that "notices" which attributes you're interested in and registers listeners for you. Is that implemented with a proxy "this?" or with actual Javascript parsing? gulp
Any reason the GitHub link isn't above the fold? That's the first thing I looked for...
I'd also be curious to know if any of the live reloading stuff was inspired by Brett Victor's "Inventing on Principle?" Something about tools that let you create "live" seems to be in the air.
Wasn't there a Backend-as-a-Service platform released recently for use with Backbone.js? Does anyone remember what that was? Seems like we're seeing a new wave of "front-end only" application frameworks coming out...
Seems to have a minor glitch with unicode characters? When you do Colors.remove() everything goes away, but the entries with unicode all come back? Somewhat strange...
Interesting tech, but db access from the client scares me to no end, call me a curmudgeon I guess.
Performance on that url also seems to be super slow right now with a lot of people hitting it. Curious to see how Meteor handles loads, it's really exciting stuff.
[[citation needed]]. From what I remember, the FSF is pretty consistent in saying that deriving from GPL code is derived work. If your linking constitutes a derivation (a common example would be a database handler that you adapt to your application after you've loaded it) then it is a derivation. If you just loosely call it, it is not.
It is possible for a piece of software to rely on the output of another piece of software without being derivative. Hell, that's basically how any interface in the world works.
As the wikipedia article on the GPL notes, the problem is not so much the GPL, but how derivative work is not that well pinned down in copyright law itself. That it appears ambiguous in the GPL is a result of that. My rule of thumb is to approach it from the angle of "what is the software worth if you take out what is linked?" - If the software can function without the linked code, it may not be derivative, but the actual question is whether it is useful without the linked code. Whether it carries out the tasks that the user needs the software for without the linked code.
To me, it's more of a social question of how much the linkee is indebted to the linked.
I think Meteor actually has the opposite problem: Running a web app is not generally considered to be distribution, so as long as you aren't actually giving the source code to anybody else, the requirements of the GPL don't apply to you. (IANAL, but this is my understanding.)
Wouldn't this only apply to the server side code of the app? If any proprietary code is also bundled and distributed client side by Meteor then I think the GPL provisions would apply.
Meteor runs on the client, not the server. If the server sends the code to the client so that the client can run it, the code is being distributed to the client. Better make sure that you have a link to the un-minified version of your site's JS if you minify it and use Meteor, and of course don't try to restrict your users from studying, copying, modifying, and redistributing your site's JS.
IANAL and my understanding of the GPL in a web context is at best fuzzy, but I still believe the following to be true:
The majority of application code is run on a user's browser. This means it is distributed (or conveyed) to the user. Thus, you have to offer every user of the app a possibility to obtain the unobfuscated source code.
But there is more: The GPL requires you to offer not only some JS files, but everything needed to run the application. This would include everything on the server-side as well.
Except that the nature of Meteor is that the source code is always being distributed out to the client. Meteor is quite a bit different from the usual web framework where all the code is run on the server.
Except that the nature of Meteor is that the source code is always being distributed out to the client. Meteor is quite a bit different from the usual web framework where all the code is run on the server.
It kills its usefulness for proprietary software, unless you're willing to pay the Meteor guys whatever they ask for a license. But I'd like to point out that there's actually a lot of software out there that isn't proprietary, and Meteor looks like a dramatically better way to write it.
Want to offer third-party oauth login ? - nope you can't.
Want to use like/tweet/+1 buttons ? - nope you can't.
GPL essentially means your website can't have anything on the client-side which is not GPL compatible. And from reading the Meteor guys website that's not what they intend, their choice of GPL was to ensure and changes to Meteor get contributed back and for that LGPL is a much better licence.
Meteor's own website violates the GPL licence of Meteor as it stands (assuming it contains code from any third-party contributor).
It's not quite that black-and-white. Why do you think OAuth is prevented, for example? You don't have to include JS code from Twitter in your page to enable OAuth logins to Twitter. Similarly, Facebook Like buttons run in a separate iframe; you can make a clear argument that they are a separate program from your site.
You're probably right about Google Analytics.
It may be true that they adopted the GPL without carefully thinking it over, or it could be a deliberate choice, as with GhostScript — whose commercial customers are mostly printer companies, who are willing to pay for a license so they don't have to send their printer firmware source code to all their buyers, which the GPL would require.
Sencha is another JS toolkit using the GPL to encourage people to buy licenses for proprietary use.
To quote the GPL faq "Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide."
Sure you can argue these things, but for most people it just won't be a risk worth taking (if you ever want to raise money using GPL client side code could cause a nightmare when it comes to due diligence) and they'll use another another framework instead.
GPL applies to code not content, the interaction between content and code gets very messy when it comes to GPL which was never really designed to handle content.
It's why it's now common place for GPL projects to licence the content part of their product under creative commons and the code under GPL.
If I use it in my project and after a while I want to charge for the service and I don't distribute all my code, am I in trouble? if yes, I forecast a slow and steady walk into the event horizon for this nice little thing.
It doesn't matter if you charge for the service or not. As soon as you allow someone to access your project, you have to make the source code available to them.
"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. We are happy to be flexible. What's important is that we have a conversation about how you are using Meteor, and what support and further development you need, so we can keep everyone in the community on the same page."
tl;dr I do not think that the GPL is suitable to build an open source community around a web framework.
With the current licensing it looks a lot like they are pondering a dual-licensing business: Offer a GPLed version for free and charge for commercial licenses.
Since the product seems to be very promising and since the GPL is not suited for many use-cases (web startups, freelance work for clients and even many inhouse developments), this might actually work.
Being a developer myself, I see nothing wrong with a bunch of other developers wanting to be paid for their work. If this is really how they want to play it, I wish them all the best. (If this really is the case, I find the current copy on their website a bit misleading, though).
On the other hand, if their goal is to establish a vibrant open source community around meteor, then I think they are on the wrong track.
To accomplish that you need to have a low barrier of entry for a) users of your product and b) contributors to your project.
The GPL, in the case of a web-framework that blurs the client-server divide, sets the bar quite high for both groups:
a) Other commenters seem to agree with me that every app developed with a GPL'ed meteor has to be put under GPL as well. The implications alone might drive some people away from using meteor, but even having to think about those things upfront can be discouraging. Some people do not like the GPL, some may not be able to work with it and some may simply want to be able to choose the license for their work themselves.
b) If they are offering a commercial license, it will not be easy for them to accept outside code contributions. They need to establish some legal documents (Contributor Agreements, maybe Copyright Assignments) and a process for accepting contributions. This makes it a lot harder to contribute than simply sending a pull request. They cite the MySQL business model as something they closely studied. MySQL has a particulary bad reputation for not accepting outside contributions. And this is mainly due to their dual-licensing model.
I strongly believe that Ruby on Rails became popular so quickly and still has an active community because of its liberal license (MIT).
Personally I am very excited about meteor and I wish that they reconsider using another license. It does not have to be MIT, even though that is what I would choose, but even LGPL would be better IMHO.
If they want this to be the next Django/Rails/Express/whatever, where a large and enthusiastic community both uses and develops the product then the answer is fairly clear: No, this is not a suitable license.
If their idea is that it's an nominally open source project where all control and most development takes place inside the originating company, and the community mostly just pays license fees then: Sure, it's a great license.
Longer clarification: Django is licensed under BSD, Rails and Express under MIT. Why? Because these licenses allow me to use these frameworks for my own webapps, without making the entire client/server code base available. I can toss together a Rails-based contacts manager, or a Django-based todo list app, and let people sign up, and even charge a monthly fee, and NOT have to give the code to the entire app out.
In short, as long as Meteor is under the GPL, I can use the framework for free, but I cannot let anyone use a webapp I create with it without giving away all the source code. Which means that I'm very unlikely to actually install and try Meteor on my next project. My choices are basically "ignore Meteor" and "pay a license fee to the devs". Meteor is awesome, and probably well worth the license fee (whatever it might be), but it's fairly obvious that this is a huge limitation on the frameworks potential for adoption.
(It's worth noting that both Django and Rails were actually developed for a project, and then released under permissive licenses, because the framework wasn't the product, and the dev teams didn't need to try and monetize it. Meteor is the product, and the dev team does need to monetize it. And, again, Meteor looks awesome! So I can fully understand why they chose GPL, and I fully support that choice! But it is worth noting the consequences of that.)
In the twenty-five or so years of the free-software movement, we've built the Internet and the World-Wide Web; made the Encyclopedia Britannica obsolete by producing something dramatically better; built history's most portable operating system, which now runs everything from most smartphones to most supercomputers, with contributions from hundreds of companies, including its biggest competitors, IBM and Microsoft.
But even after twenty-five years, there are still people who think they have to make a code base proprietary to make money on it.
I'm horrified.
What do you think will happen if you toss together a contacts manager or to-do list app and charge a monthly fee, and give out all the code, just as the Meteor devs have given out all their code to you? Maybe some of your users will decide to run the app on their own server and stop paying you. Or try to compete with you. But probably most of them will want to use the site operated by the app's primary developer. And all of your would-be competitors are just free R&D increasing the value of your site.
What's so terrible about making web apps that are free software?
Nothing. I've made several and made money on them. (Wikitravel, StatusNet). There are others who have done so, too -- WordPress.com being the classic. Probably the biggest place we're seeing this right now is in IaaS and PaaS efforts -- OpenStack, Nodester, CloudStack, OpenShift, CloudFoundry. Open Source all the way.
You seem confused. :) There's nothing at all wrong with making webapps that are, themselves, open source. It's actually a good thing!
But open source frameworks and languages that try and give developers the maximum freedom to make whatever they want see much higher adoption, uptake, mindshare, marketshare, engagement, developer excitement, community participation, user-submitted bug fixes, etc., etc., etc. than ones which don't.
Start listing popular frameworks - how many of those frameworks are GPL?
Off the top of my head, I would name: Sinatra, Rails, Django, Flask, Backbone, Batman, Knockout, Tir, CakePHP, Symfony, Spine, CherryPy, web.py, Pyramid, Zend, and Brubeck. Of those, every single one except Brubeck is licensed with BSD, MIT, or some variant - and Brubeckmight be too; I couldn't find license info.
There's nothing terrible about making web app that are free software...but the plain truth is, people don't make web apps that are free software with frameworks that require that. They go pick one of the popular frameworks, which all have permissive licenses. You can be horrified if you want. :)
In their FAQ, they mention wanting to keep the changes people make open for now, which is why they chose the GPL. If that's the case and they're not pursuing a dual license business strategy, I'd suggest that the Mozilla Public License 2.0 is a better choice. It's very explicit that the files that come in the distribution are the ones for which derivative works need to be under the same license.
If dual license is what they really want, I'm not particularly interested at this stage.
"The MPL has been approved as both a free software license (albeit one with a weak copyleft) by the Free Software Foundation and an open-source software license by the Open Source Initiative. The MPL allows covered source code to be mixed with other files under a different, even proprietary license. However, code files licensed under the MPL must remain under the MPL and freely available in source form. This makes the MPL a compromise between the MIT or BSD licenses, which permit all derived works to be relicensed as proprietary, and the GPL, which requires the whole of a derived work, even new components, to remain under the GPL. By allowing proprietary modules in derived projects while requiring core files to remain open source, the MPL is designed to motivate both businesses and the open-source community to help develop core software." - http://en.wikipedia.org/wiki/Mozilla_Public_License
The problem with licensing Meteor as GPL is that it creates a high level of uncertainty.
If I'm going to start a new hobby or side project, perhaps hoping that it'll get bigger someday, I still have no idea if, when or how it'll make money so it doesn't makes sense to contact Meteor to find out how much licensing is, but the doubt will always be there and as likely as not I'd just not use Meteor to avoid finding out too late that the commercial license terms are unacceptable for whatever I end up with.
There's also uncertainty about what exactly I can or can't do with a GPL licensed web framework. To some it's very clear that I'll only have to release my changes to the framework, to others it's very clear that I'd have to release the whole app as GPL. To me it's unclear either way and as long as that uncertainty exists it makes using it tough call.
If it's hard to justify doing a hobby project with those concerns, it'll be next to impossible to get buy-in on a new project at work. In fact, as cool as Meteor looks, and as much as I'd love to use it, I wouldn't even present it as an option.
I'd prefer pay for support or hosting or add-ons or whatever; as long as I know up-front what the costs are likely to be. I don't think a more liberal license will prevent the community from contributing back, Rails, Django, Node etc. being the obvious examples. I'd love to see Meteor take off and the devs obviously deserve to make money on it, but personally the GPL just feels like it's only huge downside to an otherwise very exciting project.
This isn't just a web framework where all the code is on the server, Meteor code is always distributed (to the browser) so I wonder if GPL is a complete non-starter. It doesn't matter if you want to charge or not, all of your modifications on the server side would seemingly need to be distributed back out.
I am to blame for that. Here is our thinking on it:
- Though it "feels wrong" (definitely with you there), is it really any different from downloading an installer package and running it?
- You can just go to install.meteor.com in your browser if you want to see what the script does (or just leave off the | sh), which is arguably better than other installation mechanisms.
Portability, robustness, flexibility and security.
There's little reason to spread out a package like meteor all over /usr/local. But many reasons against doing that.
To illustrate, a few simple questions:
What if I need multiple meteor versions on the same system (different versions for different users/projects)?
How do I quickly switch between different meteor versions (often needed in fast-moving projects like this)?
How do I monkey-patch meteor to try something out and/or contribute back?
What if I absolutely must mix meteor with an unsupported version of node or other runtime dependency?
What if all my servers are SuSE Solaris95 but you only provide packages for Debian and RedHat?
How do I bundle my meteor runtime with my deployment?
I am definitely not in favour of piping curl output to sh and giving root access.
I do prefer packages installed to /usr. You can easily solve the multiple-version-problem: Debian/Ubuntu has `alternatives`; Gentoo has `eselect` etc.
With these tools it is easy to "slot" packages (Gentoo terminology): /usr/bin/meteor would become a link to /usr/bin/meteor-0.1, /usr/bin/meteor-0.2 or whatever. And it is selected by the `alternatives`/`eselect` commands.
And how do you bundle your runtime? Just install the darn package!
If you are using SuSE Solaris95 and all your software is packaged for Debian or RedHat, then you should consider switching to a distribution that makes it easy to install third party software using the native package manager. If that means building a deb or rpm, then so be it; it's not that difficult.
I agree with all of this :) Meteor is self-contained and installing it in /usr/local is totally optional. The reason we install into /usr/local is that it is a way to get the 'meteor' command into the user's path without trying to edit their dotfiles for them, and without setting obscure system preferences that the user would have trouble unsetting. We went to a lot of trouble to make it easy to try Meteor, and we thought that "great, now go edit your dotfiles" would have lost a lot of people.
If you don't want it in /usr/local, you can check it out anywhere you like and just run the 'meteor' in the top directory of the checkout, and it'll work great. This is mentioned in the README/on Github, and it's how we have been developing Meteor. You can have as many copies of Meteor on your system as you like, and they can even coexist with a copy at /usr/local. So for me, I type '~/co/meteor' to run the meteor that I'm developing on, and 'meteor' by itself to run the latest official release.
You can either build the binary dependencies (node, etc) yourself by running an included script, or if you do not, the first time you run meteor it will automatically fetch a prebuilt binary kit for your convenience. All of the binary dependencies are kept in a directory in the checkout and managed by meteor, meaning that each meteor install on your system can have its own version of node.
Finally, to your last point, 'meteor bundle' does exactly that :P In fact, right now on our deploy servers, we have live apps running that were deployed with a variety of historical versions of meteor, all coexisting side by side.
I'm sure we'll have to revisit all of this as the Meteor ecosystem gets bigger and more complicated -- when all of the packages do not fit in a 'packages' directory, and when there are more binary dependencies than node and mongo. But I hope that this helps to persuade you that we're not totally nuts, despite how sleep deprived I was when we recorded that screencast.
If you thought this was a helpful answer, could you repost the question on Stack Overflow (with the 'meteor' tag), and drop me an email (address is in my HN profile?) That way I could repost this answer there in case it might be helpful to other people.
I agree with almost everything you say; you seem to have it right then, I just didn't go through github so I never saw the README.
However, I would still argue that you should get rid of the packages, that's extra-work you could better spend elsewhere. For someone installing a dev-toolkit it's absolutely not too much asked to paste "echo >>~/.bash_profile 'source ~/.meteor/magic.sh'".
They have to do that anyway as soon as they need the latest git-HEAD because of some bug in the release version (we know how it goes, don't we? ;-)).
So by giving them the right instructions right away you save them this extra step. And you save yourself from making a bad (and false!) first impression on the older and grumpier devs like myself.
I will admit that it's my preferred way to install things like this. I can look at it and see what will happen easily.
I will also admit to disagreeing with the poster suggesting that it should all go to ~/.meteor. I kind of hate that type of install... at least when I don't have an option. I don't want to install it multiple times for different users, and I don't like "system" software in my home directory, I like to keep my user data there and back it up more regularly that /usr/local which is all things I can reinstall in case of disaster.
Please provide an npm package! In addition to the security, uninstall and versioning problems mentioned by others, not every one runs Debian and Redhat. If you provide a node package, anyone who can install node can install meteor.
edit: Any by not every one, I mean me, running ArchLinux.
You're running a script that you've never seen on your machine with your user account. It's a dangerous habit at best. At worst you're exposed to poor code and man-in-the-middle attacks.
As someone else pointed out, it also makes versioning difficult.
It was a few years since I was "in" with the new things happening in the web-world.
But how did JavaScript come to be the new "cool" language? It got some horrible problems with object oriented stuff, some really strange bugs/features, and it's slow-ish.
I liked making cool stuff with JavaScript, but compared to something like ruby isn't this a step backwards?
I can see the advantages of this framework, but it still seems wonky.
Ubiquity is one reason. Ultimately, the "horrible problems" and "strange bugs" just turned out to be "unfamiliar differences." Also, newer JavaScript runtimes (V8) tend to smoke other dynamic languages in speed tests: http://shootout.alioth.debian.org/u32/which-programming-lang... – so it's not "slow-ish" so much as "really, really fast." ;)
I'll have to think of a use for this, but this definitely seems really interesting. I think working to make building web apps easier and faster is an awesome mission, so mad props to you guys, looking forward to see where this project goes.
349 comments
[ 133 ms ] story [ 355 ms ] threadWe'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 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.
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 :)
Does that freak anyone else out? Where are they doing permissions checking? Who can run what database commands under what circumstances?
"Currently the client is given full write access to the collection. They can execute arbitrary Mongo update commands. Once we build authentication, you will be able to limit the client's direct access to insert, update, and remove. We are also considering validators and other ORM-like functionality."
So just for toys for the moment. Still, very cool...
That may be because of programmer laziness or because of some sort of inherent impedance mismatch between web-scale apps and the user account system of most DBMSes, but it seems like a bad way of doing things.
I think it's high time we had a web-scale data store that actually had decent per-user access control baked into it right at the model level, to the point where a sane person could trust it to live on the open internet. It seems both possible and desirable, but maybe I'm missing something.
I realize that there are huge scaling/throttling/DoS issues with, say, creating a new UNIX user every time someone signs up for your online meme generator, but that's mostly because UNIX wasn't really designed for millions of users on one box.
On the other hand, as an unprivileged user on a Linux box, you can't really do much damage beyond hogging resources and possibly spying on other people's poorly-secured files. If there's a bug and you do find a way to trash the system or escalate privilege, it's front-page news.
The problem right now is that every two-bit web app implements its own ad-hoc permissions system, often at the wrong layer of their stack. If it could be commoditized into a widely-used and widely-audited system, I think it would do a lot to improve security on the Internet.
(To open up a whole new unsupported argument, on some level the fact that one needs a key-value store, a filesystem, and a hand-optimized in-memory cache to build a reasonably fast web service smells like we're still making humans do a lot of things that a machine could do a much better job of.)
The rationale is that clients typically end up doing sorting and filtering on subsets of the database anyway, as they get more sophisticated and start caching data. For example, Gmail starts to need a notion of an email message on the client, to avoid going back to the server for the same message. When I worked on Google Wave I saw firsthand the complicated plumbing you need in order to do this in an ad hoc way. (They used GWT to share the model objects, but synchronized the data manually.)
You can also separate this facility from your database completely, and use it as a way of sending "data feeds" to clients; then use methods as RPCs.
There would need to be some sort of public key system for authentication, but in the end you are still compromising your data if the client gets hacked. There would have to be a database control layer for the final say, and thats called a server.
This would mean creating database user accounts on the fly for people, but it would resolve this problem (as long as the views are secure).
Once the auth branch lands, you'll have two choices.
One options is, you can turn off the shortcuts entirely, and write a method for each scenario where the client would be allowed to write to the database. This gives you the same security model as a REST API.
Or, you can register an authorization-check hook with insert/update/remove, so you can vet each write and decide whether to allow it or reject it. This might work well with an ORM where you've marked some fields as writable, and some as protected.
At this stage, we want to give people a choice and see what they do.
Reads are handled in a totally different. You explicitly define what data a given client is allowed to synchronize down to their local cache (by using Meteor.publish to define certain database queries that are available for client subscriptions.) The client can run whatever queries they want against their cache, but the only stuff there is the stuff you explicitly let them subscribe to, so it's OK.
Stupid hypnic jerk question perhaps, but, how's it deal with injection attacks ? is this left upto the javascript programmer to make sure strings are "safe" ? I almost dread the answers.
https://stackmob.com/platform/help/tutorials/ios_sdk
See https://parse.com/docs/data#security for more details.
We know the Meteor guys well and are really excited about what they're building. It's very complementary.
We're both advocating a new paradigm in software development and the faster it comes the better.
I am curious about the security aspect of writing to DB directly via the client but I'm sure you've thought of it. I love the 'add less', 'add coffeescript' feature. Can't wait to try this out soon.
It's tough to find a pace that holds the attention of the experienced people while not losing the people that are new to web development.
Seriously though, Meteor looks incredible and I can't wait to mess around with it! Awesome work.
Monetization: We're still figuring that out. For now, we just want to see what people do with it. We think a lot about companies like redhat and mysql, and how they have been successful while building open ecosystems.
I haven't felt that way about Node.js or even its higher-level frameworks like Express or Batman. This feels like "The One", even though I've been absorbing the docs and screencasts only for the last 20 minutes.
Edit: to clarify I specifically meant a front-end tool to help me leap a level in personal development skill.
I am using backbone for a while and it's backend agnostic which is great !
This one have more resemblance to knockout.js( I am talking client side) and it's MVVM design, backbone doesn't even try to approach that problem.
- backbone - jquery - meteor <- the low level of the high level :)
You use meteor as a foundation to build your application as backbone is more or less your application itself. Think "CoreFoundation" vs "AppKit" kind of difference.
Here's my concern: If I use Meteor as it is intended, and I also want a my application to have API, I'll have to re-implement all of my logic server-side[1]. This seems like a step back, unless I'm misreading things.
I'd love for the Meteor team to address this. Does Meteor make writing APIs easier?
[1]: I'm aware that much of the "client-side" code is executed server-side too, but that's due to Meteor's magically transparent client-side framework.
We couldn't go into everything in the video (it was already too long!), but the piece you're missing is Meteor.methods(). This lets you define methods, which are functions that the client can invoke on the server by calling Meteor.call(). If you choose to also ship the code for these methods to the client (it's optional) then you'll get full latency compensation like we talk about in the video. (This means that Meteor can latency-compensate arbitrarily complex functions, like "read this record, then add 2 to X if this field is false, else create a new record Y.")
In fact, every Meteor app already has an API :) Your Meteor client can connect to any other Meteor server by calling Meteor.connect(), and can then subscribe to any realtime datasets that that server is publishing, or invoke any methods available on that server. This is done with a protocol called DDP, but we could map DDP to REST fairly easily.
What about a non-Meteor client connecting to a Meteor server? Does that client have to understand DDP, or is that what you mean by "we could map DDP to REST" - there's no support for non-DDP clients now, but it's planned?
The latency compensation and Meteor.call() interface sound great, but what I understood by the GP's question about an API was "how can other clients besides mine talk to my app?".
now downvote me.
From the docs: "A Meteor application is a mix of JavaScript that runs inside a client web browser, JavaScript that runs on the Meteor server inside a Node.js container..."
Node.js is very low level and is more analogous to Ruby than Rails.
P.S.: You should provide your cli via npm. Go and register the name before someone else do. (It's not taken currently http://search.npmjs.org/#/meteor)
Any reason the GitHub link isn't above the fold? That's the first thing I looked for...
I'd also be curious to know if any of the live reloading stuff was inspired by Brett Victor's "Inventing on Principle?" Something about tools that let you create "live" seems to be in the air.
EDIT: oh yeah, Backlift! (http://www.backlift.com) This is definitely an interesting trend.
Seems to have a minor glitch with unicode characters? When you do Colors.remove() everything goes away, but the entries with unicode all come back? Somewhat strange...
Interesting tech, but db access from the client scares me to no end, call me a curmudgeon I guess.
On a related note, they took it down now.
You appear to be confusing GPL with the "GPL With Linking Exception" https://en.wikipedia.org/wiki/GPL_linking_exception
As the wikipedia article on the GPL notes, the problem is not so much the GPL, but how derivative work is not that well pinned down in copyright law itself. That it appears ambiguous in the GPL is a result of that. My rule of thumb is to approach it from the angle of "what is the software worth if you take out what is linked?" - If the software can function without the linked code, it may not be derivative, but the actual question is whether it is useful without the linked code. Whether it carries out the tasks that the user needs the software for without the linked code.
To me, it's more of a social question of how much the linkee is indebted to the linked.
So no, I don't think I am confusing the two.
https://en.wikipedia.org/wiki/GNU_General_Public_License#Lin...
https://en.wikipedia.org/wiki/GNU_General_Public_License#Com...
The majority of application code is run on a user's browser. This means it is distributed (or conveyed) to the user. Thus, you have to offer every user of the app a possibility to obtain the unobfuscated source code.
But there is more: The GPL requires you to offer not only some JS files, but everything needed to run the application. This would include everything on the server-side as well.
Sencha's take on this might also be interesting in this context: http://www.sencha.com/legal/open-source-faq/
They have been using a GPL dual-licensing model for their products for quite some time now and I suspect they consulted more than one lawyer.
It pretty much kills the usefulness of this project.
Want to use google analytics ? - nope you can't.
Want to offer third-party oauth login ? - nope you can't.
Want to use like/tweet/+1 buttons ? - nope you can't.
GPL essentially means your website can't have anything on the client-side which is not GPL compatible. And from reading the Meteor guys website that's not what they intend, their choice of GPL was to ensure and changes to Meteor get contributed back and for that LGPL is a much better licence.
Meteor's own website violates the GPL licence of Meteor as it stands (assuming it contains code from any third-party contributor).
You're probably right about Google Analytics.
It may be true that they adopted the GPL without carefully thinking it over, or it could be a deliberate choice, as with GhostScript — whose commercial customers are mostly printer companies, who are willing to pay for a license so they don't have to send their printer firmware source code to all their buyers, which the GPL would require.
Sencha is another JS toolkit using the GPL to encourage people to buy licenses for proprietary use.
Sure you can argue these things, but for most people it just won't be a risk worth taking (if you ever want to raise money using GPL client side code could cause a nightmare when it comes to due diligence) and they'll use another another framework instead.
That's a fairly insane contention. The GPL license document itself would violate that.
> Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
It's why it's now common place for GPL projects to licence the content part of their product under creative commons and the code under GPL.
If I use it in my project and after a while I want to charge for the service and I don't distribute all my code, am I in trouble? if yes, I forecast a slow and steady walk into the event horizon for this nice little thing.
http://meteor.com/faq/how-is-meteor-licensed
With the current licensing it looks a lot like they are pondering a dual-licensing business: Offer a GPLed version for free and charge for commercial licenses.
Since the product seems to be very promising and since the GPL is not suited for many use-cases (web startups, freelance work for clients and even many inhouse developments), this might actually work.
Being a developer myself, I see nothing wrong with a bunch of other developers wanting to be paid for their work. If this is really how they want to play it, I wish them all the best. (If this really is the case, I find the current copy on their website a bit misleading, though).
On the other hand, if their goal is to establish a vibrant open source community around meteor, then I think they are on the wrong track.
To accomplish that you need to have a low barrier of entry for a) users of your product and b) contributors to your project.
The GPL, in the case of a web-framework that blurs the client-server divide, sets the bar quite high for both groups:
a) Other commenters seem to agree with me that every app developed with a GPL'ed meteor has to be put under GPL as well. The implications alone might drive some people away from using meteor, but even having to think about those things upfront can be discouraging. Some people do not like the GPL, some may not be able to work with it and some may simply want to be able to choose the license for their work themselves.
b) If they are offering a commercial license, it will not be easy for them to accept outside code contributions. They need to establish some legal documents (Contributor Agreements, maybe Copyright Assignments) and a process for accepting contributions. This makes it a lot harder to contribute than simply sending a pull request. They cite the MySQL business model as something they closely studied. MySQL has a particulary bad reputation for not accepting outside contributions. And this is mainly due to their dual-licensing model.
I strongly believe that Ruby on Rails became popular so quickly and still has an active community because of its liberal license (MIT).
Personally I am very excited about meteor and I wish that they reconsider using another license. It does not have to be MIT, even though that is what I would choose, but even LGPL would be better IMHO.
If they want this to be the next Django/Rails/Express/whatever, where a large and enthusiastic community both uses and develops the product then the answer is fairly clear: No, this is not a suitable license.
If their idea is that it's an nominally open source project where all control and most development takes place inside the originating company, and the community mostly just pays license fees then: Sure, it's a great license.
Longer clarification: Django is licensed under BSD, Rails and Express under MIT. Why? Because these licenses allow me to use these frameworks for my own webapps, without making the entire client/server code base available. I can toss together a Rails-based contacts manager, or a Django-based todo list app, and let people sign up, and even charge a monthly fee, and NOT have to give the code to the entire app out.
Someone else linked to Sencha's discussion of the GPL and JS webapps, and it's highly relevant: http://www.sencha.com/legal/open-source-faq/
In short, as long as Meteor is under the GPL, I can use the framework for free, but I cannot let anyone use a webapp I create with it without giving away all the source code. Which means that I'm very unlikely to actually install and try Meteor on my next project. My choices are basically "ignore Meteor" and "pay a license fee to the devs". Meteor is awesome, and probably well worth the license fee (whatever it might be), but it's fairly obvious that this is a huge limitation on the frameworks potential for adoption.
(It's worth noting that both Django and Rails were actually developed for a project, and then released under permissive licenses, because the framework wasn't the product, and the dev teams didn't need to try and monetize it. Meteor is the product, and the dev team does need to monetize it. And, again, Meteor looks awesome! So I can fully understand why they chose GPL, and I fully support that choice! But it is worth noting the consequences of that.)
But even after twenty-five years, there are still people who think they have to make a code base proprietary to make money on it.
I'm horrified.
What do you think will happen if you toss together a contacts manager or to-do list app and charge a monthly fee, and give out all the code, just as the Meteor devs have given out all their code to you? Maybe some of your users will decide to run the app on their own server and stop paying you. Or try to compete with you. But probably most of them will want to use the site operated by the app's primary developer. And all of your would-be competitors are just free R&D increasing the value of your site.
What's so terrible about making web apps that are free software?
But open source frameworks and languages that try and give developers the maximum freedom to make whatever they want see much higher adoption, uptake, mindshare, marketshare, engagement, developer excitement, community participation, user-submitted bug fixes, etc., etc., etc. than ones which don't.
Start listing popular frameworks - how many of those frameworks are GPL?
Off the top of my head, I would name: Sinatra, Rails, Django, Flask, Backbone, Batman, Knockout, Tir, CakePHP, Symfony, Spine, CherryPy, web.py, Pyramid, Zend, and Brubeck. Of those, every single one except Brubeck is licensed with BSD, MIT, or some variant - and Brubeckmight be too; I couldn't find license info.
There's nothing terrible about making web app that are free software...but the plain truth is, people don't make web apps that are free software with frameworks that require that. They go pick one of the popular frameworks, which all have permissive licenses. You can be horrified if you want. :)
If dual license is what they really want, I'm not particularly interested at this stage.
"The MPL has been approved as both a free software license (albeit one with a weak copyleft) by the Free Software Foundation and an open-source software license by the Open Source Initiative. The MPL allows covered source code to be mixed with other files under a different, even proprietary license. However, code files licensed under the MPL must remain under the MPL and freely available in source form. This makes the MPL a compromise between the MIT or BSD licenses, which permit all derived works to be relicensed as proprietary, and the GPL, which requires the whole of a derived work, even new components, to remain under the GPL. By allowing proprietary modules in derived projects while requiring core files to remain open source, the MPL is designed to motivate both businesses and the open-source community to help develop core software." - http://en.wikipedia.org/wiki/Mozilla_Public_License
If I'm going to start a new hobby or side project, perhaps hoping that it'll get bigger someday, I still have no idea if, when or how it'll make money so it doesn't makes sense to contact Meteor to find out how much licensing is, but the doubt will always be there and as likely as not I'd just not use Meteor to avoid finding out too late that the commercial license terms are unacceptable for whatever I end up with.
There's also uncertainty about what exactly I can or can't do with a GPL licensed web framework. To some it's very clear that I'll only have to release my changes to the framework, to others it's very clear that I'd have to release the whole app as GPL. To me it's unclear either way and as long as that uncertainty exists it makes using it tough call.
If it's hard to justify doing a hobby project with those concerns, it'll be next to impossible to get buy-in on a new project at work. In fact, as cool as Meteor looks, and as much as I'd love to use it, I wouldn't even present it as an option.
I'd prefer pay for support or hosting or add-ons or whatever; as long as I know up-front what the costs are likely to be. I don't think a more liberal license will prevent the community from contributing back, Rails, Django, Node etc. being the obvious examples. I'd love to see Meteor take off and the devs obviously deserve to make money on it, but personally the GPL just feels like it's only huge downside to an otherwise very exciting project.
- Though it "feels wrong" (definitely with you there), is it really any different from downloading an installer package and running it?
- You can just go to install.meteor.com in your browser if you want to see what the script does (or just leave off the | sh), which is arguably better than other installation mechanisms.
Curious to hear people's thoughts :)
Do. Not. Require. Root. Not optionally, not sometimes, not "maybe". NEVER.
Your universe is ~/.meteor. Do not even think about touching anything outside that. It's taboo.
You clearly know what you're doing otherwise, so please get this one right from the start and save yourselves a lot of headache later on (cf. npm).
Install to ~/.meteor and provide the user with a small snippet to paste to their ~/.bash_profile ("source ~/.meteor/magic.sh").
I'm sure you have good reasons, I just can't see them here.
To illustrate, a few simple questions:
What if I need multiple meteor versions on the same system (different versions for different users/projects)?
How do I quickly switch between different meteor versions (often needed in fast-moving projects like this)?
How do I monkey-patch meteor to try something out and/or contribute back?
What if I absolutely must mix meteor with an unsupported version of node or other runtime dependency?
What if all my servers are SuSE Solaris95 but you only provide packages for Debian and RedHat?
How do I bundle my meteor runtime with my deployment?
I do prefer packages installed to /usr. You can easily solve the multiple-version-problem: Debian/Ubuntu has `alternatives`; Gentoo has `eselect` etc.
With these tools it is easy to "slot" packages (Gentoo terminology): /usr/bin/meteor would become a link to /usr/bin/meteor-0.1, /usr/bin/meteor-0.2 or whatever. And it is selected by the `alternatives`/`eselect` commands.
And how do you bundle your runtime? Just install the darn package!
If you are using SuSE Solaris95 and all your software is packaged for Debian or RedHat, then you should consider switching to a distribution that makes it easy to install third party software using the native package manager. If that means building a deb or rpm, then so be it; it's not that difficult.
If you don't want it in /usr/local, you can check it out anywhere you like and just run the 'meteor' in the top directory of the checkout, and it'll work great. This is mentioned in the README/on Github, and it's how we have been developing Meteor. You can have as many copies of Meteor on your system as you like, and they can even coexist with a copy at /usr/local. So for me, I type '~/co/meteor' to run the meteor that I'm developing on, and 'meteor' by itself to run the latest official release.
You can either build the binary dependencies (node, etc) yourself by running an included script, or if you do not, the first time you run meteor it will automatically fetch a prebuilt binary kit for your convenience. All of the binary dependencies are kept in a directory in the checkout and managed by meteor, meaning that each meteor install on your system can have its own version of node.
Finally, to your last point, 'meteor bundle' does exactly that :P In fact, right now on our deploy servers, we have live apps running that were deployed with a variety of historical versions of meteor, all coexisting side by side.
I'm sure we'll have to revisit all of this as the Meteor ecosystem gets bigger and more complicated -- when all of the packages do not fit in a 'packages' directory, and when there are more binary dependencies than node and mongo. But I hope that this helps to persuade you that we're not totally nuts, despite how sleep deprived I was when we recorded that screencast.
If you thought this was a helpful answer, could you repost the question on Stack Overflow (with the 'meteor' tag), and drop me an email (address is in my HN profile?) That way I could repost this answer there in case it might be helpful to other people.
I agree with almost everything you say; you seem to have it right then, I just didn't go through github so I never saw the README.
However, I would still argue that you should get rid of the packages, that's extra-work you could better spend elsewhere. For someone installing a dev-toolkit it's absolutely not too much asked to paste "echo >>~/.bash_profile 'source ~/.meteor/magic.sh'".
They have to do that anyway as soon as they need the latest git-HEAD because of some bug in the release version (we know how it goes, don't we? ;-)).
So by giving them the right instructions right away you save them this extra step. And you save yourself from making a bad (and false!) first impression on the older and grumpier devs like myself.
I will also admit to disagreeing with the poster suggesting that it should all go to ~/.meteor. I kind of hate that type of install... at least when I don't have an option. I don't want to install it multiple times for different users, and I don't like "system" software in my home directory, I like to keep my user data there and back it up more regularly that /usr/local which is all things I can reinstall in case of disaster.
I guess the ideal would be to ask the user.
Comment...
This probably needs to check it $PARENT/bin is actually in the path, and maybe tell the user that they'll need to add it.edit: Any by not every one, I mean me, running ArchLinux.
npm is out of my scope (in fact, even arch is)
https://github.com/sstephenson/gosh
As someone else pointed out, it also makes versioning difficult.
But how did JavaScript come to be the new "cool" language? It got some horrible problems with object oriented stuff, some really strange bugs/features, and it's slow-ish.
I liked making cool stuff with JavaScript, but compared to something like ruby isn't this a step backwards?
I can see the advantages of this framework, but it still seems wonky.
Not compared to Ruby. ;)
>I liked making cool stuff with JavaScript, but compared to something like ruby isn't this a step backwards?
http://fingernailsinoatmeal.com/post/292301859/metaprogrammi...