I think it would be comparable, but not equal, to a factory walkout. Without active bug-squashing, DevOps and server maintenance, there is an increased risk of a major outage, which would even affect previous customers as well. Also, most tech companies collect revenue incrementally, via subscriptions, ads and the like, rather than up-front like most factories would. And getting a scab developer up to speed would likely take a lot longer than getting scab factory workers up to speed.

There are some differences as you said. If you're an auto factory that goes on strike, the management is likely still making money—they have all the cars made yesterday and the day before to sell. Of course, the pressure would rise much quicker in a factory vs a tech company; where the latter could presumably float itself for a few weeks, the former would start losing money within days.

A programmer walk-out is way worse. The Bus Factor is a real thing. Hire a new team to replace the old one on a complex project and it'll be months or years before they start doing anything productive. Making things worse, bit-rot is real and threatens existing software with failure if complaints aren't addressed.

You're right that distributed/remote teams present challenges to collective labor organizing.

You're mistaken in thinking that a walkout is the only, or even primary, method of direct action organized collectives can employ.

Here are 197 others: https://www.aeinstein.org/nonviolentaction/198-methods-of-no...

>It's going to end badly, unlike factories where a walkout would but a strain on production. A walkout necessarily doesn't put a strain on tech.

Certain types of work-to-rule (https://en.wikipedia.org/wiki/Work-to-rule) would bring most tech companies to their knees in a matter of minutes. It wouldn't just gum up the works as it would in industry, it could literally put systems into failure states.