4 ms·
Hi, I'm the OP (or at least the author of the blog post.) I should have been clearer. Most of the core devs have side projects that they're building on Meteor.
by geoffschmidt 14y ago
Hi, I'm the OP (or at least the author of the blog post.)
I should have been clearer. Most of the core devs have side projects that they're building on Meteor. I'm building a social contact manager, which I'm using for a community group I'm involved with. Nick built an app to keep a database of his wedding guests. David built a app to keep track of the schedule for his favorite TV shows. Matt has built some games.
What we're not doing is trying to turn any of these other projects into businesses. Meteor is the reason we exist, rather than something that we have to continually justify to ourselves as an "engineering investment" as we build our "real" product.
You're exactly right, it is poison to try to build any kind of API without having some motivating use cases in front of you. So one of our rules is, we try not to add any feature to the framework without having seen people implement it several times "by hand" in the app. Then we try to find the common bits between those implementations, polish them until they shine, make it accessible to a new JavaScript developer, and finally package it as an optional Smart Package.
So far, every feature in Meteor has been built to scratch an itch that we had while building actual apps in Meteor. For example, the reactive templating system was originally built to make the meteor.com homepage easier to build. The new auth/accounts package is something we've all wanted for our weekend projects for months. And the forms/live templating overhaul that David is working on comes partly from the difficulty we had with embedding Twitter buttons in the meteor.com homepage app, and partly from the large amount of boilerplate code that I had to write in my social CRM.
Finally, there actually is one fully-scaled commercial app that we'll soon be building on Meteor, and that's the web interface that'll let you manage your deployed Meteor apps and share them with other team members (if you choose to use our "meteor deploy" servers.)
- bonzoesc 14y ago> I should have been clearer. Most of the core devs have side projects that they're building on Meteor. I'm building a social contact manager, which I'm using for a community group I'm involved with. Nick built an app to keep a database of his wedding guests. David built a app to keep track of the schedule for his favorite TV shows. Matt has built some games. > What we're not doing is trying to turn any of these other projects into businesses. Meteor is the reason we exist, rather than something that we have to continually justify to ourselves as an "engineering investment" as we build our "real" product. Won't this lead you to make choices that make sense for short-term projects but age poorly as your codebase grows? Many of the choices in Rails versions as early as 1.0 are undoubtedly influenced by the implementation of Basecamp (a non-trivial app) using the framework, and during the last eight years it feels like large projects have only gotten more manageable and maintainable.
- slurgfest 14y agoWho knows? Maybe it will prevent them from focusing unduly on use cases that match with what they happen to be doing at the expense of other use cases. I'm not sure why someone's ability to design an API is more heavily in question just because they have a serious commitment to building that API rather than working full-time to build a company. There's nothing wrong with building a company and there's nothing wrong with building a tool either.
- dinkumthinkum 14y agoCrazy idea, but what if you get some enterprising young startups to bet on you early? I think having some big projects, even if you don't want to build one yourself, bet on you as a technology would be the best path to put to rest these concerns. I think there is a need to demonstrate it's effectiveness in a complex piece of software.