First of all an apology for taking so long with this.
This is the continuation and expansion of a talk where I summarized the results from the Meteor Community Survey 2021. You can watch the recording on YouTube.
The anonymized data are now available together with my graphs and any additional processing and handling (on the second sheet). In case of current version usage I had to get the data directly from the Google Form reporting because Google Sheets converted strings to numbers such that versions 1.1 and 1.10 were treated as the same thing.
If you want to personally go through the responses, follow this link
This year we had 298 respondents. That is 91 more than in 2020. Not as big a jump as from the 57 respondents in 2019, but still a nice increase. This and given some comments it looks like it was due to Meteor Software generously mentioning the survey in their newsletter.
In questions, notably this year there was a shift towards additional offerings around Meteor.
At the time of the survey, Meteor 2.5 was just coming out, so 2.4 or latest was the most current option. As we can see we have most people being up to date with the latest Meteor. Despite the notable obstacle of the 2.3 update many have made it through, though there is still a significant number of respondents on the two previous versions. There are some significant holdouts on versions 1.6, 1.8 and 1.10.
For 1.6 I can only think of the stopper being that in 184.108.40.206 you had to manually install
meteor-node-stubs. v1.9 includes upgrade to node 12, which could be a major stopper for some to stay on Meteor 1.8 and v1.11 upgrade could have been hampered by Cordova, but that seems very unlikely. In either case people at these versions should update at least to the latest v2.2 to get the security patches for Node 12, but even that one is being discontinued in a few months.
Special cases are the use cases before v1 of Meteor. I can only hope that those are internal apps that are not facing the Internet as the Node version is ancient. These are also early days of Meteor so updating them might not be feasible and instead re-building them might be a better solution. From comments there often was no time to deal with update issues if they arose or there was no desire to update if the app was just working with the risk of breaking things. Although I sympathize with that point, I have to point out the general security risks (omitting performance benefits and other goodies added) that is running an older version of Meteor that includes versions of Node that had multiple security releases since.
The always favorite question of front-end selection. As in previous years, React is the top choice, closely followed by the much bellowed Blaze and finally risings stars of Vue and Svelte very much behind this duopoly. Blaze had a minor release this year and another one is planned and there is small, persistent work going on with it so there need not to be any worries about it being discontinued. React and Vue are also getting a lot of love with improvements to libraries that interact between them and Meteor.
Another unchanging statistic is the use of GraphQL with Meteor. Even though Meteor has an official integration for Apollo GraphQL, the pickup was not so big with Meteor. This might also be that the early projects adopted other strategies of data retrieval before GraphQL came onto scenes and those are well known today and use the out of the box Meteor methods or other ways better suited for the given projects. The second issue is that GraphQL comes into play for Meteor developers once they reach limits of pub/sub. I hope that the positive answer here is going to increase with new people knowledgeable of GraphQL from their other projects coming to Meteor.
As with GraphQL, the same situation is with Redis OpLog. Though Redis OpLog has a bit more usage here I think the data show that most Meteor apps don't make it into the mass market and from comments and my interactions with people over the years I know that Meteor is often used on internal apps or apps with limited audience.
Often times there is a complaint that Meteor supports only MongoDB for a database. That is not entirely accurate. I would do a disservice to the community if I didn't mention Vlasky's
mysql package and if you search you will find other packages as well. Still using other packages than MongoDB is limiting as you for example can't use the accounts package, still over a tenth of respondents don't seem to mind and enjoy using other databases.
It is no surprise that most respondents are using MCP, after all this is the community that conducts the survey. Hopefully the 50 or so respondents that did not known about it have learned about it now.
Overall the satisfaction with the community newsletter remained the same. Sadly at Meteor Impact I had to announce the discontinuation of newsletter in its current form. This was due to conflict of interest (at the time I was being contracted by Meteor Software and I run my own newsletter for my sponsors).
It seems that this question has been coming forth lately more and more. Sadly the overwhelming majority would not consider financially supporting Meteor community developers. Let's be honest here, "maybe" is just a polite way of saying no. Few good souls who were not willing to contribute in non-financial ways. A few were outraged at even the thought of any financial support for packages that support their business or company they work at. We have seen and I believe that we will see even more problems in the coming years with developers supporting important packages/software stopping and chaos that is going to come out of that. I can't help but to get reminded of this:
Anyhow, I and others have already written about this and much more will be written in the future.
For those few willing to at least consider financial support these were the results:
Compared to previous years we now have a clear winner in the multitude of choices which is GitHub sponsors.
For companies there was reiteration of issues with corporate and desire for some centralized fund that they could support that would take care of determining who should get supported and so on. Sadly the biggest problem from this comes to determine who would be in control of this fund and deciding who gets the money. Things can get very nasty when it comes to money and so we have a paradox. Best would be if developers would get it directly, but companies would for the most part prefer some centralized authority to do that. Maybe we need Tidelift or something similar for Meteor.
Now this question was interpreted broadly by the respondents and comments ranged from general wish lists for Meteor or specific packages to complains. Bellow I have summarize what I believe are actionable suggestions that the community could take on from a high point of view (ie. no specific packages, Meteor features, etc.):
- Educational resources
- Meteor kitchen sink
- Meteor starter apps
- Help with major community apps like Wekan
- Articles and videos
- Maintain more packages
- More events & meetups
- More opinionated / definitive paradigms and solutions
- Be more active on the forums (question threads in particular)
- "quit begging for money"
- "launch a big call for financial participation"
- More tutorials
- Create common tools
- Translate resources into other languages
This year there was a new section focused on Meteor Cloud offering. Since it it closely tied to Meteor itself I felt the need to ascertain what people think. Some of the related features requested could be developed by the community, others could be an inspiration to Meteor Software.
I always wondered how many people are hosting on Galaxy. About a third of responders do in some fashion. If we consider that this is where Meteor gets its money from to continued development it is neither good, nor bad. Reasons wary, but no matter the reasons this show that there is a great potential for Meteor Software to increase its customer base. It might be just figuring out what is the main show stopper from the reasons discussed bellow.
For those who are not hosting on Galaxy it most often comes down to client/company requirements like residency laws/GDPR in many countries or corporate policy. We can also see this reflected in the question for future regions, question about where people are hosting if not on Galaxy and it is often mentioned in the comments. Another group that doesn't host on Galaxy are those who believe that it is cheaper elsewhere and that particular price is the most important aspect. Let's take a look where else are people hosting:
Note here, that the
other category often includes regional hosting providers.
Sadly some of the commenters had very outdated ideas about Galaxy and completely missed that there is a free tier and Tiny containers. For a long time I was wondering if to include these data as it just looked as bad data that were not helping, but in the end I decided to keep it to be open with everyone about it. After all this is a data point showing that outdated perception remain.
I'm a fan of what MongoDB Atlas is doing with their hosting and especially with how you can easily select and make different regions (and now hosting providers) interconnected. I'm very well aware that it is an incredible achievement that required an army of developers (and a mountain of money) to make this happen and that it is impossible for apps, but I think it might be possible with Meteor in the future. Well... one can dream. 🤣
Either way for a new region to open there needs to be a significant demand for Meteor Software to justify the costs of doing so.
Anyhow here is a list of AWS regions that respondents would like to see open.
From the comments, the desire for different countries in the EU to have their own deployments has to do with residency laws/GDPR that require that the servers are run in the country where the data is being collected/processed. So for France and Germany, the AWS region in Ireland is not going to cut it. Also from Germany you can also better serve central and eastern Europe (🤔 if the devs from Vazco answered this survey en masse, it would explain why Germany was the top here, but later we see that there weren't that many responses from Poland). There is also a significant Meteor community in France and France has particularly tough laws around this (from what I understand), so Paris deployment is highly desirable. Tying with Paris is a Brazilian deployment, which I think would make sense as the next step to support South America.
We'll have to wait and see. Sadly my desire for the Tokyo region was not met with the demand. I guess I have to work more in this region. 🎌
Now talking about these comments is not easy. Mainly because some of them like improved log navigation which has happened in the time between the presentation of the survey results at Meteor Impact and writing of this article. Also as mentioned above some users haven't clearly been on Meteor Cloud for years. So what follows is my, cleaned up (omitting features already deployed or were directed to Meteor/community itself), list of features/things respondents would like to see:
- UI improvements
- Even cheaper hosting
- Bundled MongoDB (for paid plans)
- Performance improvements
- Better secrets management
- Ability to launch in customer-owned VPCs
- Improve APM
- GitLab integration
- Community plugins
- Integration with Apollo Studio
- OAuth to other social service
- Better diagnostics for unhealthy containers
- Meteor shell
- Run methods from UI
- CDN / asset hosting
- Migrate from other services tool (Heroku)
- On premise hosting
- Make reporting features open source
- Custom Nginx config
- Other than AWS providers
As expected most responders use Meteor at work. The rest either for some of the projects or they are hobbyists. After all Meteor is great for single developers.
As many would have expected Meteor is most often used by small companies and startups. Though there was a noticeable bump for the 1000+ people companies. This doesn't necessarily mean that there are large companies that use Meteor for their projects, but like with any massive companies there might be some projects in Meteor (ie. Disney).
Respondents most often went to the official Meteor sources followed by written articles. Dev.to, new this year as an option, also performed pretty well. I think that this shows that the Meteor community can improve in communication.
And I will end this with my favorite, a map where the responders reside. AS always we see USA and Canada dominating, but Brazil, France, Germany and Australia are also quite the rising stars. There are definitely more Meteor developers in many of these countries than the number suggests, but they just did not know about this survey. Something to think about for next year on how to improve the spread.
Just looking at the engagement of the survey I would say that the Meteor community is on a rising trajectory. When it comes to the technological section there is no doubt, some of the issues pointed out in the survey were already addressed, many others are in the works. Discussing the results and other circumstances at Impact and other meetups makes me believe that there is still some groundwork in the ecosystem that needs to be done before we can see a return to past heights, but we are getting there. Will 2022 be the year? I don’t think so as these things need to ripen before they can explode on a scene.
What do you think? What will you do this year?
If you like my work, please support me on GitHub Sponsors ❤️.