Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improving the collaborative process between MDG and community #10477

Open
KoenLav opened this issue Mar 1, 2019 · 76 comments

Comments

@KoenLav
Copy link

commented Mar 1, 2019

❗️ Bug
I think I found a bug in the way the development of Meteor is currently organized and would like to work together with the community to resolve this.

Instead of hijacking the 1.8.1 release thread (sawry), I'd like to get a constructive discussion going here with the end goal of establishing better communication between MDG and the community.

The Issue
The resources which MDG currently commits to Meteor, a rather large open-source framework, combined with the (lack of) communication around this, causes uncertainty which leaves the community with insufficient confidence in the future of Meteor.

Key terms

  • Resources: Meteor is too big to run by a one-man team;
  • Communication: Lack of communication causes uncertainty.
@KoenLav KoenLav referenced this issue Mar 1, 2019
@smeijer

This comment has been minimized.

Copy link

commented Mar 1, 2019

I'm supporting a topic like this for the full 100%. Like I've mentioned in the release branch, part of me feels wrong about "complaining", as it's a free product. And we often have the (unspoken) rule of not to complain about something that's free. Or that we should fix it by contributing or forking ourselves, as that's the spirit of open source.

That being said, I also believe that a company that got a 31 million USD investment, should be able to handle the community that made this investment possible. I strongly believe that it's the community that makes investments like this possible. Even though the brains behind MDG Meteor deserve some serious respect.

2012 - https://blog.meteor.com/meteors-new-11-2-million-development-budget-7370586949e7
2015 - https://blog.meteor.com/announcing-our-20m-series-b-funding-49dcfd3c3c6f

The 2012 blog, contains the following quote of Geoff, CEO of MDG:

Our agenda for the next few years is as follows:

  • Support the Meteor community. This includes everything from publishing books and organizing conferences, to being responsive to bug reports and pull requests, to finally making some cool tshirts.

The 2015 blog, contains the following quote of Geoff, CEO of MDG:

Our continuing commitment to you is to ensure that we deliver on 3 things:

  • Meteor. ...
  • Galaxy. ...
  • Community. The software is only half of the picture. The Meteor community is the other, equally important half. We would be nowhere without your support in building, evangelizing, and extending the platform. Meteor Development Group exists to serve and support you, so let us know how we can help, and we will listen and do our very best.

So, after receiving a 20 million dollar investment, the community was "half of the picture". I can definitely agree with that. @gschmidt, you're welcome!

To get the timing right, the 20 million USD investment was May 19, 2015. Then on November 18, 2015, Geoff published a post on the meteor forms in response to all that was happening around the Blaze (communication) fiasco.

2015 - https://forums.meteor.com/t/next-steps-on-blaze-and-the-view-layer/13561

You can stop reading after the first paragraph, let me quote:

Hi everyone,

For those of you I haven’t met, I’m Geoff Schmidt, one of the original Meteor core developers and CEO of MDG. With Galaxy in the field now and doing great, I’ve been able to clear out a big chunk of my schedule and you can expect to see me much more active on the forums.

I've done some analyses before, and came to the conclusion that his activity didn't really grow after that statement:

              Geoff          Sashko
Joined:       Feb 27, '15    Feb 24, '15
Last Post:    Feb 22, '16    May 1,  '18 
Seen          May 10, '16    Jul 12, '18

STATS
visited:         86 days       807 days
read time:        7 hours      240 hours

topics viewd:    51          5 900
posts read:     638         35 100
topics created:   6             71 
posts created:   22          3 000

A comparison I made on 5 October 2018, between Geoff's activity and Sashko's activity. At this moment, I cannot create new stats as his profile has been made private.

To quote me from that topic (link above):

He hasn’t been here for over 2 years. Only three months after the post mentioned above, right in the rural times of Meteor. He decided not to come back to the forums and listen to or get involved with the community.


Don't see the part above this line as crying or complaining. I believe it's important to know your history, to be able to learn and move on.

Point being, I've lost faith in changes. The year of the 20 million USD investment, is the year they lost the connection with the community. This is confirmed by this SO trend line:

Meteor Trendline

source: https://insights.stackoverflow.com/trends?tags=meteor

We're dealing here with a CEO that promises to get involved but doesn't. Leaving the impression that he took a nice share of the 31 million, and just doesn't care anymore.

I wouldn't be surprised if Apollo would get some nice funding any time soon.


TLDR

I lost faith in changing this company, and try to make it listen to its community. They have/had a few awesome developers there (@stubailo, @benjamn), but I'm not a fan of management, so to say.

My hope is in creating a fork. There are some great ideas out there that can be used for an initial roadmap; see https://forums.meteor.com/t/thingking-about-meteor-2-0/46022

Perhaps some great contributors like @zodern, @yorrd, @StorytellerCZ, @KoenLav have thoughts about this and can chime in it. (not in a specific order, and sorry if I missed your name).

@morloy

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2019

I see two options for making Meteor the great thing it really can be:

  1. Adding official maintainers from the community
  2. Create a community-maintained fork

For MDG, I have the feeling that they are too much focused on Apollo. It seems to be a great project and a good path for MDG. But the current state of Meteor misses many exciting opportunities.

@benjamn

This comment has been minimized.

Copy link
Member

commented Mar 1, 2019

Can I ask a concrete question of this group?

What specifically matters to you about the final official Meteor 1.8.1 release that isn't satisfied by the beta releases?

The long release cycle exists so that folks who need the new stuff can begin using it sooner, and those who can wait for the official release will (eventually) benefit from all the testing and validation that went into the beta/RC process.

From my perspective, if you're a Meteor developer in 2019 and you don't know about the beta/RC release cycle, you're probably not actively invested in Meteor development, or in Meteor's future. And that's fine, but it means you're enjoying the benefits of free software without helping to ensure its longevity. If the relative infrequency of official releases bothers you, you've probably already figured out that the beta/RC cycle is the place to be.

I've tried in the past to make predictions about when official releases will happen, and it just doesn't work. Unexpected contingencies like Cordova bugs emerge at surprising times, and demand my/our attention. I'm sorry that I've ignored requests for new predictions, but please understand: my predictions will always be pretty vague, because I don't fully understand what you're (collectively) looking for in an official release.

If you have a specific feature or bug fix that you'd like to see released officially, and you think it's ready to ship, I would really appreciate that kind of feedback. Obviously those requests need to be balanced against any bugs that other folks are expecting to see fixed, but concrete reasons to cut an official release would help a lot. Right now the 1.8.1 release is in a sort of limbo where I'm waiting to be sure the update process will be smooth, and passive developers will be glad they updated. Are we there yet? I genuinely need your help to make that call.

@KoenLav

This comment has been minimized.

Copy link
Author

commented Mar 1, 2019

@benjamn wow, claiming that the people mentioned in this thread aren't actively involved.

There's a lot of things in your answer I'd like to reply to. But let me first reply to this; if MDG needed the help to decide, MDG should have asked.

Communication.

Even without MDG asking, people told their stories, for instance the Cordova/HCP changes.

I'll make sure to reply more later...

@benjamn

This comment has been minimized.

Copy link
Member

commented Mar 1, 2019

Please allow me to clarify: I absolutely consider all of you to be actively involved in the beta/RC process. If that wasn't obvious, then I misspoke.

