Re: ESC meeting minutes: 2024-10-31

[Németh László]

Hi Andreas, hi all,

Andreas Mantke  ezt írta (időpont: 2024. okt. 31., Cs, 19:57):

> Hi all,
>
> Am 31.10.24 um 19:07 schrieb Thorsten Behrens:
> > (...)
>
> > * Feature locking (Andreas)
> >+  "Remove blocking
> functions feature from core"
> >+ re-visit from last week - any new views?
> >+ Heiko: having a 'freemium' label in the code - is not ideal. but
> more a question
> >  of labelling stuff, rather than technically wrong. And not
> affecting the desktop
> >  version anyway
>
> feature locking in an api is affecting the whole LibreOffice. And the
> labeling of stuff with Freemium makes it clear that the whole review
> process seemed to be broken, if not at least the ESC stops such commits.
> (And also not even a BoD member regularly participating at the ESC
> meetings raised an issue about that patch).
>
> And I looked at another big world wide open source project where I have
> been working on: Plone.
>
> They created and constantly improve their api. And I have not seen
> anything about feature locking (or similar) in that software (api) yet.
>

It seems, Plone uses groups to achieve similar feature locking (not
equivalent, because it's a completely different type of software, likely
with a much smaller code base):
https://5.docs.plone.org/adapt-and-extend/config/configuration-registry.html

Labeling stuff with Freemium likely means nothing more, that some clients,
who supported LibreOffice development asked for feature locking in their
customized cloud office service.  I find it highly unlikely that this would
be to run the free LibreOffice in reduced mode, and asking money for the
full version. It's quite the opposite: premium corporate clients of the
cloud office providers can lock arbitrary features for their users,
according to their policy/requirements (see GDrive/Google Docs, Office 365
for schools and other organizations). So feature locking over LOK is a new
feature of LibreOffice to help LibreOffice deployment for all users.

Feature locking was always one of the main requirements for public
administrations, and for other places, which try to avoid frequent
usability problems of a huge user base. Feature locking on the UI was
already implemented by Sun Microsystems/StarDivision for
StarOffice/OpenOffice.org. As Gábor Kelemen talked about 5-6 years ago at
LiboCon, feature locking on the UI was not complete enough for the
LibreOffice migration projects of the Hungarian public administration.
Gábor solved a few locking problems for the Hungarian public
administration, too, e.g.

– https://bugs.documentfoundation.org/show_bug.cgi?id=119021 Finalized
configuration item Calc - Formula - Syntax still editable (which problem
was reported by Gábor when he worked for NISZ, the biggest IT service
provider of the Hungarian public administration);

