Hi Cor,
Well, some weeks (ago?) I've seen passing some discussion about this
(not followed details).
The devil is in the detail :-))
But to me it looks as a misinterpretation.
- yes, support contracts are important, because also that generates
revenues for the companies sponsoring developers of LibreOffice;
- no, a support contract will not in general guarantee 'enterprise
stability', because... what ís 'enterprise stability'?
How about : "Not making the product any less functional than how it was
when the project behind the product was taken over with much hue and cry
about how the Foundation "will protect past investments by building on
the solid achievements of our first decade...". Users and companies who
are persuaded to switch from OOo to LibO are entitled to expect that the
product not be less functional than it was when under different
stewardship. I'm not saying it has to be perfect, no software is, but if
you are used to using Product A with a given functionality framework,
and then someone comes along and says "Join our merry band, we will
protect the previous investment made in Product A with our Product B",
then it is legitimate to expect that functionality framework to continue
to provide as broad a spectrum as possible. Anything less, and the new
group has failed in its mission and its duty to protect that "past
investment".
I was one of the first to follow from OOo, and made a significant
donation when the Foundation started its fundraising, but that is not
what I'm concerned about the most. I still believe that it can be a good
product, but I have my sincere doubts about it being "enterprise ready"
and am not afraid to be honest and say/write so. It doesn't make me less
of an enthusiast, just that I am honest enough with regard to the state
of the project to qualify my statements in relation to the use of
LibreOffice as a business tool.
IMO the initial remark from Michael Meeks was to indicate that when you
want to be rather sure (...) that specific fixes are done or features
realized, you are welcome to do it yourself, have someone doing it
(after all it is open source) or get a support contract that gives the
right for fixing an amount of issues.
So if an enterprise relies on specific features, it can simpley wait for
the moment that is happens ... but probably it is not the most logic
choice.
Which is what I said in my first sentence, that some bugs will be fixed
eventually at any rate, no matter what, just not necessarily within any
given timeframe.
Ultimately, it is not merely the remarks that Michael made, that I may,
or may not, have misinterpreted. As I mentioned, it transpires from
other mailing lists, the dev irc channel, the bug reports, the decisions
to consider any given bug as a stopper or not.
On the Foundation FAQ page, one can find this :
Q: What difference will The Document Foundation make to users of
LibreOffice?
not have and will not have a commercial product which receives
preferential treatment. We only have one focus - delivering the best
free office suite for our users - LibreOffice.
"our users" : who are they ? Individuals ? Businesses ? Charities ?
Educational and Training Institutions ? Their needs are different,
sometimes converging, at others diverging. The project needs to know how
to cater to those needs and listen to those who are in need. Telling
people to "get stuck in" isn't going to happen for the majority of use
cases where people just want to use the software - this is not a new
problem in the free software development world, we all know that there
are often far more casual users and non-coding contributors than actual
code contributors, so why don't we just face those facts. If the way
forward is to request monetary contributions for fixing bugs, let us be
honest about it. However, I know for certain that some developers do not
really like the idea of a "bug bounty" system, because it brings with it
an associated "perceived obligation" to produce a result and a
requirement by the project in general to manage more carefully how
developer resources are used, thereby taking the fun out of contributing
to a free software project. I can fully understand such a position, if I
were a developer working on LibreOffice in my spare time, or
occasionally just because I felt like it, I would probably adopt the
same approach.
Therein lies one of the conundrums for the LibreOffice project and the
Document Foundation : businesses want results, they want to be able to
use the product in a "business production environment", and they might
even be prepared to fork out some money for it (and I say might), but
only if in return there is some guarantee of a deliverable, a timescale
and clear development plan. An individual user might be less fussed
about it all and be prepared to either wait until XYZ bug gets fixed (or
not), or just put up with the status quo. The difference between
proprietary and open source software is that with an open source
project, users are led to believe that they can obtain what they want by
"contributing". All the "contributions" (be they financial or other) in
the world are not going to help if there is no clearly stated roadmap.
Referring people to the minutes of the ESC is like telling them to
parachute out of an aircraft into the desert and then find their own way
to the oasis - you get the parachute, but for the rest you are on your
own. Let us not forget those businesses which have already invested in
OOo, be it through migration deployments, or support contracts - today
they find themselves in the unenviable position of a product which has
essentially gone dead at least until Oracle decides what it really is
going to do with the shattered leftovers, and a new vibrant community
project that appears to be managed by a hydra, uncertain or hesitant to
clearly state its position with regard to how it sees the project
developing and how things are to be coordinated. It is no easy task and
I'm the first to admit that harmonising opinions, gathering momentum and
forging a clear way forward for the future takes time - however,
businesses, even more so than individual users, require security,
stability and reassurance - they do not want to be "left in the lurch" -
no sane budget, financial or technical manager would accept that risk.
If the project is not prepared to meet those needs head on then it must
state so clearly, and not mislead them into thinking that "one can leap
before one looks" (pun intended).
Alex
![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
