Commercial entity vs community development and distribution

Hi *,

Sophie suggested that I might want to raise what I perceive as an issue here on this list, that is connected, but not identical, to the issue relating to the Attic question, and the questions around the sidelining of features/functionality in commercially developed and distributed versions of LibreOffice / X entity branded products (X being the commercial entity).

As it is not directly related to the Attic question, I have started a new topic.

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.

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).

I try, to the extent possible, to use LibreOffice versions made available through the AppStore.

On the one hand, it is suggested, on the LibreOffice download web page, to support the business solution providers if we use LibreOffice in a professional or commercial capacity. I believe that my business does this by using the versions provided via the AppStore.

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).

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.

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.

My take from all of this is that I foresee the macOS LibreOffice product becoming solely distributed by one entity in the long term, due to inaction, or passiveness from the Board to allow things to continue as they are. The current commercial entity, due to the business decisions it makes with regard to its own internal code development/maintenance strategy, then gets to choose which functions are maintained and which are deprecated.

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 also rather doubt that it would be satisfactory for the commercial entity as well.

From a business perspective, I may as well just switch to using Office365 or GoogleWorkplace at ca. 50EUR/month for the same 5 seats, and accept the limitations, and/or paying optional extra features that might be necessary to have an equivalent setup.

The question I have then for the Board is this :

- what is the Board going to do to address the issue of abandonment of features in commercially provided/branded versions of LibreOffice ?

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 ? My current concern is that it might, or, as appears to be the case, it will be built off the commercial entity's build environment (this ties back to the questions around the LOOL project) and released with that reduced feature set.

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.

That is the concern I would like to see addressed.

Thank you for listening to me, and apologies in advance if I may have ruffled a few feathers.

Alex Thurgood

Hi,

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.

I don’t think it’s right. As far as I’m concerned, LibreOffice Vanilla is built from the LibreOffice source without any change (hence the name Vanilla). https://developer.apple.com/app-store/review/guidelines/ says:

2.4.5 Apps distributed via the Mac App Store have some additional requirements to keep in mind:


(viii) Apps should run on the currently shipping OS and may not use deprecated or optionally installed technologies (e.g. Java)

So as far as I’m concerned, it is not possible to include Java based HSQLDB in LibreOffice Vanilla. Omission of Java is a technical limitation, not a commercially focused decision.

Regards,
Andras Timar

Hi Andras,

LibreOffice from the AppStore is branded Vanilla in the AppStore, but displays as “Community” (e.g. 7.2.4.1 LibreOffice Community).

It is not identical to the “Community” version available from TDF.

Java functionality is but one part (an important one, but one part nonetheless) of Base functionality.

According to this:

https://pretagteam.com/question/how-to-bundle-a-java-application-to-a-mac-os-x-app-bundle

it would seem that it is indeed possible to include all of the required ressources (i.e. bundling a JRE/JDK) into a product acceptable for inclusion and distribution via the AppStore.

Not doing so would then be a decision based on effort/reward for the entity building and distributing the product. Again, which I can understand.

However, the Java functionality is but one of the issues.

For example, current Collabora releases (whether Vanilla or Productivity) do not include postgresql or mariadb connectors - this is feature deprecation creep, for whatever reason.

The reason I raised this topic is for there to be a discussion on how the Board resolves that issue - i.e. the difference in products which appear under similarly confusing names via different outlets, when businesses in particular, are being pushed, by the LO download page itself, towards a product with reduced feature functionality, under the pretext that the business user will help the community at large and obtain some kind of benefit from supporting the business entity. My experience as a business case user shows there to be a mismatch between expectation and reality. If nothing is done, I fear that that gap will only widen.

That is the point I feel needs addressing.

Alex

Le 12/01/2022 à 11:52, Andras Timar a écrit :

Hi,

On Wed, Jan 12, 2022 at 10:09 AM Alexander Thurgood <alex.thurgood@gmail.com> wrote:

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.

