I can write a blog post about the effort, although the FOSDEM presentation covers it for the most part.
The first effort was by oco and this effort is completely independent. He started with OOo4Kids, since it was stripped of many dependencies. At this time LibreOffice didn’t exist and I remember from compilation instructions, that OOo even had it’s own build tool (dmake). We didn’t have Java port and OOo depended (heavily?) on that. LibreOffice did a great job of rewriting all of this to GNU make and stripping Java, so that made things easier.
I think the main issue was that LibreOffice requires a lot of libraries. I see people blasting package management for making system unnecessarily complex, hard to tinker with, etc. Let me say this: I wouldn’t start working on this port if package management didn’t exist. I still remember a mess with gcc4 libs being picked up by gcc2 for linking which would throw mysterious errors.
Back to the libraries: porting them was pretty easy but tedious. Most of them compiled out of the box thanks to POSIX compatibility, but some had, for example custom library detection logic and they were PITA to get working (langtag, ixion, orcus).
Now to the VCL backends: currently there are two native backends in progress. First one [1] is completely BeAPI based, for LO 5.3 and that is what was presented at FOSDEM. After my presentation I got feedback that perhaps it would be better and easier if we took cairo backend for rendering and BeAPI for the rest, since VCL is kind of a mess. I started working on that [2], but it didn’t go far - rendering works fine since cairo handles that, but windows don’t even refresh properly on mouse move.
The main problem with implementing BeAPI based backend is Common Text Layout which ensures there are no document rendering differences between different OSes. It also handles right-to-left text, etc. I didn’t manage to figure out how to implement it. but the main issue is that we don’t have APIs for rendering RTL languages. So back to using external libraries like harfbuzz. That makes native backend kind of pointless. (EDIT: harfbuzz is not a bidi library) Now that we have Qt port, cairo is also pointless IMO since it’s almost the same thing. (Using external thing to interface with OS.)
Some answers to this are above, additionally:
I don’t think that’s a worthwhile endeavor anymore.
- It looks pretty native now, and even with BeAPI backend you won’t get much better - there is still VCL as a layer of indirection.
- (speculation) I’m afraid that LO might even drop native backends in favor of Qt. That would be a lot of work wasted, especially with our strained resources.
I’d love to see native backend, but I think my time can be better spent elsewhere (like WebKit, or fixing bugs in the OS itself). If anyone wants to work on it there is a rough diagram of how things work in BeAPI (5.3) backend [3].
Ending thoughts:
When I started working on the port (2014) there was only an idea on TDF wiki about using Qt for GUI.
IIRC Qt/KDE backend is sponsored by City of Munich which wanted better integration with KDE.
I believe a 1 month full-time contract would be enough to implement a somewhat working native backend, with another month for polishing.
And finally: I’m very glad to see LO finally working! Thanks diversys and 3dEyes for your tremendous work on Qt and KDE. 
[1] GitHub - KapiX/libreoffice_core: Read-only LibreOffice core repo - no pull request
[2] GitHub - KapiX/libreoffice_core at haiku-6.0
[3] LibreOffice for Haiku - kacperkasper.pl