– or https://bugs.documentfoundation.org/show_bug.cgi?id=106943 Disabled
state of experimental features and macro recording settings not reflected
on the UI (which was reported by Dávid Pénzes, who is the editor of
academic journals (e.g. see Neveléstudomány [Educational Science], a
journal from one of the biggest Hungarian university, edited in LibreOffice
Writer: https://ojs.elte.hu/nevelestudomany).

So there are public administrations, academic research, education,
organizations, companies, not only cloud office providers, with real user
needs for feature locking. This is obviously not only about freemium, as
the final name of the API (BlockedCommand) indicates correctly.

But there is a difference to our community: they have more and different
> sized corporate and also volunteer contributors. They don't fork
> projects away from their community. And the developers value the
> contributors in non-code parts (e.g. documentation, marketing ...) of
> their project too.
>

Unfortunately, there are negative trends that seem to strengthen these
opinions, but I have a much better opinion of our community.

I had a presentation last year where I showed that the number of
LibreOffice core developers has decreased by 20% in the last 5 years. I'm
very sad that last year we lost the LibreOffice development team at NISZ
completely, mostly at Red Hat, and partially at Munnich. I can't blame
these companies and municipality for abandoning or scaling back
development, because I don't know the background of their decision (apart
from the fact that free software has got a fundamental problem: it's worth
quitting support if there's someone to do the work for us, see
https://en.wikipedia.org/wiki/Business_models_for_open-source_software).
The good thing, that some of their developers were saved by Collabora
Productivity, allotropia and TDF, also for our community. too. In fact, I
am very grateful to both past and present employers for allowing full-time
code and non-code contributors to work for the benefit of the community.
They are the exceptional organisations that have served and continue to
serve th

Re: ESC meeting minutes: 2024-10-31

[Dr. David Alan Gilbert]

* Andreas Mantke (ma...@gmx.de) wrote:
> Hi all,
> 
> Am 31.10.24 um 19:07 schrieb Thorsten Behrens:
> > (...)
> > * Feature locking (Andreas)
> >+ "Remove blocking 
> > functions feature from core"
> >+ re-visit from last week - any new views?
> >+ Heiko: having a 'freemium' label in the code - is not ideal. but more 
> > a question
> >  of labelling stuff, rather than technically wrong. And not affecting 
> > the desktop
> >  version anyway
> >+ Ilmari: but Andreas is not complaining about the label, but about the 
> > feature
> >+ Hossein: perhaps this can be a compile-time option instead?
> >+ Michael W.: unclear if that resolves it for Andreas
> >+ Ilmari: does not see the point either
> >+ Cloph: sees no prob here, either - several other places with 'locks' 
> > already in
> >+ AI thorsten conclude this from the side of the ESC, leave comment in 
> > the patch
> 
> 
> after some further thoughts on the process I find it very disturbing
> that the ESC made its decision (and discussion) without even looking at
> the 'freemiumDenyList' (or its renamed version / file). Because we are
> talking about Free Software / FOSS it should be necessary to look first
> on the facts/reasons for the blocking/locking function. But that is only
> really possible if you know the list of denied features.

Hmm; I'm not on ESC, and don't work for any company, so, with that said.

I do agree with you that freemium like things are horrible, but in the
end there's nothing in the free licenses stopping anyone releasing a modified
build that hobbles some features and then another build that has them.
(Although what does the trademark policies say?)

Are there any good reasons for one? Hmm, I've seen things where 
companies really don't want to support a particular feature, e.g. because
it's flaky or they don't employ anyone who knows how to fix it when it breaks;
so that's a kind of sane use for an interface like that.
I can't really object to that.

(Personally I'd rather that be an interface that then allows you to enable
it with a big scary, logged, warning telling you that you don't
get support for it).

IMHO just using it so you can scrape more $ from the customers for
some features other than support is rather natier and just annoys
the customers; but then again as I say, I don't think the licenses
stop it.

> Thus I expect the ESC to ask for this list, publish it and start the
> discussion and decision from scratch again. And I think the discussion
> and decision has to be done without those who have an CoI on this topic.

I think the point is to make the list flexible, so I doubt that would work.

> There were some attendees with such potential conflict in the
> discussion/decision on 2024, Oct. 24/31.

The ESC isn't exactly huge, so I can see how that might be tricky.

But two other thoughts:
  a) I'd rather have the code in LO rather than distro companies
having hacked the hell out of LO to what they ship to customers.

  b) This seems to have been more controvercial because it was only
found out later;  an obviously contentious thing should be discussed
before going in, and it seems wrong for that not to go through a lot
of review.   Getting ESC to think how we stop controvercial things
going in without more visibility seems worthwhile.

Dave
throwing his own two cents into a discussion that probably already has too
many.

> And I would appreciate if the ESC would have a deeper look on those
> patches which only make it to a distro branch and not to the LibreOffice
> master (or a LibreOffice release branch).
> 
> Regards, Andreas
> 
> --
> ## Free Software Advocate
> ## Plone add-on developer
> ## My blog:http://www.amantke.de/blog
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

Re: ESC meeting minutes: 2024-10-31

[Ilmari Lauhakangas]

On 10.11.2024 19.12, Andreas Mantke wrote:

Am 10.11.24 um 17:16 schrieb Ilmari Lauhakangas:

On 10.11.2024 18.07, Andreas Mantke wrote:

