"We're mostly volunteers, so people implement whatever they feel like doing :-) The essence of open-source."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.