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


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




Context


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.