Am 31.10.24 um 19:07 schrieb Thorsten Behrens:

(...)
* Feature locking (Andreas)
   + "Remove
blocking functions feature from core"
   + re-visit from last week - any new views?
   + Heiko: having a 'freemium' label in the code - is not ideal.
but more a question
 of labelling stuff, rather than technically wrong. And not
affecting the desktop
 version anyway
   + Ilmari: but Andreas is not complaining about the label, but
about the feature
   + Hossein: perhaps this can be a compile-time option instead?
   + Michael W.: unclear if that resolves it for Andreas
   + Ilmari: does not see the point either
   + Cloph: sees no prob here, either - several other places with
'locks' already in
   + AI thorsten conclude this from the side of the ESC, leave
comment in the patch



after some further thoughts on the process I find it very disturbing
that the ESC made its decision (and discussion) without even looking
at the 'freemiumDenyList' (or its renamed version / file). Because we
are talking about Free Software / FOSS it should be necessary to look
first on the facts/reasons for the blocking/locking function. But
that is only really possible if you know the list of denied features.


No, we are talking about *the deployment of FOSS* specifically.
Deployers are free to apply whatever freemium restrictions they want.
You may personally find it tasteless that LibreOffice now makes this
easier, but that is no reason to spend any more time on this and
certainly no reason to bring up CoI.


we (TDF) has to use its resources for the support of FOSS and not the
support or ease of freemium software / restrictions. That is and would
be a misuse of financial, personal etc. resources of the charity
organization, which has to be avoided (if you like that or not).
Thus it is necessary to review the decision. And the ESC has also to
take care of CoI issues.


Before your complaints, TDF was not using its resources on this topic. I 
hope you will stop, so we avoid more resources being spent.


Ilmari

Re: ESC meeting minutes: 2024-10-31

[Andreas Mantke]

Hi Ilmari, hi all,

Am 10.11.24 um 17:16 schrieb Ilmari Lauhakangas:

On 10.11.2024 18.07, Andreas Mantke wrote:

Am 31.10.24 um 19:07 schrieb Thorsten Behrens:

(...)
* Feature locking (Andreas)
   + "Remove
blocking functions feature from core"
   + re-visit from last week - any new views?
   + Heiko: having a 'freemium' label in the code - is not ideal.
but more a question
 of labelling stuff, rather than technically wrong. And not
affecting the desktop
 version anyway
   + Ilmari: but Andreas is not complaining about the label, but
about the feature
   + Hossein: perhaps this can be a compile-time option instead?
   + Michael W.: unclear if that resolves it for Andreas
   + Ilmari: does not see the point either
   + Cloph: sees no prob here, either - several other places with
'locks' already in
   + AI thorsten conclude this from the side of the ESC, leave
comment in the patch



after some further thoughts on the process I find it very disturbing
that the ESC made its decision (and discussion) without even looking
at the 'freemiumDenyList' (or its renamed version / file). Because we
are talking about Free Software / FOSS it should be necessary to look
first on the facts/reasons for the blocking/locking function. But
that is only really possible if you know the list of denied features.


No, we are talking about *the deployment of FOSS* specifically.
Deployers are free to apply whatever freemium restrictions they want.
You may personally find it tasteless that LibreOffice now makes this
easier, but that is no reason to spend any more time on this and
certainly no reason to bring up CoI.


we (TDF) has to use its resources for the support of FOSS and not the
support or ease of freemium software / restrictions. That is and would
be a misuse of financial, personal etc. resources of the charity
organization, which has to be avoided (if you like that or not).
Thus it is necessary to review the decision. And the ESC has also to
take care of CoI issues.

Regards,
Andreas

--
## Free Software Advocate
## Plone add-on developer
## My blog: http://www.amantke.de/blog

Re: ESC meeting minutes: 2024-10-31

[Ilmari Lauhakangas]

On 10.11.2024 18.07, Andreas Mantke wrote:

Am 31.10.24 um 19:07 schrieb Thorsten Behrens:

