Meteor Raises $11.2M from Andreessen Horowitz(meteor.com)
meteor.com
Meteor Raises $11.2M from Andreessen Horowitz
http://www.meteor.com/blog/2012/07/25/meteors-new-112-million-development-budget
114 comments
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.)
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.)
> 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.
> 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.
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.
Among the guys at Meteor, we've built a lot of apps already in the past. For example, I wrote EtherPad. So you could say we're extracting from our extensive collective experience.
Do development frameworks built for their own sake ever really work in the wild?
It's hard to say what technologies were or weren't "built for their own sake." You can't invent good tools and abstractions without taking the cues from somewhere. That doesn't mean a new kind of hammer has to come out of a particular kitchen renovation, or a new kind of detergent has to come out of a single load of laundry. We're deeply embedded in a community of people who do the same things over and over, and we think we know what the next set of tools should look like. Was SQL extracted from some particular app? How about Heroku, Parse, or jQuery? HTML? In most cases you could probably frame the story either way.
I think we're really talking about the "over-engineering" stereotype. Even saying we're working full time on a framework can set off that alarm. Oh no, that's too much engineering! Don't worry, we'll keep it under control.
Do development frameworks built for their own sake ever really work in the wild?
It's hard to say what technologies were or weren't "built for their own sake." You can't invent good tools and abstractions without taking the cues from somewhere. That doesn't mean a new kind of hammer has to come out of a particular kitchen renovation, or a new kind of detergent has to come out of a single load of laundry. We're deeply embedded in a community of people who do the same things over and over, and we think we know what the next set of tools should look like. Was SQL extracted from some particular app? How about Heroku, Parse, or jQuery? HTML? In most cases you could probably frame the story either way.
I think we're really talking about the "over-engineering" stereotype. Even saying we're working full time on a framework can set off that alarm. Oh no, that's too much engineering! Don't worry, we'll keep it under control.
Good point. We do use Meteor. Our own site has always run on Meteor, and we build other tools and personal projects with it. Dogfood is good -- we now have an experimental version of server side rendering in Meteor because we had the pressure to get www.meteor.com into Google's index.
It's not a bad strategy to build the framework alongside a product. But shipping real product is a huge commitment. We spent weeks just getting all the pieces in place for the first Meteor release in April: text, design, docs, a screencast, release engineering, community outreach. For now, we think we can move faster and build a better framework if that's our only product focus, instead of trying to ship two great things at the same time.
It's not a bad strategy to build the framework alongside a product. But shipping real product is a huge commitment. We spent weeks just getting all the pieces in place for the first Meteor release in April: text, design, docs, a screencast, release engineering, community outreach. For now, we think we can move faster and build a better framework if that's our only product focus, instead of trying to ship two great things at the same time.
It would probably be valuable to use some amount of that $11m to fund development of interesting applications/startups that showcase Meteor in the real world. For instance, you notice something interesting a community member is building on their own time, but you don't want to focus on it. In my experience close partnerships can work as well as dogfooding, as long as you trust the source and can make the right decisions based on the feedback.
I feel that this is implicit in the post, that there will be this outreach/advocacy/support?
"Create opportunities for Meteor developers — for example, encourage companies to adopt Meteor, creating jobs. We want to make you famous and get you paid.
Support the Meteor community. This includes everything from publishing books and organizing conferences, to being responsive to bug reports and pull requests, to finally making some cool tshirts."
"Create opportunities for Meteor developers — for example, encourage companies to adopt Meteor, creating jobs. We want to make you famous and get you paid.
Support the Meteor community. This includes everything from publishing books and organizing conferences, to being responsive to bug reports and pull requests, to finally making some cool tshirts."
I think that's a great idea. The ability to do creative things like this is the "silver lining" of having so much money in the bank (which, as I mentioned above, is something I generally consider a risk, or at best a hedge.)
I'd love to hear your ideas about how this could work, and when we should start doing it (it's probably way too early?) either here or on meteor-talk.
I'd love to hear your ideas about how this could work, and when we should start doing it (it's probably way too early?) either here or on meteor-talk.
This will definitely require more than the two minutes of thought I put into this post, but. . . Large companies like Adobe, Microsoft, etc, often sponsor projects that will serve as good marketing for whatever initiative they're trying to push. Something similar could work once you see projects out there. In the spirit of openness you could setup and initially fund a non profit similar to Apache Software Foundation with a board that decides where the money goes. Doing something like Google's Summer of Code might spur some interesting projects. Or maybe even set aside the cash and do some sort of community voting contest thing. Like: "Build something awesome and win up to X in no-strings-attached cash, voted on by the internet." Put in caveats like it has to become a full time project, etc.
Leap Motion spent presumably a lot of their funding to get free SDKs with free devices in the hands of developers.
You guys might consider running a "mini-VC" with portion of that money to get few startups onto Meteor.
You guys might consider running a "mini-VC" with portion of that money to get few startups onto Meteor.
I'm here with you - $11m for pure long-term development without any hands-on application seems like a clear path to an over-engineered solution.
Agreed. I worked on an open-source app development framework and found it really difficult to "do the right thing" unless we were actively building "real world" apps with it.
Although they have enough money to not do consulting - I strongly suggest they take on strategic apps (even for free!) that push the boundaries of the framework. It'll be a better product for it.
Although they have enough money to not do consulting - I strongly suggest they take on strategic apps (even for free!) that push the boundaries of the framework. It'll be a better product for it.
100% agreement. When your app behaves like a framework there needs to be examples of applications on top. I had the same dilemma when I was about to release my dashboard framework (https://my.infocaptor.com) . I had all the documentation but to truly demonstrate the framework and various different ways, we had to build various little dashboards. some of the dashboards were plain stupid like the "bug olympics" but they were built to demonstrate certain features which we did not have enough sample data to build upon.
The question is do you build "real valuable applications" or "not so useful but demo like apps". We built the 2nd category apps in first go and now with our customers we are helping them build the first category of applications.
The question is do you build "real valuable applications" or "not so useful but demo like apps". We built the 2nd category apps in first go and now with our customers we are helping them build the first category of applications.
That plan worked out amazingly well for Diaspora!
I've long thought that the spiritual difference between RoR and ASP.NET is that one is built by application developers, and the other is built by language and framework developers.
Indeed. Though you'll note that ASP.NET is conspicuously absent from my list of nightmare monstrosities.
Not because it's not a nighmare monstrosity. It's the posterchild for nightmare monstrosity frameworks. But it's unique in that if ignore roughly 95% of the "point and click your way to unmaintainable intranet sites" garbage, what's left is pretty much pure awesome.
Deep in the center of the hairball is a tight little framework for building websites that has access to a really good, really big library that can do pretty much anything you'd want to do with a computer.
So it's both terrible and awesome at the same time, depending on whether you know which bit you're supposed to use. I wouldn't be surprised to find that there was a team at Microsoft somewhere using that small bit to build stuff and guiding the project just enough to make sure none of the good got mangled by the tons and tons of bad.
Not because it's not a nighmare monstrosity. It's the posterchild for nightmare monstrosity frameworks. But it's unique in that if ignore roughly 95% of the "point and click your way to unmaintainable intranet sites" garbage, what's left is pretty much pure awesome.
Deep in the center of the hairball is a tight little framework for building websites that has access to a really good, really big library that can do pretty much anything you'd want to do with a computer.
So it's both terrible and awesome at the same time, depending on whether you know which bit you're supposed to use. I wouldn't be surprised to find that there was a team at Microsoft somewhere using that small bit to build stuff and guiding the project just enough to make sure none of the good got mangled by the tons and tons of bad.
I can't agree with that at all. ASP.NET even after you remove all the point-and-click crap is still a mediocre web framework at best and arguably horrible in a number of crucial areas. One thing it is not is "pure awesome".
1. It isn't nearly as extensible as Rack and Rails. I mean not even in the same zip code.
2. It is not a very testable framework to work with. The ASP.NET abstractions are horrible for this, while the .NET MVC ones are better but still suffer due to all of the issues with the testability of the core of ASP.NET. Most of the testability abstractions that modern ASP.NET does have were added purely as afterthoughts, and awkward does not being to describe working with them.
3. ASP.NET regularly violates the "principle of least surprise". One of my favorite examples is where the HttpContext class throws an exception from the `.Request` property getter if you attempt to access it during the application startup (ironically it is actually starting up in response to a request so this is both confusing and inconvenient in addition to being bad API design).
.NET MVC is a poor man's Rails and working with it is merely a far more verbose and complicated way to accomplish the same thing. It is far less extensible, painful to test and automate around and has a far weaker OSS ecosystem around it.
I could honestly, go on. I worked with ASP.NET for years before moving on to Rails and occasionally node.js (though I'm really not all that big of a fan of callback coding).
1. It isn't nearly as extensible as Rack and Rails. I mean not even in the same zip code.
2. It is not a very testable framework to work with. The ASP.NET abstractions are horrible for this, while the .NET MVC ones are better but still suffer due to all of the issues with the testability of the core of ASP.NET. Most of the testability abstractions that modern ASP.NET does have were added purely as afterthoughts, and awkward does not being to describe working with them.
3. ASP.NET regularly violates the "principle of least surprise". One of my favorite examples is where the HttpContext class throws an exception from the `.Request` property getter if you attempt to access it during the application startup (ironically it is actually starting up in response to a request so this is both confusing and inconvenient in addition to being bad API design).
.NET MVC is a poor man's Rails and working with it is merely a far more verbose and complicated way to accomplish the same thing. It is far less extensible, painful to test and automate around and has a far weaker OSS ecosystem around it.
I could honestly, go on. I worked with ASP.NET for years before moving on to Rails and occasionally node.js (though I'm really not all that big of a fan of callback coding).
I suspect the "pure awesome" part is at the IHttpModule and IHttpHandler level, where you can do everything except receive and produce grievously invalid HTTP requests. If you need to do that, IIS is extensible via WCF to host more than HTTP.
If you don't use the legacy static accessors like HttpContext.Current, it's actually quite testable. HttpContext.Current is especially bad because it uses thread local storage, so you have to be very careful about when and where you access it.
If you don't use the legacy static accessors like HttpContext.Current, it's actually quite testable. HttpContext.Current is especially bad because it uses thread local storage, so you have to be very careful about when and where you access it.
I may be telling you things you are already well aware of, but ASP.NET MVC is a separate framework that removes 99% of the utter crap that came along with ASP.NET WebForms, so there definitely is a team at MS that sympathises. To go even further, Nancy.fx is a third party framework that gets even closer to the metal.
I still have enough of an undying love for the C# language that I dream of running Nancy.fx on Mono, on Linux, giving me the best of at least three worlds.
I still have enough of an undying love for the C# language that I dream of running Nancy.fx on Mono, on Linux, giving me the best of at least three worlds.
Agreed.
I also follow Blender 3d; they regularly make short movies to drive various areas of development. Since they started that, the quality and ease of use went way up, and it's more ready for real studios.
I hope Meteor makes some awesome examples/tests at least.
I also follow Blender 3d; they regularly make short movies to drive various areas of development. Since they started that, the quality and ease of use went way up, and it's more ready for real studios.
I hope Meteor makes some awesome examples/tests at least.
You are worrying prematurely.
"without taking on consulting work or trying to create some other application on top of Meteor to sell" != "Meteor will be built without real-life feedback"
debergalis cleared this up below: "We use meteor to build the meteor site".
Furthermore, I'll bet you hard cash that they are already working on partnerships to get people using Meteor for real applications.
Your post was valid, but everyone jumping on the band wagon has raised MY red flag. I think we're seeing reactions of either:
(1) worrying prematurely
- or -
(2) "I secretly want other people to make bad decisions and fail"
"without taking on consulting work or trying to create some other application on top of Meteor to sell" != "Meteor will be built without real-life feedback"
debergalis cleared this up below: "We use meteor to build the meteor site".
Furthermore, I'll bet you hard cash that they are already working on partnerships to get people using Meteor for real applications.
Your post was valid, but everyone jumping on the band wagon has raised MY red flag. I think we're seeing reactions of either:
(1) worrying prematurely
- or -
(2) "I secretly want other people to make bad decisions and fail"
>Do development frameworks built for their own sake ever really work in the wild?
AFAIK Node.js, which Meteor is built on, was built for its own sake and has done well in the wild.
AFAIK Node.js, which Meteor is built on, was built for its own sake and has done well in the wild.
Node's changed pretty drastically from the original vision though:
http://four.livejournal.com/943068.html
http://four.livejournal.com/963421.html
Meteor can do that as well, conceivably, if need be.
Ditto.
Another good example is Cappuccino/Objective-J. One of my favorite things about the whole Cappuccino/Objective-J framework was that 280 North built 280 Slides with it very early on. Going through the paces of developing an actual app with your framework is an essential process to creating something really useful.
The fact they've already decided they're not going to actually build a sellable product on top of it anytime soon is worrying, to say the least.
Another good example is Cappuccino/Objective-J. One of my favorite things about the whole Cappuccino/Objective-J framework was that 280 North built 280 Slides with it very early on. Going through the paces of developing an actual app with your framework is an essential process to creating something really useful.
The fact they've already decided they're not going to actually build a sellable product on top of it anytime soon is worrying, to say the least.
280 Slides seems like the opposite data point for me. It seemed like merely a demo of what you could do and that Cappuccino overall is fairly bloated and searching for real-world problems to solve. And 280 Slides is of course now gone, having never had much viability.
> Do development frameworks built for their own sake ever really work in the wild?
i guess so. Django was built for a CMS and then they open sourced it. Rails was built for Basecamp and then they've extracted it and open sourced it.
i guess so. Django was built for a CMS and then they open sourced it. Rails was built for Basecamp and then they've extracted it and open sourced it.
Agreed. I came here to post basically the same line.
>without ... trying to create some other application on top of Meteor to sell
I hope I dont see millions of dollars of time spent on abstraction and magic, or losing sight of a scientific process or an ability to correct fundamental architectural flaws that would challenge or invalidate the need for or the existence of what is now meteor, just because there has been introduced a fiduciary duty. Introspection on the fundamental usefulness and proper use cases in comparison to competition or existing equivalents is an ongoing dialogue that would be unprofessional to dismiss. Meteor is for everything? I really doubt that. Dont think about proper tools for the job, dont think about how to really scale out javascript architecture or solve that problem without subjectivity, dont think simplicity, just think meteor?
Marketing like this seems out of place in open source -- especially javascript frameworks -- which in proper form is most functional as a meritocracy. Along this continuum we will see meteor probably fitting right in at oscon, and maybe thats where they want to be, because it seems like its just going to be enterprise software with a hipster twist, donning open source as an applause light.
>Meteor was also a stealth participant in the S11 cycle of Y Combinator.
Sorry to be more cynical than everyone else in this comment thread, meteor guys, but I had red flags going up about meteor the first time it was posted on HN and I saw testimonials for a javascript framework that wasnt even production ready.
This is an open source javascript web framework: https://github.com/meteor/meteor/blob/master/app/server/serv... https://github.com/senchalabs/connect#authors
>without ... trying to create some other application on top of Meteor to sell
I hope I dont see millions of dollars of time spent on abstraction and magic, or losing sight of a scientific process or an ability to correct fundamental architectural flaws that would challenge or invalidate the need for or the existence of what is now meteor, just because there has been introduced a fiduciary duty. Introspection on the fundamental usefulness and proper use cases in comparison to competition or existing equivalents is an ongoing dialogue that would be unprofessional to dismiss. Meteor is for everything? I really doubt that. Dont think about proper tools for the job, dont think about how to really scale out javascript architecture or solve that problem without subjectivity, dont think simplicity, just think meteor?
Marketing like this seems out of place in open source -- especially javascript frameworks -- which in proper form is most functional as a meritocracy. Along this continuum we will see meteor probably fitting right in at oscon, and maybe thats where they want to be, because it seems like its just going to be enterprise software with a hipster twist, donning open source as an applause light.
>Meteor was also a stealth participant in the S11 cycle of Y Combinator.
Sorry to be more cynical than everyone else in this comment thread, meteor guys, but I had red flags going up about meteor the first time it was posted on HN and I saw testimonials for a javascript framework that wasnt even production ready.
This is an open source javascript web framework: https://github.com/meteor/meteor/blob/master/app/server/serv... https://github.com/senchalabs/connect#authors
The testimonials were a bit weird, esp. since they came from people who presumably weren't using the framework. Once we all realized this was a YC thing, what happened was quite clear. YC and YC partners was throwing their valley knowhow and marketing heft into "selling" a framework in a very early stage -- and very successfully, given the wide interest it has sparked and the $11M they've just raised.
I think this is a bit of a wait and see game, since this is experimental on a number of levels. On one hand, YC has started selling certain companies before they are ready on the basis of super-smarts and presumed future output. VC is willing to put in cash and see what happens. Everyone wants a piece of the next "Rails" and to create an ecosystem there, although probably no one is exactly certain what it will take to gel.
In short, I'd say that the red flags are justified, but also it is cool to see the potential ecosystem for an open source project go from zero to sixty in a few seconds because of YC and co. From the moment I'd like to give them the benefit of the doubt and hope that the hype is for real. The world could use something better than rails and a slick Javascript MVCish framework would be very nice.
I think this is a bit of a wait and see game, since this is experimental on a number of levels. On one hand, YC has started selling certain companies before they are ready on the basis of super-smarts and presumed future output. VC is willing to put in cash and see what happens. Everyone wants a piece of the next "Rails" and to create an ecosystem there, although probably no one is exactly certain what it will take to gel.
In short, I'd say that the red flags are justified, but also it is cool to see the potential ecosystem for an open source project go from zero to sixty in a few seconds because of YC and co. From the moment I'd like to give them the benefit of the doubt and hope that the hype is for real. The world could use something better than rails and a slick Javascript MVCish framework would be very nice.
YC and YC partners was throwing their valley knowhow and marketing heft into "selling" a framework in a very early stage -- and very successfully, given the wide interest it has sparked and the $11M they've just raised.
Gah. No. Raising $11M is not success. Raising $11M is putting yourself $11M in debt to investors. They will be successful when enough people are using, and paying for, Meteor that they turn a healthy profit. They are far from success right now. Arguably, further than before they took the money.
Gah. No. Raising $11M is not success. Raising $11M is putting yourself $11M in debt to investors. They will be successful when enough people are using, and paying for, Meteor that they turn a healthy profit. They are far from success right now. Arguably, further than before they took the money.
As the guy that raised the $11M, I agree completely. It is terrifying and a huge risk.
IMO, the biggest downside to raising a lot of money is that you are no longer accountable to anyone. You can run around saying "We're rockstars! We're winners! Catered dinners! Aeron chairs!" for years, even if you make no progress and produce nothing of value. At least if you stick to the "right" cocktail parties.
untog, I'm counting on people like you to call us out if we get slow, fat, stupid, lazy, and arrogant. Ultimately, we will be measured by what we ship, or better, what other people ship on top of Meteor.
IMO, the biggest downside to raising a lot of money is that you are no longer accountable to anyone. You can run around saying "We're rockstars! We're winners! Catered dinners! Aeron chairs!" for years, even if you make no progress and produce nothing of value. At least if you stick to the "right" cocktail parties.
untog, I'm counting on people like you to call us out if we get slow, fat, stupid, lazy, and arrogant. Ultimately, we will be measured by what we ship, or better, what other people ship on top of Meteor.
> IMO, the biggest downside to raising a lot of money is that you are no longer accountable to anyone. You can run around saying "We're rockstars! We're winners! Catered dinners! Aeron chairs!" for years, even if you make no progress and produce nothing of value.
Aren't you accountable to those you've raised money from?
Aren't you accountable to those you've raised money from?
[deleted]
Oh, please. Fundraising is a point of success. Equity is not debt. As is more than clear, "healthy profits" are not necessary for an acquirer to find value in a property. It is easier to argue that they are closer to more success.
[deleted]
I will take Meteor seriously when it is acknowledged and supported by the existing node.js community and the leadership. There is a large group of module authors who are cranking out beautiful, useful modules for both the browser and server at 1000x the rate of a normal human being. I am not going to list names here but check github or npm repository, etc. It is this team that makes node.js special, not simply 'javascript on the server'. If Meteor can gain support from this _established_ community I will start taking it more seriously.
Why not use the 11M in funding to hire one of these node.js leaders full-time? Outside of Meteor, what contributions has the Meteor team made to node.js and the ecosystem of modules? The founding team has no presence in the development community and yet their technology stack is built on top of it. I need to see that people I trust in the node.js community are driving and influencing the direction Meteor is headed. In fact, its almost a warning sign if Meteor can't staff any of the node.js leadership full-time as they certainly have the cash to do so. I will be watching who they are hire next very closely.
The lack of node.js leadership in their organization is already evident in the product decisions they are making which wouldn't stand a chance if they had a true representative of the node.js community on their team. A glaring example is the decision to build their own package management solution instead of adopting npm or working with npm to drive it forward if its missing useful features. Meteor is leveraging the output of the node.js ecosystem yet not recognizing its existence in their own product. They seem to be segregating themselves.
Why not use the 11M in funding to hire one of these node.js leaders full-time? Outside of Meteor, what contributions has the Meteor team made to node.js and the ecosystem of modules? The founding team has no presence in the development community and yet their technology stack is built on top of it. I need to see that people I trust in the node.js community are driving and influencing the direction Meteor is headed. In fact, its almost a warning sign if Meteor can't staff any of the node.js leadership full-time as they certainly have the cash to do so. I will be watching who they are hire next very closely.
The lack of node.js leadership in their organization is already evident in the product decisions they are making which wouldn't stand a chance if they had a true representative of the node.js community on their team. A glaring example is the decision to build their own package management solution instead of adopting npm or working with npm to drive it forward if its missing useful features. Meteor is leveraging the output of the node.js ecosystem yet not recognizing its existence in their own product. They seem to be segregating themselves.
Bingo.
It has been uniformly dismissed/ignored by the larger node.js community. Take from that what you will.
It has been uniformly dismissed/ignored by the larger node.js community. Take from that what you will.
At Throne of JS last weekend, Meteor stole the show in my opinion. The other frameworks (Backbone, Ember, Angular, etc) were about how to build rich JavaScript web apps on top of current backend technology, whereas Meteor is envisioning something new.
I'm not sure I want to write JavaScript everywhere but what they are able to demonstrate was super cool.
I'm not sure I want to write JavaScript everywhere but what they are able to demonstrate was super cool.
If anybody else is curious about said talk, here are the slides: https://speakerdeck.com/u/ericf/p/advocatus-diaboli-throne-o...
if there will be a video, i'd be interested in that
if there will be a video, i'd be interested in that
First Github, then Meteor. As Peter Levine pointed out in his blog (http://peter.a16z.com/2012/07/25/meteor-magic/) Andreessen Horowitz is making strides towards "help[ing] developers build the next generation of applications."
Are there any other VC firms that have had such a stong foothold on the foundation of application development?
Are there any other VC firms that have had such a stong foothold on the foundation of application development?
$11m (implying a valuation of of over $20mm) is a lot of money. (Although in a world of $7 rent, $150k developers, etc, it isn't as much as you'd think).
However, Meteor looks like it has some chance of being a huge platform, maybe the next big one. Even if it just dominates a niche, that is more than enough to justify the investment. A bigger series a reduces risk for the company, and a lot of the other interesting hard tech companies out there raise that amount of funding early (eg Bromium).
Red Hat does a pretty good job of demonstrating how open source companies can make a lot of money.
However, Meteor looks like it has some chance of being a huge platform, maybe the next big one. Even if it just dominates a niche, that is more than enough to justify the investment. A bigger series a reduces risk for the company, and a lot of the other interesting hard tech companies out there raise that amount of funding early (eg Bromium).
Red Hat does a pretty good job of demonstrating how open source companies can make a lot of money.
Some naivety being thrown around in this thread:
Andressen Horowitz doesn't need to see a direct return from meteor. If they think that the existence of meteor is a good thing for their other investments, then the indirect return they see from those projects is a good thing.
Andressen Horowitz doesn't need to see a direct return from meteor. If they think that the existence of meteor is a good thing for their other investments, then the indirect return they see from those projects is a good thing.
Eventually the [VC] generation that Fred Wilson leads will fall behind, as did the one led by John Doerr at Kleiner-Perkins. What they will be replaced with is one that is not only aware of the usability of products, but also has a sense for the flow of open technologies to fuel the ecosystem. These VCs will make side investments in technologies that are not intended to produce an IPO or acquisition, rather are intended to produce a new layer of technology that a whole generation of startups can feed off. At the same time, some percentage of each fund will be plowed into programs designed to generate the next layer after that.
- Dave Winer
- Dave Winer
Interesting point, but if that is their thinking, they didn't share it with me :)
As far as I know, they're looking the billions of dollars a year that IBM makes on WebSphere and thinking, "all of this spending on middleware and applications servers, where is it going to go in the future, if the future is client-side JavaScript, native mobile apps, and other things that fetch data over the wire and render it locally?"
They're hoping that in the fullness of time, many corporations will build important apps on Meteor, and that when those apps go to production we'll get a slice of their operations budget. It's the same model as the relational database.
As far as I know, they're looking the billions of dollars a year that IBM makes on WebSphere and thinking, "all of this spending on middleware and applications servers, where is it going to go in the future, if the future is client-side JavaScript, native mobile apps, and other things that fetch data over the wire and render it locally?"
They're hoping that in the fullness of time, many corporations will build important apps on Meteor, and that when those apps go to production we'll get a slice of their operations budget. It's the same model as the relational database.
That's not our thinking :-).
I'd say our thinking is threefold:
* Meteor needs to exist. There needs to be a great way to build modern, dynamic client-server web apps. Meteor is a real breakthrough and deserves to be fully built out and supported.
* As Geoff notes, the market is actually very large. Much like we think Github can eat a lot of the market for source code control systems and developer tools (a multi-billion-dollar market today -- IBM/Rational etc.), Meteor at scale should be able to be a great business on top of a great technical and open source phenomenon.
* There's a lot of historical resonance for me personally -- I was the guy who kick-started the Javascript project at Netscape 17 years ago (originally called Livescript) -- the goal then was a single scripting language and framework on web client and server. Client worked great, server not so much. (Java was the opposite -- server worked great, client not so much.) Given that Javascript has become the most widely used programming language in history, I think the original idea deserves to be fully implemented, and Meteor is what we should have built back then had we known everything that we know today.
I'd say our thinking is threefold:
* Meteor needs to exist. There needs to be a great way to build modern, dynamic client-server web apps. Meteor is a real breakthrough and deserves to be fully built out and supported.
* As Geoff notes, the market is actually very large. Much like we think Github can eat a lot of the market for source code control systems and developer tools (a multi-billion-dollar market today -- IBM/Rational etc.), Meteor at scale should be able to be a great business on top of a great technical and open source phenomenon.
* There's a lot of historical resonance for me personally -- I was the guy who kick-started the Javascript project at Netscape 17 years ago (originally called Livescript) -- the goal then was a single scripting language and framework on web client and server. Client worked great, server not so much. (Java was the opposite -- server worked great, client not so much.) Given that Javascript has become the most widely used programming language in history, I think the original idea deserves to be fully implemented, and Meteor is what we should have built back then had we known everything that we know today.
[deleted]
It's unlikely that Andressen Horowitz would make an investment because they anticipate the company's services will increase the value of their portfolio. I think it's far more likely that they're looking for a positive return on Meteor.
Maybe, but probably not. I suspect AH believes 1) it can make a big financial return and 2) if it does, it's a model for funding this type of "company".
I've been leaning towards DerbyJS because pages are also rendered in html (SEO, no-js)and it uses npm instead of making it's own repository... http://blog.derbyjs.com/2012/04/14/our-take-on-derby-vs-mete...
But Meteor has the advantage now, looking forward to what they do with it. Congrats to them!
But Meteor has the advantage now, looking forward to what they do with it. Congrats to them!
These two frameworks are so similar, and so close in developmental progress. Derby follows more closely the spirit of Node. Meteor's upper hand is its press/following/critical mass, Derby's its architecture and authors. There's some good discussion going on here https://groups.google.com/forum/?fromgroups#!topic/derbyjs/A...
Meteor has brand-new experimental support for serving HTML to crawlers. Check out the Google cache for meteor.com :) The links work and everything. This just went live this morning.
Congrats. Could someone please explain the business model of such open source based startups in general?
Could someone please explain the business model of such open source based startups in general?
There are a few different models: for example, "open core" where part of the overall product is open source, and then layers of proprietary stuff are put on top and the aggregated "thing" is sold (but can't be redistributed). Then you have "dual licensing" where the product is purely under a F/OSS license (often times the GPL or another "copyleft" license) and the company sells commercial licenses that offer different terms (such as the right to redistribute a derivative product without needing to make your own product F/OSS).
And then there are the "pure play" OSS firms... everything is F/OSS, but they test/certify certain builds, and ship binaries for money even though you can download something which is probably 99.999% bit identical (images and copyright notices being the main differences). In this model what the customer is paying for is - arguably - not software at all, but "peace of mind," indemnification, certification, the "somebody to sue" factor, support, etc. Red Hat are a good example of this latter model. JBoss binaries are freely available, and CentOS is nearly identical to RHEL, but yet people still pay Red Hat for JBoss and RHEL.
In all three cases, there are also supplemental things the firm can sell for revenue, such as training classes, certifications, professional services work, T-shirts, etc.
There are probably still some other variations that I'm forgetting at the moment, but I think those are the big three.
There are a few different models: for example, "open core" where part of the overall product is open source, and then layers of proprietary stuff are put on top and the aggregated "thing" is sold (but can't be redistributed). Then you have "dual licensing" where the product is purely under a F/OSS license (often times the GPL or another "copyleft" license) and the company sells commercial licenses that offer different terms (such as the right to redistribute a derivative product without needing to make your own product F/OSS).
And then there are the "pure play" OSS firms... everything is F/OSS, but they test/certify certain builds, and ship binaries for money even though you can download something which is probably 99.999% bit identical (images and copyright notices being the main differences). In this model what the customer is paying for is - arguably - not software at all, but "peace of mind," indemnification, certification, the "somebody to sue" factor, support, etc. Red Hat are a good example of this latter model. JBoss binaries are freely available, and CentOS is nearly identical to RHEL, but yet people still pay Red Hat for JBoss and RHEL.
In all three cases, there are also supplemental things the firm can sell for revenue, such as training classes, certifications, professional services work, T-shirts, etc.
There are probably still some other variations that I'm forgetting at the moment, but I think those are the big three.
Here's what I learned when doing this research for Meteor.
* You can sell training, but it's low-margin. If that's all you do, it probably ends up looking more like a consulting business, because you have to recruit armies of teachers if you want to scale up the business.
* You might think you can sell support, but it's hard. There's a catch-22. If your product is good enough that people want to use it, it's probably good enough that they don't use their support incidents and end up not wanting to renew their support contracts.
* You can sell some kind of management software or application server that only big companies need. This has been a sweet spot for some other projects. Developers at small companies don't have any money, and developers at large companies don't have any budgetary authority. But, the operations teams at larger companies have a budget, and if you have an offering that's useful to them, they're able to pay what it's worth.
* You can sell long term maintenance of other people's software. This is the Red Hat model. They put their LTS stamp of approval on a collection of packages, and guarantee that those packages will be maintained for N years. People will pay for this. The investors I talked to seemed wary about this model. "Yeah, Red Hat got to $1B of revenue, good for them, but man, it took a long time."
* Platform-as-a-service is harder than it looks. Small customers will pay incredibly huge markups. But that's only if you look at it on a percentage basis, rather than in terms of absolute dollars. When someone gets big enough to be paying you "real money," they tend to leave your PaaS, either because it's too expensive (it becomes financially reasonable to pull the function in-house) or because you don't give them enough control or security.
* If you make your software GPL, you can extract a few million bucks from big companies that can't use any GPL software, which sometimes happens for complicated reasons involving, eg, patent cross-licensing deals. If your software is truly universal and something that every developer must have, they will write you big checks for GPL exceptions. But these are one-off deals and you can't really build a business on them.
* You can sell training, but it's low-margin. If that's all you do, it probably ends up looking more like a consulting business, because you have to recruit armies of teachers if you want to scale up the business.
* You might think you can sell support, but it's hard. There's a catch-22. If your product is good enough that people want to use it, it's probably good enough that they don't use their support incidents and end up not wanting to renew their support contracts.
* You can sell some kind of management software or application server that only big companies need. This has been a sweet spot for some other projects. Developers at small companies don't have any money, and developers at large companies don't have any budgetary authority. But, the operations teams at larger companies have a budget, and if you have an offering that's useful to them, they're able to pay what it's worth.
* You can sell long term maintenance of other people's software. This is the Red Hat model. They put their LTS stamp of approval on a collection of packages, and guarantee that those packages will be maintained for N years. People will pay for this. The investors I talked to seemed wary about this model. "Yeah, Red Hat got to $1B of revenue, good for them, but man, it took a long time."
* Platform-as-a-service is harder than it looks. Small customers will pay incredibly huge markups. But that's only if you look at it on a percentage basis, rather than in terms of absolute dollars. When someone gets big enough to be paying you "real money," they tend to leave your PaaS, either because it's too expensive (it becomes financially reasonable to pull the function in-house) or because you don't give them enough control or security.
* If you make your software GPL, you can extract a few million bucks from big companies that can't use any GPL software, which sometimes happens for complicated reasons involving, eg, patent cross-licensing deals. If your software is truly universal and something that every developer must have, they will write you big checks for GPL exceptions. But these are one-off deals and you can't really build a business on them.
The business model is:
"Get acquired by somebody with a lot of money that wants to use your tech in their other projects"
which is exactly what happened.
"Get acquired by somebody with a lot of money that wants to use your tech in their other projects"
which is exactly what happened.
By raising this amount of money, we've (semi-deliberately) closed the door on any possibility of an acquihire. The valuation is too high for the VCs to agree to that outcome, and one of the privileges of Series A shares is the ability to veto acquisitions.
So we have two choices: (1) build Meteor into a great development platform, get a lot of people to build apps on it, and find something that we can sell to the operations department of big companies that are using it (I wrote a bit about this in other comments), or (2) fail.
So we have two choices: (1) build Meteor into a great development platform, get a lot of people to build apps on it, and find something that we can sell to the operations department of big companies that are using it (I wrote a bit about this in other comments), or (2) fail.
I think that AH just wants your tech. to exist. This is the same as any other company investing in OSS.
Mostly training and consulting. There is no better indicator that you know a framework best if you made and maintain it.
Another way, that the Meteor guys are trying (probably on top of training and consulting) is to sell an enterprise solutions. This solution will probably be an all in one appliance that enterprises can buy so they have an easy way to deploy and manage Meteor applications internally.
Another way, that the Meteor guys are trying (probably on top of training and consulting) is to sell an enterprise solutions. This solution will probably be an all in one appliance that enterprises can buy so they have an easy way to deploy and manage Meteor applications internally.
WebFWD has a useful overview video of Open Source startups, licenses to ponder, business model's, and goals.
http://blog.webfwd.org/post/27490054493/getting-your-softwar...
http://blog.webfwd.org/post/27490054493/getting-your-softwar...
I love the idea of Meteor and want to use it on some projects, the only thing I don't like is how language-centric it is on the back-end. node.js is okay, I'm not completely adverse to coding server stuff in JavaScript, but I'd prefer having a choice of languages, for instance most of my server-side code is in Python. I wonder how friendly its architecture would be to supporting multiple language back-ends eventually.
The architecture is designed specifically to support your choice of backends. The Meteor client and the Meteor server speak a simple JSON-based protocol called DDP. A Meteor client can talk to any server that can speak DDP. A Meteor server can talk to any client that can speak DDP. In fact, clients can connect to multiple servers by calling Meteor.connect() to open additional connections.
We already have a demonstration DDP client that is written in Python :)
My prediction is that in the future, you'll often see a breakdown where the user interface team works in JavaScript, and some of their code runs on the client, and some on the server. Other teams will build backend services in whatever language is best for the job, and they'll talk to the JavaScript written by the UI team (sometimes interfacing directly on the client, and sometimes, for example when multiple services are integrated, going through some JS code on the server.)
That's just a guess though.
We already have a demonstration DDP client that is written in Python :)
My prediction is that in the future, you'll often see a breakdown where the user interface team works in JavaScript, and some of their code runs on the client, and some on the server. Other teams will build backend services in whatever language is best for the job, and they'll talk to the JavaScript written by the UI team (sometimes interfacing directly on the client, and sometimes, for example when multiple services are integrated, going through some JS code on the server.)
That's just a guess though.
Sounds great! Thanks for that info, now I know what to look for in the docs :)
I think for that you'd be better of using something like ember.js
If they can make Meteor as accessible as PHP, they have a great chance of success. It's definitely heading in the right direction.
Perhaps a naive question, but how does AH envision getting its $11M+ back and in what time frame?
We have a 10+ year lockup on our money -- we can go to 13 years without too much effort, and longer if necessary -- so there's no near term pressure for financial return.
The goal is to build Meteor to its full potential both as a technology (including open source) and a company. If that happens, the long-run return will be fine.
The goal is to build Meteor to its full potential both as a technology (including open source) and a company. If that happens, the long-run return will be fine.
What they're dreaming of is: lots of big companies write their vital business apps on top of Meteor. They spend billions of dollars on middleware and application servers that helps them deploy, monitor, and control these apps across their 100 divisions and 5 data centers, similar to the billions of dollars they've spent in the past on Oracle, WebSphere, Tuxedo, Tibco, etc. Meteor does an IPO.
Failing that, they're hoping that we can replicate the success of JBoss ($420M to Red Hat), XenSource ($500M to Citrix), or SpringSource ($420M to VMware), all of which took open source software and sold it to the enterprise, and each of which did it under the direction of one of Meteor's new advisors (David Skok, Peter Levine, and Rod Johnson respectively.)
As for time frame, they are patient and expect it to take a long time. They know that it takes years for a platform to be adopted.
Failing that, they're hoping that we can replicate the success of JBoss ($420M to Red Hat), XenSource ($500M to Citrix), or SpringSource ($420M to VMware), all of which took open source software and sold it to the enterprise, and each of which did it under the direction of one of Meteor's new advisors (David Skok, Peter Levine, and Rod Johnson respectively.)
As for time frame, they are patient and expect it to take a long time. They know that it takes years for a platform to be adopted.
Thank you. Couldn't hope for a better reply.
(edit) I am honestly surprised to see a VC invest into (what amounts to) a fundamental technology. Though, given the valuation bubble we are in, it makes sense. VCs now have a choice between continuing to speculate by funding upload widget startups ($2-3M a pop, two years of runway) and putting money into the core tech. Fingers crossed, this becomes a trend.
(edit) I am honestly surprised to see a VC invest into (what amounts to) a fundamental technology. Though, given the valuation bubble we are in, it makes sense. VCs now have a choice between continuing to speculate by funding upload widget startups ($2-3M a pop, two years of runway) and putting money into the core tech. Fingers crossed, this becomes a trend.
100% agree :-).
Salesforce bought Heroku for a boatload of dollars. It's not difficult to imagine that someone might acquire a next-generation application development platform. Just one possible exit.
I really wonder the idea of putting $11M to a javascript framework.
Wow, congrats. Great work.
Anyone know if they are close to having proper auth in the client for DB work yet?
Anyone know if they are close to having proper auth in the client for DB work yet?
While it hasn't landed in the master branch yet, you can follow the progress of auth support in the auth branch: https://github.com/meteor/meteor/tree/auth
See also discussion in the meteor-core list: https://groups.google.com/forum/?fromgroups#!topic/meteor-co... https://groups.google.com/forum/?fromgroups#!topic/meteor-co... and https://groups.google.com/forum/?fromgroups#!topic/meteor-co...
See also discussion in the meteor-core list: https://groups.google.com/forum/?fromgroups#!topic/meteor-co... https://groups.google.com/forum/?fromgroups#!topic/meteor-co... and https://groups.google.com/forum/?fromgroups#!topic/meteor-co...
Thanks for sharing this!
Thanks.
Yes, we now have an authentication system that lets you define limits on which documents each client can read and modify. It's available on the "auth" branch in the Meteor repository.
https://github.com/meteor/meteor/wiki/Getting-Started-with-A...
Yes, we now have an authentication system that lets you define limits on which documents each client can read and modify. It's available on the "auth" branch in the Meteor repository.
https://github.com/meteor/meteor/wiki/Getting-Started-with-A...
Do you have an ETA when you will officially release Meteor with auth?
this.
i can't even touch it until i know i can make sure a client can't even see the existence of rows it's not allowed to read.
i can't even touch it until i know i can make sure a client can't even see the existence of rows it's not allowed to read.
That's precisely how Meteor auth works. Each client can request a set of documents from the server -- think of it as a predefined query. For each of those requests, your server code decides what (if anything) to send back to the client.
That's exactly what I was going to ask. That's the one thing keeping me from building something serious with Meteor.
The rest I tried, and it does look really nice for real-time webapps, as soon as the Javascript development environment grows up a bit more.
The rest I tried, and it does look really nice for real-time webapps, as soon as the Javascript development environment grows up a bit more.
So far it seems like Meteor is focused on data syncing and live UI elements. That's neat when done well, but the main pain points for client-side heavy apps is the mismatch between the server and client and between the traditional URLs structure of web pages and the MVC structure of apps.
I'm looking for:
* Complete parity between server and client-side rendering for content. This is required both for first-page performance, caching, and SEO.
* URLs as the foundational organizing principle of the app. The mismatch between clicks, back buttons and external links makes code hard to organize and apps behave strangely without serious work.
* Database agnostic. Relational datastores remain incredibly productive and proven for the vast majority of apps.
I'm looking for:
* Complete parity between server and client-side rendering for content. This is required both for first-page performance, caching, and SEO.
* URLs as the foundational organizing principle of the app. The mismatch between clicks, back buttons and external links makes code hard to organize and apps behave strangely without serious work.
* Database agnostic. Relational datastores remain incredibly productive and proven for the vast majority of apps.
IMO, this is dead on.
We group your first two requests together as a project called Routes, and it will be one of the big initiatives we take on once the authorization and account work is shipped to production.
As for your third request, we're been careful with this. Internally, Meteor is already database agnostic. For example, DDP, the Meteor wire protocol, is based on tables, and all of the code that performs latency compensation, etc, doesn't make any database assumptions. Mongo support is provided by a Smart Package that includes the client-side Mongo emulator and the server-side Mongo connector. Supporting SQL, Redis, Couch, etc, is a "simple matter of programming." We'll likely do Routes first since there's more technical risk there.
We group your first two requests together as a project called Routes, and it will be one of the big initiatives we take on once the authorization and account work is shipped to production.
As for your third request, we're been careful with this. Internally, Meteor is already database agnostic. For example, DDP, the Meteor wire protocol, is based on tables, and all of the code that performs latency compensation, etc, doesn't make any database assumptions. Mongo support is provided by a Smart Package that includes the client-side Mongo emulator and the server-side Mongo connector. Supporting SQL, Redis, Couch, etc, is a "simple matter of programming." We'll likely do Routes first since there's more technical risk there.
From my cursory review Meteor a few months ago, I got the sense that it could be a game-changer like Rails. However, by raising this money they're going a very different route than DHH and company.
It will be interesting to see how this plays out over the next few years.
It will be interesting to see how this plays out over the next few years.
So, as I write Node.js and Socket.io based applications, lots of my code(on the server at least) focuses almost completely on protecting myself from bad data/malicious users. I know it works this way for almost any application, but how does Meteor handle this? I saw in the screencast someone opening their chrome console and touching the database directly. This seems like an absolute nightmare to protect! Currently, I only need to protect the individual web address that gets, puts, posts, etc. It's a single query with clear attack vectors that can be guarded against. How in the world do you protect a server and data using this framework?
My first reaction when I saw him opening the chrome console was the same, its going to be a nightmare to build and maintain secure apps with this thing.
I guess the theoretical plus side, security-wise, of pushing everything through one abstraction is the potential for simplifying security. Non-layered approaches like Meteor make me a bit queasy, though. Will be interesting when its auth mechanism undergoes community security review.
Interesting idea.
I have questions about the following:
I have questions about the following:
> Database Everywhere. Use the same transparent API to
> access your database from the client or the server.
It's always a good idea to separate business logic from presentation logic. The idea in Meteor is that your business logic can run on either the client or the server as is appropriate in a given situation. For example, if you want to get the most recent 10 posts in the news feed, the exact same line of code works on both the client and server. Why have two APIs for this when you could have one? Of course the server still has to make sure that clients can't read or write to records they shouldn't (cf point 6, "Sensitive code runs in a privileged environment.")
Congratulations! Talk at Throneofjs for Meteor was excellent, especially liked the
meteor remove insecure
After their recent shocking Github investment and now Meteor, a16z are, IMHO, the most impressive VC firm in the US.
They have a very long-term vision, they put their money where their vision is, and that's the best thing founders can wish themselves when raising funds, may my investor will look as far as I and ever further.
Congrats!
They have a very long-term vision, they put their money where their vision is, and that's the best thing founders can wish themselves when raising funds, may my investor will look as far as I and ever further.
Congrats!
Why the NIH package system instead of npm? That's the main showstopper for me w.r.t investing time into meteor.
What is their mobile native app story (if one has been announced)? -- I'm not sure how I'd integrate the meteor backend with a native client (can't use a phonegap-like sdk in my case).
"we've arranged $11.2 million in funding for Meteor's continued development."
That's a nice arrangement. Do anyone know about other open-source web frameworks that have managed to get so much funding?
That's a nice arrangement. Do anyone know about other open-source web frameworks that have managed to get so much funding?
While I was fundraising, VCs told me that DHH could easily have raised a lot of money for Rails had he chosen to. I don't know for sure that that's true, but it certainly seems plausible given Meteor's experience.
Even though we chose a different path, I really admire what DHH did with Rails. We studied the original Rails screencast very carefully when were making the Meteor screencast.
Even though we chose a different path, I really admire what DHH did with Rails. We studied the original Rails screencast very carefully when were making the Meteor screencast.
Maybe. Good luck with Meteor. It's interesting to follow!
[deleted]
I'm surprised that people quickly adopt Meteor yet chastise PHP for enabling bad app developers, wouldn't Meteor do the same thing?
I expect to see some of this money used to purchase actual meteors: http://www.ebay.com/itm/CANYON-DIABLO-IRON-METEORITE-140-gr-...
Let's come back to this when Meteor is actually deployed in a real production environment handling 200 requests a second. Until then it seems like a lot of hot air.
Well deserved! Congrats to the team.
BUT CAN IT SHARE PICTURES???
"$11.2 million is a lot of money. What it gives us is certainty. No matter what else happens in the world, the core team will be able to focus entirely on Meteor for several years"
Assuming you're not targeted with any software patent suits.
Assuming you're not targeted with any software patent suits.
[deleted]
Does that raise any red flags for anybody?
Do development frameworks built for their own sake ever really work in the wild?
I think of successful ways to build web apps, and the names that spring to mind are rails, django, php, etc. that evolved by developers who were using them to build stuff. In some cases (rails, django especially), they were the side product of a single application.
I think of overarchitected nightmares such as Fusebox and some of the magic frameworks that would be Meteor's competition, and they tend to share the quality of having been built as the Ultimate Solution to Everybody's problem (with the conspicuous exception of the developers themselves, who aren't actually dogfooding it for anything).
To be clear, I'm impressed by Meteor and I'm looking forward to seeing where it goes. But it makes me a bit uncomfortable to see a declaration like "we're definitely not going to try building anything with it!" tacked onto their funding announcement.