If it was shrink wrapped software they would need a bigger sales team, a bigger support team, a bigger professional services team, etc. It’s just trade offs.

That's a really interesting point, and it piqued my curiosity. I decided a pretty fair comparison was Red Hat at the time of its 2005 IPO.[1] Its annual revenue for FY2005 was $278 million, so adjusted for inflation, a little smaller than Asana. (I'm annualizing the last reported quarter for Asana, because of its meteoric growth rate.)

But, still a fair good comparison of the shrink-wrapped software startups of yesteryear to today's SaaS business model. Operating systems certainly seem inherently more complex, so that should handicap things in favor of Asana. Of course, Red Hat is just re-packaging what's mostly developed by external open source contributors. But still, if we're talking about the overhead of support/services/sales, if anything that should make things harder for Red Hat.

In terms of COGS (cost of goods sold), its amazing how close the two land together. 14% or revenue at Asana and 17% at Red Hat. Since COGS includes technical support, it doesn't really seem that shrink-wrapped software is significantly more costly to support than SaaS.

For both companies sales is a major expense item. Still Red Hat's model seems to have a handy advantage. Its "only" paying 32% of revenue to sales, whereas Asana is paying a whooping 76% of revenue to sales. To be fair Asana is achieving a much faster growth rate than 2005-era Red Hat. Still, there doesn't really seem to be any clear sign that shrink-wrapped software is more expensive to sell than SaaS. At least in the enterprise space.

However with R&D costs the discrepancy's pretty clear. In 2005, Red Hat was spending 16% of revenue on this line item. Asana triples this rate by spending nearly 50% of revenue on R&D. And again, ipso facto it certainly seems like Red Hat is developing a much more complex product.

[1]https://www.annualreports.com/Company/red-hat-inc

And honestly its actually even more work in many ways, since you need to be able to work anywhere, not just in a well known environment.

In the age of VMs and containers I'm not sure it's still true.

I've been involved in debugging a bug in a software that occurred on Kubernetes cluster at the client site but couldn't be reproduced locally. Reproducing that is so much harder than a similar software installation. You have so many moving parts that it's pretty much impossible to create a test cluster with the same properties.

Also, with SaaS you can get access to log files, if it's installed on prem that can be heavily restricted by regulation.

Sure, but it's economies of scale. You only have to do the hard stuff once at the source, instead of having every node do it individually.

Also if stuff goes wrong in the node model, the customer will blame you even if it's mostly their fault. So it's also important for brand benefits.

On the other hand if stuff goes wrong in the centralized model it goes wrong for everyone everywhere, and it almost certainly is really your fault.

I agree trade-offs, but I sometimes feel the gain has not been all that great.

The point is, Asana has 300 people, but with a SaaS model, their clients need less IT staff than with an in-house server. If Asana has 10,000 customers, they’ve just reduced IT personnel costs across the industry with 300 Asana employees, which is almost guaranteed to be a net cost reduction for the industry.

One of the subtle things about SaaS is far less "up-front" costs or fixed costs. This helps sell to business around the lines of pay-as-you-grow rather than commit to x years of SLAs. Shrink-wrapping software takes away this key sales lever and leads to longer sales cycle which might be part of the reason why SaaS models are so attractive.

Good luck now having to build and maintain software that needs to reliably and correctly update itself on +70K instances not under your control.

That's not even taking into consideration the fact that you no longer quite know what's going on in those 70K instances, which leads to extremely rigorous tests or the need for a big support team.

It would be interesting to know what costs the Jira self hosted option has put on the product for comparison to Asana's running costs.

Those downsides could also be considered upsides from a certain perspective: More work, more jobs; the industry grows.

Whose perspective is that, though?

Individual companies don't benefit from low productivity, and neither does the economy as a whole.

I think at least a segment of (an, The?) economy grows from some kinds of unproductive churning. Maybe it depends how you define productive. I'd argue that gambling or gaming are not productive even though they are lucrative for some and fun for many.

Well, now we are getting into philosophical territory.

As a simple example, watching a movie doesn't produce anything, but it does give people joy. Similarly, eating anything tastier than the bare minimum gruel to keep you alive and healthy mostly just gives you extra joy.

Orthodox economics is perfectly fine with that. They deal in 'utility'. Fun is a perfectly fine product to deliver.

So eg gambling or playing the lottery can be perfectly rational, as long as you are aware that you are doing it for the entertainment value, and not as a financial investment.

Now for our situation: I hold that the extra work here doesn't provide any net gain in utility. Not even for people who like programming: there's enough other programming work left that's not just churn and that's not any less enjoyable.

Of course, the humble agnostic choice of orthodox economics is not the only possible one. If you are some kind of puritan or a paperclip maximizer, you'll know for a fact that producing fun is not productive. Only paperclips count (or whatever puritans optimise for).