This is not really a direct alternative and may not be quite what you're looking for, but a similar solution that requires a TPM (Trusted Platform Module) is called 'Trusted Boot', or tboot. It differs in some key ways, but its ultimate goal is the same - to establish a level of trust in the boot chain and state of your system.
Tboot itself is actually an open source implementation of a concept called an MLE, or Measured Launch Environment. In a nutshell, its a blob of binary code that executes and utilizes Intel TXT to put the machine into a privileged and trusted state, where it can then take measurements (SHA-1 hashes in TPM 1.2) of the OS and related components, and push them to the TPM to be stored securely. For example in Linux, tboot can be setup to execute immediately before the kernel loads and it will generate hashes of the kernel binary, kernel parameters, and initramfs image and send them each to the TPM.
Additionally, a TPM and compatible motherboard/BIOS allows for measurements to also be taken of various components in your system much earlier in the boot process, such as the BIOS image itself, custom BIOS settings, PCI card firmware (GPU, NIC, and more), the bootloader (grub, for instance) and more. You may be wondering what good are those measurements? Well, not much by themselves. Instead, the TPM can be used to do a number of things if and only if those measurements are a specific value, such as reading/writing to TPM NVRAM, or decrypting a key only the TPM can decrypt. These measurements can also be conveyed securely (and anonymously, if desired) to another party, so that party can establish trust remotely. Subsequently, a system can be designed to only boot up or execute some software if the TPM has some specific measurements in its PCRs, meaning it booted a specific set of software - ie it provides integrity.
Fundamentally, the TPM and tboot combined provide a broad spectrum of system coverage and at least on paper from what I understand can be extended to measure/hash virtually anything you want by using an API to send hashes to the TPM for storage. One important thing to note is that hashes do not simply get loaded plainly into the TPM. Instead, when a hash is to be stored in an internal register in the TPM (PCR, or Platform Configuration Register), it is concatenated with the previous value of the register, and the blob is hashed and the result stored in the register. The result is that each register accumulates state, and any difference along the way causes the end value to change. This is called a tpm 'extend'.
Fundamentally, I think the TPM and tboot offer much more capability than secure boot does. The TPM is a sort of general purpose cryptographic coprocessor that can be used for secure storage, RNG, system state reporting to other hosts (attestation), and more.
Unlike Secure Boot, which utilizes signatures and halts the bootup process if a signature doesnt check out, the TPM/tboot does not use signatures and does not directly stop the boot sequence. Rather, a system has to be designed to fail boot up by requiring the TPM to perform some action, which it will only do if the system is in some defined state, if so desired.
As for your concern about the open-source bit and transparency of it all, even tboot/TPM delves into a stratum of implicit trust, and really, its an unavoidable leap of faith in my mind, unless literally every piece of software was open source, and the hardware as well, and hardware schematics were understood. In the case of tboot and the TPM, this implicit trust goes all the way down to the chipset and the processor itself. Supposedly a public key checksum is embedded into the chipset that is used by processor microcode to start the chain of trust. This checksum isn't explained completely in texts I own, but what is explained is that a signature is verified by processor microcode on a block of code resident within the BIOS image called the BIOS ACM for the SRTM, or SINIT ACM for DRTM. In order to verify a signature of course, a public key must be used and my guess is that the public key is embedded in the ACM for space reasons and verified against this hardware resident checksum mentioned earlier.