
Meteor Raises $11.2M from Andreessen Horowitz - debergalis
http://www.meteor.com/blog/2012/07/25/meteors-new-112-million-development-budget
======
jasonkester
_No matter what else happens in the world, the core team will be able to focus
entirely on Meteor for several years, without taking on consulting work or
trying to create some other application on top of Meteor to sell_

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.

~~~
debergalis
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.

~~~
jconley
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.

~~~
geoffschmidt
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.

~~~
jconley
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.

------
enos_feedler
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.

~~~
2mur
Bingo.

It has been uniformly dismissed/ignored by the larger node.js community. Take
from that what you will.

------
100k
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.

~~~
arnorhs
If anybody else is curious about said talk, here are the slides:
[https://speakerdeck.com/u/ericf/p/advocatus-diaboli-
throne-o...](https://speakerdeck.com/u/ericf/p/advocatus-diaboli-throne-of-js)

if there will be a video, i'd be interested in that

------
warech
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?

------
rdl
$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.

------
blhack
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.

~~~
geoffschmidt
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.

~~~
pmarca
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.

------
JTxt
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...](http://blog.derbyjs.com/2012/04/14/our-take-on-derby-vs-meteor/)

But Meteor has the advantage now, looking forward to what they do with it.
Congrats to them!

~~~
lefnire
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...](https://groups.google.com/forum/?fromgroups#!topic/derbyjs/AMJ-
FaYnMjI)

------
sharjeel
Congrats. Could someone please explain the business model of such open source
based startups in general?

~~~
blhack
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.

~~~
geoffschmidt
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.

~~~
blhack
I think that AH just wants your tech. to exist. This is the same as any other
company investing in OSS.

------
radarsat1
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.

~~~
geoffschmidt
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.

~~~
radarsat1
Sounds great! Thanks for that info, now I know what to look for in the docs :)

------
gellis
If they can make Meteor as accessible as PHP, they have a great chance of
success. It's definitely heading in the right direction.

------
huhtenberg
Perhaps a naive question, but how does AH envision getting its $11M+ back and
in what time frame?

~~~
geoffschmidt
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.

~~~
huhtenberg
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.

------
bbayer
I really wonder the idea of putting $11M to a javascript framework.

------
lukeholder
Wow, congrats. Great work.

Anyone know if they are close to having proper auth in the client for DB work
yet?

~~~
glasser
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-
core/g4Bsm3yFTe4) [https://groups.google.com/forum/?fromgroups#!topic/meteor-
co...](https://groups.google.com/forum/?fromgroups#!topic/meteor-
core/PdwPNpMmlRU) and
[https://groups.google.com/forum/?fromgroups#!topic/meteor-
co...](https://groups.google.com/forum/?fromgroups#!topic/meteor-
core/-KHgLzb6xHo)

~~~
tegansnyder
Thanks for sharing this!

------
equark
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.

~~~
geoffschmidt
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.

------
drumdance
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.

------
jhspaybar
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?

~~~
quattrofan
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.

~~~
mcantelon
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.

------
tlogan
Interesting idea.

I have questions about the following:

    
    
       > Database Everywhere. Use the same transparent API to
       > access your database from the client or the server.
    

Is this a good thing? I have been always under impression that separating data
management and application logic is a good idea - basically a must. Meaning
lets think about more complex way to look at the database (temporal, stream,
event processing, etc.). How this can be then possible?

~~~
geoffschmidt
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.")

------
tlear
Congratulations! Talk at Throneofjs for Meteor was excellent, especially liked
the

    
    
      meteor remove insecure
    

that was a great touch

------
tzury
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!

------
stuffihavemade
Why the NIH package system instead of npm? That's the main showstopper for me
w.r.t investing time into meteor.

------
smoody
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).

------
flexie
"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?

~~~
geoffschmidt
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.

~~~
flexie
Maybe. Good luck with Meteor. It's interesting to follow!

------
brador
Anyone know the planned business model on this one?

------
phmagic
I'm surprised that people quickly adopt Meteor yet chastise PHP for enabling
bad app developers, wouldn't Meteor do the same thing?

------
tferris
<http://news.ycombinator.com/item?id=4052120>

------
tibbetts
I expect to see some of this money used to purchase actual meteors:
[http://www.ebay.com/itm/CANYON-DIABLO-IRON-
METEORITE-140-gr-...](http://www.ebay.com/itm/CANYON-DIABLO-IRON-
METEORITE-140-gr-METEOR-CRATER-AZ-FORMER-UNM-MUSEUM-PIECE-/221080520933)

------
dreamdu5t
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.

------
zanst
Well deserved! Congrats to the team.

------
wikkiwa
BUT CAN IT SHARE PICTURES???

------
wissler
"$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.

