It can work for a long time, but eventually it does create opportunities for competitors.
You're absolutely right that there's a floor for how simple these products can be, but most of the incumbents aren't anywhere close to that.
However, I do believe a (slightly) better competitor could be created, with better technology, better workflow, etc. If well-capitalized. If it had well-factored plugins. If you had a top-notch team to design all that and then build it.
That's a lot of ifs. Joel says it isn't guaranteed a brand new team will even do better than the old on the essential angle. It's risky and costly enough to prevent it from happening.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Experience probably has already taught you some of these ideas, but you hadn’t invested the time to reason about them and putting them together. Then you read an old blog post, from two decades ago, putting all those ideas into words and it simply clicks in your mind.
Thanks for sharing the link.
SAP and Jira are just not great software. They’ve got excellent sales teams, connections, and probably great support. That’s the key to getting user-hostile software into big orgs.
But the most likely scenario, I think, is that built-for-purpose competitors will build products that peel away small pockets of SAP's customer base over time.
The irony of course is that a product like SAP is the end result of similar built-for-purpose products being hoovered up and merged together in the first place.
Everything is a pendulum!
[1] https://www.cbinsights.com/research/craigslist-unbundling/
The requirements change, merge, flow. In theory each department within the enterprise could have their own optimized, silo'd tool ... but then you need "enterprise integration platforms" to glue together all the workflows between them.
Probably not. SAP is an everything-to-everyone product. Using Fred Brook's terminology for essential versus accidental, the problem with everything boxes is that even just the essential complexity of such a product is so insanely large that they are sufficient to produce a "horrid" product. Of course they don't have just the essential complexity and add a healthy dose of accidental complexity, but so would any putative "less horrid" replacement by the time it successfully solved the same essential problems as SAP.
Closer to home, "bug tracking" is an example of an everything-to-everyone product. I can't even count the number of times I've seen a "simpler, less horrid" bug tracker get started due to the perceived horribleness of the current bug tracker, but the new bug tracker simply became the old one once it tried to grow into the same niche. This may sound strange to 2022 ears, but I remember when JIRA was being pitched as the simpler solution and developers were pretty keen on it. There will never be a mature bug tracker that is any fun to use, because by the time it's everything to everyone it'll just be the same morass of being everything to everyone again. It turns out that the "less horrid" bug tracker wasn't actually intrinsically less horrid... it just wasn't everything to everyone. Instead it was a bug tracker for developers, so developers love it. But then if developers are going to be allowed to use it everywhere, it has to satisfy all the other stakeholders too, and it inevitably mutates into an everything for everyone product.
(See also: Salesforce. Letting users configure custom DB schemas is a key indicator of being an everything to everyone product. To some extent, programming languages too; there's a lot of people who pine for something simpler (such as the people who think that if we just went to visual languages, or tried to jam everything into "no code") and don't understand that by the time you have a general purpose language that is truly general purpose you've got a large amount of irreducible essential complexity whether you like it or not.)