I still want to know what you—as actively involved beta/RC-using developers—want from an official 1.8.1 release (or any other official release) that you're not getting from the betas.

@morloy

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2019

Personally, I’m fine with the current release cycle. I simply feel that there’s a lot of stuff in the pipeline that doesn’t get ready just because MDG isn’t dedicating the resources to Meteor.

For example, Typescript support was announced in the Meteor 1.8 blog post. And it seems to be used internally by MDG, but apparently there’s no time available to clean it up and make it public.

I opened up a PR for source maps in Nov ’18 and didn’t yet receive a single comment from the maintainers. This makes me feel that Meteor simply doesn’t get the attention from MDG that it deserves. Meteor has 40k+ stars and is the best full-stack framework out there, but not even one maintainer working full-time on it (this is my guess and might be wrong, but everybody at MDG seems to be working on Apollo as well). It’s quite sad to see Meteor float in the void without a clear roadmap.

@yanickrochon

This comment has been minimized.

Copy link

commented Mar 1, 2019

I may not have contributed directly to Meteor, but I have been following this project for about 6 years now, and have at least one medium-sized project currently running on some private company server for the past 3 years without failure.

My biggest issue from MeteorJS is how quickly third party projects and libraries fall behind. If I want to start a new project with the current stable release of Meteor, some tutorials no longer work, or the referenced projects are simply dead, not maintained. This is, to me, a project killer. How many times have I heard project managers argue over open source because of "lack of or unreliable long term support"?

Extending the release periods is fine, as it gives enough time for third party projects to keep up to date, but there should be some way to monitor the compatibility. For example, the accounts-ui has not been significantly updated for the past two years, and the Angular tutorial should be called "legacy" because AngularJS is on life support (LTS).

So, release cycles should include :

  1. Updating the docs with up-to-date tutorials, using most recent vendor updates (e.g. Angular)
  2. Making sure that all the "must have" third party packages are maintained and still actively supported.

These things should get the community more involved, and increase the level of assurance in the Meteor ecosystem.

m2c.

@brucejo75

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2019

OK, I am ignorant of your current processes 😺

I was starting to write my response when I rediscovered this: https://github.com/meteor/meteor/milestone/61

For me this helps explain why 1.8.1 is not released yet! That is where I can get specific in my feedback.

Some tweaks

I also like the model that VSCode uses: https://github.com/Microsoft/vscode/milestones

  1. issues in current release (are addressing)
  2. issues on deck for future releases (intend to address soon)
  3. backlog (would like to fix)

Curating these lists is quite a bit of work. But they communicate very clearly where future energy is intended to be put into the release.

Time based releases?

I have observed when projects move to time based releases (e.g. VSCode: monthly, node ~weekly) it has the effect of building confidence with all stakeholders. I experienced this first hand many times and it is a simple fix that is usually easy to make.

I think Meteor could move to a quarterly release cadence and that would help build confidence in the overall processes. To make it work you will need to start enforcing some tough standards:

  1. the schedule is feature priority 1, nothing can block this.
  2. to be in a release, you need to be submitted with zero known bugs. This makes sure that the release is all about the integration of all features, not the debugging of a feature.
  3. if a feature is blocking a release date, it can and will be dropped.
  4. there will be internal dates on a milestone (e.g. nothing, absolutely nothing new 30 days prior to release date)

Each quarterly release could drive a theme or 2. Or a release could simply be about fixing bugs or cleaning up tools. But each quarter a release is made.

@StorytellerCZ

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2019

Would I love to see more communication and resources put towards Meteor? I think that goes without saying for any project I like and follow as intently as Meteor.

Can I personally contribute to the Meteor development? Only very little (busy with my day job and trying to start a business) that I have to blush when I see the Contributor tag next to my comments.

