We're mostly volunteers, so people implement whatever they feel like doing :-) The essence of open-source.
Come help out if you can, or sponsor some fixes with one of the LibreOffice consulting companies.
I am extremely appreciative of what open-source developers do. One only has to look at the Linux ecosystem to see how much work they've contributed—and of course there's much more than just that.
What you say is obvious, volunteers are unlikely do work they do not like and I'd certainly not expect them to do so. However, unfortunately, that, in my opinion, is often (but not always) the Achilles's heel of much open-source software.
For example, open-source software often lacks drivers or that good drivers only arrive much later than they do for commercial software. The two mitigating reasons for this are that hardware interfaces etc. are often proprietary and the info is more likely to be released through commercial agreements leaving open-source developers to reverse engineer them which is messy and timeconsuming. But a second factor is even more important, which is that very few developers like writing drivers (I hate doing so and it's years since I've done so—so I'd not expect others to do so for free). A good illusion of this is Linux's old NTFS driver, it was a 'dog' and often corrupted files. Luckily it was fixed recently when the commercial operation Paragon donated a revamp/rewrite of their commercial NTFS code (no doubt out of vested interest, compatibility etc.). That new driver probably doesn't do much for Linux Diehards who interface with ext4, etc. (and it's likely why the old code was never properly developed), but the replacement is a godsend for mixed environments where one is trying to introduce Linux to Windows users.
The problem then is how do we fill the gap between what open-source developers want to do and what users actually need? It's really a vexed problem that remains to be solved if open-source software is to become widely competitive with its commercial counterparts.
For a long time my view has been that we need a middle-ground solution here. For example, large projects such as LibO should be developed under a nonprofit structure that would pay developers for their efforts. The amount developers would receive as compensation would be less than that paid by commercial interests but it'd certainly be more than a token amount. This way, only those who had a true commitment to the project would work on it and payment would also provide the incentive to get the less popular development done, thus projects wouldn't be held up.
Revenue to pay developers would come from the sale of the software, which, say, for LibO could be around $20 - $30 which is only a fraction of what MS charges for MSO. Such a scheme would be criticized on grounds that the source would then have to be closed. That problem is also easily solved if the license agreement required that the source could be only be compiled on condition that the binary was only for one's own personal use—resale of the complied code would be strictly forbidden. Given its nominally low price then by far the vast majority of users would opt to buy the program already compiled.
No doubt, there are many variations on such a scheme and much tweaking would take place before an optimal solution was found. Overall, with such a scheme users would be better off as development would be faster and proceed more smoothly.
I can only stress again that I am in favor of open-source development and I do donate to open-source projects, also if I have to buy software then I only do so from small independent commercial developers. In fact, in recent years, I've bought no code from the Big developers except for Windows which was already installed on a machine, even then that's been strictly limited as most of my machines run Linux.
What prompted my original comment about LibO was my recent bad experience, in fact it was quite horrific. It needs a separate post to provide even a reasonable outline as so many things went wrong. However, in brief, it goes thus: I'd not written long and detailed documents in either MSO or LibO for some time and by that I mean complex documents over 100 pages. LibO has been the default WP for ages but I occasionally use MSO on .doc files created by others to ensure no page format anomolies.
Anyway, recently I had to produce a legal document in which some drafts were in excess of 150 pages and about 100 were in the form of a complex landscape table where some cells were split horizontally and vertically. Not only were there memory leaks, the table would take ages appear, certain operations such as deleting cells that split across pages would lock the program and it could only be killed by the task manager (this, unfortunately, was in Windows), moreover there were multiple instances of Write that had to be killed or it wouldn't reopen. Also, the LanguageTool extension (which I needed) caused Writer to cease up when certain actions were invoked, these were separate to the earlier mentioned problems which were present even if LanguageTool was disabled or not installed.
Somewhere between revision 200 and 550 the file became corrupted but it was not obvious until around rev 550 when I found I couldn't delete some parts of the table. Backups didn't help as they contained the corruption from early on. I then had to cut-and-paste into a new file using plaintext to get rid of the corruption which still wasn't obvious, I thus lost almost all of my complex formatting. These problems cost me several weeks lost work, and to make matters worse I was on a court-imposed deadline that I could not alter.
That's only part of the story. Moreover, I wish to hell LibO had some utility that would find corrupt parts within an .odt file and either correct them and or bring them to my attention. Finding some way to edit—or even examine—a raw indigestible and unintelligible .odt file would be extremely useful.
Also, it would have been good if I could have sent the hundreds of crashes to The Document Foundation but with the sensitivity of the doc and the fact that I couldn't carefully review exactly what was to be sent back I found most annoying. That process for advising crashes isn't fit for purpose.
I really do need an extended blog to fully explain what happened. I note from the changelog of ver 7.6 that one of the table code bugs has been fixed but I've yet to fully verify that, however, it still locks up when I try to correct a spelling error before the speller autocorrects it (it's so damn slow, I can beat it manually).
Similarly, I also note LT has notched a single point release since my original trouble but Writer 7.6 still often fails to engage or interact with the extension, that is LT is active but no grammar or spelling correction takes place. To fix this LibO must be closed down and restarted. I don't know if this is a bug in Writer or LT, either way it's really a damn nuisance.
Hopefully you will be happy to hear that a company has funded some improvements to that part of the code, and those improvements should roll out over the current and the next release.
ODT files are theoretically human-editable, because once you expand the file (using e.g. unzip) you have a small set of XML files, which can be edited as text and then wrapped up into an ODT again.
Finding "corruption" is not really a thing (at least for writer documents), the spec for writer documents is sufficiently complex that parts of it are in conflict with itself, and compromise solutions must be found in the code.
The writer code to lay the document out is sufficiently complex that it has multiple chunks of guard code specifically designed to make it give up when it cannot make reasonable progress.
Very good to hear about the table improvements, I look forward to seeing them.
Re ODT, I unzipped it and looked at the XML and the stuff in the table section was formatted so badly (tightly together as one huge blob of text sans proper spaces and structured formatting). Given the ODT is over 900k long and having examined the XML for an hour or so I simply gave up. I hate to think how long it would have taken me to examine it in detail let alone resolve it without me first going crazy.
As I was in a desperate hurry I cut my losses and used my time fixing it in a way where I could at least estimate the time required.
"the spec for writer documents is sufficiently complex that parts of it are in conflict with itself,"
This sounds like what was happening, in parts of the table when paging up or down between pages sections of text (both within a cell with multiple lines of text and across cells in lines before and after). Text in a cell would mix and fold over itself or fold over the text in the cell in the line above or below it. Given that some cells could have text of several hundred lines in length sections of the table (but not all of it) became an almighty jumbled mess.
Right, at times it just gave up and if it didn't resolve (respond to commands within a minute or so) I killed it with the task manager.