it currently has 61 bugs and 17 pull requests. of concern is this bug in particular:
we have integrated this package into our app and it’s having issues on Android. when i see such outstanding issues and pull requests, it makes me wonder if we should start looking for another solution. it also makes me wonder, for a package owned by “meteor”, why there isn’t more activity.
we started on Meteor w/ the idea that it has a promising future. seeing a funded group like MDG helps sell that message. but i feel like i’m not seeing the results of that funding in making a large, active community. what am i missing?
I think it is safe to say that mdg:camera is not a supported package. It was released as part of the mobile example apps when the Cordova integration was first released, but hasn’t seen any substantial development since.
It is important to note that it doesn’t actually do too much: it is basically a simple wrapper around cordova-plugin-camera. So it may make more sense to use that directly or define your own wrapper if you have a need for some of the features it adds. I suspect most issues opened are either feature requests that wouldn’t be needed when accessing the plugin directly, or issues with the plugin itself that will have to be fixed downstream.
why? it’s marked as a meteor package. i’m new to Meteor, so maybe i don’t understand, but doesn’t that mean it’s down to MDG to maintain it?
if not, what does MDG do? i would have thought its purpose is to grow and support the community. imho, that won’t happen unless 1) Meteor demonstrates to the world that its better than other MEAN solutions because of its packages, and 2) those packages are well-documented, easy to use, and maintained.
if the purpose of MDG is something other than supporting and maintaining packages, i’m truly curious as to its purpose.
This is a bit of a technicality, but mdg:camera is not a core Meteor package. Those do not have an organization name (so it would have been camera).
We definitely care more about maintenance of core packages, but even those are not all ‘down to MDG to maintain’. Meteor is an open source project, and we rely on the community to help us improve and maintain it. Besides working on other projects (like Galaxy and Apollo), MDG developers generally work on infrastructure and major platform features that other contributors and package authors can build on.
thanks for the clarification. being new to the platform, i don’t yet have a sense of what’s core or not. if there’s any notion of “non-core but useful packages”, it seems to me that camera support would qualify. i’ve looked at the code and agree it’s pretty straightforward. i’ve already forked it for my own purposes.
thanks for the clarification on that as well. i guess i missed the announcement on Apollo and did some quick reading on it.
if i may, as a newcomer: i’ve worked various MEAN solutions before and was drawn to Meteor for a MVP (now in its 5th week of dev) because of the promise of rapid prototyping. the packages for registering/login, schemas, and autoforms were a large factor in deciding to go with it. and my team has built a lot in those 5 weeks. BUT, now that we’ve dug in deeper, i’ve found a few pain points / observations. if i may:
it looks to me that the heyday of packages is in the past. many are not active or outright deprecated w/o viable replacements.
there are a lot of SO posts and articles that reference direct, now non-functional links to the Meteor docs, and finding that info is hit and miss.
most of the SO advice looks to be outdated. one must read through all the comments to get hints that’s the case. again, it seems to me that the heyday of Meteor questions is in the past.
i don’t get the sense that there are a lot of people contributing to this forum, especially for the Help questions that are more than basic questions.
my intent is to provide some insight / constructive criticism from an experienced dev new to the platform. i hope it’s helpful.
Thanks for taking the time to write down your experiences. Meteor is in a bit of a transition at the moment, so I realize some of what you encounter may be confusing. The general theme is that we are aligning Meteor more with the rest of the JavaScript ecosystem, deemphasizing some Meteor-specific ways of doing things.
One change is that Meteor 1.3 has made it easier to use packages for npm, so most of the wrapper packages on Meteor’s own package server are no longer needed. Another point of transition is that we support React and Angular as view layers, so questions about Blaze may receive less attention because less people are using it.
We’ve recently reorganized the docs to make them better organized and maintainable, but as a consequence direct links may no longer work. The content should still be there however (and should be easier to find in the new structure!).