I started an issue here on GitHub, but wanted to bring the conversation to the general audience so that we could get some more opinions.
Back when the infamous Blaze thread was announced, I noticed the vibe in the community changed, completely. Given how unpredictable and unplanned it was, people had difficulty trusting the platform.
The people that I’ve kept contact with here all began to slowly diversify and ultimately abandoned the eco-system. Perhaps the biggest indicator of “lack of faith” I’ve noticed had been in Meteor Toys sales - that thread really hurt sales.
Apollo multiplied that effect even further.
However, many of us are still enjoying Meteor, its a good product and the alternatives may not be so attractive. It also looks like Meteor may be expanding to new audiences. Plus, Ben had been doing a lot to ensure Meteor is up to par with the competition.
One of the things that made people confident in IBM, Microsoft, Node, and even some Meteor packages, is long term support, and it would be great to see Meteor restore confidence in its community through similar means.
What do you think? Would this impact your choice on using Meteor and/or sticking with it?
Agreed, now that the dust has settled on the Meteor alignment with the rest of Node ecosystem thanks to great work of benjamn, abernix and the rest of the community, I think it’s great opportunity for the MDG leadership to strengthen the confidence and the support for the platform.
There are several ways of doing this and long term support is definitely one of them. I truly believe that Meteor has a unique value proposition, Apollo got a lot of marketing in the last year or so, but if MDG push a bit on Meteor marketing, I’m sure it can reach much wider audience.
But personally my source of confidence in the platform is seeing really smart and skilled folks like benjamn, abernix and rest of community believing in the vision and keep pushing forward. And my other source of confidence are the success stories we hear about in the forms of people starting business and doing startups using Meteor.
Completely agree. Long term support was one of our top concerns with our project.
We generally have been very happy with Meteor. Our main worries have always been “will Meteor still be Meteor in the future”, fear of abandonment, and worry of refactors being too large without any features to assist with migration (for example, when Apollo is added to Meteor, or worries about the Meteor package functionality all being lost when they move to NPM completely).
Meteor has came a long way and I believe now would be a great time to start marketing more & offering long term support - as long as MDG is actually prepared for that. We might NEED to get any major factors out of the way first, so that may be why MDG is waiting.
One of the reasons behind lower sales of your tool is probably the fact that Meteor has become advanced system for pro teams not a tool for newbies. And pros don’t need GUIs that much, only hardcore, only plain text!
You can still use Meteor exactly how you did back in the day as well. At least, until backwards compatibility is completely removed (if that still happens).
I don’t think this question can be answered unless we define what “Meteor” means. If you look at where the team has been focusing their efforts lately you can clearly see that some areas are priorities while others aren’t. In my opinion a lot of the frustration here comes from people who don’t want to face the fact that today’s Meteor is a very different beast from 2015’s Meteor.
To give a concrete example, if what you value most in Meteor is having an integrated, simple front-end layer you’re probably pretty disappointed right now. On the other hand if you value a faster, more capable build tool, then there’s never been a better time to be a Meteor user.
The thing is, if you want that you’ve still got it. Except that you probably don’t realise you’ve got it, because (as others have pointed out) the tutorials are all focused on the “new” way of doing things.
I don’t know what the answer is, and I suspect neither does MDG. You either promote Meteor as the best way to develop modern JavaScript apps - which inevitably leads to professional coding standards and a perceived steep learning curve, or you promote it with an ultra-low barrier to entry. The danger with that being that the expectation is set that to use Meteor you don’t need to learn anything - and that path leads to disillusionment.
Agree 100% with this. Meteor’s way better today than two years ago, but old impressions linger if you weren’t too impressed back then. So, now’s the time to hit seasoned JavaScript developers hard with a strong message: Meteor’s here to stay, it makes your life easier, you still get to develop with all the stuff you want to use, and you get a build tool which generates standards compliant JavaScript.
Bring back the great marketing: the seven principles - they’re as true today as they ever were - just because others have copied some of them doesn’t change that. Promote “star Meteor on github” again. Get @gschmidt and @debergalis on the promotions circuit again - they’ve got so much more to shout about now!
Indeed - whatever one might think of Meteor, it’s the only tool of its kind, and a lot of companies built successful products with it.
+1 - Meteor has “matured” a lot now, and whether you like to using real-time JSON with the MongoDB/LiverQuery stack or prefer something like Apollo, there’s a time, place and path for both. Now we just need a way to stamp in that status.
That’s sort of the thing - MDG has actually done a better job than we expected in this department, and by not offering LTS, they heavily undermarketed their work.
It’s actually very much the same beast as always. It just became more flexible and so people have begun to deviate from what I call the “righteous path”
I think a big discussion is, since Meteor is a “big” product now, what do we want to stabilize?
Here are some ideas:
DDP: this really should have been broken out in like an organization, like ddp.org
MongoDB support: will it keep up with new MongoDB versions?
Pub/Sub + LiveQuery -> this is still crack and the community is finding ways to scale it.
Methods & Fibers: we want to know that the logic we write will work long term
The coding style of the “new, modern” version of JavaScript
Meteor-specific packages: this is how many write their apps
Build tools: perhaps some kind of guarantees around how the build system will work?
Cordova: is it guaranteed that this will always be updated and maintained?
I do think, that Meteor needs to re-think the way it cuts and slices the system into multiple packages… then it would be much easier to reason what has LTS and what does not. A thread on that coming up in a bit…
That is so true, technically they’ve done an amazing job keeping backward compatibility.
That’s great marketing strategy right here! a lot of great and actionable ideas on this thread! I also would love to see @gschmidt and @debergalis back on pushing Meteor, their understanding and vision for JS ecosystem, web and software industry as whole are very inspiring.
I think that’s a great list, and with the possible exception of Fibers it should be doable.
I don’t think MDG can really make any guarantees around Fibers - they’re really completely outside the “standard” Nodejs ecosystem. While I love them and they really have done what MDG wanted, they are probably not sustainable in the long run. The rest of the JavaScript ecosystem is settling on Promises - and specifically async and await to solve the sync-style programming issues that we Meteor developers have been able to ignore.
So, I see three ways forward:
Fibers keep up with Nodejs. Unlikely in the long term in my opinion.
Ditch Fibers, but use async and await under the covers. This gives us source code style compatibility.
Ditch Fibers and adopt async and await with a smile. This puts Meteor on the same playing field as the rest of the community, but means rewriting potentially lots of code. However, much of that could be transpiled or fixed in-place by some utility.
My personal view is that 3. is the best option for long-term sustainability and penetration into the rest of the JavaScript community.
If it helps you get the idea - the drop happened right alongside the thread. Before, people viewed buying the tools as an investment for 1 or 2 years since Meteor just kept getting better.
After those announcement, they just had no idea what is next. The community is still in that state of anxiety today - we do not know what will happen to MongoDB support, the accounts packages, or anything really.
Oddly, what we see is, Meteor is getting better, but on the marketing side, they opposite is being signaled.
I started an discussion on GitHub in regards to how Meteor can be better “split up” to give developers more ways of controlling their application:
If we slice up the system, perhaps the packages can then be exported into their own repositories. The main repository would host the build tool and serve as the integration point for all the other packages.
Once we have a good layout there, MDG can designate LTS support for different parts of the framework.
As far as immediate term support is concerned – I would classify it as breathtaking!
I posted an issue 2 days ago, and @benjamn published the fix less than 4 hours later!!
I think people need to decide how to fund all the work. Maybe MDG can’t afford to invest in meteor anymore. They’re a company. I think the community needs to do one of two things:
Make it a habit to use Galaxy. So many people complain about the price, post threads about setting a $5 container up on DO-- and whatever. Then they cry about MDG not investing in Meteor enough. Galaxy is an interesting way to fund MDG’s galaxy work. Maybe MDG can earmark 10% (or whatever %) of Galaxy revenues to be used for fund Ben and another dev’s FT work on meteor? Then maybe people will see the increased price as not just a good value, but as a simple way they can help keep meteor alive.
MDG (or someone else) should setup a crowdfunding account to fund as many FT devs as we can get to work on Meteor.
Otherwise, I don’t know if we can depend on people working for free (open source or at MDG).
The idea of pinning it all on marketing is tough. People in general (and devs too) buy into hype. People buy $400 sneakers even when they can get the same thing for $50. Devs are constantly chasing libraries around.
I hear you 100% - and I really do not get the people who spend hours to save the $10 premium on Galaxy.
The thing is, people who look for LTS (Long Term Support) are usually people who are looking to build real businesses. They may also be the people who wouldn’t sweat paying for the $500/mo tier for Galaxy.
I agree, promote Meteor more and get more people to buy into using Galaxy. I really believe in Meteor and what it has to offer, and would love to see it be as popular as Rails for building web applications. That said, I do think Galaxy would benefit from “hobby” accounts, basically ones that people can build proof of concept ideas on, and then encourage them to understand the value of Galaxy and, ultimately, become a paying customer.
Your suggestion to structure the ‘journey-discussion’ via slices or however this shall be named is important. Ideally, each slice with some back-up or plan B option (which could be somewhat secured on specification/interface level only, also avoiding to divert effort but structure alternative discussions a bit better and be able to have some leveraged strategy).
Anticipation remains key, not for speculation but to be able to act on time (be able to read various signs/trends); in case one ‘slice’ is under fire, lost traction or support; a replacement initiative could be timely engaged. Anticipation and flexibility: if some ‘slice-architecture’ is not established a fire or crisis in one key area may drag the whole full stack down ('ships have still compartments to lock full flooding / draining).
Also, having only Apollo as efficient hosting is a nogo for most larger companies (lock-in risks are much to high; here there must be two redunant ‘slices’ companies / services at least if this should scale up and sustain, this competition is also requied to scale-up Apollo).
FYI: This input is based on 43 years IT experience - Meteor encounter some 3 years ago during regular IT evolution/evaluation tracking (so far mainly checked performance on deep lists via JSON MongoDB imports), browsers perf. vs. Angular /React and follow re-run on new versions. Yes 1.5 seems pretty good (no regression seen yet).
Then, Meteor was/is a great full stack I recommended to check for (architecture / process - UX cycle speed) learning or to start some pilots (large company).
Consider, each slice will get under fire periodically or will encounter the better solution and needs to be replaced (reason I put my years IT exp.). On the positive flip-side the decision may come from the Meteor community to replace (for a better solution) a slide. Dependencies (License) are also becoming more and more complex, obscure to manage (e.g. React).
Congratulations to core team and contributors , Hope you will stay engaged and motivated.
