> 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.
Who 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.
Crazy 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.
> 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.