I understand the situation that MDG is currently in. My hope is that there is plan to move more resources towards Meteor and Galaxy (would love to see more regions - MongoDB Atlas region editor spoiled me 😋 ) once Apollo reaches some great point. It just means that in the meantime I have to do more (and I would like to if I didn't had more pressing matters, for example I would like to update the MongoDB functionality used by Meteor to allow things like insertMany, etc. in a nice Meteor way).

When it comes to releases I'm only afraid that there is feature creep every release (ie. how 1.7.1 became 1.8, which leads to long times between releases), I'm afraid that we are reaching the same point with current 1.8.1 work. But I'm in the beta process so that isn't that pressing for me. Though I would like to see more PRs merged after 1.8.1 and React packages are have some great PRs ready as well. Still at the end I don't have problem with the speed. At the same time revising the roadmap could be a good practice after each release.

In the end though I think @benjamn gets the short end of the stick here and for my part I'm extremely happy that he is focusing on development because that is where his talents are best used, if that means less communication on general stuff, then that is fine with me.

In the end this topic belongs to the forums (where this was being addressed multiple times) not on GitHub. I sadly don't think that any discussion here is going to get attention of the people that can actually change the current status quo. It is only going to waste @benjamn's time.

@sakulstra

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2019

I can somehow relate to the sentiment of this thread (although not very affected by it).

It's not sth special I want/need from this release. This release fixed some issues for us(mostly the node upgrade irrc) so we started using one beta in production at some point. More frequent releases would allow us going the beta route more lightweight as now we have to decide between: "upgrade to beta-x containing a bunch of stuff i don't know anything about and have no time to look into" or "miss out on patch releases". I feel like we're in the same situation as we have been in 1.8.

I personally am looking forward to https://github.com/meteor/meteor/blob/devel/Roadmap.md#full-transition-to-npm since the 1.3 blog post. For the last year we couldn't keep up with fixing/forking/inlining dying atmosphere packages we've been relying on. We've been facing similar issues as reported in https://forums.meteor.com/t/testing-meteor-apps-in-2018-a-rant/44662 and ended up not unit testing the meteor-serverside of things at all and using jest + a massive amount of mocking to test the rest. Perhaps that's a completely irrational thought/hope -> I'd just imagine things would be easier if meteor was better integrated in the npm ecosystem.

I don't expect that to happen in the coming releases, but I'd love to see some transparent communication on how to get there / how we as community can help getting there. I guess open prs like this one: #9603 somehow discourage leaps in that direction, although I personally always had a very pleasant and helpful experience with my prs (thank you 👏).

@jamesmillerburgess

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2019

I'm actually quite happy that MDG still supports Meteor as much as they do, even though Apollo has been such a success and investment there must certainly have a much higher ROI. That's not an easy choice to make for a small tech company with limited resources.

As @benjamn suggests, we use the beta versions when they have something we are interested in, so we aren't waiting for an official release before taking advantage of improvements.

The main complaint our developers have about using Meteor is long build times, and thankfully someone from the community has stepped up recently to help alleviate this issue.

@jamesmillerburgess

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2019

Actually I should note that @benjamn has been focused on build times and has done amazing work there. I’m just glad that in addition we are benefitting from community involvement on the issue!

@smeijer

This comment has been minimized.

Copy link

commented Mar 1, 2019

@jamesmillerburgess, I very much appreciate @benjamn his work, but unless I've missed something the recent performance improvements are thanks to @zodern and @yorrd.

That being said. @benjamn, In my opinion, the issue lies between the lines of your post. And thereby it's pretty much impossible for you to fix.

I think I can speak for all of us here when I say I'm thankful for what you are contributing. We realize that you are a busy man and try to do whatever you can.

And that's what our problem is. You're a one-man team. The post you've written is (understandably) very personal. "I've tried, my predictions, I'm sorry...".

I hate it that it's you who's the receiver of this topic. The thing is, we are grateful for your contributions. We are just missing MDG, your colleagues, CEO, marketing, management, communications, other developers/contributors.

Meteor is too big to run by a one-man team.

I fully understand that you can't or won't respond to all posts on the forum and/or github. It's not your job, and it's too time-consuming. And that's why you should have gotten support from other MDG members.

That's the thing. You are awesome! But you can't run this project alone.

So to you personally @benjamn, Thanks for your hard work! I'm grateful. Despite my frustrations towards your employer.

@jamesmillerburgess

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2019

@smeijer

I'm considering Meteor 1.8 with the delayed legacy builds to be recent, but maybe we are thinking in different time frames.

@morloy

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2019

@smeijer you got a point here. Meteor is too big of a project for the support it currently gets.
Maybe it’s wrong to blame MDG here. They have venture funding and need to look for themselves how to turn that money into a sustainable business. And maybe that’s not Meteor. (Although in this case, they shouldn’t be running on Galaxy as well.)

I wonder if the support of the community would be large enough to sponsor at least another full-time position, maybe via Patreon? I’d definitely throw in some resources to make Meteor a thriving project!

@KoenLav

This comment has been minimized.

Copy link
Author

commented Mar 2, 2019

@benjamn just to make sure; this is definitely not criticism on your work; I'm addressing MDG as a whole.

I guess I did misinterpret your comment, apologies for that.

I'm going to get back to everyone's questions and suggestions within a week; it's good to see there is significant interest from people to improve upon the current situation.

I don't think things are bad, just that they could get better and some structure/planning/communication could help with that.

With regard to 1.8.1; we've been using it in production for a couple of weeks without any issues (I also tested Cordova, but not yet the HCP changes), but shall we move the discussion specific to 1.8.1 to the release thread?

@yorrd

This comment has been minimized.

Copy link

commented Mar 2, 2019

Honestly guys, not trying to make this thread longer than it needs to be. This is going to be a +1 with a somewhat different perspective. I love Meteor, it cuts down on initial development time like no other tool to date. And believe me, I have done a lot of research.

@benjamn (sorry for spam tagging) there are two questions that I'm currently asking myself that both add up to the same issue: I just don't know what to expect from the future out of MDG right now. If I would and the goals would be useful to us (they have been so far), we as Adornis would invest heavily in community maintained packages and pull requests towards Meteor AND Apollo. We like and support your move to build a new data system (sorry for the stupid expression) and would like to be a part of it because you and the rest of MDG have proven to be a reliable source of innovation and thought-through software.

  1. what is the future of Apollo + Meteor, does MDG have a focus on bringing reactive data and optimistic UI (minimongo like) to Apollo? We're trying to hack together something that works inside Meteor and we're going to release it open sourced when we have something semi-stable. I'm skeptical towards this because live queries and optimistic UI (while certainly being possible) don't seem to be a focus right now if I interpret you guys on slack and github correctly
  2. what is the future of an officially supported TypeScript package? I started working on rewriting the whole barbatus package in order to support the new incremental compiling stuff from 3.3, but I'm just not sure if our work is going to be done in vain because MDG release a better version a few weeks later anyways

Conclusive answers to these two questions would help us plan more long-term and allocate resources towards open source software, mainly Meteor, Apollo and lit-html.

And to clarify: there is NOTHING WRONG with your release process and the way you do open-source, especially you personally, benjamn (like others have stated). Meteor for me is a prime example how a community engages and comes together around development of the platform. The ONLY thing we as a company are desperately in need of atm is clear communication on the current priorities. I'm not even sure who within MDG would make that overarching decision to be honest, and I think that's part of the problem.

Thanks for your time, I know this is a shitty subject for you guys and there are no easy answers here.

@yorrd

This comment has been minimized.

Copy link

commented Mar 2, 2019

@morloy we're interested in participating in funding or helping with development on Meteor, assuming that is what MDG would sign off on and support as well

@brucejo75

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2019

I looked at the issues that are holding up 1.8.1 and they are a little surprising for this release:

  1. They are pretty stale, a lot of them have not been commented on this year.
  2. There are requests for PRs, but the community has not stepped up.
  3. Some of them seem like internal / annoying errors that are kind of edge cases that should not delay the release.
  4. Some of them are waiting on MDG review input.

Are these issues really holding up 1.8.1? It seems like they are not?

Candidates for punting (not high priority and need work)

#10427 [WIP] Allow interrupting delayed builds.
#10381 Changing port in development can cause MongoError
#10366 Lazy compilation errors swallowed in certain circumstances
#10345 [wip] Remove multiple restart feature
#10230 Meteor including unnecessary node_modules
#10341 Source maps in standard-minifier-js
#10237 Multiple concurrent deploys to Galaxy puts deploy steps in a loop

Issues that need some action

#10277 Hot Code Push broken on iOS [is this resolved?]

@sebakerckhof

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2019

Thanks @benjamn for taking some time to get involved in this discussion, however:

I've tried in the past to make predictions about when official releases will happen, and it just doesn't work.

I don't think this is the issue at hand here. It's not so much about missed ETA's. We're all developers here so everyone understands how relative time predictions can be (when the 1.8.1 thread started my bet was actually on it being renamed to 1.9 around March anyway ;) ). But the complaints are about a total lack of communication.

MDG has always been untransparent about their future plans and roadmaps. Understandable, people will hold you up for it. This wasn't so much an issue when we knew that the main focus was on Meteor. But since 99% of the company is focused on Apollo this brings a lot of uncertainty. I think this uncertainty is the core of the problem and can be alleviated with even a little bit of communication. There's people building their products on Meteor without a clue if MDG is planning to keep Meteor alive. That can feel frightening. Seeing there's been very little activity since December on the Meteor repository and you working on Apollo doesn't help.

Now we can say that MDG doesn't owe anyone anything and it's open source so everyone can contribute if they don't like it. But MDG is also not very welcoming towards contributors. There's PR's that have been open for a year without any comment of any MDG member. This is of course partially due to an understaffed team maintaining Meteor, but even a small comment stating your thoughts would be so much more motivating for contributors and will in the long run benefit everyone.

@amerzad

This comment has been minimized.

Copy link

commented Mar 3, 2019

I know my words may just be wrong, completely out of context or plain stupid or theoretical, but here is what I have in mind.

I personally have developed several apps using Meteor, and some of them are in production, and the operations guy love Meteor because it is the best scaleable solution we have compared to several other frameworks, and it actually allowed for a very big productivity boost for simple solutions done by very newbie developers with training of less than 4 months, and some of these solutions are in production for more than 4 years without any serious problems.

Yet, by time, Meteor apps was always in danger of being replaced with something else because some developers didn't like that so much magic in Meteor, but that was not the actual problem with them.

The actual problems is that, they think having Meteor in their CVs is not that impressive like having Django, Laravel, or even Express.js because these are the ones they are hearing about everywhere, and they are the ones which big companies are doing their projects with, and because Meteor was very easy and powerful to the degree that they started thinking that it cannot differentiate strong from weak developers!

