Michael Meeks, a LibreOffice developer, writes progress reports on the project, plus talks on open source engineering and onboarding developers.
HN links it for LibreOffice internals and slide decks on understanding large codebases, as well as his comments on the OOXML standard.
He has a slide deck [1] that he links to in the interview, where he tries to highlight some challenges with grokking large codebases, and techniques one can use to compartmentalize understanding and build from there. I found it both a bit too colloquial yet also too opaque, but there's some useful nuggets in there.
It also speaks to a significant problem: large codebases are inherently difficult to understand, which forms a barrier to entry. This is despite the fact that most software makes use of various abstractions to break problems into smaller parts.
In the general sense, I believe it's worth thinking about how the particular abstraction mechanisms used in software impact a new contributor's productivity, vs. the productivity of someone more familiar with the codebase, especially for projects that are developed in the open, or with high developer turnover.
[1] https://people.gnome.org/~michael/data/2016-04-29-solving-problems.pdf
GNOME and LibreOffice developer Michael Meeks' summary:
"Apparently this is a somewhat divisive attempt by an exiting Oracle, along with IBM to sideline the existing developer community, their governance, their aspirations, membership, licensing choice (explicitly adapted to meet IBM's needs incidentally), bylaws, and so on. All of this despite a profound, frequently stated open-ness to including new (particularly large) corporate contributors inside TDF, and taking their advice seriously."
http://people.gnome.org/~michael/blog/2011-06-01.html
ECMA 376 is explicitly intended as documentation of what Office 2007 does. Michael Meeks of LO (then at Novell) worked on it and says it did this job: https://people.gnome.org/~michael/blog/2014-02-26-cabinet-office.html#tc45
But in practice there's no such thing as "OOXML" - there's only what Office 2007, 2008, 2010, 2011, 2013 and 2016 happen to do. So if you want to work with the stuff, you verify everything. The standard is, like so much Microsoft documentation, best treated as based-on-a-true-story fiction with an unreliable narrator.
There's a in-browser version of LibreOffice being worked on since quite some time (first announcement was in 2011[1]), but there's not much information online about the current status.
They have video[2] and a wiki page[3] which at least shows how to enable it (custom build required):
[1] http://blog.documentfoundation.org/2011/10/14/libreoffice-conference-announcements/
[2] http://people.gnome.org/~michael/data/2011-10-10-lool-demo.webm
[3] https://wiki.documentfoundation.org/Using_LibreOffice_in_a_Web_Browser
Most of the community developers have jumped the bandwagon to work with LibreOffice. It seems that the developers still with OpenOffice.org are mostly working for IBM and Oracle. The project just did the first release (http://www.openoffice.org/news/aoo34.html) after two years of silence, but there's still a lot to do before they are featurewise competing with LibreOffice. You can see a feature comparison here: http://people.gnome.org/~michael/blog/2012-04-26-ooo-comparison.html
More:
https://www.gnome.org//~michael/blog/2014-01-30-under-the-hood.html
https://www.gnome.org//~michael/blog/2014-07-29-under-the-hood-4-3.html
https://people.gnome.org/~michael/blog/2015-01-29-under-the-hood-4-4.html
https://people.gnome.org/~michael/blog/2015-08-05-under-the-hood-5-0.html
Keep an eye on 5.1 as well :) https://wiki.documentfoundation.org/ReleasePlan/5.1