ESC meeting minutes: 2024-10-31

Mon Nov 11 03:27:41 UTC 2024

Hi Andreas, hi all,

Andreas Mantke <maand at gmx.de> 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)
> >    + <https://gerrit.libreoffice.org/c/core/+/174865> "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 the needs of millions alongside their clients and donors.

Because you forked a project from our community, you probably did not mean
that there is a bad fork and a good fork. As Danese Cooper (who ran the
first Open Source Program Office at Sun Microsystems, helping the company
to open up its source code, including StarOffice, releasing the
OpenOffice.org project, our code base) wrote in her book:

“The 4 [Free Software] Freedoms also allow contributors to 'fork' the
project, cloning a complete copy so
that the person initiating the fork can make modifications as desired. This
is a failsafe measure
to protect contributors from misuse of their contributions—they can always
fork and start a new
project if they disagree with the direction of the original project to
which they contributed. This
is what has happened, for example, to the OpenOffice.org project, which led
to the LibreOffice
fork of the project and the community.” (Danese Cooper and Klaas-Jan Stol,
Adopting Inner Source, O'Reilly, 2018, page 7
https://innersourcecommons.org/documents/books/AdoptingInnerSource.pdf).

I don't know about the Plone community, but ours does, and I haven't found
that the developers don't appreciate non-code contributors. This is not
possible just because there is no such thing as a developer: almost without
exception, they are also reviewers, mentors, lecturers or translators, as
e.g. more and more core commits are coming from primarily non-coders as
well, fortunately.

On the other hand, I can confirm that a similar opinion was expressed by
one of the directors at our last board meeting, which I refuted
immediately, because the exact opposite of his statement was true, as I had
given examples.

I don't know what better rebuttal to that than answering your concerns
here. Our
excellent (coding and not-coding) community members spoke to the indicated
problem here and at your gerrit commit, and the ESC consisting of them was
also asked.

Again quoting Danese Cooper (on the same page from her book), that altruism
is not enough to develop even the simplest free software:

“The concept of Enlightened Self-Interest must be introduced to explain the
moti‐
vations behind Open Source development. This is the idea that all
participants
are ultimately motivated not only by altruism, but also by personal needs
to get
something specific done—what Raymond characterized as “scratching an itch.”
Many well-known Open Source projects started out because of the creators’
per‐
sonal “itches”: Larry Wall had to create reports but wasn’t quite happy
with the
tools available to him, which included C, Awk, and the Bash shell, and so
he cre‐
ated Perl. Linus Torvalds created the Linux kernel simply because no Unix
imple‐
mentation was available for his 80386 machine (see Open Sources by
O’Reilly6 for
a more detailed history). These motivations to start projects can be
personal
needs, but projects may also be driven by other types of motivations, such
as
curiosity, the directives of an employer, or the desire to increase
personal reputa‐
tion.”

Anyone who lives with simplifications or paradoxes, e.g. free software
development is only about altruism, but free software development companies
are only about profit, should be treated with due suspicion, because they
are simply not right.

Moreover, it is exactly the dedication and passion I see in our community,
including the code and non-code contributors, staff of free software
ecosystem companies, TDF and volunteers that created the best free software.

Thanks for that,
László

> Regards,
> Andreas
>
> --
> ## Free Software Advocate
> ## Plone add-on developer
> ## My blog: http://www.amantke.de/blog
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20241111/6fd5ae85/attachment.htm>