Yes, they are guilty of following their benefits over the benefit of their projects and companies they are working for, and even the management is guilty of preferring the developer experience over the actual benefit and economics, but that is the reality, at least according to my experience.

In the Islamic literature, I had read a wisdom which I feel that it is very very real, which says: Oh son of Adam, nothing have driven you like delusion.

So, how to make the hype active again for Meteor so new/old developers will be willing to spend their time and learn Meteor and participate in the forums or at least increase the download rate and make them press that star button?

I feel it is just that problem with all the guys who complained about the silence.

But for my self I would say, silence is good. I personally look at things from the perspective that I will die tomorrow. Nothing is more important than being quiet as much as possible so we can listen to the reality. And the reality I see is that, Meteor is still relevant to my work as it was from five years with no future guarantees, but I have one new catch, big changes are up ahead, mostly driven by AI, WebAssembly and SaaS, and these things are the only things which worries me about Meteor future, and my career in whole as a Meteor developer.

But for others, I think they need some noise, and everything they want is some noise, so they can tell others and themselves that Meteor is alive. I personally think Meteor is still the best solution for prototype speed production development which can take you far enough before you will need to hit yourself with huge development costs of optimizing the performance. And that in my opinion is good enough for this age where 91% of startups are failing.

I am not saying there is nothing missing in Meteor or I am not annoyed at all by the very long standing feature requests, but I am saying, we (Meteor community and MDG) need to make that noise and do something which can impress people every while, or they will think we are dead, and their delusion could cause us to actually die.

Maybe I am the last one to say that due to how much little I contributed to the community, yet, be sure I fought many battles which Meteor was the flag I was holding, yet, pressure in the Middle East area is just huge, and humanity is writing a bad page of history in my region, so I don't expect this to change much, sorry, I wish I could do more, but at least I am doing some noise 😉

I am sorry if I offended anybody, I am almost completely stranger to your culture, and I hope I didn't do harm more than benefit.

@rj-david

This comment has been minimized.

Copy link

commented Mar 3, 2019

Summarizing the discussions, there are 3 major issues in this thread:

  1. Communication

  2. Resources for development

  3. Confidence on Meteor's future (in effect, can be a product of number 1 and 2 above)

@aliogaili

This comment has been minimized.

Copy link

commented Mar 3, 2019

Good summary.

Actually 50% of the forum posts (and please keep those post at the forum where they belong and let the devs do their work), are all the same:

  1. Is X dead
  2. Will X be alive Y years from now
  3. Why my feature (that no one else cares about) not being addressed
  4. If the dev go silent for a week, then panic mode is on. It's the twitter age and nobody goes silent..
  5. X was really good (just for me) Y years ago, why can't we go back?
  6. And the favorite question, I want a unix time stamp of the next release date when the devs are navigating a minefield of unknown unknowns with tight resources.

Despite the multiple times MDG confirmed verbally (and in code) their commitment to Meteor long-term, despite the many successful companies who are also committed to support meteor long-term, and despite the active repo with the interesting recent merges pertaining to build speed, people still need more social proof.

So in order to resolve this, I suggest public ceremony where MDG team does a wedding like voes that they'll be committed to commit free code to the repo for the rest of their existence.

Ok more seriously, I think adding more maintainers to the repo would help, the other potential action is forking, but personally I don't think this is necessary and might do more harm than good, I for one is happy with where it stands today, and hope it'll keep getting better. But I really think this post should have been in the forum.

@KoenLav

This comment has been minimized.

Copy link
Author

commented Mar 3, 2019

@aliogaili those posts turn into "is Meteor dead" exactly because they are on the forums (I think). Also most of them don't raise any concrete suggestions for improving things (aside from asking more commitment in word or actions from MDG).

This issue is intended to improve communication (and/or planning/structure) to get a more fruitful collaboration with the community as a whole.

Several people who have been actively involved in the development of Meteor have already chimed in, with either helpful points of view or even very concrete suggestions to (further) improve the collaboration.

A forum, by its definition, is a place for discussion, whereas an issue tracker is aimed at pinpointing and resolving issues.

That's the reason I posted this over here. I can see that this is debatable, but let's not turn this into a discussion (whether it's a discussion about what is the actual issue here or where it should be posted); let's focus on identifying possible improvements.

ps should MDG think this is better suited in the forums then I'm sure all of us won't mind :)

@aliogaili

This comment has been minimized.

Copy link

commented Mar 3, 2019

I see your point and there might be truth in it. I just hope this thread stays on-point, positive and constructive.

@coagmano

This comment has been minimized.

Copy link
Contributor

commented Mar 4, 2019

Big +1 here for an update schedule. Even if it's just to create in impetus to check and merge PRs.

As much as I don't understand the internet's desire for constant commits to a project, as long as there's updates coming through on a schedule we can point to that as a strong signal that things are okay.

As for my issue on brucejo75's list of things pending for the next milestone(#10366 Lazy compilation errors swallowed in certain circumstances)
It definitely shouldn't block a release. I haven't even run into it since 😆

@MastroLindus

This comment has been minimized.

Copy link

commented Mar 4, 2019

Just adding my 2 cents, mostly to agree with the others:
I am very grateful to @benjamn for his hard work. I truly am.

However as the person that needs to take decisions on which technology to rely on for my business, I cannot deny to be concerned about the current situation.
A huge framework like Meteor with only one main active developer maintaining it, it's a concern. Especially if in the last months that developer had a bunch of commits for meteor, and 40-50 times that for Apollo.

The problem is not what meteor doesn't support now. I think it is quite in good shape, (even if certain things would really be appreciated, I for one am also really waiting for official typescript support, or better support for the last mongo features without having to rely constantly on rawCollection()).
The problem is how much trust you can put in a technology that doesn't move forward very fast, in a world that is running at a ludicrous speed.

When as a decision-maker I need to pick one technology, I try not to pick the one with the best features. I try to pick the one that is more alive, thriving, in terms of community, maintainers, clear vision for the future, etc.

I really loved Meteor so far, but that love is mostly coming from how it used to be 4-5 years ago than now.

So what would I like to see from Meteor to help the situation?
1)Either invest more resources (especially active maintainers) in the project, or help the most active members here to step in if it's not possible
2)Release some form of regular communication (blog, wiki roadmap, github issues, whatever) maybe similar to what typescript and visual code's projects are doing, that states what is your vision, where do you want to go, what do you want for meteor at the end of the year, or so. It can also be "we just want to keep it in the current state, and maybe release some critical fixes if necessary". But at least it's clear and people can plan and decide accordingly what to do.

Little (maybe unrelated) disclaimer about Apollo:
I am very happy for MDG to be excited and investing a lot in Apollo, and I wish it to be very successful for you guys.
However I really don't think it fits many projects, especially small-medium projects, where the simplicity of Meteor is really the selling point. So I am not particularly excited about possible apollo-meteor merges, integrations and such, as I think they fit really different kind of projects. GraphQL is still far from being the industry standard and I would like to not have buy-in into it in order to enjoy all the other amazing tools you have built here.
I am just saying this to state that I really would like to see a future for Meteor as it's on thing, and not having to end up as a package for some other frameworks because of the lack of support.

