So, full disclosure, I worked 4 years in SAP's LinuxLab (ending 16 years ago). I also hated interacting with their interfaces, but I do understand why they exist:

Comparison with hosting your own email is like a dozen orders of magnitude off in complexity. SAP really only makes sense for ginormous corporations, but up in that range, Oracle's ERP is the only real competition. Just the kernel of SAP is on the order of 100 million lines of code, and that's not counting the even more hundreds of millions of lines of business logic.

It'd be more like saying, "I'm going to reinvent email, write all clients, servers, and try to get everyone to adopt it." Except that would still be a few orders of magnitude off.

SAP has modules that handle regulatory issues in virtually every country in the world. There's so much business complexity that's encoded into its systems that it's literally hard for mere mortals to grasp.

I mean I'm pretty confident that if SAP was rebuilt from scratch today, one could reimplement its core functionality within a tenth or less of that amount of code you mentioned.

But there's literally decades of use cases and experience contained in that code. That's one major issue with people thinking about rewriting software, they vastly underestimate the amount of things in there.

I mean on the surface SAP is just a database with a UI and some business rules - 99% of software is - but that in itself is so often underestimated.

(Source: anecdotal, I underestimated 'just' a configuration interface, except that it had hundreds of models and thousands of fields. In hindsight I should've looked for an off-the-shelf data management thing where all I would have had to do was configure the fields and validation rules and some rough layout. Instead I tried to build it in naive Go, sqlite, a REST API and a React/bootstrap front-end. It's a great solution IMO, but not if you're a solo developer working on a domain that big).

Almost all software could be rewritten to be more concise. But SAP's actually too big to have one architect get an overview of everything and then conceive of an optimal solution. Anything with its level of complexity will have to have evolved to get to that point.

And if you managed to get it down to only 10% of its current size, it'd still be several times larger than the Linux kernel.

SAP makes copious amounts of money, so naturally people have tried to replace it. So far, they have not succeeded.

>> Now, I get it, once you have to deal with taxes and payroll in multiple countries it gets messy, but why wouldn't you consider that a core part of your business worth investing into?

It may work using an open source model. However you don't really want to invest into non-core business(es). It takes away money, talent and energy that you would better put into doing what you do best.

I've experienced this first hand developing an invoice system(not my core business). I still use it but if I were to do it again I would develop only the functionality that I was missing in the commercial offering and try an integration. Time spent on the none core business is time wasted.

> However you don't really want to invest into non-core business(es)

The problem is who gets to decide what is "core" to your business?

Look at airlines, once the McKinsey types were let loose it turned out none of the stuff we think is core is needed at an airline; no need for in-house staff, catering, baggage handling, check-in, maintenance or even [owning] any actual aircraft. So much easier to operate without all that stuff to look after!

Taken to the extreme presuambly one would end up with nothing but an airline's name and trademarks, a handful of overpaid management types, and maybe a bunch of lawyers to look after all the outsourcing/subcontracting and licencing deals.

> So much easier to operate without all that stuff to look after!

But only if there are someone who can and would provide you with all that stuff.

> Taken to the extreme presuambly one would end up with nothing but

This is the premise of 'The 4-hour Workweek'. It was a quite entertaining read.

Apple is a bad example - they make computers, that is their core business. From chips (ok, they don't own any chip fabs, iirc they used to have their own manufacturing but later outsourced to China, but they do design) up to software, plus marketing and distribution (which is always where the money is - eg Nike makes boatloads selling shoes while the sweatshop workers are paid pennies). The iPhone? It's a computer with access to cellular networks. The iPad? It's a computer. Everything Apple has made since OS X in ~2000 is a Unix computer. Even, if I'm not mistaken, watchOS and tvOS are Unix based.

It's like when Mercedes/BMW et al started making SUVs after years of making sedans and coupés. It's a different form factor, but still the same basic product.

As an example of this, I was at a large government department that was in the middle of a mainframe operating system upgrade project. Not the hardware! The applications were also largely staying as-is. Their budget was two billion dollars, which just blew my mind.

I was chatting with a member of the small army of project managers involved, and I was trying to explain to him that for that kind of money I'll build them a whole new mainframe from sand. Silicon, circuitry, operating system, applications, everything.

For two billion dollars you could literally afford to build a dedicated foundry just to stamp out the sheetmetal for the case and still have 1.9 billion left over for everything else.

>Now, I get it, once you have to deal with taxes and payroll in multiple countries it gets messy, but why wouldn't you consider that a core part of your business worth investing into?

Because it's a complex legal issue that isn't in the competency of most companies, getting it wrong has consequences. Since most companies have similar legal requirements, there's enough scale for a large 3rd party. Also, some countries require the local IRS-alike to approve your software if you wish to file certain tax reports. Bad UX pales compared to these requirements.

Because you can find SAP data entry employees/specialists everywhere - but full-stack developers nowhere.

> I host my own email and it works fine

I think we've established from the various "I give up hosting my own email" articles posted on HN that this is basically down to luck.

"but why wouldn't you consider that a core part of your business worth investing into"

Yes, that's true, and every organization of any size (one sufficiently large enough to implement SAP) will have experts in those domains. The problem is that implementing them in software is a large task - definitely not impossible, or even extremely difficult (it's just CRUD on a grand scale), but you need software that can change quickly when new legislation is implemented, etc. Painful, and the reason why so many do implement a COTS ERP. Hell, even Google run SAP S/4HANA these days (they migrated off Oracle ERP AFAIK).

it's not about self-hosting your email, it's about writing your own email server