Personal Edition label and define is wrong.

Board Discuss
#1

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.

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.

Peter Dolding

#2

Hi Peter,

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 :wink: but I can see how that would annoy people. But anyhow -
interesting feedback.

  Thanks,

    Michael.

#3

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

#4

Hi,

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

#5

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

#6

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, and QA. LibreOffice Bug 86621 is most easily fixed by
writing some user documentation. If somebody really want to do the
request RFE, a minor rewrite of the Base component is required. That is
going to take far longer than 10 hours to do.

jonathon

#7

Hi,

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

#8

Hi,

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 actually even more code is coming from the company's. Some sometimes I see LibreOffice as a company Enterprise (at least a code level); not talking about documentation/translation/ask/marketing/infra

So it's a project of company's; being open for people who want to contribute (for free) with community events and such. And the company's a doing this currently still for free; but question how sustainable this model is.

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.

LibreOffice is growing in number of users (based on the stats), the community isn't getting much bigger. Or looks shrinking to me. Developer count down. (Can be get a better paid job elsewhere? Code to hard to read. All moved to b e app developer?). QA volunteers down; old regulars show up less. So even this a problems. Maybe linguistic issue (English). So core user base living in country's where this less common to speak?

Best,

Bjoern

Regards,
Telesto

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.