There’s so much gloom and doom about MDG’s commitment to Meteor on these forums. For a reality check, I just went to github to look to see if there is any activity on the Meteor codebase:
Based on what the community is saying here, I expected crickets. The reality is more encouraging.
Well, the community said that only 1 MDG member is maintaining Meteor at the moment (benjamin) - the others are working on Apollo if I got it right.
Which is why it’s good to look at the data. 15 developers made 142 commits to the Meteor codebase in the past month. Benjamin was responsible for 92 of those commits, so he’s clearly the primary maintainer, but not the only one. Of those other 14 developers, not sure the extent of their relationship to MDG.
Sure, I think it’s a communication issue on MDG’s side. People seeing that there are only 1 or 2 MDG contributors (your charts show Benjamin and Tom) -> Meteor is dead.
I’m not one of the people that say that Meteor is dead, but even if you’re looking at the last year. You must admit that benjamin is indeed the only one that is doing some real work. See the stats here. He has 1158 commits in the last year (1 december '15 till 2 december '16), where as “the number 2” has only 194. That’s a huge gap!
Yes, there are others, one with 130 and others with a ~50 commits. But looking at their timelines; you see only one being really active.
Changing the time range to the last 3 months, doesn’t make it better. Benjamn has almost 10 times more commits than the number 2:
To make this a fair comparison; also see the activity over whole 2015. Commits there where more equally divided over multiple maintainers:
We’re trying to do two things:
Anyway, I would say the best way to make more diverse contributors to the framework is to contribute yourself! Build the future you want.
@sashko For clarification purposes only, are you saying you see this as a likely possibility at this time?
I don’t hope so, I would really like to support MDG, but they don’t deliver anything I would need (except the framework).
Application debugging → Kadira
Hosting → Own VPS servers, each project has different specifications, even the server location plays a role. We also need to install some packages (like ffmpeg) on the servers, so Galaxy isn’t an option. Never got it why Galaxy wasn’t developed as deployment solution with additional hosting offers. This would reach much more developers/customers. Now it is a hosting solution, only satisfying some customer needs.
It’s not a possibility at this time. I’m just saying for every project it’s good to have diverse investment - I think I phrased it in an overly dramatized way. In fact we’re currently hiring new people to work on Meteor.
@sashko. Fantastic. It’s good to hear that. I’m having a great experience developing with Meteor.
@sashko, that is big news. Would it be over the top for me to start a new thread here titled something like “Big News: MDG Hiring New Meteor Developers” and linking your post in this thread?
I don’t think it’s big news - we’re pretty much hiring most of the time, just like many other companies. But we’ve had more success with targeted outreach, for example people who are already active contributors or proactively reach out to us directly.
I understand of course. At the same time, very often I see people here and on Meteor-related Slack channels saying ‘we know that MDG has abandoned Meteor because they only have one single developer working on it. Almost all their developers are working on Apollo.’ This argument has carried a lot of weight with Meteor developers, convincing many that MDG is pivoting away from Meteor and plans to abandon it. It is a big contributor to the doom-and-gloom posts on this forum.
It will be very reassuring to many Meteor developers when they hear that, on the contrary, MDG is hiring new people to work on Meteor. 
Most of what I’ve seen or heard in the past seems to run contrary to what you are saying. We hear things are changing, but the team needs to do X, Y, or Z first. I think many are moving on because other tech is moving faster, easier to work with the OSS team, and makes more sense in the long run to invest in smaller libs instead of bigger frameworks. I think most of MDG would agree at this point, given how much time/money/energy is spend on the OSS library Apollo… I mean, Geoff has changed his title on the GraphQL presentation to founder of Apollo.
Perhaps it might be possible to read too much into that. Geoff is founder of both MDG and Apollo. Clarification from @sashko would certainly be welcome.
@joshowens Geoff used that title at my suggestion because he was representing the Apollo project and team, our GraphQL-based project, at a GraphQL-focused conference. Also, to avoid confusion. However, he mentioned being the founder of Meteor and MDG heavily in his keynote, if you had a chance to watch it.
Most of what I’ve seen or heard in the past seems to run contrary to what you are saying. We hear things are changing, but the team needs to do X, Y, or Z first.
@sashko was referring to our outreach to potential hires, not contributors. Still worth mentioning that there are currently clear paths to get involved in the project. While this hasn’t always been the case, and the pace of change might not be what everyone might like, there’s nothing preventing anyone getting started as a contributor today, and we are hugely grateful to those who have done just that.
Meteor is possibly the farthest thing from a “small library” in the whole JavaScript ecosystem. Focusing on small libraries is a very valid approach to development, but not one that the Meteor platform is built around. I agree it’s great that Apollo is built to be more modular from the start, which we think will make it easier for people to contribute and build new components.
Parts of Meteor would definitely make good smaller libraries, and that’s something we are trying to work on when we can. But the main priority has been to preserve compatibility for people with heavy investments in Meteor in large production apps so that they can continue to get new features and performance improvements without having to port their whole codebase.
I think that has come with a cost of some thought leaders moving away from Meteor to newer and faster-moving projects that are more configurable and support some more modern features, but IMO working hard on backwards compatibility and upgrade paths is the most important and successful principle of Meteor as essentially the only full-stack batteries-included JavaScript framework available. The fact that Meteor devs can have code from 3 years ago live side-by-side with CSS modules and React in the same app without having to set up multiple build processes is, in my opinion, a monumental achievement, but understandably not something everyone needs.
Please know that this is massively appreciated by some of us in the community. I’m actually in awe of what has been achieved in this regard.
Couldn’t agree more. I’m one of the beneficiaries of this, having had a project in production with Meteor versions from 0.5.7 right through to 1.4.2.3, with no refactors required that were so big they made me give up in despair.
