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
