Hi Alex,well... it's nice to see that you fully understand the dynamics involved so you saved me a lot of typing ;-)
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=146104That 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?
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.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*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?MySQL connector connectivity Postgresql connector connectivityAll 3 of these are either absent (mariadb/postgres) from LibreOffice Vanilla and Collabora Productivity, or present, but broken (ODBC connectivity).
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.
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.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.
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 :-)
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 -- Paolo Vecchi - Deputy Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint
OpenPGP_signature
Description: OpenPGP digital signature
