Twitter is threatening to sue Meta over Threads [pdf]

1. Many people who were commenting on how this would adversely affect Twitter were doing it solely because they didn’t like Musk, as opposed to an understanding of how software development works. So these people were basically predicting that Twitter would stop working entirely in 2 weeks. But that’s not how software is developed. If it was, engineers would never be able to take a vacation and major web apps would all start failing on Jan 1.

Those who understood how software development worked recognized that what we would see instead is a slow decay in software quality where things would consistently become slightly worse. Also, we’d see a complete inability to change major functionality without causing problems. Finally, there might be a few big bang failures (eg the domain name expires, but no one with access to the domain is still hired by Twitter anymore) but those would be few and far in between and would take time to uncover (although it does appear Twitter has faced at least one such situation).

Twitter is indeed facing these situations.

2. The real threat to Twitter was always competition. In a competitive environment staying still is a death trap since your competitors will outpace you. There are a few reasons why Twitter has largely escaped this so far. (a) Twitter’s business is a fundamentally bad business model with a lot of hassles most businesses simply don’t want to deal with. (b) a misconception by many competitors that there was something fundamentally wrong with Twitter that needed to be addressed.

(b) is why Bluesky and Threads have been the most successful Twitter alternatives. They’ve basically been Twitter clones and are not trying to fundamentally change the model. Of course, Bluesky is now basically getting crushed by Meta’s resources and existing user base, but they were fundamentally ok the right track and could have been competitive if they were able to reach technical parity earlier.

In a non competitive world this might be true (although I have my doubts). In a competitive free market world it isn’t because a competitor can then beat you by hiring more developers and delivering more features faster than you could.

> Its easy to find many examples of apps that were challenging to build even just 10 years ago, that are somewhat trivial now.

The consequence of this isn’t that people continue using those tiny apps. The consequence is that people’s expectations increase dramatically. There was a time Evernote was a Unicorn. Today, even though building a product like Evernote would still be fairly challenging, it’s considered a feature.

> You don't need 100s of operations people if you move from on-prem to serverless,

I have not yet, in practice, seen overall spend go down by moving to serverless. You may have fewer ops people, but you now need more devs to achieve the same work because a lot of ops has been shifted to devs. That being said, I’ve often seen serverless not even lead to a reduction in ops.

> Many products that required 1000s of people 10 years ago, may only require 100s today. To me this is just a fact

This does not come close to matching reality. In the late 90s early 2000s you and a handful of other devs could build a multimillion dollar product using Visual Basic which only ran on Windows and was distributed as a binary to be run by your clients and it would be a best in class product.

Today, you would need a designer, web developers, and someone with experience in pushing it to production and securing it to simply build an MVP version that ran on browsers. In addition you would need another set of iOS developers and another set of Android developers. Heck, you may even need an Apple Watch and iPad app to be competitive. All of this would probably be required to simply make your app competitive, never mind best in class.

What your comment appears to be missing is that with software development becoming easier, what changes most is an increase in customer expectations.