I had a long dissertation here destroyed by random F12 and backspace key that I can't deal with retyping again, but I fully disagree.
UEFI mandates certain, user and developer and admin UX nice, minimums regarding boot process. You can fully expand on supported filesystems, or even non-FS sources to boot from. Even from paper tape if you want to. You're not bound to magic partition on a fixed disk[1] anymore than you're with OpenFirmware (and decidedly less than IBM PC BIOS compatibles).
None of the comparable alternatives were really FLOSS (by the time OFW went open source, EFI was shipping on x86 and amd64[2]), coreboot/uboot/redboot/etc were too limited, by themselves being e-waste framework unless paired with upper layer to provide open platform for users and developers.
EFI was available, back in 1.1 timeline, as open source code for x86 and IA-64 (the IA-64 specific bits were called "SAL" IIRC), then some bright mind at Intel decided to close it down. Fortunately they open sourced it back as TianoCore and we now have FLOSS solution (it's as proprietary as OFW at this point in time, and it's more of an open platform than uboot/coreboot/etc).
The available "less proprietary" options all created closed platforms, where you need excessive porting to boot anything the vendor didn't ship for you. It's trivial to make firmware so flossy it will make RMS shed tears of nostalgia for KA-10, but it's not going to be useful for majority if they ever want to run something not provided by vendor. Minicomputer/workstation complex firmware monitors etc. happened because diagnostics were often needed, and some required at least some compatibility with third party hardware, but them - including origins of OpenFirmware - implicitly accepted a closed platform where vendor would need to ship a special "hardware enabling" OS update or ship entire OS version to match new platform.
UEFI might have proprietary roots, but it (and ACPI) is designed specifically to provide for the case of freedom of end owner to run whatever crap they want, including older version of OS they already got used to.
[1] Unless the hardware is too cheap, like Qualcomm ARM systems with UEFI where various critical services are patched in windows drivers to be handled through magic files on ESP, or in permissible CHRP OpenFirmware variants where magic partition on fixed disk is explicitly mentioned as an option.
[2] EFI based firmwares started shipping by 2005~2008 timeframe on x86 and amd64, mainly due to DXE providing way easier method to integrate 3rd party code. It was also from start designed to handle multiple platforms, partially thanks to having IA-32 and IA-64 code simultaneously as early as EFI 1.0, which made it easier option to handle future 64bit platforms.
I've been in that situation. There used to be a very handy Firefox addon called "Lazarus" that helped. Quantum killed it. This may help - not tried it yet:
Unfortunately not. Proper writeup would require sitting down for some software (and hardware) archeology to dig out stuff that in some cases seems to have been pulled off the internet on purpose (original open source EFI 1.10 release) or by virtue of disappearing companies (SRM source & documentation disks for OEMs, various random workstation documentation and programs that don't necessarily made it to bitsavers, things like that)
UEFI mandates certain, user and developer and admin UX nice, minimums regarding boot process. You can fully expand on supported filesystems, or even non-FS sources to boot from. Even from paper tape if you want to. You're not bound to magic partition on a fixed disk[1] anymore than you're with OpenFirmware (and decidedly less than IBM PC BIOS compatibles).
None of the comparable alternatives were really FLOSS (by the time OFW went open source, EFI was shipping on x86 and amd64[2]), coreboot/uboot/redboot/etc were too limited, by themselves being e-waste framework unless paired with upper layer to provide open platform for users and developers.
EFI was available, back in 1.1 timeline, as open source code for x86 and IA-64 (the IA-64 specific bits were called "SAL" IIRC), then some bright mind at Intel decided to close it down. Fortunately they open sourced it back as TianoCore and we now have FLOSS solution (it's as proprietary as OFW at this point in time, and it's more of an open platform than uboot/coreboot/etc).
The available "less proprietary" options all created closed platforms, where you need excessive porting to boot anything the vendor didn't ship for you. It's trivial to make firmware so flossy it will make RMS shed tears of nostalgia for KA-10, but it's not going to be useful for majority if they ever want to run something not provided by vendor. Minicomputer/workstation complex firmware monitors etc. happened because diagnostics were often needed, and some required at least some compatibility with third party hardware, but them - including origins of OpenFirmware - implicitly accepted a closed platform where vendor would need to ship a special "hardware enabling" OS update or ship entire OS version to match new platform.
UEFI might have proprietary roots, but it (and ACPI) is designed specifically to provide for the case of freedom of end owner to run whatever crap they want, including older version of OS they already got used to.
[1] Unless the hardware is too cheap, like Qualcomm ARM systems with UEFI where various critical services are patched in windows drivers to be handled through magic files on ESP, or in permissible CHRP OpenFirmware variants where magic partition on fixed disk is explicitly mentioned as an option.
[2] EFI based firmwares started shipping by 2005~2008 timeframe on x86 and amd64, mainly due to DXE providing way easier method to integrate 3rd party code. It was also from start designed to handle multiple platforms, partially thanks to having IA-32 and IA-64 code simultaneously as early as EFI 1.0, which made it easier option to handle future 64bit platforms.