I don’t think it’s right. As far as I’m concerned, LibreOffice Vanilla is built from the LibreOffice source without any change (hence the name Vanilla). https://developer.apple.com/app-store/review/guidelines/ says:

2.4.5 Apps distributed via the Mac App Store have some additional requirements to keep in mind:


(viii) Apps should run on the currently shipping OS and may not use deprecated or optionally installed technologies (e.g. Java)

So as far as I’m concerned, it is not possible to include Java based HSQLDB in LibreOffice Vanilla. Omission of Java is a technical limitation, not a commercially focused decision.

Regards,
Andras Timar

Hi Alex,

thank you for “ruffling some feathers”, this is exactly what we need!

If the community stays silent then to some it may seem that everything is OK, we need the whole community to be more vocal and to tell us what they think should be improved.

Your email raises 3 main concerns:

1) Support offering from commercial entities
There isn’t much we can do in this area as each company chooses its own business model.

Offering a SLA to fix a bug could mean spending a day in fixing and testing the patch as it may mean weeks of development and testing so it isn’t that easy to price it for SMEs.

Maybe one day, when they’ll have enough subscribers to their services, they will be to offer different SLA to SMEs but that’s entirely up to them.

2) Market differentiation Community/Commercial offering
In your last email you seem to say that you spotted difference in features between the version you used.

Apart from the Java bundling issue (thanks for pointing to a potential solution and to Andras for the explanation) is there anything else that you think we should look at?

In terms of brands I agree that it may be confusing.

Anyone could compile LibreOffice and stick it on an app store and there are products out there that we can see they are built from LibreOffice.
It’s FLOSS so as long as they don’t claim it’s an official LibreOffice package and don’t use our brands then anyone can do it.

In that situation the resulting product with its own brand could have more or less features but that’s going to be the packager choice.

To create more clarity I think we should to start building on the internal skills we already have to ensure we can deliver LibreOffice “by TDF” to our community in the app stores regardless of the choices commercial entities may want to make.

Talks have been in progress for a while so if you’d like to influence the process please let us know what you think.

Another thought is related to the eventual cost of the app on the app stores.

TDF already fulfils its duty by making LibreOffice available for free from our web site.

The app store is a very convenient way for users to install LibreOffice but the whole process adds extra costs and issues as rules and procedures can change often.

Would it be OK for the community to exchange convenience for a TBD monetary contribution, made from the app store and going directly to TDF, which would be equivalent to a donation?

3) TDF direct involvement in development
What you said in regards to development which may or may not follow some of the preferences that corporate contributors may have is indeed a potential issue.

There are many contributions coming from volunteers that follow their own interests, issues they want to fix or even languages that most haven’t thought about adding yet, Klingon being one of a few (majQa’!).

While there are new features and fixes coming up all the time from all types of contributors most of what TDF can do at present to address issues that are not taken in consideration by others is to create tenders.

While tenders are a good tool to get specific and generally complex things done, often out of reach in terms of complexity for a single contributor, it is a slow process to get the tenders written, evaluated, voted on and then get the results delivered.

While we need to go through that process for some new development, I believe we should also start employing a team of internal developers that can take care of many bugs and features that have a level of complexity that is in between what single contributors/small teams can provide us with and what a tender to a larger team can deliver.

That would also allow us to build the internal skills and capacity we may need in case a large contributor decides to focus on other things and probably to respond more quickly to bugs and to requests like yours.

I hope I’ve provided good answers to your questions so let me know if my opinion, and what I would like to promote within the board, matches your expectations or something more/different needs to be done.

Ciao

Paolo

On 12/01/2022 10:08, Alexander Thurgood wrote:

Hi *,

Sophie suggested that I might want to raise what I perceive as an issue here on this list, that is connected, but not identical, to the issue relating to the Attic question, and the questions around the sidelining of features/functionality in commercially developed and distributed versions of LibreOffice / X entity branded products (X being the commercial entity).

