Hi Alexander,
Let me jump in with a few thoughts here.
> Thank you for listening to me, and apologies in advance if I may have
> ruffled a few feathers.
First - don't worry about that =) it's good to discuss this stuff; I wish more people were as straightforward with their concerns, thank you.
I am a business user of the LibreOffice software product, and for those who know me, or of me, I have been a long time community volunteer active in QA, and previously to that in the documentation projects. My focus within these projects has pretty much always been related to Base, and in line with my business activity, pretty much related to using LibreOffice on macOS.
Thank you for all your contributions.
My business is a small one, 4 to 5 machines, and is based essentially on various macOS machines (a combination of Mac minis and Macbook Pro devices).
Sure; so - for an individual user to fund some massive work (like making LibreOffice Base a more beautiful piece of software) would be generous to the point of impossibility (there is no money-fairy for any of us =)
The only way to fund this is to somehow aggregate demand across a very large number of people to allow large projects to be funded. To some degree TDF does that with its donors already, in a much smaller way app-store buyers do that too.
Having aggregated the cash - the next problem is to work out what to spend it on.
Unfortunately - this tends to dis-aggregate the funding again - so we end up either with too little money on each of many features, or we re-focus back onto the most 'popular' feature / fix work which have significant interest. Probably that doesn't help here.
This is far from unique to LibreOffice - large commercial software suffers from this too - as well as having a much higher transaction cost around getting involved & fixing the things you care about. Wander into an under-loved part of Microsoft Office and you will find plenty of rough edges.
It is hard to see a way of avoiding that.
I try, to the extent possible, to use LibreOffice versions made available through the AppStore.
That's much appreciated; thank you.
Nonetheless, as a paying business of these versions, I am left in a quandary.
My business relies on daily use of database interactions, including the use of queries, forms, and to a lesser extent, reports. The business implements a number of different database solutions, ranging from mysql/mariadb/postgres server backends and/or embedded hsqldb (and hopefully when the functionality is finally of an equivalent scope, embedded Firebird).
Right; Base is a rather less-used code-path / feature than say writer.
It seems increasingly obvious that the provider of these commercial versions is not interested in maintaining database functionality and the supporting Java functionality that accompanies the Base module. The reasons for this may be perfectly valid commercially-focussed decisions, and not just linked to the specifics of the AppStore rules.
Sigh; you are probably right.
On Mac, there are many intersecting issues here, I'm not fully up-to-date, but we have to use the MPLv2 / Category-b subset for the app-store binaries (I was re-reading their tweaked app-store rules today as it happens). I imagine that Mac sandboxing may cause some headaches, and prolly there are bigger issue around ODBC drivers on Mac:
https://developer.apple.com/forums/thread/671258
It is possible to package an entire JVM - and bundle that - along with all of the related security issues, download size etc. but this creates a large amount of ongoing busy-work that takes resource from other things. Also IIRC the ARM64 / M1 / JVM story is/was far from beautiful.
Apple seem to have a proven ability to churn their platform API and even architecture wise rather more quickly than is helpful for us cf. the PPC version.
Be that as it may, the only way for my business activity to access the full range of database options is to use the TDF LibreOffice version, and even that is beginning to fail in a number of areas.
Hopefully it still works to use the TDF version - and I see very little chance that Base will be 'atticised' in the near future - or that this was even in the scope of this proposal, but perhaps it is wise to discuss that possibility.
My take from all of this is that I foresee the macOS LibreOffice product becoming solely distributed by one entity in the long term
I think that is very unlikely; at least, unless that entity is TDF.
I have been told variously and rather glibly in the past that an SLA would solve the problem - the fact is that the costs and provision of such a SLA from a vendor are neither transparent upfront, nor realistic for a small business with 5 seats.
I'm not going to advertise Collabora's Engineering Support packs here, but they have fixed-price per root-cause fixes. That the price reflects the costs & risk there is an unfortunate commercial reality.
For myself, I'd love to have significant resource to spend on improving base - I hate to see under-loved bits of code; but commercial reality bites hard here. Luckily there are some great volunteers around who keep Base alive - cudos to Lionel in particular. However Base looks far from healthy commit-wise.
- what is the Board going to do to address the issue of abandonment of features in commercially provided/branded versions of LibreOffice ?
So - the board in the past funded some work to try to get Firebird into a state where it could be used as an HSQLDB replacement - which can be shipped on Mac. I think that can provide an alternative today, and quite probably we should put more effort into making it work nicely on Mac (does it?). However migrating HSQLDB to Firebird is far from trivial not least (IIRC) because we have a rather inflexible yacc SQL parser built-into LibreOffice that needs quite some work to be compatible.
Some of this task was competitively tendered, and that tender was delivered, even over-delivered on - but that process was badly bitten quite badly by the problems of writing a spec. for a very large-scale problem that can be delivered for a small fixed-cost. Competitive tendering is far from a panacea for implementing things - you tend to get exactly what you asked for, but not necessarily what you want.
If the attic solution is adopted for such abandoned features, does this mean that the TDF LO version for macOS would one day be put into that attic ?
Probably not - but there are not over-abundant commits focused on macOS.
Clearly, one can't force any commercial entity to do anything with regard to source code that is initially under an open source licence That is, after all, the whole point of open source code. However, the future of the project will be put in jeopardy if the commercial developments take over as the main release channel for any given arch/OS.
Hmm; so - I'm not so worried about that. The main release channel on Linux is the (many) distribution vendors - and we see no catastrophe unfolding there.
There are lots of really feature-rich LibreOffice's on Linux distros - indeed, I would really recommend using Linux in place of Mac as a solution for your Apple / DRM'd app-store issues =)
I think the problem around Base is/was relying on Java for desktop applications ("re-write in JavaFX!") - which is dying as a cross-platform desktop app technology (while still going strong on the server: as we can see from the Apache log4j excitement! =)
Beyond that - I would seriously caution against believing those suggesting that "if only TDF hires developers then you, (yes your) bug will be fixed!" - that sounds like "touch the television and you will be healed" to me. We have hundreds of person years of work in our bugzilla alone to tackle before we reach a bug-less perfection =)
While it is clear that TDF could usefully have more development mentors to stimulate development and volunteering in all sorts of areas (including Base) - the idea that a handful of these these would operate under some ability to fix large numbers of issues of interest to minorities seems unlikely. The risk of TDF choosing to do divisive negative-sum game things with them is quite real however - indeed it seems to be one motivation for hiring.
Beyond that - we currently have a nice mechanism for the ESC to approve tendering of things, if you can write a small spec. for what you want - and it has a clear cost, then it can be included and ranked. I'd encourage you to get involved there.
TDF owns promoting that process, hopefully you've heard of it. We try not to fund things that would be done anyway - that would be a waste of donors money. Then in theory having had the board rank these in a fair process - we create a budget for TDF. Some proportion of these tasks are tendered, procured, and completed many months later if at all.
I share a deep frustration with the back-end of delivering on this process - even though it is somewhat more streamlined than it was.
However it seems to me a better process than individual board members making individual commitments about features being implemented if only they can hire a pet developer =) That seems a process that is unlikely to scale, and may result in a lot of irritation - there are many people who see their particular issue as being the highest priority in the world - as eg. our QA team can attest =) There are many worthy areas that need funding.
The process of fairly directing a handful of developers to work on things that are most important to (whom?) the board / the TDF staff / the ESC / TDF members / bug reporters / QA volunteers / some proxy for our global userbase ? is unclear to me and quite challenging to get right. I would hate to see the project further consumed by divisive in-fighting over what to do.
I believe Marina came up with some way of getting users to direct the proposed TDC spending that sounded interesting and that could perhaps be used to encourage more financial contribution on focused issues - but TDC was unfortunately killed before it started, and that could be experimented with.
So - anyhow - I hope those reflections help.
You certainly highlight an interesting challenge. How can we find individual volunteers and resources to apply to such problems ? More development mentors may help, its worth a try - but I'm sure many more such problems will remain.
Regards,
Michael.
