Date: prev next · Thread: first prev next last
2022 Archives by date, by thread · List index

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:

    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.


To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.