As it is not directly related to the Attic question, I have started a new topic.

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.

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).

I try, to the extent possible, to use LibreOffice versions made available through the AppStore.

On the one hand, it is suggested, on the LibreOffice download web page, to support the business solution providers if we use LibreOffice in a professional or commercial capacity. I believe that my business does this by using the versions provided via the AppStore.

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).

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.

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.

My take from all of this is that I foresee the macOS LibreOffice product becoming solely distributed by one entity in the long term, due to inaction, or passiveness from the Board to allow things to continue as they are. The current commercial entity, due to the business decisions it makes with regard to its own internal code development/maintenance strategy, then gets to choose which functions are maintained and which are deprecated.

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 also rather doubt that it would be satisfactory for the commercial entity as well.

From a business perspective, I may as well just switch to using Office365 or GoogleWorkplace at ca. 50EUR/month for the same 5 seats, and accept the limitations, and/or paying optional extra features that might be necessary to have an equivalent setup.

The question I have then for the Board is this :

  • what is the Board going to do to address the issue of abandonment of features in commercially provided/branded versions of LibreOffice ?

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 ? My current concern is that it might, or, as appears to be the case, it will be built off the commercial entity’s build environment (this ties back to the questions around the LOOL project) and released with that reduced feature set.

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.

That is the concern I would like to see addressed.

Thank you for listening to me, and apologies in advance if I may have ruffled a few feathers.

Alex Thurgood

Hi Paolo,

Answers/comments/response inline :

Le 12/01/2022 à 14:56, Paolo Vecchi a écrit :

1) Support offering from commercial entities
There isn’t much we can do in this area as each company chooses its own business model.

Offering a SLA to fix a bug could mean spending a day in fixing and testing the patch as it may mean weeks of development and testing so it isn’t that easy to price it for SMEs.

Maybe one day, when they’ll have enough subscribers to their services, they will be to offer different SLA to SMEs but that’s entirely up to them.

Just to add that I’m not at all entirely convinced that it is the Board’s duty to oversee this part - of course, what a commercial entity decides to offer in terms of business support is entirely up to them - suffice it to say that the economics of the vendor support field clearly seem oriented to large scale deployment.

Unfortunately, this completely ignores the fact that in many countries in Europe at least (I can’t speak for others), the industrial tissue is made up majoritarily of small businesses or very small businesses, i.e. units with between 1 to 10, or 10 to 30 or so employees, artisans and craftspeople. I don’t see any commercial offerings within the current commercial vendor community surrounding the LO project which appear to target that size of business. I can fully understand and appreciate why that might be - client expectations exceeding the ROI of the commercial vendor for the time and effort required to fix X,Y, or Z bug specific to that small business’ needs.

It is indeed a shame that there are no such offerings presently, but those (V)SMEs still require something, otherwise they may as well just stick to the other existing alternative commercial solutions around, including the proprietary ones. The rationale about having a drive to recruit commercial development/support vendors to the project was that they are/were necessary to enable the LO community and project as a whole to survive.

I firmly believe that they still are, but they are nonetheless failing to fill/meet the needs for those small businesses. Perhaps as you say, one day, they will be in a position to offer SLAs adapted to those small enterprises, but 10 years down the line, that hasn’t yet materialized, and it seems unlikely to do so IMHO given the current direction that the majority of development efforts from these vendors appears to be taking, i.e. online service offerings as opposed to monolithic product installations.

Anyway, like I said, I’m not sure that this is the Board’s job to ensure business offerings that meet substantially every business user’s needs, but I do feel it worthwhile for the Board to keep an objective eye on where things are going in relation to this point.

2) Market differentiation Community/Commercial offering
In your last email you seem to say that you spotted difference in features between the version you used.

Apart from the Java bundling issue (thanks for pointing to a potential solution and to Andras for the explanation) is there anything else that you think we should look at?

