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; * SOHO ** Micro-business; ** Micro-enterprise; * SMB ** 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 processes; > * 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 workforce. 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/OpenOffice.org 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. jonathon -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