P.S.: I still want to thank @benjamn , from developer to developer I appreciate the enormous effort you have put in this project for everybody else benefit. Being a one-man-team I just wish you didn't have to do everything by yourself, it's not good for you, it's not good for the community, it's not good for Meteor.
And thank also to all the others (@yorrd @hwillson and everybody else) for the contributions, you guys are awesome.

@aliogaili

This comment has been minimized.

Copy link

commented Mar 4, 2019

Very well said @MastroLindus!

I also share your perspective on Apollo, while I truly admire the engineering work on Apollo, I just don't see it reaching the level of impact that is has been hyped to be (REST replacement), it seems to be an overkill for majority of the projects. In fact, I don't even think it'll be as impactful as Meteor once the hype settle (but I do think think it's the go-to tech for a flexible enterprise APIs).

Meteor is at the core of many successful businesses and open source repos. We're using to power 5 enterprise apps and counting, we're using RocketChat and Wekan for task management which also powered by Meteor! I personally know that RocketChat is being deployed in Canadian and UAE government offices since it can be hosted internally.

Furthermore, many successful startups such Quali and Classcraft are very open about the role Meteor played in their success. In addition there is VulcanJS which powers another layer of web apps and sites such as LessWrong and there are many great community contributors such as CulfOfCoders and CleverBeagle.

I think a 40K star framework with such an impact does deserve more attention.

@KoenLav

This comment has been minimized.

Copy link
Author

commented Mar 4, 2019

@benjamn

What specifically matters to you about the final official Meteor 1.8.1 release that isn't satisfied by the beta releases?

From my perspective, if you're a Meteor developer in 2019 and you don't know about the beta/RC release cycle, you're probably not actively invested in Meteor development, or in Meteor's future. And that's fine, but it means you're enjoying the benefits of free software without helping to ensure its longevity. If the relative infrequency of official releases bothers you, you've probably already figured out that the beta/RC cycle is the place to be.

Using beta versions in production should not be necessary. The Node fixes (Fiber bomb) and Cordova changes (incl. HCP fixes) are the main reason for us to want to move ahead. We've definitely 'figured this out', but that isn't to say we're happy with it.

The long release cycle exists so that folks who need the new stuff can begin using it sooner, and those who can wait for the official release will (eventually) benefit from all the testing and validation that went into the beta/RC process.

This is a nice way of framing it after the fact, but the release post mentions a 'quick follow up'. So either there was a different planning and the community was misinformed, or there was a planning but it got thrown out of the window, or there really wasn't (isn't) any planning at all (my guess). In any of these cases more communication would have helped.

Just to make sure; I'm not blaming anyone, I'm want to isolate the 'issue' and work together in resolving it.

I've tried in the past to make predictions about when official releases will happen, and it just doesn't work. Unexpected contingencies like Cordova bugs emerge at surprising times, and demand my/our attention. I'm sorry that I've ignored requests for new predictions, but please understand: my predictions will always be pretty vague, because I don't fully understand what you're (collectively) looking for in an official release.

It would be nice to get an ETA on every release, but everyone understands this cannot be accurately predicted. What we do however know for sure that if there is no (communication about) planning at all then this produces uncertainty.

Even when asked about some communication about planning (whether expressed in time or work to be done) we (and I specifically) got zero reply:

@benjamn any rough expected release date for 1.8.1?

Or is there a concrete list of points which need to be addressed before release?

Maybe I should not have addressed you specifically (but then who?), but this would have definitely been a nice time to turn the question around and ask me/us/the community whether we thought it was ready for release.

Again, I'm really not trying to point any fingers, it's just about establishing where we can improve the proces (and maybe also even about finding out who is/should be responsible).

@brucejo75 created a nice overview on which outstanding 1.8.1 issues he perceives to be non-blocking, but let’s move this discussion back to the Meteor 1.8.1 release thread ;)

If you have a specific feature or bug fix that you'd like to see released officially, and you think it's ready to ship, I would really appreciate that kind of feedback. Obviously those requests need to be balanced against any bugs that other folks are expecting to see fixed, but concrete reasons to cut an official release would help a lot. Right now the 1.8.1 release is in a sort of limbo where I'm waiting to be sure the update process will be smooth, and passive developers will be glad they updated. Are we there yet? I genuinely need your help to make that call.

After asking this question I think the community, within hours, provided us with sufficient feedback to make a decision on this. Apparently merely asking the question sufficed. If there was some kind of process in place that would make this kind of collaboration more explicit I think this would help you as a person, MDG as a company and the community as a whole.

I hope we can agree the way in which MDG collaborates with the community can be improved; please let me know whether this is the case. If so we can quickly turn this thing around; instead of looking back at the past we should be working towards concrete improvements in the future.

@benjamn some people also raised the concern that this topic might just distract you from your other responsibilities and/or even that you're not the person we (as a community) should be addressing. If this is the case, please let me know and I'd happily discuss this with anyone from the MDG team.

I'll address a few more replies specifically before I attempt to provide a list of concrete action points which we might want to (eventually) split up into separate issues/threads/working groups.

@mrmowgli

This comment has been minimized.

Copy link

commented Mar 7, 2019

I'm going to add my two cents here, mostly because I still believe that Meteor is a great framework.

I think that @KoenLav is definitely shaping a useful conversation here. I'm personally on board and glad the conversation is happening and clearly productive. I understand the topic was changed a bit but there are a few things I'd like to mention as a long time user of Meteor.

I have seen a lot of change in MDG after the creation of Galaxy. I would say there was a shift away from community driven development. Definitely a lot of people left as part of the Meteor hosted community projects shutdown. I've also been watching the changes related to Apollo, and wondering where MDG was going with it. Things just generally seem to be losing focus.

One of the core things I loved about the initial incarnation of Meteor was the fact that it was clearly ahead of the game and opinionated. Learn the framework, become productive. Magic! Over time though things inside of Meteors original opinionated framework started getting dropped. Blaze is a great example. Blaze is a great system and deserves a lot of respect. However Blaze has been limping along with no new development for years and hasn't been released as an independent project that people could actually adopt and improve. What's the replacement? Angular, React, Vue? Whatever you like, including Blaze. In my opinion, constantly trying to support all of the possible combinations also means it's hard to rally around best practices, or solving common problems for the entire community.

So, I have a few suggestions in addition to the ones suggested above:

  • Become opinionated again: Figure out as a community what the best path to making an application that can grow if it gets traction and own it. Is it React, Coffeescript and Apollo? Or is it Angular, Typescript and MongoDB? Whatever the solution is, focus on that narrative and trim down the things a new adopter has to learn to be productive.
  • Standardize on NPM: Is Atmosphere a reliable source? Become opinionated, force NPM as a breaking change. Define a standard way of finding and identifying Meteor specific packages in NPM and push Atmosphere package owners to move.
  • Use Fedora and Red Hat Enterprise as an example: Fedora is the partially supported child that creates the innovation and community can easily contribute to and maintain. Red Hat Enterprise cherry picks and hardens the useful innovations from Fedora. Meteor Community could literally deal with the day to day, with some guidance from MDG, and MDG could have a cherry picked version that was security audited for production
  • Release in tandem with Node LTS versions releases: These versions are usually in preview for nearly a year before becoming the next LTS.
@MastroLindus

This comment has been minimized.

Copy link

commented Mar 7, 2019

@mrmowgli I think these points are a bit OT as it's more about concrete steps on where to take the future of meteor and less about the communication with MDG, but I'll answer quickly. I still think that both our posts should be masked from the main conversation though.

