Hi Michael,
Thanks for jumping in on this thread, and I appreciate you having taken
the time to address my points.
Comments inline :
Le 12/01/2022 à 21:45, Michael Meeks a écrit :
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.
Oh I quite agree, squaring the circle of financing development/bug
fixing and matching users' expectations is a generally thankless task
for any organisation.
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.
Oh, yes, I still remember the pain involved in transitioning from PPC to
Intel.
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.
At least for x86_64, and the ARM version seems almost functional up to
the same level , the TDF versions mostly do what we need, even with Java
on Arm (Oracle JDK 17).
The downside for the commercial offerings then is why would I continue
to keep subscribing to the AppStore versions (and contributing
financially, however little that might be), if I have to have multiple
different versions of what is perceived as the "same" software in order
to get work done ?
Lest there be some misunderstanding, I also wasn't touting that Base be
atticised, far from it, that would be counter-productive for me in
particular, my concerns were levelled more at the perceived (by me) risk
that apathy, or lack of foresight at the Board level, or whichever
circumstances, might lead to the commercially branded offerings of LO in
the long run being the only ones available via the AppStore, or indeed
anywhere. Of course, discussing strategic orientation of the project is
always useful, irrespective of the modules that might be affected.
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.
Well, at least the above would imply that someone will carry on holding
the torch, which is a good thing !
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.
I understand that, and don't have an issue with the principle at all. As
you say, the cost reflects the commercial reality, and that reality
doesn't really coincide with small business expenditure, unless they
mutualise in some way (which kind of presupposes that they actually know
each other, have the same desires, and are prepared to do something
about it).
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.
Endian-ness for embedded Firebird seems to be the elephant in the room
here. ODB files made on MacOS can not easily be shared with other
OSes/arch. There is seemingly no viable alternative to this issue. It
means no sharing of ODB files with clients, and no sharing of ODB files
over network shares to a heterogeneous pool of endpoints.
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've been there, seen it and done it, got the medal and the T-shirt in a
previous life with an even bigger firm than I currently run. If I didn't
have particular business needs, e.g.
- dictation ;
- OCR with a half-decent, semi-automatic "intelligent" UI ;
- file search engine that can actually return results based on file
contents, rather than file names alone, integrated into the file manager
and which doesn't kill your system when indexing from a file share
- decent battery life when out and about,
then I probably would switch to a Linux-centric outfit again.
I still use Linux stuff at home, but I need users (and myself) not to
generally have to fight the software (or the system) they're using (I'm
perfectly willing to admit that there are infuriating issues with
aspects of macOS, but generally, not something that most users get
uppity about or lose much work time over).
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 =)
I think I would probably place myself in the "Doubting Thomas" category,
so no worries there ;-)
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.
These are all useful concerns in my view and certainly in need of
clarification were the intentions to be cristallized.
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.
Agreed, and I don't believe that there are any easy options, nor do I
see any "prepackaged" solutions that will satisfy everyone.
Thanks again for your input Michael, it is always useful for me to have
this kind of engagement.
Alex
--
To unsubscribe e-mail to: [email protected]
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