(...)
* Feature locking (Andreas)
   + "Remove blocking functions 
feature from core"
   + re-visit from last week - any new views?
   + Heiko: having a 'freemium' label in the code - is not ideal. but more a 
question
 of labelling stuff, rather than technically wrong. And not affecting the 
desktop
 version anyway
   + Ilmari: but Andreas is not complaining about the label, but about the 
feature
   + Hossein: perhaps this can be a compile-time option instead?
   + Michael W.: unclear if that resolves it for Andreas
   + Ilmari: does not see the point either
   + Cloph: sees no prob here, either - several other places with 'locks' 
already in
   + AI thorsten conclude this from the side of the ESC, leave comment in the 
patch



after some further thoughts on the process I find it very disturbing 
that the ESC made its decision (and discussion) without even looking at 
the 'freemiumDenyList' (or its renamed version / file). Because we are 
talking about Free Software / FOSS it should be necessary to look first 
on the facts/reasons for the blocking/locking function. But that is only 
really possible if you know the list of denied features.


No, we are talking about *the deployment of FOSS* specifically. 
Deployers are free to apply whatever freemium restrictions they want. 
You may personally find it tasteless that LibreOffice now makes this 
easier, but that is no reason to spend any more time on this and 
certainly no reason to bring up CoI.


Ilmari

Re: ESC meeting minutes: 2024-10-31

[Andreas Mantke]

Hi all,

Am 31.10.24 um 19:07 schrieb Thorsten Behrens:

(...)
* Feature locking (Andreas)
   + "Remove blocking functions 
feature from core"
   + re-visit from last week - any new views?
   + Heiko: having a 'freemium' label in the code - is not ideal. but more a 
question
 of labelling stuff, rather than technically wrong. And not affecting the 
desktop
 version anyway
   + Ilmari: but Andreas is not complaining about the label, but about the 
feature
   + Hossein: perhaps this can be a compile-time option instead?
   + Michael W.: unclear if that resolves it for Andreas
   + Ilmari: does not see the point either
   + Cloph: sees no prob here, either - several other places with 'locks' 
already in
   + AI thorsten conclude this from the side of the ESC, leave comment in the 
patch



after some further thoughts on the process I find it very disturbing
that the ESC made its decision (and discussion) without even looking at
the 'freemiumDenyList' (or its renamed version / file). Because we are
talking about Free Software / FOSS it should be necessary to look first
on the facts/reasons for the blocking/locking function. But that is only
really possible if you know the list of denied features.

Thus I expect the ESC to ask for this list, publish it and start the
discussion and decision from scratch again. And I think the discussion
and decision has to be done without those who have an CoI on this topic.

There were some attendees with such potential conflict in the
discussion/decision on 2024, Oct. 24/31.

And I would appreciate if the ESC would have a deeper look on those
patches which only make it to a distro branch and not to the LibreOffice
master (or a LibreOffice release branch).

Regards, Andreas

--
## Free Software Advocate
## Plone add-on developer
## My blog:http://www.amantke.de/blog

Re: ESC meeting minutes: 2024-10-31

[Andreas Mantke]

Hi Thorsten, hi all,

Am 31.10.24 um 21:20 schrieb Thorsten Behrens:

Hi Andreas, all,

Andreas Mantke wrote:

feature locking in an api is affecting the whole LibreOffice. And the
labeling of stuff with Freemium makes it clear that the whole review
process seemed to be broken, if not at least the ESC stops such commits.


This discussion has run its course, and the ESC (after now the second
consideration) sees no problem whatsoever with the code.

I'd like to conclude the debate here, unless there's new
arguments. The ones you've stated repeatedly are no reason to revert.


it's interesting to know that you were at the board of the foundation
and regularly participating at the MC at that time and you hadn't raised
an issue about this patch with this label / title.

It should be clear for everyone here that Freemium is not  Free
Software. And the statutes of the foundation (TDF) includes only Free
Software.

