When you buy SAP, you actually get the full ABAP source code of all the business logic, which is more openness than can be said for most businesses. Having said this it's not the same as open sourcing the software, as you need a commercial license to legally execute it.
That's not quite the right perspective: it actually started out from a cross-platform position. When R/3 came out, it supported 15 platforms (e.g. most Unices), and only later did it become more and more Windows-dependent. Part of this was the desire to integrate SAP's R/3 GUI more closely with Microsoft Office.
I was with the SAP basis technology group at the time.
Not really. Last time I checked, client code using a class could modify local fields of all its instances, thus violating the tenet of encapsulation. You also have to explicitly pass "self" by hand each time.
See Section 10 of this reference, for instance.
Modern versions of FORTRAN don't have the odd reliance on source code formatting anymore that come from the punchcard era (although ironically Python relies on identation now).
I've taught graduate students FORTRAN 90 and they could pretty quickly implement matrix calculations, use imaginary numbers and I/O to solve the kind of problems they need to solve, often without prior programming experience. Science and engineering computations often require vast numerical throughput, and FORTRAN compilers are unrivalled at that (and have the best optimizers and parallelization support).
I'm not saying Python can't do the same, but change for change's sake is a pretty poor argument, and the existing huge FORTRAN libaries and code bases mean FORTRAN users truly stand on the shoulder of giants.
Ever notice that even the busiest people are never too busy to tell you just how busy they are?