Is it time to leave Meteor & MDG?

Planet Earth
1

This is a pure question to get really feedback from the community and MDG, I know MDG might not like this question. But I feel we should ask it and really start a community based discussion around the future of Meteor and were MDG is heading with Meteor.

Please be positive.

MDG will no longer support Blaze and this was talked about in a number of different threads and hopefully the community will pick it but either way this was the first step in the core changes I also feel MDG went back and forth here not really meeting the community needs not to mention there was disappoint how this was handle but also from a number of developers like myself invested in Blaze.

But now it feels like MDG scrapped their old strategy, and will eventually scrap/abandon/depreciate (what have you) the tech stack we know of today as Meteor along with it – to be replaced in favor of a new enterprise strategy revolving around Apollo.

So now what?

Maybe it’s time to move onto pure Node.JS with a package or plugin to support real-time? Maybe that is Apollo or maybe it would be better to move away from MDG?

13 Likes
2

That just makes no sense. Exactly that new strategy makes me wonder “why still use Meteor, isn’t basically just Express at this point” whereas the old deprecated things that you can still use are the exact opposite: A system that magically works without plugging stuff together, except for the fact that you won’t get as many updates anymore for your tools used.

1 Like
3

General when a company starts with providing less updates that framework or tech stack is out the door I have seen it with Flex and then Flash but also CakePHP. The question then becomes if this is the case then is it better to use something like the MEAN stack or pure Node.JS which of course is not as good as Meteor or might be more work but might have better long term support.

4

Hey @almog,

Like many of us, I pondered this. And here is what I came up with.

  1. MDG makes money offering a hosting solution (Galaxy). My own math tells me it is not profitable enough for a solid return on investment for their investors. But, still making money.
  2. There is definitely a lack of communication skills – top of MDG seem much more skilled at development then communication and vision. You alluded to their mishandlings of messages and lack of proper outreach to the community (however, @sashko is simply amazing, and should be credited for keeping much of this alive despite these mishandlings).
  3. Meteor is shifting towards the general JS community. They are not just NOT developing Blaze, they are not developing UI period. React and Angular are not from MDG and much of what is out there is community-supported.
  4. MDG is rightly going towards community-supported development. Watch what is happening on Github right now, the transfer of Blaze (and soon more pieces) will take place.

I am now convinced Meteor continues to be a great platform, and will continue to do so. I have a feeling development is proceeding towards being part of the global JS ecosystem, which reduces all our risk.

Personally, I am struggling with the moral dilemma that we are not using Galaxy yet. For technical reasons, we can’t. I would love to give back to MDG by using their platform.

They did a great job!

Edit: We are using Blaze and will continue to do so in the near future. We are not trend chasers and see tremendous value in handlebars.

30 Likes
5

@ramez you’re not worried that the Meteor framework is a taking a second step after Apollo and it seems MDG is more focused on Apollo then Meteor.

Blaze is just a small part and not a big deal at the end there are other options. But what happens in Meteor is ditched towards Apollo?

6

I am not worried about Meteor for the following reasons. But I first need to say that this is the result of soul-searching not unlike what you are going through.

  1. First, the money trail for MDG is, so far, Meteor. This is done via Galaxy hosting. I haven’t yet figured out how you can make money on a middle layer like Apollo by itself. Maybe Apollo servers, if that is possible. More likely than not, the future is to make Meteor a complete platform for GraphQL via Apollo.
  2. GraphQL servers are now popping up everywhere, you can’t make money on GraphQL alone (at least that’s what I believe). It needs to be part of something bigger – see #1. In fact, FB already released their GraphQL client (maybe they’ll even release their server!)
  3. The community is now stepping in and slowly taking over pieces. The code is after all, open-source
  4. Development on Meteor is on-going, and recently moved towards merging the two (Meteor 1.5)

Finally

(5) I believe we are in this mess because of miscommunication.

2 Likes
7

Guys, haven’t we had this discussion a hundred times already by now?

Technology gets deprecated everyday in the JS world. At least with Meteor you get a somewhat reasonable lifecycle.