ODBC connectivity - granted, there is some debate around whether support should be continued at all for ODBC connections, but that would extend to other OSes

MySQL connector connectivity

Postgresql connector connectivity

All 3 of these are either absent (mariadb/postgres) from LibreOffice Vanilla and Collabora Productivity, or present, but broken (ODBC connectivity).

To create more clarity I think we should to start building on the internal skills we already have to ensure we can deliver LibreOffice “by TDF” to our community in the app stores regardless of the choices commercial entities may want to make.

That would be a possibility, indeed.

Talks have been in progress for a while so if you’d like to influence the process please let us know what you think.

Another thought is related to the eventual cost of the app on the app stores.

TDF already fulfils its duty by making LibreOffice available for free from our web site.

The app store is a very convenient way for users to install LibreOffice but the whole process adds extra costs and issues as rules and procedures can change often.

Would it be OK for the community to exchange convenience for a TBD monetary contribution, made from the app store and going directly to TDF, which would be equivalent to a donation?

Personally, I wouldn’t have an issue with this, but it comes with downsides:

  • the vendor offerings tend to be more conservative in their changes, which is good for the overall stability of the product, whereas some of the initial releases of any new TDF LO version contain catastrophic bugs ;

  • if a TDF LO version is released with a monetary contribution through an application store, TDF should be wary of raising people’s expectations about the kind of product being delivered, and be very clear on the messaging around that, otherwise disaster awaits, when expectations outstrip capabilities to respond to issues raised - a negative review on an application store will do nothing to promote the use of OSS software, and only serve to reinforce the negativity that surrounds the use of such software in the workplace - these issues aren’t new for the commercially oriented vendors, as they already have to face such criticism anyway with their current product offerings.

While tenders are a good tool to get specific and generally complex things done, often out of reach in terms of complexity for a single contributor, it is a slow process to get the tenders written, evaluated, voted on and then get the results delivered.

While we need to go through that process for some new development, I believe we should also start employing a team of internal developers that can take care of many bugs and features that have a level of complexity that is in between what single contributors/small teams can provide us with and what a tender to a larger team can deliver.

That would also allow us to build the internal skills and capacity we may need in case a large contributor decides to focus on other things and probably to respond more quickly to bugs and to requests like yours.

I like the idea of in-house developers, and if that means increasing monetary contributions in the form of donations through an application store to help pay for that, sure, why not, but again, the messaging about what can be hoped to be achieved needs to be very clear, otherwise we (the project) will foster expectation, and possibly even greater deception, when things don’t, or can’t turn out as might have been expected from the user base. After all, the codebase for LO is massive by anyone’s standards, and it seems impossible to believe that a group of just a few developers would be able to work on all parts of the codebase with sufficient expertise and confidence.

Alex

Hi Alex,

well… it’s nice to see that you fully understand the dynamics involved so you saved me a lot of typing :wink:

Just a few notes inline.

On 12/01/2022 16:01, Alexander Thurgood wrote:

Hi Paolo,

Answers/comments/response inline :

Le 12/01/2022 à 14:56, Paolo Vecchi a écrit :

1) Support offering from commercial entities
There isn’t much we can do in this area as each company chooses its own business model.

Offering a SLA to fix a bug could mean spending a day in fixing and testing the patch as it may mean weeks of development and testing so it isn’t that easy to price it for SMEs.

Maybe one day, when they’ll have enough subscribers to their services, they will be to offer different SLA to SMEs but that’s entirely up to them.

Just to add that I’m not at all entirely convinced that it is the Board’s duty to oversee this part - of course, what a commercial entity decides to offer in terms of business support is entirely up to them - suffice it to say that the economics of the vendor support field clearly seem oriented to large scale deployment.

