About: Max Savin is a product guy, currently developing Meteor Toys and growing his consultancy through Toy Shop, while contemplating the next big thing.
Photo: http://maxsavin.com/me.jpg
Meteor Toys are a set of development packages made specially for Meteor, created as a solution to my own needs and development frustrations. On the first level is the open source Mongol and JetSetter. These two packages let you view and edit your MongoDB documents and Session variables in a visually instead the typing commands in the console. As of writing, both are quickly rising through Meteor's top 100 packages. On the second level are Meteor Toys, which extend Mongol and JetSetter, provide an additional set of convenient tools, and are the first paid package for Meteor.
In December 2014, my third start-up had crashed and thoughts about getting a job were running through my mind. Around that time, I had become proficient in Meteor, and decided to interview at what may have been the only Meteor-based company in New York. During the interview, the team encouraged me to build and maintain a package, and I thought it'd be a fun challenge.
In search of an idea, I recalled a widget I created while building my first Meteor app; a box that sat in the bottom left corner of the browser. The box returned a count of how many documents you had in each collection, and let you run Collection.find().fetch() on click.
Seeing the convenience it could bring to any Meteor developer, I extracted it into a package called MongoInspector and began to promote it at the Meteor NYC meet-up. Each month, I gave a lightning talk to spread the word and gain feedback, and each time, I've been delighted by the community.
During one of the talks, I explained how MongoInspector 'disappeared' in production by checking if the Meteor.AbsoluteUrl() was on localhost. That's when Abigail Watson and Adrian Lanning of the Velocity team informed me of the undocumented debugOnly property for packages.
The debugOnly property tells Meteor's build process to exempt the package from your production code. Funnily enough, Abigail and Adrian were part of the Velocity team, which actually requested Meteor Development Group (MDG) to implement this feature. They request it because it didn't makes sense to ship tests to production, and in effect opened up an interesting door.
With debugOnly, I realized you can open up all kinds of convenient security holes to gain super powers in development mode, and the still keep the ability to sleep when your app is in production. To see how its implemented, take a look at this package.js file.
MongoInspector slowly gained a couple of hundred of downloads, and it was encouraging to think that there's probably 100 people out there using it throughout their day! I decided to keep pulling the string, and equipped MongoInspector with a special set of methods that allow it to perform any command on the database. This turned it from an inspector to an editor, and lead to the rebrand into Mongol.
Choosing the method approach was very convenient because it respects your application security and doesn't require insecure to work. Whenever you changed a document on the server, Meteor would instantly bring it to the client. It worked just as if you had a database admin tool right in your app.
Parallel to all this, I also launched SessionInspector, which evolved into JetSetter, which is the same concept as Mongol but for Session variables. JetSetter carries a similar narrative - whatever happened on the MongoDB side, happened slightly later on the Session variable side. It's not always easy being the younger child, but they both got the attention they needed. 😁
Mongol and JetSetter's rise through the top 100 packages, and the convenience of the debugOnly package property, encouraged me to consider what else can be brought into the Meteor development environment. With the boring stuff abstracted away came the challenge of inventing something new, and it lead to a bunch of package ideas, such as:
- Impersonate: when working on an app, you often have to sign in and out of different accounts to make sure your application works properly. Rather than require you to sign in and out of different accounts, Impersonate lists your accounts and lets you sign in by clicking on them.
- Method: when you need to call a method manually, you often have to go into your source code to see how the parameters are lined up. The Method toy displays them to you automatically, and lets you type in their values as you go.
- AutoPub: Autopublish is very useful in development, but at some point it has to be removed from the application. Meteor Toys let continue to tap into its benefits by letting you use it only when you want.
- Shell: Run any code on the server as if it ran from a Method. Once you run it, it'll give you back the results and the Method code you'd need to paste into your application.
As more ideas hit, I realized I need for an extendable interface, which lead to create what I call the Orb component. Each one carried its own functionality, designed to save you a minute here and there.
Mongol is a fortunate because two contributors came along to perfect it; @Krawalii and @JackAdams. They added automatic collection detection, improved Mongol's inner workings, and BrentAbrahams even glued in his Editable-JSON package to make document editing easier.
When we were actively working on it, one of Krawallii's pull requests broke Mongol, and JackAdams called him out. Krawalii made a new fork called "krawaliibreakstoys" to prepare a fix, and I found the title amusing. Around that time, I'd been thinking of branding the tools under one name, and Meteor Toys occurred to me as a good one.
After completing the Meteor Toys bundle, the question of could/should they be monetized sprung up, and if so, how. Since they are tools, like an IDE or color editor, I figured they should carry a price. I showed them to my comrades in the Meteor community, and almost everyone gave the same price suggestion, so I hit the easy button.
The challenge was in deciding where to draw the line between what is open source and what should cost money. The art is in making both the free side and the paid side compelling. You want people to be content with the free version, so that its worth engaging with, yet leave enough incentive for a paid upgrade.
I decided to divide them between what people already had capabilities for and what hadn't been done before. The standard console commands listed were automated by Mongol and JetSetter, and they were to used to mark the line:
[ FANCY CHART ] Mongol [col 1]
- Collection.find()
- Collection.find().fetch()
- Collection.find().count()
- Collection.update()
- Collection.remove()
- Collection.insert()
JetSetter [col 2]
- Session.get()
- Session.set()
- Session.keys
After the launch, some people spoke through their wallets and others through forum comments. Not everyone welcomed paid packages, and I feel it should be given more understanding. Having money go through the ecosystem is a win for everyone: Meteor Development Group makes money off deployments, contributors make money off building/supporting their packages, and developers make money off their applications, while receiving a well-supported solution.
I've heard worries about paid packages cannibalizing open source packages, but looking at other platforms (such as WordPress, Photoshop, etc) shows us the opposite. By enabling developers to invest time into making commercial packages, I'd bet we would see more innovation and greater commmitments from more contributors. I'd bet it would translate to more packages and options, not less open source packages.
The Meteor Toys journey has been extremely rewarding, and I look forward to where it will go next. I feel it enhanced Meteor's development environment and hopefully made developers happier, while helping me pay for the quad-shot cappuccinos. It also reflected one of my favorite things about technology: we have a lot of opportunities to create things that benefit every party involved.
By bringing parts of the "IDE" into the application itself, we can manipulate things in their context, and with debugOnly at our hands, we can create convenient openings in the framework without worrying about security. This is what Meteor Toys are built upon, and with your support, I'll continue to devote my time to ensuring they continue to improve and adapt to the framework.