If you need to build a new app the question is: "What framework can help me the most in building what I want."
3 options:

  1. As of today it would be Meteor, just like it would have been 2 years ago. -> Use Meteor.
  2. 2 years ago it would be Meteor, but today not anymore. This is probably because of newer stuff in the larger JS community and that’s where Meteor tries to change to make itself relevant again for those users.
  3. Today it’s not Meteor and 2 years ago it wouldn’t have been Meteor. -> Use the other framework.

“Will Meteor still be here in another 2 years” is not a very useful question, since in the JS world there’s not really any other framework that gives you this guarantee. Maybe it’s a useful question if you’re comparing cross-technology ( with .Net, Ruby, …).

The only thing I hope is that MDG doesn’t forget about the people who choose Meteor for its reactivity. Some apps need “instant” reactivity across users and that’s not a high priority for Apollo. So I hope livequery keeps getting some love until there’s a viable alternative in Apollo.

18 Likes
8

Although such questions are rightfully warranted - you are investing in it after all - the answers, I believe, are simply in favor of Meteor and MDG’s vision.

Evolution and innovtion are inevitable and in a such high velocity realm like software development, it should even be considered absolutely necessary.

MDG does one better and goes to great lengths to be backwards compatible, while proposing carefully crafted upgrade/migration paths. Had it not been the case, most Meteor apps from 6 months ago would be breaking today. But I do find that my apps from 3-4 years ago still run just fine, albeit not exactly easily updatable due to third party dependencies lacking support. But I’ve had good mileage with all of them, in fact last week, while needing to demo a very old app, realizing it had been pre 1.0 and needed upgrade, it took me about 10 minutes to upgrade to 1.3.5, granted it was a rather small app with very minimal 3rd party dependencies.

Regarding deprecations of technologies, well that’s eventually going to happen. Mind you they still do support them, and they even agree to hand over governance to the community for those would be deprecated parts. But you should also understand that if they are deprecating something and advising the community to move on to some X stack, you probably should listen. I used to be a vocal member of the “we want blaze” camp until I decided to take an actual, willing and positive look at their suggestion, React and now it is my go to ui stack and I’m actually trying to see if it would be worth converting old Blaze apps to tap into what React has to offer for the future!

And it is all the same with GraphQL. I keep finding myself trying to tame reactivity, tearing down subscriptions to convert them to method calls or trying to mark them as non reactive, only to see that where I’m trying to architecturally head towards, MDG is already there with Apollo! There is a reason some very smart people decided to bet 20 million dollars on them some years ago when they did not even have any monetization strategy whatsoever! They’re even on the innovators quadrant of a Gartner report. For those who are not familiar with what Gartner is and what it means to be on one of their reports, let alone the magic quadrant, that’s h-u-g-e!

Anyhow, regarding their vision, I think they are spot on with their strategy on separating their core offering into

  • Data (Apollo)
  • Build Tool (Meteor)

Now, Apollo is arguably the most innovative GraphQL solution out there.

And I don’t know you guys, but if I wanted to develop a JavaScript app, build it for web, iOS, and Android, and possibly Electron and while at it for other targets such as a Chrome Extension, I know I can quite easily achive my build tool setup within a few hours on Meteor and a few packages.

On the other hand, trying to achieve the same using a host of build tools, getting them to play nice with each other, configuring endless files, digging up gotchas in documents and github issues would probably take at least a week or even more, for what, to be able to say “Hello World”.

I don’t know what MDG’s plans and intentions are in monetizing their innovations, but they are smart people and their investors must as well be as smart, given their track record on other investments they’ve made. If those investors have cast their vote of confidence on MDG, why should you care if Galaxy makes money or MDG may or may not be able to profit? How much revenue did Instagram generate before getting acquired for a sizeable $1B? 0! Z E R O that is, 0!

I think what we can do to pay back is to actually enjoy what we have and stop second guessing this every other day. Yes they do have notoriously bad communication skills, but hey, I’d rather have them giving me the next feature then explaining me why and why not!

So there you go, I believe you should grab tight on MDG’s vision, probably even be an early adopter as much as you can, and sleep sound knowing you’re in good company!

