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

Re: [board-discuss] Personal Edition label and define is wrong.

On 2020/07/16 10:04, Bjoern Michaelsen wrote:

I think TDF marketing should provide guidance on how running a successful major
LibreOffice deployment without external support is set up, and what benefits this yields.

Back in the days of OOo 1.x, there was a document describing how to
migrate from MSO to OOo. One of the issues with it, was that what works
for an organisation of size "x", is overkill for an organisation of size
"x - y", and inadequate for an organisation of size "x + y". Compounding
the issue, is legal requirements for document retention.

It might be useful to create a White Paper on migration to LibO
specifically for each size/class of potential user:
* Individuals;
** Micro-business;
** Micro-enterprise;
** Small business;
** Medium size business;
* Large business;
** Enterprise;

Either the same, or a different White Paper could go into the virtues
and vices of ongoing paid support, for each business size/class.

This could be something along the lines of the following bullet points:
To be successful:

Unless the organisation is literally starting from scratch, with no
pre-existing documents, somebody who can guide the organisation through
the migration process is essential:

* Which data must be converted into an ODF file format;
* Which data can remain unconverted;
* Who, when, where, and under what circumstances unconverted data will
be converted;
* Training in using LibO, as it applies to the organisation's workflow

* You need approximately 1 experienced C++ developer per 2000 seats.

A good migration guide should be able to provide a rough estimate of the
number of RFEs the organisation will file each year, that improve LibO
functionality, within the organisation's workflow processes.

Using Collabora's Tier 3 rack rate as a guideline (^1) to the cost of
in-house Tier 3 support, the break-even point is around 100 bugs fixed,
or RFEs implemented, per team member. If the organisation expects to
have fewer than 100 bug-fixes or RFEs (^2) per year, they will save
money by utilising Tier 3 support from an established LibreOffice
Ecosystem partner. If the organisation expects to have more than 100
bug-fixes or RFEs per year, then it might be more cost-effective to do
it in-house.

* Depending on circumstances, you might need resources to support with documentation, translation 
and training.

There is no might about those items.

The second biggest hurdle in migrating from anything to LibreOffice, or
any other office suite, is training the users in how to use an office suite.
Not training in the specifics of LibreOffice, but in how to use an
office suite.

The third biggest hurdle, is having documentation that covers how the
organisation utilises the office suite. The needs and requirements of a
secretary in a religious organisation, are very different from those of
an analyst for a hedge fund that operates as a market maker, even though
both organisations employ roughly the same number of people - 5.

The benefits are -- if you have the experience and resources of leading such a team -- that you 
have a local team that will learn about your specific
requirements, can solve the issues and even might spot and fix them before they impact your 

One of the more frequent criticisms of LibreOffice, is that it does not
include an email client/communication centre. Any migration of
LibreOffice needs to consider what email client will be used, and
integrating it into LibreOffice.

_Microsoft Teams_ is not currently an official part of Office365, but it
is part of a SAAS meta-package that organisations can utilize.  Going
forward, LibreOffice migrations might need to take into consideration
AV, and text messaging formats.
I don't know what software are adequate replacements for those. Asterix,
Signal, Jitsu? HexChat, Pidgin?

I would assume Munich (just before it was killed politically) is the most
successful example of that and starting from scratch, it took them
approximately a decade to get there. So anyone considering a major deployment
of LibreOffice should wonder:

* Does the experience of running such software development teams exist in-house?
* Does the entity have a decade to get the deployment and support team to run smoothly?

The way not to migrate, is during a long weekend, have IT replace all
the computers, which are pre-installed with Linux, Thunderbird, Firefox,
and LibreOffice. When employees come to work on Tuesday, tell them that
there was a major system upgrade, so things might be slightly different.
(The organisation that did that, installed OOo 1.1.x, not LibreOffice.
It took about six months for the employees to calm down, and figure out
how to use the software.)


1) If the wage of coders in Germany is on a par with that in Seattle,
Collabora anticipates that a major bug will require less than 10 hours
of work to fix. Ubuntu Bug 255161/ Bug 92946 took a year
to track down. Granted, once the problem was known, it took about
fifteen minutes to write and run a sed script to fix the issue.

2) This assumes that an RFE and a bug fix take about the same amount of
time to code, and QA. LibreOffice Bug 86621 is most easily fixed by
writing some user documentation. If somebody really want to do the
requested RFE, a minor rewrite of the Base component is required. That
is going to take far longer than 10 hours to do.


To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


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.