Thus there are questions about the reasons why a member of TDF's leading
body (https://www.documentfoundation.org/board-2020-2022/) didn't raise
an eyebrow and prevent the foundation from getting patches with such
title / label or purpose.

Regards,
Andreas

--
## Free Software Advocate
## Plone add-on developer
## My blog: http://www.amantke.de/blog

Re: ESC meeting minutes: 2024-10-31

[Thorsten Behrens]

Hi Andreas, all,

Andreas Mantke wrote:
> feature locking in an api is affecting the whole LibreOffice. And the
> labeling of stuff with Freemium makes it clear that the whole review
> process seemed to be broken, if not at least the ESC stops such commits.
>
This discussion has run its course, and the ESC (after now the second
consideration) sees no problem whatsoever with the code.

I'd like to conclude the debate here, unless there's new
arguments. The ones you've stated repeatedly are no reason to revert.

> [plone]
>
> They created and constantly improve their api. And I have not seen
> anything about feature locking (or similar) in that software (api)
> yet.  But there is a difference to our community: they have more and
> different sized corporate and also volunteer contributors. They
> don't fork projects away from their community. And the developers
> value the contributors in non-code parts (e.g. documentation,
> marketing ...) of their project too.
>
The implied accusations (that the LibreOffice project would do none of
the above) seem to be either borne out of ignorance (then please
educate yourself!), or meant to distort reality. Please stop what
you're implying regardless, since the project I'm contributing to, is:

 * constantly improving its API
 * has corporate contributors of all sizes
 * and greatly values non-code contributions (to the point that every
   TDF trustee has exactly the same weight: one person, one vote).

Cheers,

-- Thorsten


signature.asc
Description: PGP signature

Re: ESC meeting minutes: 2024-10-31

[Ilmari Lauhakangas]

On 31.10.2024 20.57, Andreas Mantke wrote:

Hi all,

Am 31.10.24 um 19:07 schrieb Thorsten Behrens:

(...)



* Feature locking (Andreas)
   +  "Remove blocking 
functions feature from core"

   + re-visit from last week - any new views?
   + Heiko: having a 'freemium' label in the code - is not ideal. but 
more a question
 of labelling stuff, rather than technically wrong. And not 
affecting the desktop

 version anyway


feature locking in an api is affecting the whole LibreOffice. And the
labeling of stuff with Freemium makes it clear that the whole review
process seemed to be broken, if not at least the ESC stops such commits.
(And also not even a BoD member regularly participating at the ESC
meetings raised an issue about that patch).


Preventing users from customising LibreOffice in unified deployments has 
been possible for a long time and this is a similar mechanism. Nobody 
supports your request to revert the patch. Reverting would also mean 
that in principle we should remove all of such feature locking 
functionality implemented previously.


Ilmari

Re: ESC meeting minutes: 2024-10-31

[Andreas Mantke]

Hi all,

Am 31.10.24 um 19:07 schrieb Thorsten Behrens:

(...)



* Feature locking (Andreas)
   +  "Remove blocking functions 
feature from core"
   + re-visit from last week - any new views?
   + Heiko: having a 'freemium' label in the code - is not ideal. but more a 
question
 of labelling stuff, rather than technically wrong. And not affecting the 
desktop
 version anyway


feature locking in an api is affecting the whole LibreOffice. And the
labeling of stuff with Freemium makes it clear that the whole review
process seemed to be broken, if not at least the ESC stops such commits.
(And also not even a BoD member regularly participating at the ESC
meetings raised an issue about that patch).

And I looked at another big world wide open source project where I have
been working on: Plone.

They created and constantly improve their api. And I have not seen
anything about feature locking (or similar) in that software (api) yet.
But there is a difference to our community: they have more and different
sized corporate and also volunteer contributors. They don't fork
projects away from their community. And the developers value the
contributors in non-code parts (e.g. documentation, marketing ...) of
their project too.

Regards,
Andreas

--
## Free Software Advocate
## Plone add-on developer
## My blog: http://www.amantke.de/blog