Oh and, where else did you ever see such a vibrant, selfless, helpful community? The worst case scenario, you will have made a lot of very smart friends here on the forums and should MDG ever tank - god forbid - you’ll have them caringly embrace and guide you towards a solution :wink:

43 Likes
9

As we’ve communicated over the past 6+ months, we’re investing heavily in Apollo to make Meteor better so it attracts a much larger community of professional developers to ensure it’s longevity. At the same time, we’re aligning Meteor (and Apollo) to the modern professional developer ecosystem vs. continuing to make it a closed, esoteric stack that may be easier-to-use for some but only for small slice of the app dev world. The world of developer tools and platforms has evolved since the early days of Meteor and MDG’s decisions in R&D and commercial efforts reflect where we think the future is heading. A cornerstone of the strategy of expanding to a larger market of professional developers also includes new commercial products and paid services which we’ve already begun delivering for GraphQL via Apollo while continuing work on Meteor & Galaxy too.

I recommend watching the various roadmap and strategy talks we’ve shared in recent months; we’ve been very transparent in our intentions and have generally delivered on what we’ve committed to (with a lot of help from the community!) and we’ve got a lot more coming this year!

“Meteor 1.4 and Beyond” - Matt DeBergalis

“Product Roadmap and Strategy” - Matt DeBergalis

“The Future of MDG” - Geoff Schmidt

30 Likes
11

This is great thanks.

I would ask the following question; MDG is focusing on Apollo as you said to attract more developers (“attracts a much larger community of professional developers”), basically scale. MDG needs bigger scale both for growth, marketing and as a company. And please don’t make this just about the community or “ensure it’s longevity” maybe to MDG longevity at the end of the day MDG has raised a lot of money and needs to show growth. Basically what Ruby on Rails or Java has done.

This makes sense and is great but can we expect the meteor framework to have the same amount of effort as Apollo? is MDG committed in keeping meteor alive? Yes there is the roadmap but we can we get an official statement that is very clear and straightforward.

When you think about Apollo it makes sense to use it with other stacks for example Node.JS and Apollo if that is the case why would we need meteor and wouldn’t MDG look at meteor the same was as it did with Blaze. IE we offer Apollo which is the core and then developers will choose their stack which has wider community support like Node.JS or RUby and for client React or Angular. How does meteor fit in this?

1 Like
12

I’m not sure what you mean by “can we get official statement that is very clear and straightforward”; between what we’ve communicated about our product strategy via official videos I’ve shared and actual open source work on the Meteor and Apollo projects, what specifically do you think is missing?

Our investment in Apollo helps accomplish two goals: make Meteor more usable by more developers + make Apollo/GraphQL a key part of all modern apps. The two open source projects intersect and our experience with building the data system for Meteor now informs Apollo R&D. Right now, building Apollo is the single best way for MDG to invest in Meteor. While Apollo enables better support for non-Mongo data sources for Meteor apps (1.5 release), Apollo is also usable in non-Meteor apps as well (e.g. Node, Ruby) - it would be foolish to only enable GraphQL support for Meteor. But don’t attempt to create controversy by oversimplifying the tradeoffs; they aren’t zero sum. If we weren’t investing in Meteor, why would we bother putting Apollo/GraphQL in the 1.5 release? Remember, we also have a set of commercial products and services for that depend on Meteor and Apollo adoption which gives us the ability to continue investing in both.

17 Likes
13

I think the absolute worst case scenario is they hand meteor over just like they (presumably will) hand blaze over.

I think that something like the below could be useful for blaze if not meteor. If people really are dependent on Blaze/Meteor, they should be okay with donating $10 a month to something like this… and maybe more “corporate” sponsors would donate more. It wouldn’t take much to provide the funding needed to keep Blaze/Meteor running:

https://opencollective.com/

Incentivizing Open Source Authors:

14

Hi,
First appreciate you and everyone else taking the time to clarify everything, the idea was to get real feedback as I do care for the platform but also have clients and decisions around the future on were things are heading. The best way to make clear, informed and a good decision is to ask hard and honest questions.

