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.
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.
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.)
> 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.
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.
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.
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.
"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'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.
You guys might consider running a "mini-VC" with portion of that money to get few startups onto Meteor.
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.
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.
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.
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).
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 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 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.
"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"
AFAIK Node.js, which Meteor is built on, was built for its own sake and has done well in the wild.
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.
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.
>without ... trying to create some other application on top of Meteor to sell
>Meteor was also a stealth participant in the S11 cycle of Y Combinator.
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.
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.
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.
Aren't you accountable to those you've raised money from?
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.
It has been uniformly dismissed/ignored by the larger node.js community. Take from that what you will.
if there will be a video, i'd be interested in that
Are there any other VC firms that have had such a stong foothold on the foundation of application development?
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.
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.
- Dave Winer
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.
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.
But Meteor has the advantage now, looking forward to what they do with it. Congrats to them!
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.
* 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.
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.
"Get acquired by somebody with a lot of money that wants to use your tech in their other projects"
which is exactly what happened.
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.
We already have a demonstration DDP client that is written in Python :)
That's just a guess though.
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.
(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.
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.
Anyone know if they are close to having proper auth in the client for DB work yet?
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...
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.
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'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.
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.
It will be interesting to see how this plays out over the next few years.
I have questions about the following:
> Database Everywhere. Use the same transparent API to
> access your database from the client or the server.
meteor remove insecure
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.
That's a nice arrangement. Do anyone know about other open-source web frameworks that have managed to get so much funding?
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.
Assuming you're not targeted with any software patent suits.