When Meteor first launched, I was one of the very very many people who said that Meteor looked amazing, but was afraid that their license would hamper adoption.
With the change in license, I think the only major hurdle has been removed. The fundamental idea is good, their current execution is extremely slick, and their immediate plans[1] look achievable. I have very high hopes for the project.
[1]: I originally said roadmap; as mcrider rightly points out Meteor does not have one. There is some info floating around about current development goals (notably related to adding authentication), which is what I was thinking of.
Edit: I figured that's what you meant, I was just curious if you had seen an official roadmap. I guess they are too fresh to have one and are waiting for more community input before formalizing their goals -- Which is fine by me.
Unless you plan to modify Meteor, ship your version and not share your changes, there are very few things you can do to violate the GPL by using Meteor.
Meteor is neither a library nor boilerplate code to add upon. Lots of folks seem to be "hating" on GPL for no good reason, except maybe not knowing it (which is a good reason but it's hardly justifiable at this point).
If you use a GPL library all of your code has to be released under a GPL compatible licence. The Meteor framework counts as a library due to the way it interacts with your code.
You might be confusing it with the Lesser GPL which allows library code to be incorporated into propriety software (or websites in this case).
The way Meteor works is that the client side framework is bundled with your code and pushed to the browser of the end user, it's this pushing of the merged framework + your code that counts as distribution under the GPL.
The code isn't just run server side.
Also you should read the following sections of the GPL faq which should help clarify your understanding of the issues:
What I don't understand well yet is the way Meteor works. I'm waiting until they (and firebase) make their final version available, although I've played a bit with them.
If it does bundle itself then it could have implications. Maybe LGPL would be more reasonable then.
Some products offered under GPL license require you to publish your code if you use it as a library.(ExtJs was one example of this) So MIT license for Meteor will help wider adoption.
Why would you want to ship Meteor as a library? Even if you do ship it, if you don't link to it (which I don't even think you will reasonably can) you wouldn't violate GPL.
I feel it is sad that so few HN hackers seem to appreciate the vision of the GPL. GPL needs more indispensable software like this for it to thrive and protect us all from a future of completely locked down computers.
From a user perspective, GPL offers in theory more freedom, since new products built on codebase X will also be free.
It is debatable if this is true in practice. If less software gets built as a result of the license restriction, the GPL takes away freedom. Even closed source software adds some freedom - the freedom of choice.
From a developer perspective, there is no question which one is more free. We often do not have the choice to release our software as open source, and when we do, an invasive license like the GPL is still a headache. If I can pick up a library or framework and just use it, that's the one I will pick.
"GPL takes away freedom" is a very developer-centric point of view. From user point of view GPL gives freedoms that MIT/BSD don't give.
Where freedoms of developers and users conflict, GPL sides with users.
In other words, GPL only takes away your freedom to take freedom away from others. If you don't intend to restrict others' freedoms, GPL shouldn't get in your way.
The GPL actually trades off freedom over time. Specifically, it trades away actual freedom right now for the person who currently has a copy of the code, in an attempt to secure potential freedom later for people who do not yet but might someday have copies of the code or of code derived from it.
As such, the GPL is always, in the "now", a license which grants less freedom than, say, the BSD or MIT licenses. Most objections to the GPL, including my own, come from a position of cost/benefit on the trade it wants to make, and of disagreeing that that trade is worth making.
I agree with your first paragraph, but come to different conclusions.
The way I see it GPL values freedom over short-term gains.
You can put BSD software in the AppStore, which is nice short term, but long-term that's helping platform that is a golden cage.
Wouldn't it be nice if Android was GPL v3? Instead of giving operators freedom to lock down handsets and add uninstallable crapware, give users freedom to customize and upgrade their phones. Of course, GPL-Android could have hard time gaining traction in the market because of GPL being unappealing to crapware-installing operators, but if it did succeed, that would be significant long-term win for users' freedom.
Specifically, it trades away actual freedom right now for the person who currently has a copy of the code...
How so? As far as I know, if I have GPL code, I can do whatever I want with it. Could you tell me any action I might want to take that the GPL prevents?
The only "freedom" the GPL removes is the freedom to restrict the actions of others. To me, that seems like a rather odd sort of freedom.
The GPL doesn't prevent you from linking to BSD software.
All it does is prevents you from redistributing the resulting binary under a license that could result in the user's freedom being restricted. I.e., the only thing that is prevented is (BSD, GPL) -> BSD, since the next step might be BSD -> Proprietary.
Right. I want to give others the freedom to use my software in propietary ways, so I put my software under a BSD license. This means I can't use GPL-licensed libraries.
The freedom potentially lost to users due to Meteor going with a non-GPL open source license is that somebody could fork it and make a better version that eventually becomes dominant but restricts the user by {charging money, only working in a subset of environments, not being updated to work with other web languages, or just lacking a desired feature}.
Edit: I'm personally glad they went with the MIT license. Also, even if a fork takes place, the original code is still available.
jQuery changed the face of client side development, and its MIT license has encouraged significant and substantial corporate participation, but I have never even heard of a jquery fork. They actually have MS offering paid support for their library.
Rails changed the face of server side programming, and its MIT license has only increased corporate participation. Where is the rails fork?
Node.js changed the face of the app server landscape and is probably the latest big thing in web development. MIT license, where are the forks?
It is definitely a theoretical possibility, but it just doesn't seem to ever happen in this world. What does happen is you gain the ability to have companies throw money/manpower behind your project that they would otherwise have spent building a competing product that they could actually use.
> I'm personally glad they went with the MIT license. Also, even if a fork takes place, the original code is still available.
I think this is a point many fail to consider. BSD and GPL are, in many ways, synergistic. Having libraries available in both is the best ecosystem for both devs and end-users, IMO.
I would say there is a question from a developer perspective. The idea that more choice is better and makes one more free is a cultural one and not an objective fact. There is a point where one has too many choices and they become a real encumbrance. I think Barry Schwarz has done a good job of describing this phenomenon.
I think Vasco is also brings up another valid argument. Not all choices are equal and some are not even actually choices. Either way you want to look at it, one can honestly make a sensible and consistent argument that more software does not automatically mean more freedom.
I agree with you, but just to point out what I believe the GPL people think about your point: If you're going to write non-GPL'ed code, they would prefer you wouldn't even write the code, Stallman has said this many times. I think they equate this to something along the lines of just creating more "prisons" and just because you have a bunch of "prisons" to choose where to spend your life, it doesn't make you more free
Did he say this? Seems like a really bad analogy to me. If more people are using Meteor, for example, the entire ecosystem will grow. Even if half the devs are writing closed source, they are learning a common tool and that skill lets them contribute to the common knowledge pool (eg. they can answers questions on StackOverFlow). It also creates a bigger market for Meteor developers, thus accelerating adoption.
The FSF has little choice but to consider a lot of licenses "free", but is also quite clear in the opinion that strong-copyleft licenses are always superior, and that people who do not use strong-copyleft licenses aren't really as good as people who do use them.
I license code under the GPL. If I write something and release it open source, I'm doing you a favour by letting you use it for free. If you make changes and distribute them, the least you can do is return the favour and give them back. If you're not happy with that arrangement, you're free to not use my code.
I wouldn't be happy if I spent a lot of time writing some open source software and then a company came along, improved on it, and distributed it in their closed, proprietary software. That's why I prefer the GPL over the MIT license.
> If you make changes and distribute them, the least you can do is return the favour and give them back
I agree. But if your code is a minor library like a json parser, a dijkstras algorithm solver, or a custom button? Should all of my company's product's code neccesarily be GPL as well? What if we already use non-free code from somewhere else? Even if we are happy to fix and contribute back all buggs we find, and any feature we add, we can't. Because you won't let us use the code without GPL.
Now you will tell me that is what the LGPL is for.
...until I want to release my product on the Appstore. The user can't replace the dynamically loaded library, so the LGPL doesn't apply. Then I need to make sure there is an exception for this specific use case.
Headache.
You might argue that without the GPl, i have no incentive to contribute back the bugfix I did. Let's for the sake of this argument pretend that I'm a heartless sociopath, driven only by greed.
By contributing back buggfixes, I make sure future versions of your code (with other peoples buggfixes) include my fix, and is compatible and field tested with it. There is no downside to me, since my competitors either haven't run into the bug or can fix it themselves.
If you're not happy with that arrangement, you're free to not use my code
Exactly. This conversation exists because guelo was complaining about people choosing to not use the GPL code. They don't like the arrangement. geon articulates why.
I don't follow this war so I don't know if "anti-gpl" is a known, identifiable group that actively fights the gpl, or if it is a term you are using to describe dissenters in threads like this. If the latter, be careful: people like me aren't anti-gpl, it's just not the right tool for everything I do. I am working on software that may have some "magic sauce" on which my business thrives, and for this I wouldn't choose to give it a license that says I have to give it away for free.
There are those who think I shouldn't be able to make something of value (known because others are willing to pay for it) and not give it away at all. Or rather, I can, but not software. But let me give you an analogy.
Suppose somebody sold a camera- a very nice camera- that came with the terms of use that said, "Any picture you take with this camera must be made available to anybody who wants it at full resolution and downloadable from your website (etc etc)." Furthermore, some versions of the license state that any work which includes any picture from this camera has to be made available for free. So if you make a poster, or a collage, or anything else with the picture you have to make to poster, collage, etc. downloadable at full resolution for no charge.
My guess would be the not many professional photographers would use the camera for their professional work. It might be great for students, or for artists trying to make a name for themselves, for personal use, and/or perhaps a slew of folks I'm not thinking of right now. But not for pros. In fact, if all cameras started doing this it may seriously harm the field of professional photography. I wouldn't pay a professional photographer to take pictures for a branding series of advertisements that my competitor could simply steal and reuse to devalue my branding. Parents of small kids would give serious consideration as to whether they want the pics of the kids on the web (I have to sign a release for if, for instance, a school or camp wants to use my kids' picture in its promotional material, for example- so it's a concern for some at least).
So the idea that all software should be gpl is not correct, in my view, although I am not in any way anti-gpl.
Freedom of choice is inherent and not relevant to the subject.
I chose not to go to an Irish pub to watch the game between Barcelona and Madrid tonight just as I chose to investigate Derby instead of Meteor because of its previous licensing policy. We can agree that the existence of the Irish pub increased my number of possible choices, but it didn't extend my freedom of action.
I had the _option_ of going to an Irish pub, but I had the _freedom_ of smoking a cigarette at the terrace I chose to go to.
GPL restricts the pool of potential collaborators.
Also, GPL has served its purpose: these days 1) almost everyone realizes that it is in everyone's interest to share code and contribute back (maintaining private forks is expensive in the long term), and 2) most software is offered as a service and the value is not just in the software, but also in the infrastructure, maintenance, support, etc, meaning you rarely encounter the problem of restricted liberties because of a software license.
Note that you do not need a copyleft license to support sharing.
In web development, perhaps. In embedded systems (including the huge world of consumer electronics like cellphones) I suspect that if the linux kernel wasn't copyleft there would be few corporate contributions to its public codebase.
I'm open to a compelling argument for why the GPL is better than a license that basically says "you can do whatever you want with this." (From the perspective of deterring the locking down of computers by corporations.)
If it isn't obvious, GPL is an attack against proprietary computers and against the corporations that have been trying repeatedly over decades to bottle-up and monopolize the computer revolution.
Is it surprising that the GPL represents the antithesis of the startup community?
No matter how idealistic any large group of young hackers will want to be, fiduciary duty will always trump everything when you play with business. You can love the GPL as much as Stallman himself, but when you're grasping for any edge you can find over your competition, you'll think twice before shipping her a tarball of your source.
Yes, that was the original contrast, versus the MIT license of the OP. Sure, people will opt to not release code when it contains trade secrets or whatnot, but the thread is about MIT vs GPL, basically.
Anyway, not to play thread police, it just seemed to me that it was veering off into another direction. I'm cranky in the mornings!
The GPL is extremely permissive WRT users. It allows people to obtain, modify and distribute the code, provided that they keep it GPLed and provide the source with binaries.
Contrast this with proprietary software.
There are restrictions for developers, namely that you can't link GPLed code to non-GPLed or GPLable code, and that you can't close the source.
Liberal licenses are easier on developers, but they don't guarantee that the source will remain open. Software is ubiquitous nowadays, and most appliances use closed source software of unknown quality and probity. There's spyware in every cell phone, for example.
By all means fire up a new thread and I'm sure you guys will wrap this up in no time. But for the sake of the rest of us here to discuss the topic we're discussing, please don't drop a little religious war into the middle of it.
It could hardly be more on topic, and until your dismissive post, the discussion was civil.
You're the one who conflates licenses and religion, and who refuse to even discuss the topic.
The choice of software licenses is far more nuanced than religion. There's a lot of misinformation around the GPL, and it doesn't hurt to talk about it.
GPL 3 has a clause forbidding the use of GPL 3 licensed code on locked down computers. Googling for "anti tivo clause" will bring up a lot of discussion about it.
This would be true if it were an area where Open software didn't already dominate. As others, including the developers of Metor, have stated, this software being GPLed was detrimental to the overall user base because there were many people who were not willing to use and contribute to software with a restrictive copyright. The existing culture of web development is already centered around permissive licenses, trying to introduce a new product with more onerous usage conditions now will just lead to it languishing because its usage of the GPL is a weakness.
Most websites are commercial, and they operate in competitive spaces. They will not consider using GPL code if it means their own site code becomes GPL-licensed.
GPL works when the people using it must contribute whatever small patches or modifications they have made, not when they have to turn over multi-million-dollar codebases worth much more (commercially) than the GPL tool in question.
Maybe I'm just not the audience for Meteor, because while it looks like a great project but as a nodejs guy, the fact that it hides itself away from the platform and turned away from the fantastic npm makes me sort of weary about it as a whole.
But I imagine people coming from rails or whatever don't find this a problem at all.
Personally, I agree that sticking with npm is the best solution. We have managed to do this with Derby (http://derbyjs.com/) while still providing easy app creation, automatic packaging, realtime data syncing, and reactive model-view bindings.
It's awesome to see that Meteor is now permissively licensed, but I would prefer to see them embrace npm as well.
After all, that's the point of an API - to hide the dirty details.
I mean, I've not touched assembly code in over 10 years. I've not touched C++ in 10. This is a good thing, but I do remember saying the same thing about Java about hiding memory details. Now none of these languages require heavy memory management and hide nearly all those dirty details.
It doesn't seem like meteor is ready for prime time, but it is impressive (like RoR or roo) how you can make a site in less than 10 minutes.
SocketStream is a nice framework (also in early stages) that embraces npm and other node conventions. It doesn't support reactive programming out of the box, but I wouldn't be surprised if someone decides to build a module for it.
Hi simplify. I'll be releasing an new version of SocketStream this Sunday which allows developers to do just that.
The new Request Responder API will allow developers to experiment with many different approaches to models, model synching (e.g. with Backbone.js and Ember.js) and reactive templating.
Rather than put opinionated choices about models and clients-side frameworks into the core, we'll ensure the best third-party modules are fully documented and supported before featuring them on our website.
I think this is a great move. Longer term it'll be better for Meteor, the team and the community.
Ruby on Rails would be fine as an analogy here. The monetization model might be different from directly licensing and selling the framework, but these guys are smart, they'll figure it out.
I am quite impressed by this. The team listened to the feedback from the community. They weren't obligated to do so :-)
We got some amazingly specific and valuable feedback -- check some of the Meteor HN threads. MIT is going to be a big part of making Meteor available everywhere.
Awesome - I was one of those highly critical of the original license, so let me be among the first in congratulating them on making this (quite major) change so quickly.
Oh, wow! I'd been working on what appears to be a Meteor-like framework with the very premise of "All the same APIs are available on the client and the server — including database APIs!" for the past few days. It came from my frustration of having to duplicate JS code on both the server and client which just seems stupid when you can provide the same API but with different end-points for each side (i.e. client -> API, server -> DB.)
Isn't it a security risk to allow arbitrary mongodb (or minimongodb) commands in the client side? In their demo, they show a client deleting data from a js console. If that is possible, what prevents an evil user from doing the same to my deployed meteor app?
This is awesome news. There are currently 3 competing frameworks: Meteor, Firebase and Derby, all discussed on HN last week. I guess the new license gives Meteor a big plus.
This is great to hear. This issue was one of my great qualms with the platform, and the biggest argument for creating a copycat platform. Now to address the auth/permissions!
Just a random thought but perhaps you should put up a honeypot version on it's own server to see where the weak spots in security are. Then invite the community to find the holes, or actually ask the hacking communities to help identify gaps in security? Honeypot in this instance meaning a machine dedicated to pulling in attacks (Like flies to honey) to help you identify weak areas of your framework.
If these guys can stick to the spirit of the project, add what can truly help push the system forward while ignoring the multitudes of one offs that will try to chip away the utility, this really has a shot of not only being a game changer but helping define the game for years to come.
While reactivity is an interesting idea and possible incremental improvement, the huge win is in saving us from building UI. Why aren't there more frameworks like Cappuccino but with built in bindings to the DB?
I don't think 'better' is the right question. Their's room for multiple frameworks. To answer the question I think Meteor's strong suit is live coding for rapid prototyping.
You've got a team of cracker jack developers who introduce a product that, frankly, isn't ready for prime time by any sane person's definition with the goal of targeting the majority of developers (e.g., not the most experienced, and not the ones operating at the top end of scale), with no real mention of license?
I expected it to be a commercially licensed language, and honestly, was perfectly happy with that. This is of course better, but leaves me wondering just a little more what the business model is. Not that it's going to stop me toying with it -- I think Meteor is the best JS framework I've seen for ease of use.
I would suspect the business model will be support and feature development. In a widely used framework, there will always be people who need it customized, or need to integrate it in new and interesting ways, or require some sort of commercial support contract in order to use it. If they make these options available early on, they will make money.
I was surprised as well. I got a little scared when I read their email announcement earlier this week where they talked about this license announcement. I fully expected it to be some sort of commercial license due to the lack of information given previously and the polish that even their prototype unfinished product had.
As for the business model, I could possibly see them doing hosting. Although there's no shortage of node.js hosts, they could fine tune their service to work well with the Meteor framework and integrate it in a way that a generic node.js host wouldn't be.
is there an open source license that says says free to use for people etc.. but if you have a company larger than x then you must support the project with $$$ ?
I don't know of any projects that do exactly this, but there are projects that are dual-licensed. You can either use the code under the GPL or buy a commercial license and use it in your proprietary code.
ExtJS is a great example of this sort of dual-licensing, and I've seen it on other projects as well.
Anything's possible, but caution advised to anyone who tries this. It's not always apparent to open-source developers how much pain custom or obscure licenses cause in big organisations (ie the kind of paying customers in your proposal).
Even if it's just a normal license with a single clause variation, it becomes a different license from a tracking perspective. A lot of companies have standard policies on open-source and anything not following one of several popular licenses might be forbidden or require a drawn-out review process at best. This gets even more complicated when you consider packages might not be directly used, but be part of a dependency chain where you have to map out the whole graph in order to demonstrate compliance.
More importantly, how do I keep clients from fucking up my database? How is security being done?
Seriously, if I'm not capable of baking limitations into data persistence/logic at the server level then this entire framework is worthless except for building up a portfolio of cute demos that can't be used for any real work.
As this question comes up every single time Meteor or Firebase is brought up, I think its fair to say that "we're working on it" wasn't and isn't a good enough answer.
From their newsletter which just went out, can't find a link online.
"Please make sure it's reasonably secure. Meteor security isn't as hard
as people think. Admittedly it doesn't yet have the delicious "candy
coating" that the database and DOM update stuff has, but we didn't,
like, forget to put any in. Here's what Made With does:
* Use Meteor.publish() and Meteor.subscribe() to control what clients
can see (remove the 'autopublish' package first). Actually you may not
need to do this for a blog.
* Use Meteor.methods() and Meteor.call() to define secure server
functions and call them from the client. Then lock down your app by
disabling the "training wheel" methods that let any client do any
write."
Also from a quick skim of the server code itself it looks like they are using connect, so you it's possible that you could roll something up using a connect middleware package like everyauth. [1]
That would mean hosting your own server though rather than using the simple meteor deploy.
>* Use Meteor.publish() and Meteor.subscribe() to control what clients can see (remove the 'autopublish' package first). Actually you may not need to do this for a blog.
Scoping isn't enough.
>* Use Meteor.methods() and Meteor.call() to define secure server functions and call them from the client. Then lock down your app by disabling the "training wheel" methods that let any client do any write."
So, I can't make a production-grade app unless I use 0% of the magic.
You're absolutely right. But all frameworks have to go through these humps. Hell, I remember just 2 years ago having MongoDB in production it would regularly crash. We got rid of it in production, but I'd reconsider using it now.
Which features, are making you consider MongoDB? I'm asking because I wrote a (really short and small) MongoDB-ish abstraction layer over SQLite the other day (https://github.com/stochastic-technologies/goatfish), and it seems to me that it's trivial to emulate the MongoDB queries and various other features over SQL without all the hassle of it eating your data or requiring 100 GB of RAM for a few indices.
I think they should've tried to commercialize it. There is a real lack of good, new development systems these days. If you completely open source a new system, developers will just rip it off, contribute nothing, and it will go nowhere. So where's the incentive to continue making it better?
Developers need to wake up, and realize that new, and substantially better systems can be built if they are willing to pay for them. Unfortunately the FOSS community has burned into developers' consciousness to never pay for anything, ever, which produces and environment of extreme lack of innovation.
Our development tools completely fucking suck precisely because developers are no longer willing to buy quality development tools.
As a Rails developer, your comment baffles me. We are practically drowning in open-source Ruby gems, many that are very useful and of high quality.
> If you completely open source a new system, developers will just rip it off, contribute nothing, and it will go nowhere. So where's the incentive to continue making it better?
The exact opposite of what you described happened with Ruby on Rails.
I think that's demonstrably false given how good development tools actually are, particularly open source ones. If anything, too much work goes into open source development tools--certainly much more than in any other category!
Just look at how much is accomplished--and how is easily--by various start-ups using open source technology. There are great web servers, web frameworks, libraries, programming languages, text editors and all sorts of other stuff (that I don't use much so can't comment on).
Also, plenty of people contribute to (popular) open source libraries and frameworks. Even less popular projects get a good amount of contribution--I'm following a couple of emacs modes (a fork of JS-2 and Haskell-mode) as well as some tools (like DoctorJS) on GitHub and all of these get pull requests surprisingly often. I suspect the ratio of contributors to users is pretty high.
In short, open source as a model works if your only goal is quality software. Making a framework open source is a good course of action and we should encourage it.
I think that's demonstrably false given how good development tools actually are, particularly open source ones
I'm curious about your specific frame of reference. Which tools do you have in mind? Have you also used Visual Studio, C#, and Linq as a point of comparison? (I have not, but they are mentioned favorably in these comments.)
A lot of people might cite Eclipse as a good development tool. The Java GUI library used to implement it was much lauded as well. However, it was not so much Open Source that drove its quality as the willingness of IBM to commoditize Java and Java development environments out from under Sun.
GCC was a going concern, but a lot of its development was funded by commercial firms that wanted fixes or extensions. Chromium and Firefox have certainly benefitted from outside funding.
From what I've seen, FOSS can often produce good back-end software but user-facing stuff is often lacking in a certain polish, unless there is commercial backing and paid professionals are contributors.
I've also read that the majority of FOSS projects become stagnant. I think of them as startups but for a different system of compensation. That's not good or bad. That's just the reality of how these things work.
Well, I think mostly about the tools I usually use: JavaScript, Haskell (GHC is really absurdly awesome), Emacs (which has really good support for certain languages including JavaScript and Haskell but emphatically not Java), TeX, GNU/Linux, Git and probably a bunch of other tools and libraries that don't spring to mind immediately.
I have used Visual Studio (mostly for C++ but a tiny bit of C# for WPF stuff), but not too much. I've found myself significantly more productive with Emacs, but I've also now used Emacs quite a bit more. I also used a full version of Intellij in my summer job, but was thoroughly unimpressed.
Now, I'll grant that the tools I've listed tend to have harsh learning curves. However, I posit that they are exceptionally effective in experienced hands. I think this is not a drawback: learning a tool is a constant expense where being more efficient is a benefit proportional to how much you use that tool. I would rather have tools that are harder to learn but more efficient than the opposite. Now, it is true that a tool that is easy to learn does not have to be less efficient and a tool that's harder to learn does not have to be more efficient, but I have found the two to be correlated in practice.
While the user-facing FOSS projects may be less polished in general, I have found that this does not hold nearly as much for developer tools. The main problem with letting developers design UIs is that they assume that everybody thinks like them; this isn't an entirely unfair assumption when writing tools for fellow developers! As I have mentioned, while FOSS developer tool UIs may be harder to learn, I have found them superior overall. Emacs is a perfect example--it does not follow any conventions of other common software (it pre-dates all that other software, after all) but within itself it is by far the most consistent UI I have ever encountered. In fact, I think Emacs is a great picture of brilliant UX; the sole problem is that it lives in its own universe (and isn't as slick or shiny as some newer options).
And of course, with the right lisp incantation, you can do magic.
Finally, it is true that the majority of FOSS projects become stagnant. Then again, this is doubtless true of the majority of non-FOSS projects as well. Back in my Windows days, I would frequently encounter "shareware" that had fallen into disrepair. The main difference is that an abandoned FOSS project can easily be patched or even brought back to life (JS-2 mode is a perfect example of this); abandoned proprietary software is basically dead.
Now, clearly, proprietary programs like Visual Studio supported by large companies will not die. But that is true of big open source projects as well: most of the ones I listed aren't disappearing any time soon. So stagnation is really constant across all software; the difference is that FOSS software is much more difficult to kill completely.
Hopefully my aimless ramblings have cleared my views on the subject.
I think that's demonstrably false given how good development tools actually are
No. Development tools seriously suck. Show me an IDE that can debug multi-client websocket code. Good luck. Every open source IDE's like Eclipse are useless these days because they can no longer keep up with the new problems being introduced.
Light Table is maybe the first genuinely new, commercial, development environment to be introduced. People are gushing over the possibilities. All of a sudden people might, for the first time in 15 years, be willing to pay real money to make their lives easier.
The open source model is a socialist model that has failed to keep up with the pace of technological change, and encourages developers to not purchase development tools which slows innovation in development technologies. FOSS ultimately holds back innovation.
You speak of light table, but that specific project wouldn't have existed without clojure which uses the eclipse license; doesn't this make it a derivative of open source?
Furthermore, ibdknox open sources the majority of his projects...
How can you reconcile with this information? It seems to me that most of the interesting software coming out these days is a product of the open source movement, rather than an attempt to escape from it.
You seem to ignore the fact that open-source allows more people to use a product. When more people use it, more activity happens - which leads to evolution.
Not sure how you can ignore the open-source software that rules the software development world.
More people using a product does not lead to innovation. It leads to more people using the same free product and not realizing how much better their tools could be if they were willing to pay for them.
Open source tools rule the world simply because they are free, and developers everywhere are unwilling to pay for better tools, which hold back innovation of better tools. Why would anyone build a substantially better development tool if nobody will buy it?
Conflating FOSS to socialism is patently absurd (FOSS is very monetizable and comes in many different forms that you can incorporate into many different business models) and an attempt to co-opt a very negative "red baiting" sentiment in others.
I do a fair bit of development of Django using PyCharm. Django is BSD licensed; PyCharm is closed-source. Both are, in my view, amazing tools.
Open source platforms are overwhelmingly dominant, awesome, and (at least for web frameworks) licensed as BSD/MIT or equivalent. Open source IDEs are uh... ...let's just say they're an acquired taste, and leave it at that.
Since we're talking about Meteor, the proper comparison appears to be platforms; as a result I have to say wavephorm is full of it. If he's trying to argue that Eclipse is terrible...well, he's right, but he's on the wrong thread. ;)
> Open source IDEs are uh... ...let's just say they're an acquired taste, and leave it at that.
You say PyCharm is amazing. IntelliJ which it is based on is open source. Eclipse and Netbeans, which are generally considered to be in the same league, are also open source. The only IDE commonly considered to be in the same league as these three IDEs with regard to refactoring and feature count would probably be Visual Studio.
Cool I can now use this in my closed source project without ever giving any change back!
Hate this GPL that requires you to give back anything if you let others get your product.
Maybe you should check out other MIT licensed frameworks and assess whether they have fostered a closed or open community.
Rails is MIT licensed and as a result we have seen a lot of companies build their web applications on Rails and build very successful businesses, but we have also seen a range of opens source plugins/gems and applications themselves built around Rails which have resulted in a better web community.
This is 2012, developers who care about something like Meteor also care enough about open source to give back. We don't want developers to be forced to make their products open source, they should feel compelled by the enjoy of helping others.
GPL requires you to give back; MIT gives you the choice. Developers are by nature creative people. And humans are not incapable of altruism. Even with an MIT license, I expect a lot of community contributions to pour in.
In fact, I expect more community contributions to come in. MIT means (perhaps) a lower percentage of users will give back, but there will be a higher absolute number of users since the license is more permissive.
Until you want to use some CDDL-licensed code. Or some APSL code, or one of the many other mutually incompatible viral licenses out there. Especially in something like a web framework, where most of the clauses of the GPL wouldn't apply anyway. License dickwaving makes the community a worse place. Stop doing it, sit down, and code something.
With the change in license, I think the only major hurdle has been removed. The fundamental idea is good, their current execution is extremely slick, and their immediate plans[1] look achievable. I have very high hopes for the project.
If you haven't checked out Meteor yet, at least watch the screencast: http://meteor.com/screencast
[1]: I originally said roadmap; as mcrider rightly points out Meteor does not have one. There is some info floating around about current development goals (notably related to adding authentication), which is what I was thinking of.