Saying that no one is trying to “create controversy” if you can’t take the hard and direct questions then maybe someone else should answer them. Also let’s be honest MDG did a bad (thats the nice version) with Blaze I can send you 2 / 3 threads were the entire community was pissed off about this not to mention MDG backtracking. So you can me and the community the benefit of the doubt.

To make things very simple and direct.
Apollo is great and we allow meteor applications to connect to different data sources like SQL and it will also let none meteor frameworks like Ruby, Node ect… enjoy real time this is amazing and I look forward to it.

The question is very simple if I can use Node + Apollo + React and it does what meteor does why should I use meteor? Will meteor last? Is MDG committed to provide vaule within meteor that is better then Node or Ruby. At the end the only thing that is really MDG is Apollo.

Also what I have seen MDG talks about meteor becoming a toolkit is that a full developer framework or the command line tools to deploy and host your application? Maybe I missed but that’s why I’m asking.

Finally yes do more were developers and it’s a community so you can always do more and be better. I don’t maybe hire a community manager

15

I guess part of the question is “For existing Meteor users who have chosen Mongo because of Meteor, are obviously not on rails/raw node and are very happy with the mongo syntax, why should they be happy to see MDG using part of its bandwidth focussing on Apollo/graphQL?”

This is like “For people very happy with Blaze, why should they want Meteor to spend time on other framework/focus less on improving what is already working for them” Maybe they have no reason to. Or you’ll have to convince them that having a larger community involved in a smaller set of common features is actually going to bring them some benefits, or that you’re making some changes that are better for their future. This is not obvious for all current Meteor users about Apollo.

It probably makes a lot of sense for Meteor as a company to look for scale (and $), but it’s not obvious for its users that this the first thing they need. We’d all like to be convinced that “building Apollo is the single best way for MDG to invest in Meteor”, but from my point of view with my Meteor product working fine, I’m not looking forward to a change in stack. I’m looking forward to having my stack work better.

2 Likes
16

As a consultant, you should always use the best technologies possible to deliver solutions to your clients. Period. It’d be fairly arrogant for us as an open source vendor to believe that only Meteor should be used for web and mobile development. As Meteor aligns with the larger JavaScript ecosystem and also supports GraphQL-based integrations/data sources, you’ll have more flexibility than ever to bring state-of-the-art tooling to your customers’ apps.

Will Meteor last? That isn’t a question that MDG can solely answer; it’s something that you and the Meteor community answers with your valuable time: time spent on contributions, time spent on content creation, time spent on professional app dev using Meteor. And I’m not sure what you mean when you ask “Is MDG committed to provide vaule within meteor that is better then Node or Ruby?” I also don’t understand “what I have seen MDG talks about meteor becoming a toolkit is that a full developer framework or the command line tools to deploy and host your application?”

2 Likes
17

Maybe it just me but it feels you’re avoiding the question by just saying “I don’t understand”

2 Likes
18

Can you please re-phrase the question(s) you want answered? Your words/grammar aren’t totally clear to me.

19

Will do once I get some sleep been up for like 48 hours, would you prefer email? Don’t want to keep going back and forth and create negative issues / comments

20

I think you’ve answered your own question: because MDG is a VC-backed startup vs. a non-profit foundation like Apache, we can’t exist only to serve our current set of open source users. As a result, our company sometimes (but not always) prioritizes decisions through the lens of delivering open source technologies that are useful to larger future populations of developers vs. a smaller current set. This is because some percentage of developer adoption eventually needs to yield revenue through commercial products/services if MDG is to stay in business. I understand that MDG’s strategic goals of growth may not easily translate into clear features that some of our open source users really want; but our community should understand that the more growth MDG achieves (both open source adoption and commercial revenue), the more likely MDG can continue to fund projects like Meteor with engineers, community programs, and infrastructure. We know (and really appreciate) that developers like you vote with your time through contributions and Meteor apps built; sometimes with your money if you use Galaxy hosting. So it requires constant prioritization for us at MDG to continue to earn your time/contributions/money through releases that are both immediately useful and/or also continue to grow the size of Meteor community.

14 Likes
21

No, we should keep discussing here as it’s important for the overall community to hear the discussion surrounding the controversial question you raised: “Is it time to leave Meteor & MDG?”

9 Likes