Hi Alexander,
Let me jump in with a few thoughts here.
On 12/01/2022 09:08, Alexander Thurgood wrote:
> 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.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.documentfoundation.org/www/board-discuss/
Privacy Policy: https://www.documentfoundation.org/privacy