Unfortunately, this completely ignores the fact that in many countries in Europe at least (I can’t speak for others), the industrial tissue is made up majoritarily of small businesses or very small businesses, i.e. units with between 1 to 10, or 10 to 30 or so employees, artisans and craftspeople. I don’t see any commercial offerings within the current commercial vendor community surrounding the LO project which appear to target that size of business. I can fully understand and appreciate why that might be - client expectations exceeding the ROI of the commercial vendor for the time and effort required to fix X,Y, or Z bug specific to that small business’ needs.

It is indeed a shame that there are no such offerings presently, but those (V)SMEs still require something, otherwise they may as well just stick to the other existing alternative commercial solutions around, including the proprietary ones. The rationale about having a drive to recruit commercial development/support vendors to the project was that they are/were necessary to enable the LO community and project as a whole to survive.

I firmly believe that they still are, but they are nonetheless failing to fill/meet the needs for those small businesses. Perhaps as you say, one day, they will be in a position to offer SLAs adapted to those small enterprises, but 10 years down the line, that hasn’t yet materialized, and it seems unlikely to do so IMHO given the current direction that the majority of development efforts from these vendors appears to be taking, i.e. online service offerings as opposed to monolithic product installations.

Anyway, like I said, I’m not sure that this is the Board’s job to ensure business offerings that meet substantially every business user’s needs, but I do feel it worthwhile for the Board to keep an objective eye on where things are going in relation to this point.

Yes to practically everything but…

I still think that the board should do its best to find ways to attract more companies that are capable to support micro/small businesses and make a living out of it.

There are a few listed in the LIbreOffice Professional Support page but it would be great to find more.

I know of a few large project in France where some partners were involved as I know of very small projects in city councils where some local IT companies install LibreOffice but I don’t think they contacted us to be listed in the Professional Support page.

I’m sure there are many IT companies that install LibreOffice because they like it and want to offer an alternative to the usual vendor but don’t yet see enough demand for training and support by businesses to make a business out of it.

Promising SLA on bug fixing could be another big issue for IT companies dedicated to SMEs as often they don’t have in house developers to fix an issue for them, what they could do is to file a bug and hope that someone will fix it. Which is roughly what most IT resellers can do even when selling products from the usual vendors.

So from a market perspective there is room anyway for services that can include a first line support through certified trainers/migration specialists which are serving many SMEs and can help them in using LibreOffice at its best, identifying potential issues and workaround and file bugs if some are found. Over time they may grow enough to actually start helping in fixing those bugs and propose/develop new features.

That reminds me of a conversation I had with a French user on Mastodon as he was complaining about something not working properly with styles, I managed to replicate the bug, found a workaround, notified the user and filed an update to the bug I found being already there:

https://bugs.documentfoundation.org/show_bug.cgi?id=146104

That could be the useful type of service your IT provider could sell to you once they have accumulated enough experience.

Have you asked them what they think about it?

2) Market differentiation Community/Commercial offering
In your last email you seem to say that you spotted difference in features between the version you used.

Apart from the Java bundling issue (thanks for pointing to a potential solution and to Andras for the explanation) is there anything else that you think we should look at?

ODBC connectivity - granted, there is some debate around whether support should be continued at all for ODBC connections, but that would extend to other OSes

MySQL connector connectivity

Postgresql connector connectivity

All 3 of these are either absent (mariadb/postgres) from LibreOffice Vanilla and Collabora Productivity, or present, but broken (ODBC connectivity).

I don’t have a Mac to test your issue but on my Linux PC I see all the possible connectors are there, I’ve tested it by creating a database out of a largish Calc spreadsheet and it worked.

Sorry I’ve got to admit that I haven’t used Base that much, I’m probably still recovering from seeing how Access has been (ab)used 2 decades ago which was the last time I’ve used it.

Maybe others have more insight about the issue?

To create more clarity I think we should to start building on the internal skills we already have to ensure we can deliver LibreOffice “by TDF” to our community in the app stores regardless of the choices commercial entities may want to make.

That would be a possibility, indeed.

