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:
- Diversify across more repositories and projects - historically, something like Apollo would have been built inside the Meteor repository and would never have been used by anyone outside of Meteor. Instead, it’s built as a collection of several packages in their own repositories. Even the Meteor docs have been split into a separate repository, which used to be in meteor/meteor as well.
- Involve a greater diversity of organizations and stakeholders - it’s not good for an open source project to live entirely from one company. What if at some point MDG can’t make money and folds? It would be much better if there are many contributors ready to pick up some of the slack.
Anyway, I would say the best way to make more diverse contributors to the framework is to contribute yourself! Build the future you want.
28 Likes
@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.
7 Likes
@sashko. Fantastic. It’s good to hear that. I’m having a great experience developing with Meteor.
3 Likes
@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?
1 Like
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.
1 Like
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. 
2 Likes
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.
2 Likes
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.
14 Likes
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.
34 Likes
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.
23 Likes
Tons of 
to @sashko’s comment above. Really nails it.
For me, I’m still so much in love with Meteor. There is simply no other framework/tech I’m this productive with from day 0, and that I haven’t outgrown. I like the stack (the “backend” and Blaze) and the ease of not having to configure a Webpack config for everything.
It would be a very sad day if the Meteor I know and love goes under. There are very smart people at MDG, and Meteor is very high tech under the hood. I appreciate their hard work every single day.
to MDG.
24 Likes
This should be pinned somewhere visible! Almost flawless backward compatibility is one of the big things that makes Meteor so special. Low learning curve comes a close second.
This framework is the most reliable tool we ever worked with. At illustreets, we are very thankful for it!
8 Likes
Yes stability of the system is prime importance to us as a company. We have a big production application running at various customer site and we do need a stable framework. We can work around big changes but not at an extreme case as it is really difficult for us to update customers just because underlying framework has changed.
This is may bother people who want to live with the cutting edge but with companies invested heavily in meteor and with a on premise product it would become a nightmare if the framework changes every few months. We would love that meteor moves totally to npm but not at the cost of stability.
2 Likes
@joshowens Sorry Josh but what you are saying can also backfire. If we invest in smaller libraries to create our own environment and if the contributors leave for new shiny things than either we maintain those libraries or go look for new ones.
Spring in Java is a huge framework which is well maintained and i would choose that before any small library. The main reason is that it is at least maintained.
I suggested small as in focus, I think you are talking small as in mind-share. I say go with the herd for many choices, React and Angular are solid examples of what I mean…
Pick things that seem like well established communities moving forward. Meteor moved slower than Webpack because they had a team of 8+ focused on many aspects of the framework. The webpack team had 2-3 people focused on 1 core piece of the stack.
While tailored integrations are super nice at the start, I am starting to think they limit you in the long term because you end up with a bunch of legacy stuff that you feel you can’t change easily.
1 Like