Re: [board-discuss] Personal Edition label and define is wrong.
Op 21-7-2020 om 00:36 schreef Bjoern Michaelsen: 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. From the perspective of (a) delivering a complete Office Suite, (b) servicing user needs, (c) to have a competing product offer it still makes sense to have an open source e-mail client; IMHO Unpaid e-mail clients for Windows become scarce. Open source even more. Maybe everybody moved to webmail? Currently using Thunderbird; but can't say it's exceptional user friendly/easy to use. For individual users there is not much left, since Microsoft Live Mail discontinued (at the individual market). You end up at freemium (eM Client/ Mailbird/ Postbox). Also found Zimbra; however requires Java runtime. So if you focus on servicing needs, there is room for an e-mail client. Similar thing might be the case of the SMB and Enterprise market. Not sure what's on offer in that area except Outlook. Don't think that LibreOffice should build their own client; however bundling/promoting/ teaming/ partnership up with some open source e-mail client could be an option to expand the suite and service they needs. Certainly at Windows (and maybe at MacOS) front. Linux of course is shipped with Evolution/Kontact. It could be: * Evolution -> Tor Lillqvist did do a port in the past: https://sourceforge.net/projects/shellter/files/Evolution/ * Kontact -> QT apps are rather easy to port in general. Or phrase it differently - as I'm not a developer - I have seen a number of QT based apps on Windows. So I assume this can be done. There is currently nothing; except get involved request from the Developers * Mailspring -> https://getmailspring.com The front-end is open source; the mail engine closed source with the intention to be open source. No calendar. * Thunderbird (but should be shipped with calendar etc. Personally still having issues with search; not liking way threads are managed and still not into the tabs). It's a bit of a lost child at Mozilla? The benefit for all of those projects is more attention if bundled with LibreOffice. And from user perspective LibreOffice becomes more 'feature' complete. So win-win The downside is that look en feel maybe different from the rest of the LibreOffice suite. Major problems: * resource * coordination * different interest About "LibreOffice is not a product -- its a project" Interesting insight. Even it though it might be little ambiguous. I'm working a on a project for company X. For the developers involved LibreOffice is a project. For volunteers its a project. At the point you're monetize LibreOffice (or a fork) it become a product. The product might be the software itself of the services around it (or both). It's a commercial project, so to say. And from perspective of all the free users is primarily a product as long you're not involved. This is why I keep asking of business case/marketing plan. These are competing factors. It are communicating vessels. If you focus more on the commercial part, it becomes a more a product and less a project. So if you see it as a project it touches the core of LibreOffice (evil). So all the dynamics might change. However a project without (active) developers is not much of project either. And the reality is the project is driven by a few core company's. And some volunteers. 23,05% is done by some volunteers; if but you zoom in. Its probably less. Lots of lines are (svg) images so lots of 'code' without much of a change. Nothing against the importance of design. But
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 code,
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 down
Re: [board-discuss] Personal Edition label and define is wrong.
Hi, On Thu, Jul 16, 2020 at 10:53:54AM +0200, Thorsten Behrens wrote: > What would be missing - as a value-proposition, or via TDF marketing - > to make it compelling for enterprises not to deploy LibreOffice > without support? 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. This could be something along the lines of the following bulletpoints: To be successful: * You need approximately 1 experienced C++ developer per 2000 seats. * You need at least one certified core developer to onboard the others into the upstream project. * You need approximately one QA person per five developers. * Depending on circumstances, you might need ressources to support with documentation, translation and training. 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. 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 inhouse? * Does the entity have a decade to get the deployment and support team to run smoothly? If not, however, that is not the end of the story: In those cases there are ecosystem companies that are able to significantly help speeding up the bootstrap, so you dont have to wait ten years to get your return on investment. 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.
Hi Peter, Michael, Michael Meeks wrote: > > Only from ecosystem members this means if this equals must pay someone > > to get this version lot of my deployments in different businesses of > > Libreoffice would never have happened.Yes I can see those wanting > > to make the "LibreOffice Enterprise" wanting as many paying customers > > as possible. > > It seem you deploy LibreOffice in lots of businesses; I'm interested in > your experience of the economics of that. > Me too - as my experience is indeed, it tends to be hard to convince enterprises later on, that FLOSS does not mean zero-cost - if your entry is via the gratis door. What would be missing - as a value-proposition, or via TDF marketing - to make it compelling for enterprises not to deploy LibreOffice without support? Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Personal Edition label and define is wrong.
Hi Peter, On 07/07/2020 00:46, Peter Dolding wrote: > Well will all new enterprise need features now appear in the > "LibreOffice Enterprise" first and then "LibreOffice Enterprise" users > have to beta test them before they come to Personal Edition? I think there were some slides which were brainstorming in Italo's deck around having the enterprise version first, and then some delay etc. Probably that's still confusing - and you point out some of the problems with that. The ask for that didn't come from me / the ecosystem - and I think there is consensus that this is not a great idea =) We already have a sensible release-train process with freezes that everybody understands and works around, and I've not seen concerns around sticking with that. That process means that features appear in master, some are back-ported to product builds and shipped earlier, but the TDF version ends including shipping them within six months. That gives an incentive to invest in creating features to differentiate and a lead-time to enjoy that before the next step on the tread-mill of trying to explain why people should buy something when there is (apparently) a free enterprise product --> over there that appears more genuine. > I have had a lot of cases where I have been able to get Libreoffice in > next to Microsoft Office at first by it being free and licensed for > anyone to use. I'm curious - what happens after that at-first ? do you have a business that provides support or services ? do they ever pay for anything that ends up supporting LibreOffice ? >>> LibreOffice Enterprise: only from ecosystem members > > Only from ecosystem members this means if this equals must pay someone > to get this version lot of my deployments in different businesses of > Libreoffice would never have happened.Yes I can see those wanting > to make the "LibreOffice Enterprise" wanting as many paying customers > as possible. It seem you deploy LibreOffice in lots of businesses; I'm interested in your experience of the economics of that. > There are a lot of projects that do Community and Enterprise editions > using those names make sense. Personal editions with open source > software almost never make any sense and normally end up writing > something in conflict with license or their community. I'm not sure that 'Community Edition' has a clear meaning to most people; personally I liked the "LibreOffice Home and Student" as a first cut ;-) but I can see how that would annoy people. But anyhow - interesting feedback. Thanks, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
[board-discuss] Personal Edition label and define is wrong.
https://nextcloud.documentfoundation.org/s/jzryGw7XDkJadmo Going through the above slide deck I see a clear problem. Page 32. >>Tag: “volunteers supported, not suggested for production environments or >>strategic documents” This statement is not 100 percent true with the current fresh and stable. Let's say I am in a production environment I need to open excel spreadsheet 16,384 columns first version of Libreoffice that I know of that is going to be able to-do that is the current 7.0 coming out that you are attempting to label Personal. Yes a document like that could be a strategic document.This has not been the first time a new feature has appeared in the fresh branch that without it is production breaking. The use cases for current fresh does not meet this definition "not suggested for production environments or strategic documents" because the existing fresh has been suggested to be used in production environments and on strategic documents in cases of document compatibility issues that need new features to fix. Page 32. >>you are using the community supported version of LibreOffice, focused on >>needs of individual users Again all the new features that appear in the fresh version/personal edition are not 100 percent targeted at the needs of the individual instead has been the new features that have not been well tested of the enterprise needs as well like 16384 columns spreadsheet in version 7.0 your normal individual outside enterprise is unlikely to ever need that feature.So to test these new features properly we need enterprise users to be using what you are attempting to rebrand Personal Edition in a limited way. Well will all new enterprise need features now appear in the "LibreOffice Enterprise" first and then "LibreOffice Enterprise" users have to beta test them before they come to Personal Edition? I guess not as this will make production deployments more unstable. I guess everyone will want to keep the status quo where the fresh or what is being rebranded here to Personal Edition to be worded as usable by Enterprise users needing new features now. Personal Edition itself clearly is stating not for Enterprise. Fresh changing to Community Edition is better here as because Community Edition can be enterprise and individual users. I have had a lot of cases where I have been able to get Libreoffice in next to Microsoft Office at first by it being free and licensed for anyone to use. Page 32 >>LibreOffice Enterprise: only from ecosystem members Only from ecosystem members this means if this equals must pay someone to get this version lot of my deployments in different businesses of Libreoffice would never have happened.Yes I can see those wanting to make the "LibreOffice Enterprise" wanting as many paying customers as possible. Also think like openlp in churches using libreoffice to display powerpoint presentations. There are a lot of different use cases like this of Libreoffice that are not individual and not really enterprise either that would fall under title of Community that don't fall under the title of Personal. How would I fix this. Personal Edition comes Community Edition. >>Tag: “volunteers supported, not suggested for production environments or >>strategic documents changes to 'Tag: “volunteers supported, Recommend for Individual users." Ok that's kind of the best I can do.Because the existing not suggested there are cases where it is going to be suggested/recommended/advised for the very things the Tag says not suggested this will lead to arguments between support people and end users that we do not need. One thing I can say clearly there is a word you cannot use in this tag is the word 'not" the license of Libreoffice is for everyone and anything suggesting what Libreoffice is really should not suggest otherwise as soon as you use the word not you are most likely screwing up. Everything needs to be written in the positive/additive not the subtractive(not and so on is the subtractive). If what is in the tag cannot be written in the positive you have a problem. Of course something the positive/additive text does not list as supported does not mean a person cannot use it that way also does not mandate you support them either because they are using a non documented usage case basically the not stuff can be implied by careful positive/additive text. Yes the "Recommend for Individual users" I put there suggests not suitable for production environments or strategic documents without in fact stating it and also not locking out that usage case completely. This is the art of the good marketing weasel(sorry Dilbert comic reference): Write stuff that suggests stuff never directly tell user/consumer how they must use it. >>you are using the community supported version of LibreOffice, focused on the >>needs of community users. Swapping individual to community here allows the Community Version to remain the testbed for new enterprise features. T