That is something I would like TDF to pursue quite soon.

Talks have been in progress for a while so if you’d like to influence the process please let us know what you think.

Another thought is related to the eventual cost of the app on the app stores.

TDF already fulfils its duty by making LibreOffice available for free from our web site.

The app store is a very convenient way for users to install LibreOffice but the whole process adds extra costs and issues as rules and procedures can change often.

Would it be OK for the community to exchange convenience for a TBD monetary contribution, made from the app store and going directly to TDF, which would be equivalent to a donation?

Personally, I wouldn’t have an issue with this, but it comes with downsides:

  • the vendor offerings tend to be more conservative in their changes, which is good for the overall stability of the product, whereas some of the initial releases of any new TDF LO version contain catastrophic bugs ;

  • if a TDF LO version is released with a monetary contribution through an application store, TDF should be wary of raising people’s expectations about the kind of product being delivered, and be very clear on the messaging around that, otherwise disaster awaits, when expectations outstrip capabilities to respond to issues raised - a negative review on an application store will do nothing to promote the use of OSS software, and only serve to reinforce the negativity that surrounds the use of such software in the workplace - these issues aren’t new for the commercially oriented vendors, as they already have to face such criticism anyway with their current product offerings.

I have specified that the payment, as I think there is no “donate” button in app stores, is to be considered as a donation and the person making that donation doesn’t buy a support contract from TDF.

In a way the donation/payment is there because we satisfy your need for convenience, which for avoiding you a few clicks means donation money going to support that convenience, but in exchange you will get our gratitude for supporting LibreOffice and the funds will go to support our techies that made it so easy for you to install LibreOffice.

If a lot of people will find the price for that convenience interesting then more funds will be available for development/developers, bug fixing, etc.

While tenders are a good tool to get specific and generally complex things done, often out of reach in terms of complexity for a single contributor, it is a slow process to get the tenders written, evaluated, voted on and then get the results delivered.

While we need to go through that process for some new development, I believe we should also start employing a team of internal developers that can take care of many bugs and features that have a level of complexity that is in between what single contributors/small teams can provide us with and what a tender to a larger team can deliver.

That would also allow us to build the internal skills and capacity we may need in case a large contributor decides to focus on other things and probably to respond more quickly to bugs and to requests like yours.

I like the idea of in-house developers, and if that means increasing monetary contributions in the form of donations through an application store to help pay for that, sure, why not, but again, the messaging about what can be hoped to be achieved needs to be very clear, otherwise we (the project) will foster expectation, and possibly even greater deception, when things don’t, or can’t turn out as might have been expected from the user base. After all, the codebase for LO is massive by anyone’s standards, and it seems impossible to believe that a group of just a few developers would be able to work on all parts of the codebase with sufficient expertise and confidence.

I totally agree with you.

Employing 4/5 good developers is a massive investment that may not have a visible impact from day 1 so managing expectations is very important.

I remember the time when developers embarked in the rewriting of large chunks of the code as it needed some modernisation and some were complaining that new features weren’t implemented fast enough.

Now we have a development mentor that is also working on some bugs while helping others understanding how to work on the massive code base we have.

Some may not see immediately the benefits but once more developers are up to speed then things will start happening fast.

Having internal developers could show results faster as lots of small neglected bugs could get fixed while developers learn to deal with the code and then they will start tackling larger projects.

So while a few internal developers doesn’t seem like much it will anyway give us more independence from external suppliers, give us more expert resources that can help in creating and validating tenders and relevant deliverables and help even more developers learning how to contribute.

So, overall, it seems like we share the same views and understanding of the issues :slight_smile:

Feel free to iterate on this strategy and to ping me and the rest of the board in regards to other issues and suggestions.

Alex

Ciao

Paolo

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.

Hi Michael,

Thanks for jumping in on this thread, and I appreciate you having taken the time to address my points.

Comments inline :

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 :wink:

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

