The trunk branch, the Bugzilla list, the OS/2 support, the user forums, the multi-hour build process, the XHTML 1.0 compliant badge on the https://www.openoffice.org/ homepage .....
Reminds me of the good old days.
Many years ago I became proficient with the Linux kernel build process, and later regularly built Mozilla with my preferred configuration and so forth. Both processes take some doing. I thought building OpenOffice couldn't be much of a challenge, it wasn't an operating system after all. I can't recall if I ever got it done. If I did, it was certainly the most vanilla possible build, taking all the defaults for a bog-standard build.
Building large software is consistently the only useful thing I can do that will fully utilize all CPU resources. Seeing all the bars in the red in htop on a box with a lot of threads doesn't get old.
I'm sure a full OS can take that long (ex. Windows, probably), but at least NetBSD can build a whole OS from source quite quickly. (Of course, NetBSD makes an effort to optimize that process; their build.sh is really a thing of beauty)
As a first approximation, one would not expect building a suite of office tools to be more complex than building an operating system kernel.
Also, for the people saying "it's only the kernel, not the whole O/S", consider that building the kernel requires having a running system with all the dependencies.
Honestly I would. Kernel is not that big if you look away from all the device drivers (you usually don't need all of them) and has a focus on minimalism. An office suite is a massive complexity monster which skews on supporting more stuff even if it means having more code.