I would be against Meteor obliging you to work in a single, specific way, when supporting more is actually costing the same effort.
If somebody prefers React over Vue or vice-versa, I really don't see what's the benefit for meteor to restrict the use to one single case.
On the contrary, I can see many existing project maintainers that would get quite annoyed to having to re-change their code once again and re-learn again something new, when something that they already know works perfectly fine.
I am happy with Meteor making things 'easy' for me, without having to juggle between many configuration files and complex build steps. I am happy to have features like reactivity out of the box if I need it.
But if I cannot choose when or how to use something, or I cannot replace one part here or there, then the whole framework can become very quickly too limiting.

Imho the role of Meteor should be to allow you to reuse everything good that all the node/js community built and just make it really easy and straightforward to do so. Less of an implementation/framework provider, and more of super-easy assembling tool.

I agree on your NPM point though. Atmosphere is past its time.

@sebakerckhof

This comment has been minimized.

Copy link
Contributor

commented Mar 7, 2019

@mrmowgli Atmosphere is owned by MDG since they acqui-hired percolate studios some years back.

@KoenLav I like the idea of starting a github organization for popular packages. Myself and some others in this thread maintain much used packages or have outstanding PR's in popular packages that are no longer maintained. Bringing these all under one umbrella organization where maintainers can easily be added when somebody disappears seems like a good idea. But I feel that's not really relevant to the core of this discussion so maybe we should move it elsewhere (Or just create the organization and discuss it there)?

@mrmowgli

This comment has been minimized.

Copy link

commented Mar 7, 2019

@sebakerckhof I had forgotten about that, so I edited my comment. Thanks for starting the community kickoff 👍

@MastroLindus I'm also ok with my posts being hidden from the main conversation.
My comment around being opinionated isn't really about restricting what works with Meteor, but the narrative when people first come to the project. It's hard to maintain great examples for beginners with just one framework, but now documentation and examples have to be made for Blaze, Angular and React. Those examples become out of date, and need to track upstream new versions of Angular etc. It also leads to questions like: React is typically linked with GraphQL, so to use React in Meteor do I now need Apollo?

To be clear, I'm not advocating removing support or keeping people from adding their technology to Meteor, but rather MDG should settle on one proven stack to document around, officially support, and get people up to speed on.

@StorytellerCZ

This comment has been minimized.

Copy link
Contributor

commented Mar 7, 2019

@sebakerckhof Me and @copleykj have made the first step towards community maintained packages: https://github.com/Meteor-Community-Packages
Once I get some more time I want to get there alanning:roles package (and release v2) and bozhao:link-accounts. Anyone else who wants to join in this effort is very much welcomed.

@KoenLav

This comment has been minimized.

Copy link
Author

commented Mar 11, 2019

@sebakerckhof @StorytellerCZ @copleykj thanks for setting up the community organization!

I think the creation of this community, the invitation of several members and the collaboration within alone will help us join forces in maintaining Meteor packages.

For everyone who has previously forked Meteor packages to make them work in their own app, or is even maintaining some package for the community as a whole, please join the community by replying here: Meteor-Community-Packages/organization#1

Also if you know some people who should be added definitely make sure that they are by mentioning them over there.

@KoenLav

This comment has been minimized.

Copy link
Author

commented Mar 11, 2019

It's nice to see suggestions D (Welcoming community maintainers to Meteor) and I (Meteor Community Organization on GitHub) are already underway.

I would however still like to ask MDG, or more specifically @hwillson @abernix @benjamn, to chime in and share their thoughts on the suggestions raised above!

Could you possibly present us with an ETA for getting back on this? That would be much appreciated.

@KoenLav

This comment has been minimized.

Copy link
Author

commented Apr 13, 2019

I've gone through the Meteor feature requests repository and noticed a lot of issues raised there have already been fixed or are no longer relevant.

I'd be happy to spend some time to clean up and organize that repository, in an effort to make it easier for the community to identify areas where contributions are encouraged/needed.

Meteor-Community-Packages/organization#4

Still awaiting a reply from MDG.

@smeijer

This comment has been minimized.

Copy link

commented Jun 7, 2019

Still awaiting a reply from MDG.

Don't hold your breath. This simply doesn't have their priority, and thereby I do not expect a reply at all.

They do reply when something is of their interest. Such as Meteor Galaxy support.

I'm quite surprised by that topic; as it proves that MDG isn't dead. They just seem to be uninterested.

@smeijer

This comment has been minimized.

Copy link

commented Jun 13, 2019

#10477 (comment)

I wouldn't be surprised if Apollo would get some nice funding any time soon.

Well. There it is: https://twitter.com/GeoffQL/status/1138829967934910464?s=19

I'm curious what this will mean for the meteor development. MDG has now more cash at hand. So it could mean that some developers can move back to meteor. It can also go the other way, and move meteor to an even lower level of priority, as that doesn't bring money home.

@arggh

This comment has been minimized.

Copy link
Contributor

commented Jun 13, 2019

I'm curious what this will mean for the meteor development.

Do you believe in Trickle-down economics...?

@trusktr

This comment has been minimized.

Copy link
Contributor

commented Jul 7, 2019

For anyone above that mentioned TypeScript, the conversion of Meteor source code to TypeScript has already begun (which you can assume will also mean official TypeScript support).

Open up #10522 and search for "typescript". In particular, see Ben's announcement: #10522 (comment). If you're in SF on Tuesday, come over to Meteor Night!

@softwarecreations

This comment has been minimized.

Copy link

commented Jul 19, 2019

I'll add my 2 cents, will try keep it short because this thread is very verbose already.

  • I love Meteor, have been using it since 2012ish

  • I'm very grateful to Members like Benjamin and the amazing development performance improvements we've gotten as well as React and NPM support.

  • I whole-heartedly agree that Meteor has a communication & marketing problem.

  • Meteor is an open source project but completely wastes the opportunity to leverage the community

  • Meteor's marketing sucks

  • Meteor appears to be dead on the surface. Yes, I know it's alive. I check the github, changelog and forum activity.

  • Meteor's self sabotage in bad marketing kills it's popularity. That SO graph above showing it's decline is no joke.

