Meteor in 2017

Looking back on a strong 2016 and what we’ll focus on next

As we roll into the year, I’ve been thinking a lot about Meteor’s exciting progress over just the last few months.

We made dramatic improvements to project rebuild times, made a smooth transition to Node 4, unpinned individual package versions from Meteor releases (allowing more frequent updates of key components), and split Blaze out into a community led project. I’m especially proud that we did all of this while keeping backwards compatibility and paving a smooth upgrade path to Meteor’s newest features.

We also worked hard to recruit and empower more community maintainers. With the help of people like Hugh Willson and Jesse Rosenberger, we’ve made steady progress closing issues and merging PRs. We’ve also started solving some of the underlying technical challenges to contributing and making it easier for people to get more involved, like maintaining a Roadmap.md and clearer contribution guidelines.

To check how well these efforts aligned with what developers building production apps most need, last month we surveyed several thousand of our Galaxy customers. What we heard back was a strong “yes” — users are thrilled about the developments in the last year. A couple of stats really stood out. 73% of respondents said the frequency of new Meteor releases is just about right (with the remainder split evenly between “faster” and “slower”). 92% are building new features or doing other extensive development on their current Meteor apps, and 77% plan to write a brand new Meteor app in 2017. We also got a ton of specific feedback on future improvements, which we’ll use as a guide for what we focus on this year.

Our focus in 2017

This all sets up a great opportunity for Meteor in 2017. Now that we have this great tool that people love to use, what should we do to turn that into something that’s more recognized by the wider JS community and continue on the path to making it more powerful and flexible? I think it boils down to three things:

1. We’re going to keep working on what production users are asking us for. We’ll keep making the build tool faster and more capable, invest in improvements across the Meteor code base, and ship more cutting-edge features, like per-module code splitting, that no other tool in the ecosystem has. And we’ll continue to engage with the community every way we can. An open source project is only successful when it includes diverse points of view, and so we want to get more developers involved who can bring their perspective on new features and ideas.
2. We’re going to be doing a lot more evangelism of Meteor this year. There’s been a lot of development on Meteor — both from MDG and the community — but there hasn’t always been time to explain and promote the improvements we’ve made. Most people who haven’t used Meteor recently don’t have a good understanding of the tradeoffs it has relative to their current technology stack. We aim to change that.
3. We’re going to refocus the platform around the developers who get the most value out of it. Meteor is unparalleled for rapidly building collaborative apps in JavaScript, loved by teams who value having a stable platform that has a reasonable answer to most typical JS development problems. So we’ll focus even more on improvements designed to work great together — including some new features in Galaxy too — so that you can spend less time on plumbing and more time building features in your app.

So how are we going to do all this?

First, with your help. We can’t do it alone — it’s that simple. If you’re excited about Meteor and our direction, get involved! You can contribute code, write docs, triage issues, and help us spread the word about Meteor.

Second, by growing our full-time Meteor and Galaxy teams at MDG. That’s already started — I’m excited to welcome Jesse Rosenberg as the newest member of our team this week. In addition to technical work across the stack, one of his goals will be finding new ways to help other technical contributors, such as his Development.md proposal. We’re looking for more great people to join, so please consider applying or referring us to other great people you know. It’s a chance to help developers around the world in a direct and meaningful way and do industry-leading work on one of the world’s most popular open source projects and most advanced containerized hosting platforms.

And third, by investing in the business of Meteor. Since its launch at AWS re:Invent, Galaxy has rapidly grown into a strong business for us, so much so that MDG beat our 2016 revenue goal by over 30%. Thousands of companies large and small depend on Galaxy to host their mission critical applications, paying as little as $1/day on the low end or sometimes over $1000/day on the high end. I’m particularly excited by the growing number of companies that are making major commitments to Meteor+Galaxy and the larger deals that we’ve closed over the last few months for enterprise Galaxy support, pre-paid containers, and dedicated clusters. The more Galaxy gets used, the more we can invest in the platform; so, we’ll be building on Galaxy all year, with upcoming additions like IP address whitelisting (coming in just a few days!) and a third Galaxy cluster running in Asia Pacific (Sydney).

What about Apollo?

What about Apollo, our new data layer? That effort has also been going really well. Apollo Client is now the #1 GraphQL client on React and Angular. Last October we launched Apollo Optics, our first commercial tool for GraphQL, and we ran a hugely successful GraphQL Summit.

A big reason for Apollo’s rapid uptake is that it can be incrementally adopted into a wide variety of stacks, from .NET and Rails and Scala, to iOS and Android, to React and Vue and Angular. And so we’ve oriented a lot of the project’s structure and goals around building tools and libraries that are useful in many different settings.

Sashko Stubailo and Danielle Man present their work on Apollo at GraphQL Summit

Meteor is one such setting, of course — Apollo got started as an investigation into a new data layer for Meteor. Many Meteor developers are already using Apollo in their apps. Both of our flagship products, Galaxy and Optics, are Meteor+Apollo code bases. But Apollo is still a young project, and it will still be some time before GraphQL can be a complete substitute for all of Meteor’s realtime capabilities.

The Meteor and Apollo projects are going to run completely decoupled, each taking their own course with their own communities. Eventually, we expect Apollo will become the standard data layer for all apps, including Meteor. We’re going to manage that transition for Meteor developers gradually, similar to how we’ve handled the introduction of other maturing technologies into the core Meteor stack like ES2015 modules.

Finally, I’d like to thank the community of Meteor developers whose constant feedback, support and evangelism has helped us so much. Your work inspires us to do more, and we look forward to continuing to find new ways to support and collaborate with you in the coming year.