The big mistake was trying to provide anything beyond Minimongo on the client side. People are very picky about what front-end frameworks they use on the front end, and typically people who have strong opinions about that are less opinionated about what they use on the back end. I'm firmly in that camp, for instance. I've been a huge fan of Firebase for a while because it frees me from the tedium of having to create another REST application just to talk to a database. If Meteor had, from the beginning, focused on simply being a kick-ass open-source alternative to Firebase they would be killing it right now.
It was a monumental task to try to create something that would please both front-end and back-end web engineers. Another issue with Meteor is that it was envisioned, not extracted. [1] From Rail's creator, DHH: "First, Rails is not my job. I don't want it to be my job. The best frameworks are in my opinion extracted, not envisioned. And the best way to extract is first to actually do."
Meteor was the goal, not an actual, real-world application. Often when this is the case the software ends up solving a bunch of problems that seem logical to solve, but in practice are not actually practical (another framework like this that comes to mind is the notorious famo.us project). Compare this to Rails and React which were forged in the crucible of real, day-to-day development and problem solving.
Let's avoid turning this into a "Meteor is doomed" or "Meteor failed" comment thread; Meteor is and has been growing consistently since it launched (see: https://twitter.com/Rahul/status/673992512768507905). The title of Sacha's post reads a bit inflammatory, suggesting something "went" wrong and that it's too late now. Rather, as his post explains, the community is currently in a bit of an identity crisis as two groups with disparate sets of opinions on where Meteor should go from here collide.
As someone who's been building with Meteor since 2012, I see all of this as a good thing. It's a sign more and more people are lending their voices and opinions to Meteor's direction. As NPM support arrives with 1.3, and as a more agnostic approach to view frameworks becomes part of core, we'll continue to see more people join, because the platform will be more open towards them.
Meteor was a new platform. It's now a mature, growing platform. And it will be a successful platform if we all keep contributing.
The post's title is "What Went Wrong". What kind of comments were you expecting here? Running an OSS project is no different than running a startup in a lot of respects – marketing and PR matters. It's great to write candid posts like this, but you can't jump into other forums where the post has been linked and try to manage the conversation after the cat's out of the bag. It ends up sounding like damage control.
Instead, you should welcome further observations about some of the perceived mistakes the Meteor team made and point out specific examples where they're being addressed.
About the tweet: It's not a graph, rather some neat bars, until it has some numbers. It is suggested that it shows relative growth, make it relative to point zero and you get undefined-ly long bars, or compress it to make it look like the product is stagnating: http://i.imgur.com/TOBLaSa.png
Also, consistent growth isn't really enough, usually, to capture a market and exponential growth is usually expected from startups.
This seems to be the same issue with other frameworks when they get to a point where they have enough adaptation and find out they need to change/update parts of their framework to get it to the next level.
Same thing is happening right now with AngularJS. Been around for a while, had massive adaptation, then they realized they needed to make major changes. Enter pivot to 2.0 which pissed a lot of people off, but the heat is dying down now and people are coming to their senses.
I'm pretty sure at some point React and other frameworks will hit their wall too.
Rails didn't hit that wall. Neither will Ember. FYI Ember is introducing new ideas by the second (pods, composable components, components over controllers, DDAU, etc) but the community eagerly awaits and embraces them. I don't know why that is.
This is really a fantastic point. It's sometimes as if people think these type of projects exist in isolation and any perceived flaws are permanent. They often fail to appreciate how much the flaws will invoke a response to address them, making them better than they would have been had the flaws never been strongly felt by the community in the first place.
> First, Rails is not my job. I don't want it to be my job. The best frameworks are in my opinion extracted, not envisioned. And the best way to extract is first to actually do.
You are slightly wrong in your history of Meteor. It was extract from an app they built. Unlike Basecamp or Facebook, the app died off and they focused on just building the framework. So while it was extracted, I think MDG has missed a lot of the learnings that something like Rails gets from core contributors that are building applications and the framework together.
MDG has actually talked about taking one week twice a year to build 'apps' with the framework, but that just hasn't been enough. I am glad they are finally working with Meteor itself to build Galaxy and supporting Galaxy customers as well, that really gets some skin back in the game.
Imo, this post is just a manifestation of the deeper issue around profitability and the fact that MDG will need to jettison some of it's development costs and pick up a much larger base of customers if they want to be profitable.
Which PaaS also builds it's own programming framework...
> Another issue with Meteor is that it was envisioned, not extracted.
This has been the Achilles heel, in my opinion.
On what might be the bright side, this sort of thing is starting to happen, albeit from the outside (e.g. not from Meteor, but from a company who hitched their wagon to Meteor):
It was a monumental task to try to create something that would please both front-end and back-end web engineers. Another issue with Meteor is that it was envisioned, not extracted. [1] From Rail's creator, DHH: "First, Rails is not my job. I don't want it to be my job. The best frameworks are in my opinion extracted, not envisioned. And the best way to extract is first to actually do."
Meteor was the goal, not an actual, real-world application. Often when this is the case the software ends up solving a bunch of problems that seem logical to solve, but in practice are not actually practical (another framework like this that comes to mind is the notorious famo.us project). Compare this to Rails and React which were forged in the crucible of real, day-to-day development and problem solving.
[1] - http://david.heinemeierhansson.com/posts/6-why-theres-no-rai...