Hi Alex,

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.

Rest assured that your concerns have been discussed within the board for quite a while especially in regards to the AppStores.

We have already done an initial evaluation of the efforts required to publish the apps and soon we should be able to confirm when we'll be able to start publishing them.

Ciao

Paolo

Thanks for jumping in on this thread, and I appreciate you having taken the time to address my points.

  Nice to talk the issues through constructively =)

Oh, yes, I still remember the pain involved in transitioning
from PPC to Intel.

  Quite =) Apple seems to deprecates APIs less quickly than Linux but rather more quickly than Windows.

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 ?

  In a nutshell, if your primary focus is Base on Mac, then at the moment it makes little sense to - except of course that supports the project somewhat. Obviously you could support the project instead by donating to TDF.

Lest there be some misunderstanding, I also wasn't touting that Base be atticised, far from it, that would be counter-productive for me

  Sure; I don't think anyone is proposing that.

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.

  My take is that app-stores are a significant strategic risk to TDF from several perspectives and that keeping people's ability to install their own software alive - outside the grip of DRM'd app stores is an important thing to do. Also - the economics of endless free updates in app-stores hurts TDF's revenue very significantly when you model it: not de-funding TDF needs to be a concern for the project.

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.

  Oh - wow, I didn't know that. Wow - that is awful. That crushed my hopes for a good Firebird based future.

  So what other options are there for a sensibly licensed, in-process database ?

  Does PostgreSQL do it - could we run the server in a thread cross-platform, can we get its data into a file ? :wink: I guess we should prolly re-do the analysis of alternatives here to work out if there is a sensible way forward; but that belongs on the dev-list - and it's a big job to even know what we might want to do.

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.

  Yep; seems like a nightmare; the endianess issue burst my bubble of having a nice direction - but just getting there slowly. How can we avoid the galloping bit-rot and fund the improvement of a good database infrastructure ? it's an un-solved question.

Thanks again for your input Michael, it is always useful for me to have this kind of engagement.

  No problem; Its a shame that the Linux Desktop is not floating your boat too, I agree with you on lots of what you wrote that I excised for brevity.

  Anyhow - I'd like to hope that we can research and come up with a plan for a capable database that we can bundle & be sure is always there for embedded db's; one that will not bit-rot, and is not built on another bit-rotting infrastructure =)

  I guess with Noel's experience perhaps a J2C++ conversion on HSQLDB would do it :wink: still at 100k LOC of Java that's also a nightmare.

  Hey ho,

    Michael.

Alex: seems the problem existed before Aug 2016, but not anymore. See https://bugs.documentfoundation.org/show_bug.cgi?id=72987#c14 and comment 17 which refer to https://git.libreoffice.org/core/commit/0cc1ddf2d8d6bc7df74fdd8f8f97381df681177d

Quoting from Lionel's comment 17:

'The problem was fixed by saving (within the odb zip structure) firebird data in an endianess-independent format, called the "backup" format, in a file with extension ".fbk".'

Ilmari

Oh - wow, I didn't know that. Wow - that is awful. That crushed my hopes for a good Firebird based future.

Alex: seems the problem existed before Aug 2016, but not anymore.

...

'The problem was fixed by saving (within the odb zip structure) firebird data in an endianess-independent format, called the "backup" format, in a file with extension ".fbk".'

  Phew - thanks for the update! Firebird/base is back on track as the notional future =)

  Good stuff,

    Michael.

Thanks Ilmari !

I seem to have missed that !

Will need to try it out again, and apologies for my erroneous statement in that case.

Alex

Do we really need an embedded database? The unique selling point of base seems to me that it's the only free DB frontend developing software around (besides "real" software development environments). So maybe we should concentrate on connectors, not on an embedded database engines which in most cases could be replaced by a calc table - and if not, then by mariaDB.

just my 2c
  (I know its's just ancillary and not the point you want to made, but scnr)