Just think about the reality of this. Meteor appears to be dead, who will want to use it?
Who wants to pour their sweat blood and tears into technology that doesn't give them any confidence it'll be around or relevant in a year or two?
If you ask a developer how they know that (pick any project that's thriving) will be alive and relevant in a year or two, they'll tell you that the project's contributors and maintainers will ensure that it is. They'll add/update/fix whatever is needed to ensure it continues being great.

Why does Meteor appear to be dead/dying?

  • Freenode IRC membership has declined from 250 down to 45 as of right now over the last few years. It's ABSOLUTELY dead. I've got ZNC running and I ask "Are you all bots?" and there's no reply for a couple of days. Good luck asking a question there!
  • The basic parts of the guide (for example installing a hello world project, someone mentioned the accounts package hasn't been updated for 2 years) are badly outdated.
  • Meteor lacks a social media person/team. Compare Meteor.com to the raspberrypi.org Meteor should have a person dedicated to improving the APPEARANCE, yes, marketing and communication of Meteor. It's not just lame stuff nerds, it's necessary and will bring more nerds. Yes I'm a nerd and used to not understand the relevance of marketing and communication either, but seriously, think about it.
  • Runs on an ancient version of MongoDB. There doesn't appear be a clear indication of what versions of MongoDB Meteor supports.
  • No official support for Preact (okay I'm not an expert, haven't tried Preact with Meteor, but Preact claims to do all the basic stuff react does at a tiny fraction of the bundle size, seems like it should be officially supported, can't be hard considering Meteor already supports React and NPM)

Please take the above as constructive criticism. I'd love to see Meteor succeed. It's still a special and relevant project in 2019. But a huge % of developers will turn their nose up at Meteor, for good reason. I understand that you guys are probably working on big, challenging things that are in demand, like typescript or whatever. But I feel this is probably poor prioritization. Meteor's #1 problem to solve is mindshare. Not even growing mindshare, but actually recovering all the mindshare they lost since 2015/6 would be a start. To gain mindshare we don't need new bells and whistles. We need to shine the old bells that we already have. We need to clean all the gunk out of them so they ring like new. Just sweep and vacuum the floor. Basic house keeping. It's a common problem that intelligent people have, they focus on the complicated problems when actually the simple problems will bring the greatest benefit with the least amount of time, money and energy spent.

@aliogaili

This comment has been minimized.

Copy link

commented Jul 19, 2019

I know what you are getting at but the hype you are after is not going to come back, Meteor passed that stage. The reality (as I see it) is that there are companies who made successful businesses out of Meteor (including MDG, qualia with 40M funding) and looking to maintaining and improving the technology behind it and I don't think they're interested in expanding the mindshare (MDG already pivoted to Apollo for revenue, although I believe Meteor + Apollo will be great ecosystem). Not all open source are that hyped, the issue with Meteor is that it raised the expectations so high during the hype peak with 41 million stars! The focus now on improving the underlaying build tool and decoupling the framework while supporting modern JS ecosystem, and I'm really happy with that direction and I'd rather see the effort focused there rather than growing more hype. Smart folks will see that and stick around, other will chase the hype. Also, most of the stuff you listed can be aided with the community and I think many are doing good job with that, and most of the PRs are being merged.

@aliogaili

This comment has been minimized.

Copy link

commented Jul 19, 2019

Some other remarks on your comment:

"Freenode IRC membership "

I didn't even know that this channel existed, I think most of folks moved from IRC in general.

"Runs on an ancient version of MongoDB."

I'm not sure what you're referring to (I'm guessing the mongodriver) but I can easily bypass and use raw driver (which I rarely did).

"No official support for Preact"

Meteor is positioned as front-end agnostic and the community can provide those integrations, plus preact is not that popular to have any official integration.

The fact that meteor is improving the underlying build tool and supporting typescript coupled with the fact that it's being used by successful startups makes it appear alive (from my perspective) so I don't even share your underlying premise that meteor is dying but surely the hype is dead, which is a good thing.

@softwarecreations

This comment has been minimized.

Copy link

commented Jul 19, 2019

I don't even share your underlying premise that meteor is dying but surely the hype is dead, which is a good thing.

I never said Meteor is dying, please don't misquote me.
I said on the surface it appears to be dying, there's a lot of people who think it's dead/dying.
image

Mindshare is very important. Mindshare is open source contributions and staying relevant. Mindshare is survival. Sure an open source project can drag on without mindshare, but why be on life support when you can thrive?

@aliogaili

This comment has been minimized.

Copy link

commented Jul 19, 2019

My sincere apology for misquoting you and yes unfortunately a lot of negative articles were written on Meteor 2016/17 declaring Meteor is dead, when in fact it got way better over the last few years. The x is dead titles tend to generate a lot of traffic and they're not restricted to Meteor (try is express dead or is ruby on rails dead).

Mindshare is survival.

I think funding is survival, some open source projects are too complex/specialized and there is a real need for dedicated resources to work on its core full-time. Without funding this is not possible, take a look at the SemanticUI case.

Anyway, for what I've seen Meteor has a really dedicated/loyal community and well funded companies behind it in addition to be being really great tech so I'm personally optimistic, but yeah things can improve.

@softwarecreations

This comment has been minimized.

Copy link

commented Jul 19, 2019

Yes, I'm mostly happy with Meteor and I agree that negative sensationalist articles are not good indications of mindshare, but when you look at the quantity of such articles compounded with the declines on SO, IRC and probably other platforms I'm not familiar with (I'd bet their own forum's popularity has declined)... combined with the fact that Meteor uses an ancient version of Mongo, the guides are outdated, there's no decent maintained router, etc etc. It's 100% justified to say many people might think it's dead/dying. Only people like us who are invested in it will look deeper when considering it for a new project.

I think if MDG spent 1% of their mega millions worth of funding on marketing and keeping basics updated it would bring the mindshare needed to massively improve Meteor in many areas.

The most commonly recommended router for Meteor is FlowRouter, which is 100% dead. This is bad. Makeup on a dead body only goes so far. It doesn't look as good as something that's alive.

Instead of only trying to solve hard problems, how about solving the trivial problems first?
Taking care of MDG's money makers is of course their highest priority as it should be, and funding is critical. But nobody can disagree with the fact that MDG has neglected the community and the result of this is clear to see in the mindshare that drained out like a sieve.

Why not spend 1% of those millions on basic things that matter to the common developer?

I feel similarly to one of the first comments above, I feel bad to complain about something that's free. It's not that I'm demanding Meteor supports the latest Mongo version. But at least communicate on Meteor's site please, what versions of Mongo are supported, and what the caveats are if you use newer versions. Any decent project is going to use an external Mongo server, and then it's wasteful to have a separate server/cluster that's only for Meteor projects. This is an issue that the common developer will encounter.

All my comments can be summarized to

  • Communication / Marketing
  • Taking care of basic requirements of the common developer
    (A router, what Mongo versions can I run, lightweight frontend, up to date guides, someone who checks the IRC channel once a day, even if it's just a 30 second reply)

I'm not looking for new whizzbang stuff. I just want the basics to work well. I don't want to feel like I'm building a house on rotting foundations. I know that Meteor is not dead, and I don't expect it will die in the next year or two. But the fact that basics aren't being taken care of makes me feel uneasy. Would you go out with a girl who doesn't brush her teeth, make her bed or shower regularly? Even if she's great conversation and attractive etc, you'd feel uneasy, right?

@aliogaili

This comment has been minimized.

Copy link

commented Jul 19, 2019

Why not spend 1% of those millions on basic things that matter to the common developer?

I guess because the common developer doesn't have/willing to pay the money to cover the 1% they would pay given how many JS frameworks out there, furthermore, the common JS developer is just looking for next framework on resume, better focus on enterprises. In my opinion, had they not pivoted to Apollo, MDG wouldn't be doing well today, a lot folks here are entrepreneurs and know how hard is it to build successful startups and it's even harder within open source. But that is my guess, can't speak for MDG.

I personally would rather pay for better tooling, it's unfortunate most of those framework go only open source path.

Would you go out with a girl who doesn't brush her teeth, make her bed or shower regularly? Even if she's great conversation and attractive etc, you'd feel uneasy, right?

Yes I'd go, attractive girl with good conversation is hard to find, I can resolve the other issues later haha.

I'll let the rest chime in, I think I made my points in this thread.

@aliogaili

This comment has been minimized.

Copy link

commented Jul 20, 2019

Actually I want to add one more thing to this thread.

With regards to mindshare, Benjamin has been working hard to make the code cleaner, more modular and modern over the last few years, take a look at 1.8.2 PR and these slide. These are very clear signals of how committed MDG to supporting and engaging the community with Meteor going forward. I really believe this is the right approach, asking MDG to put money in marketing and create hype is not but ensuring the code is more modular, modern, clean and well documented is.

Given Ben efforts in engaging the community, I think the community needs to step up and help with the typescript conversation and enhance the outdated documentation, also we can close this issue or move it to the forums and keep Github code/repo focused.

@StorytellerCZ

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2019

I agree with @aliogaili on most points, though I think there are some easy wins available to us outside of the ongoing tooling and typescript conversion (which has generated a lot of activity).
My personal favorite is updating the React packages to take advantage of new stuff in React (hooks). There are already PRs for that, we just need somebody with the privileges to jump in there, review, merge and publish.
As for hype, at this point it is really up for community to show MDG that we can help with it and maintain it if we want any investment from them. I'm working on few initiatives on this front, but sadly my time availability has become even more constrained this year.

@smeijer

This comment has been minimized.

Copy link

commented Jul 20, 2019

think the community needs to step up and help

It's not that the community isn't trying. See for example this topic, where some of the best and/or most active meteor contributors are trying to get in touch with MDG. But the problem is exactly in "engaging the community". There is no communication.

You say it's unfair to advise MDG to invest a bit in marketing and/or communication. But to be honest, they received 31 million funding for Meteor, and now 22 million for Apollo.

In the tweet, they repeat what they have said in the earlier funding rounds as well: "Big thanks to the amazing Apollo community, we couldn't have done it without you!", and another quote: "put every dollar toward our goal of helping app developers help the world.". I believe communication and engaging with the community is very important to achieve that last goal.

So there is invested 53 million dollars in the Meteor and Apollo repo's. Is it really such a bad idea to get some marketing on this? How much would a community manager earn? 100k a year? Please give this person a contract for the next 5 years.

@aliogaili

This comment has been minimized.

Copy link

commented Jul 21, 2019

The gist of many of comments here is that MDG got another round investment and it should invest in hyping meteor again. I say hyping and not communication because just less than a week Ben, the core meteor developer put all his thoughts in these slides and it is as transparent as it gets.

My points:

  1. Meteor is actually doing good, forum is active, packages are being created and core is getting better and better.
  2. I disagree with using investors money for marketing, I'd rather see MDG keep pushing on the core build system and keep making the code more modular/cleaner.
  3. From what I've seen, open source longevity is better measured by community donations, loyalty and sponsors companies who actually use the tech in real businesses and not by investors money or hype, RethinkDB is one example that comes to mind.

Finally I think the organization idea is a great initiative that came out of this thread. Right now, a lot of great community packages are being created but they're not organized, I think what would be really good is to take that community organization idea and push it step further with a website/app that list the core meteor community packages, a voting system for next features (similar to webpack feature voting) so it actually unify and organize the community voice. I think can build a simple meteor app (or maybe there is something existing for open source? ) that would initially do the following:

  1. List core community members (people/or companies)
  2. Allow voting on next roadmap items with an influencer system
  3. Accept donation (that impact the influence points)
  4. List core community packages
  5. List recommended community resources scatter around the internet
    The app/organization should be lean and easy to maintain going forward (meaning no need for for podcasts, or anything that takes a lot of manual time) since most of the folks on it will volunteer their time.

And come to think about it, if there is no app like that, it might be given to other open source communities as well. At least this would organize the voice/effort of the community.

@StorytellerCZ

This comment has been minimized.

Copy link
Contributor

commented Jul 21, 2019

@aliogaili I'm just working on a static placeholder website that would fulfill the role of simple index page of all the activities. Nothing fancy. I'm down for more advance website. Let's hash out the ideas here:
Meteor-Community-Packages/organization#5

@KoenLav

This comment has been minimized.

Copy link
Author

commented Jul 24, 2019

@aliogaili I'm not for closing this thread until there is something of a proper response to some of the constructive criticisms raised here.

It has been almost 5 months since this thread was started. I know it's a lot to read, but there's a lot to improve. Right now it just looks like MDG doesn't care (enough).

@RobinJiao

This comment has been minimized.

Copy link

commented Aug 21, 2019

Obviously, people here all love Meteor, or they wouldn't waste their time writing these long posts;
from a beginner's view, i can explain why people keep asking " is Meteor dead? "? I have the same feeling/worry.
I started to learn Meteor in Jan 2019, followed a youtube video and the official tutorial, managed to get my first app working, and works well. then build 2-3 more tiny apps. really appreciate the Meteor framework.
But it's really hard for a beginner:

  1. almost all books are 3+ years old/outdated;
  2. almost all video tutorials are 3+ old/outdated /almost all websites about meteor are gone
  3. the questions about meteor in stackoverflow are often 4+ years old
  4. the necessary packages useraccounts/flowrouter/mup have very little commits for 2-3 years
  5. Kadira team and many other developers left Meteor
    seems nobody is using meteor anymore!
    if meteor gets less new users(developers), the market gets smaller. people pay less attention to it.
    in brief, all we need is confidence - show us, please.

BTW, what people use after leaving Meteor, MERN? react+webpack +graphql? thanks
Robin Jiao

@Twisterking

This comment has been minimized.

Copy link

commented Aug 21, 2019

I will also give my 2 cents here, and somehow I can only pretty much agree with almost everyone on here.
I have been in love with Meteor pretty much from the first moment on, some time in 2012.
And it really worries me and almost hurts me to see this great, maybe best, fullstack JS framework out there making this very stupid mistake.

I agree, that there doesn't have to be a huge hype anymore like in the first 2 or 3 years. I get that. But as many said: Meteor seems to be dead (emphasis on the "seems" in this sentence)!

This is a huge problem indeed. Everyone who doesn't know Meteor for years now are afraid to use it, because it seems to be dead.

  • Communication with the community is absolutely horrid
  • Pretty much everything you can find is totally outdated (books, stackoverflow-posts, howtos, tutorials, guides, ... you name it)
  • There seems to be no vision behind Meteor any more - The Roadmap and all that are also pretty much dead
  • It seems like community contribution is either unwanted or MDG is not spending any resources to review and merge any PRs and stuff like that.

so tl;dr:
Meteor is still an awesome framework, but please MDG, for the love of god: Don't let Meteor die and also don't let Meteor seem to be dead for that matter! I don't agree with the people who say that things like this don't matter - they do matter. If enough people think you are dead, you are dead!

@smeijer

This comment has been minimized.

Copy link

commented Aug 25, 2019

  • Pretty much everything you can find is totally outdated (books, stackoverflow-posts, howtos, tutorials, guides, ... you name it)

This is not the first time I read this. I've created a topic on the forums for this subject, as I believe this can be easily fixed by the community.

https://forums.meteor.com/t/new-meteor-book/49950

The question I ask there is:

What are the questions you have? For what scope or for which subject do you wish to see tutorials / documentation? What is it that https://docs.meteor.com/ is lacking?

I'm willing to invest my time to deliver some content, but I need some content-requests to see what exactly is needed. As I myself, can manage fine with the docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.