jd

As a EU founder I think the article misses the two primary reasons Europe isn't doing well with startups.

1) Target market

USA: natural target market of 320 million people with a very high level of (disposable) income. Established businesses are happy to buy products from startups. There is a positive feedback loop where businesses try to grow fast and therefore want to outsource the stuff they're not good at so they can focus on their core skills. This means startups can pop up to take care of everything else (HR/Invoicing/Data crunching/etc-as-a-service).

EUROPE: you have to deal with dozens of languages and cultures. Although the and Germanic countries are OK with English-only products, the rest of Europe wants their products translated. Salaries are much lower here and businesses are much more conservative. Businesses that grow slowly have to care much more about operating expenses, which means they will try to do everything in-house to cut costs.

As a consequence we get the vast majority of our revenue from the US, even though people all across the world try our software.

2) Culture

A lot of people talk about starting a startup, but nobody seems to want it badly enough. Perhaps this is because there are so few success stories over here in the Netherlands. People tend to focus on the negative (what if you fail? what about work-life balance? what if you get sued?), but it's hard to say if that matters.

The US has only one Silicon Valley. There is nothing comparable on the east coast, even though the east and west coast have a lot in common. If we figure out why Silicon Valley works and other places fail to really take off we should be able to create startup hubs all across the world.

Quick correction: it's not true that rdiff-backup has to be installed on the remote server. Rdiff-backup works brilliantly with a dumb target for storage and that's how we use it in production.

Our servers periodically run rdiff-backup of all important data to a /backup partition on the same server. Then this /backup partition -- with the backup version history and metadata -- is rsynced to various dumb backup storage locations.

We've tried many backup solutions, and rdiff-backup is by far the fastest and most robust backup program we know.

Although I don't know the specifics for Braintree, it's not contradictory to accept VC money for bootstrapped companies. If a startup goes from 0 to 10M revenue without taking any outside investment then that puts them squarely in the bootstrapped camp. However, if they then realize they're in a winner-takes-all market and that they need a lot of money in order to scale up, then they can still accept VC money at that later stage.

With the exception of image gallery carousels for mobile devices. Those can work great.

Another reason why / short term & software / is the currently the sweet spot is because it allows for short feedback cycles. A startup is a company that searches for a viable business model -- a product-market fit. When you create web based applications you can gather data, A/B test and do a lot of stuff that allows you to make measurable progress in the right direction.

When working in hardware or when working on long term software projects like AI you're in a vacuum. And even smart people are not going to do very well if they can't see the consequences of the decisions they make.

So long term projects take more people, more resources, are typically much harder problems and on top of that you won't be able to collect data early on to adjust course if needed. So the risk-adjusted return on an ambitious long-term startup is going to be horrendous compared to the low-hanging fruit most web startups go for. So investors avoid the big and ambitious ideas, and I can't blame them.

This seems to be a regional issue that mostly affects the UK.

The most obvious reason is that pg writes an essay when he has an idea or an insight he wants to think and write about. New insights don't arrive on a fixed schedule.

If pg had been posting every month the HN thread would read: "Ask HN: is it just me or has the quality of Paul Graham's writing gone down?"

Good point about the link to Lotus Notes. However, infrastructure decisions are usually made for short term reasons, and that's often an OK trade-off.

Inky looks awesome, by the way.

Exactly. pg has also written about "using your email as a todo list" (in Startup Ideas We'd Like to Fund) to partially address the problem of email being more than just a dumb box for all incoming information. Email as it exists today is very obviously broken, and very few players are in a position to change it. (Although there must be some startups with the frighteningly ambitious plan to replace email as we know it today.)

Of course it remains to be seen whether this is just a first move by Google towards a big goal or whether Google is just playing with new Gmail functionality to see what happens.

Exactly. Or to put it in a different way, the total time you spend waiting for your car to recharge/refuel is way lower for an electric car. The electric car is optimized for the 99% case (where recharging at home is sufficient). A gasoline car is optimized for the 1% case where you take a road trip.

You get the exact same effect for people who claim they need a pickup truck instead of a small city car just so they can transport some furniture or motorcycles or a Christmas tree in the back.

Most importantly -- when researchers know their data and methodology will be out in the open they'll have a big incentive to make it look clean and presentable. They know they risk getting called out on excluding certain segments of the data set, so they'll have to at the very least add a small remark in the spreadsheet justifying their decision. It also makes it really easy for other researchers to pick other start and end years to test if the result only holds for the original data. Which again, encourages researchers to explain justify the input data they've chosen.

In addition, researchers are likely to discover mistakes while cleaning up the excel sheet, data sources and code before publishing it. Just like we find mistakes in our work while refactoring and cleaning up code before we push it to github.

So even when nobody ever looks at the data and code we can expect the quality of the research to improve significantly: just because the code is there to be looked at.

I think the case in favor of making data & code public for academic research is pretty overwhelming.