I know that you publish GPG signatures, but frankly, there's the "bootstrap" problem of how does the user know he has your correct GPG key? X509 solves that to an acceptable degree (and anyone can still also check the GPG sigs if she doesn't trust public CAs).

I think there are two different things being confused here.

1. Directly-Signed Distributions

The signing of Windows and Macintosh binaries is done by a procedure that relies on X509 public key certificates.  These signatures are verified by the operating system and usually do not require action on the part of the user (apart from having trust for the CA).

Apache OpenOffice does not provide those signatures at this time.  It has been under discussion but the structure for accomplishing this is not in place at this time.  Special arrangements are required to ensure the integrity of the signing process and the confidentiality of the private key that is used for code signing.

Direct code-signing is the signing that the this issue is about.  Sun and Oracle did arrange to sign their binary distributions and components of those distributions in the manner required for operating-system verification.  

2. Externally-Signed Distributions

The use of external PGP signatures is part of the Apache Software Foundation methodology for ensuring the integrity of release candidates and associated binary packagings to ensure that the materials made available for download are precisely those that were reviewed and approved for release.  This is a common approach for open-source projects, especially those that produce *nix distributions of various kinds.

Those external signatures are made available from a read-only, non-mirror location along with the digital hashes that are also usable to confirm the integrity of downloads from any source.  The signatures confirm the authenticity and the integrity.  The hashes confirm the integrity and also authenticity so long as the hash-check values are obtained from the Apache location.

Verification of these signatures requires the public key certification of the authenticated signer.

If you know the Apache ID of the release manager for an Apache OpenOffice distribution (e.g., "jsc" for Jürgen Schmidt), you can find the PGP public-key for that committer at <https://people.apache.org/keys/committer/>.  For example, Jürgen's certificate is at <https://people.apache.org/keys/committer/jsc.asc>.  This is the file to download (download, don't save the browser view) and import into a PGP client (typically GPG).

What confidence is there that this is an authentic signature?  Notice the "finger print."  There is high confidence that this public key was registered, by its fingerprint, using authorized access to the ASF account of the Apache Committer identified by "jsc".   The fingerprint is used by an automated service that retrieves the associated public key from the network of PGP key servers.  You can also see, from the public-key metadata, that jsc@apache.org is one of the associated UIDs.  Furthermore, the external signature, if it verifies with this certificate, had to be made by someone possessing the private key corresponding to this public key certificate.

Because this is the place where that public key is automatically refreshed at an ASF protected location, it is also where additional counter-signatures (the web of trust) will be reflected, as well as any revocation of the key.

I think that answers the question in the first comment.  It is a high-friction arrangement that works for developers but not so much for end-users.  That is why there is interest in using code-signing, especially since there are deviant distributions out there.

Confirming and classifying as a FEATURE request.