Re: [board-discuss] Personal Edition label and define is wrong.
Hi, On Mon, Jul 20, 2020 at 11:04:08AM +, toki wrote: > It might be useful to create a White Paper on migration to LibO > specifically for each size/class of potential user: > > Either the same, or a different White Paper could go into the virtues > and vices of ongoing paid support, for each business size/class. Maybe. OTOH, adoption without contribution is of no benefit to the project and as such the foundation should take a very close look if a bigger investment in an area really will yield contributions. > There is no might about those items. "might" might have been a bit of hyperbole, but only slightly: Im not aware of anyone trying to do a migration with 10 core developers and no trainers. On the other hand there have been way too many migration attempts with 10 trainers and no dev support (either from an ecosystem company or inhouse). All of those have hurt LibreOffice ultimately and were inresponsible by those involved with them. > One of the more frequent criticisms of LibreOffice, is that it does not > include an email client/communication centre. You call it the "one of the most frequent criticism of LibreoOffice", but its really one of the most fundamental misunderstandings about LibreOffice. LibreOffice is not a product -- its a project. As such it would have to be considered a tradegy, if there was possible set of contributors -- individual or institutional -- that the project could tap into, but failed to. For better or worse, that is not what happened wrt email. As a project, LibreOffice has to invest in areas where there is an opportunity for growth on _both_ sides of the project: need for a feature by users AND interest in contribution by contributors. Only then there can be a virtous circle of growth on both sides: contributions and adaption. Areas where there might be adoption, but little to no contribution are not sustainable and will become a burden to the project faster than a blink of an eye. At best, these areas are ignored by the project -- and there is absolutely no shame in that at all. Best, Bjoern -- 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
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; * SOHO ** Micro-business; ** Micro-enterprise; * SMB ** Small business; ** Medium size business; * Large business; ** Enterprise; This White Paper could go into the virtues and vices of ongoing paid support, for each business size. > 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 preinstalled 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. ## 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
[board-discuss] Update on marketing and communication plans for the LibreOffice 7.x series
>From the Board of Directors at The Document Foundation, the non-profit entity behind LibreOffice: Dear fellow Community members, Time has now come to decide how to proceed with some of the proposed changes taken from the Marketing/Communication Plan for 2020-2025 with the regards of the 7.0 release, due in some weeks. We really appreciated ideas and thoughts coming from our Community and we want to thank everyone who actively participated in the discussion, providing different points of views and sharing different scenarios, and proving themselves as passionate and caring members of the Community. Many contributions found on the board-discuss mailing list and/or via other channels are thoughtful, interesting and worthy of a much more profound discussion, in the common effort to overcome the challenge we have at hand: providing even better sustainability to the Project and its Community. All those ideas, objections and insights will require more time to digest, merge and distill than the short time that separates us from the 7.0 release, the major release for the 10th anniversary of our beloved project, LibreOffice. As such, the Board of Directors decided that the Marketing/Communication Plan for 2020-2025 has to undergo further investigations and refinements, that we hope to carry on with the support of Community members, with the goal of implementing in a future release some clear, discussed and agreed changes on branding and Marketing that will help improving the sustainability of the project without lessening or hindering the role of LibreOffice and its Community inside the free software panorama. Because of the importance of the topic at hand and the need of a worthy and compelling discussion with the Community, we will provide a time plan in a few days as well as some guidelines, with the goal of streamlining the process and coming to some good conclusions in a quick and effective way. As such, the 7.0 release of LibreOffice will not see any of the tagline/flavor text proposed inside the release candidate (RC) versions, the Marketing/Communication Plan for 2020-2025 or any of the alternatives proposed during the discussion, specifically inside the splash-screen, the start center and the about box; to explain it with other words, the modifications put in the RC versions with the regards of branding will be reverted to a previous state, so there will be seamless continuity from the 6.4 version to the 7.0. As stated before, none of the changes being evaluated will affect the license, the availability, the permitted uses and/or the functionality. LibreOffice will always be free software and nothing is changing for end users, developers and Community members. Yet again, we renew our encouragement to contribute actively in the discussion about the Marketing/Communication Plan for 2020-2025 in the next weeks, to allow for a more effective branding/Marketing ideas for the LibreOffice product and sustainability of its Community. LibreOffice is celebrating its tenth birthday this year. We wouldn’t be where we are today without you, our worldwide amazing Community and all of its members, no matter their profession or background. Thank you truly, to all of you, for the passion, energy and creativity you put into this joint and thriving project. We're looking forward to the next ten years to come! -- Mike Saunders, Marketing and Community Coordinator Tel: +49 30555 7992 62 | IRC: M-Saunders on Freenode The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: http://www.documentfoundation.org/imprint -- 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
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; * 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
