Hi Andreas, hi all,
Andreas Mantke <maand@xxxxxx> 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
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.”
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
