Actually, I think this is one of the major issues Meteor has at the moment. It would be ok, if only packages were affected that cover side-topics. But there are some packages that IMHO should be part of the Meteor core (like file upload - e.g. CollectionFS - or internationalization - e.g. tap:i18n) - where the response times are not that good. I don’t want to blame the package maintainers, because they are basically doing this in their spare-time. But I would love to see some care of MDG for these “core functionality” packages, e.g. by taking their ownership and maintaining them themselves. So I am quite happy to see that @sashko is now evaluating how to bring SimpleSchema closer to the core. For me, this is package is also essential, and I could not rate it high enough. And at least @aldeed is quite quick with his responses, as you can see above 
I completely agree @waldgeist @Cris. I’m using CollectionFS to upload images and it has a quirk that it returns an image URL that actually isn’t yet available, so I end up with broken image links on my page, I’m pulling my hair out, and it seems like this is a known issue, and I saw some suggestions, there’s probably various hacks I could try. But the point is some of these packages seem half-baked.
So yes, MDG, or even a community effort to identify major packages and critical issues and address them, I believe is important.
CollectionFS has its purpose in some cases, however it is way too much to integrate in core.
Most people are much better off using client-side pre-processing + slingshot, and it works great as a package not in core. MDG could mention files in the meteor guide, but that’s it. Maybe also make/mention a simple package with file upload directly to their own server, could do, but nothing as comprehensive as CollectionFS, that should definitely be as packages.
Integrating in core, it is probably too much. I am not asking to MDG to take ownership of the package, but maybe they could help with administrations.
The solution is having somebody that can help to fix the package or add maintainers.
The problem is that you read articles on the Internet that point you to a library like CollectionFS. You look at the popularity of it and it seems that that is the right path. Then after you put it in production, you start having random problems and when you file an issue on Github nobody answers except those people that say “Me, too”. You may end up spending a day digging through internals and fix the problem, you submit a pull request that goes nowhere and it feels like wasted time.
I seriously would like to start a site for “What you need to know, about package X”. That in 1/3 of a page gives me the main signals on the quality of a package or module. This is needed for Atmosphere and for NPM packages. For example: “list of critical bugs not addressed”, “author is unresponsive”, “no maintainers”. And some signals “author is not around and new upcoming changes in Meteor x.x will require maintenance.”. Encourage even on Github comments like “I tried to make it work for 2 hours, this is what I found out”. A wiki could even be sufficient if the right people are on it.
Github could be also enough except that if the author is not around other people cannot change the README.md.
In a framework such as meteor with a low barrier to entry with which it is easy to do some powerful things, you’ll easily find people with entry level skills that behave like script kiddies. It is ok, it is a business decision to create such an environment and culture.
However, you’ll find that many are followers, and if some say yeah that’s good, they’ll say yeah that’s good and simply reiterate the said word until said word is standard, until someone again says that is bad, and they will again say so.
Professionals in the open source world, will take time for due diligence as they should as their clients depend on it. Many a meteor developer is not a professional developer and that shines through.
That being said, yes MDG to professionalise their business would do well putting in a small group of professional curators with MDG being the small group of core designers and integrators like TC39, however things are changing, and so are strategies and business objectives, so holding out and seeing where the NPM path and facebook + other external influence will take it all is maybe a word of the wise.
At the end of the day, meteor is from a business perspective but a hosting platform(galaxy) like heroku and a consulting service, although with a more advanced deploy tool and integration with tools for build, dev, a number of libraries, and… a community which is a part of its actual strategy. (I only call it as I see it with my own eyes and from my own experience).
Maybe meteor had a play for carving out its own niche to take control of a significant piece of the nodejs environment, and were taken by the challenge it is to beat innovation at large, and now must reintegrate with npm and external packages such as react, redux, and others as it comes, something that is needed to survive rather than becoming famous. I’m glad it is happening, that meteor embraces npm, and taking advantage of webpack’s power becomes possible, otherwise most professionals would stay away, and those already in would leave just like those who had become professional during their meteor period.
I agree with you that CollectionFS is too “fat” to be part of the core. I just meant that any kind of upload mechanism in the core would be fine. CollectionFS was just one example. Regarding slingshot: Yes, this package is great, I am using it instead of CollectionFS for many use-cases. But it does not cover all scenarios, e.g. uploading files to the Meteor server itself. That’s where I am still using CollectionFS.
So what you basically want is a website that will tell you which programmers are willing to produce high quality software for you for free. 
Good, fast, cheap: pick two. TANSTAAFL.
On a less snarky note, as a package maintainer and curator, I wish there were a better financial model where I didn’t constantly get derailed by clients wanting work-for-hire. Grant funding would be best; followed by bounty source funding, I suppose.
Now that we’ve got FDA and HIPAA strategies worked out, I’m considering just taking the HL7 stuff closed-source since doing the curating is such a thankless job.
To add to @casperandersen 's great reply, a lot of times choosing a package for any framework (Rails, Django, Meteor), there are tradeoffs with technical debt vs an upfront speed increase.
Often the package has more features than your requirements. This means the surface area is much larger than it needs to be which can lead to complexity and additional bugs.
Most of the time I end up writing from scratch unless the package really helps me. For instance using check can be sufficient in some cases where SimpleSchema brings on more debt. However, in larger apps SimpleSchema saves time and reduces bugs by providing a battle tested solution.
TabularTables is another example. This has lots of Meteor specific functionality that is hard to write from scratch. The tradeoff is much better than other packages that do something that an NPM package would also do but has more life.
Traditionally most have shyed away from using NPM which is a shame. There are lots of libraries to solve your problem that have more users, more contributions, etc…
An example would be push notifications. Sure you could do a one liner and have push on the client and push servers but that’s a huge maintenance cost and harder to debug. Using an NPM package for APNS or GCM is a much better bet.
In fact good engineering calls for decoupling things that change and taking a standard library off of NPM and writing an adapter to make it reactive/Meteorized is an overall win.
The good news is we’re getting first class NPM support soon which makes it trivial to import great libraries! Having React as a view layer brings up a huge ecosystem of view components that can now easily be imported (React Parts).
No kidding, it gives the false impression that Meteor is losing popularity. Almost any other graph would have been nicer. Hindsight is 20/20 though, so hopefully the type of graph will change soon.
Based on this google trends search, the state of Meteor seems to be fine:
Search frequency on the terms “Meteor Javascript” is down a bit from a peak in Nov. 2015, but not by much.
To be recognized in 2016 the use of meteor appears to decrease
Choose prgramming as category on google trends.
https://www.google.com/trends/explore#cat=0-5-31&q=meteor&cmpt=q&tz=Etc%2FGMT-7
I think you should choose programming as category on google trends.
You do realize Geoff used Google trends at I think it was the JavaScript state of the union to advertise Meteor’s traction with Google trends 
?
People tend to frame data in their favor when it means they’ll win, and argue against data when it means they’ll lose.
It’s human nature to want to come out on top.
I don’t think Sashko, or Geoff, or anybody is past that.
If I were MDG, I wouldn’t brush it off as “the data isn’t facts”. I would use it as fuel to push Meteor onto even better grounds.
Wake up MDG.
My $0.02 - yes Meteor is dying. I went to the keynote at Meteor Open Camp and the panel discussion afterward. It looks like MDG is trying to get Meteor off it’s plate so it can focus on a new approach called “Saturn” and also on something called Apollo. In addition, it seems that the long build times are just not feasible for a serious development environment – it makes remote pair programming practically impossible, for instance.
Long build times are not feasible?
You guys obviously never developed anything that needed an actual compilation step.
I don’t think MDG is necessarily trying to get Meteor off their plate; Meteor is currently helping sustain and grow the company. Up to this point, Meteor is why Galaxy exists (in its current state), and MDG isn’t going to throw that away. What they are trying to do though is become (remain?) profitable (this is a good thing!). They’ve learned a lot over the past few years from both developing Meteor and watching how individuals/customers/companies use Meteor. They’ve lived through the same pain points and areas of frustration we’ve all experienced, and have learned from it. Apollo is a perfect example of this, and MDG hopes it will help push the company forward. If you take a closer look at Apollo, you’ll quickly realize MDG is course correcting on a some of the technical decisions they made with Meteor. Painful in the short term I know, but this ultimately a good thing - instead of doubling down on past decisions, MDG is listening to its customers/community, is revamping its stack, and is charging full steam ahead.
As for Saturn, it’s a micro-framework that can be used to help develop Apollo apps. Since MDG is pushing Apollo separately from Meteor (ie. Apollo isn’t dependent on Meteor), it makes sense to help Apollo developers out with something like this. That being said it’s still considered an “internal to MDG project”; we don’t know what their plans are for its use (but I’m pretty sure it wasn’t just developed for GitHunt 
).
Very discouraging to see topics like this on the first page & with by far the most amount of clicks… More people have viewed this post than have viewed the welcome to the forum…
But I do hope it catches MDG’s attention. I believe much of the community is worried about the direction of Meteor.
And rightfully so! I know I have that worry myself where I’m not sure if Meteor is even going to be in active development in 1 year. At least, not in the form we have known it in the past.
It doesn’t really seem like we’re simply “getting new features to improve Meteor”. The way this is being handled sends a much clearer message that Meteor’s kind of being pushed out of the way for Apollo and in order to mesh with the JavaScript world as a whole. This sacrifices everything Meteor was built on, and what we know Meteor as, in order to make a new product.
Yes, MDG may be trying to use what they learned towards Apollo. But as a Meteor user, why would I want to move to Apollo if it doesn’t even have the same values at Meteor?
TBH I’m a bit worried for the future, as my job has a major project with Meteor that will be ongoing for at least for the next 1.5-2 years. But no one can even say if in 1.5-2 years Meteor will still be supported, or if it will be given up completely in order to support Apollo, without a way to transfer our Meteor project to an Apollo project.
Sure, Apollo may push the company forward. But what about us users? There hasn’t been any indications that we will not be left behind, and 1.3 has started a trend of that.
So in the end, right now I can’t blame users for being worried about the future, concerned with the direction of Meteor, or for feeling a sense of abandonment.