Draft text: an "attic" proposal

Dear board, dear TDF members, all,

as mentioned a few times during board calls, Emiliano and me have been
drafting a proposal what to do with no-longer-active projects at TDF.

Here's the draft we're both happy with:

-%<------------------------------------------------------------------

## Introduction

It can happen, with a huge project like LibreOffice, that parts
of the project worked on by the community will become obsolete or
superseded by other projects. The following proposal will cope
with the need to let the code (and/or other form of text related
to the code) to be publicly available, while setting the correct
expectations around its availability, suitability for a
production environment, quality and security.

## What is the “attic”?

The “attic” is a special area of TDF infrastructure where part of
the code/documentation/translations can be parked, that is not
anymore actively developed. This will help setting the correct
expectations on its status of development, while not losing its
fundamental trait of being open source (so its code must be
publicly available).

In the present proposal, the “attic” would be a single host
inside TDF infrastructure, available in HTTP/HTTPS protocols,
responding to a URI similar to:
https://attic.documentfoundation.org

## Specificity of the “attic”

This “attic” space will have, at minimum, the following characteristics:

• It is supported by git – the well known CVS developed by Linus
  Torvalds initally and used to share the sources of the Linux
  kernel. Being supported by git will ease the forking of the code
  contained there;

• Any repositories inside it will be made “read only”, so no “push” or
  “pull request” mechanisms will be available: this allows changes to
  the code to be shared as it was the last time it was “atticisized”;

• Anonymous access to the repositories has to be made the default
  access method: we want the code present in the “attic” to be always
  available to everyone;

• It should have a recognizable URL – or internet address, less
  technically: this allows for the code present to be clearly
  separated by other actively developed code;

• A specific text explaining the nature of the code, its
  “de-atticization” requirements and how to get support on the code
  inside the repository to be present in the README of every
  repository. The text of these disclaimer, the de-atticization
  requirements will be discussed further on in the proposal. Regarding
  contacts to get support, the idea is to provide quick and ready
  information on who/where to ask for anything related to the code in
  the repository.

The proposed implementation of this space is by using
git-http-backend1. The proposal has already been evaluated by the
Infra team and the overhead for maintaining such a solution will be
“negligible”.

## Atticization process

The Engineering Steering Committee (ESC) of TDF, the Board of
Directors (BoD) or one or more of its Directors can propose the
“atticization” of a part of the project. That proposal will have to be
voted on successfully by both the ESC and the Board of Directors.

The specific code proposed (mostly, entire git-based repositories)
will be then effectively atticized by the Infra team. Other than
moving the repository to the attic, these other changes will be
needed:

• Deactivation of specific -dev or -users mailing list;

• No new binary releases will be provided (older releases will persist
  in download archive);

• Changing eventual specific category on BugZilla to “Atticized repo –
  please do not use” (ed.: needs to be checked by Infra/QA/Ilmari);

• Possibly disable Ask/Discourse pertaining categories (ed.: needs to
  be checked by Infra/Sophie).

## De-atticization

A part of the project that is actually present inside the “attic” can
be moved back into active development, whenever sufficient interest
around the code emerges.

## De-atticization requirements

A repository can be de-atticized when it reaches the following requirements:

• A publicly available repository has to be present, collecting new
  modifications to the initial project. This repository needs to be
  based on the initial atticized repository;

• The modified code has to be open source/free software under an
  OSI-approved license;

• At least three different developers have committed changes to the
  forked repository, ideally not all of them affiliated to the same
  entity;

• Every developer should have pushed 5-10 non-trivial commits over the
  span of at least three months;

• The de-atticization proposal has to be supported by at least one
  member of The Document Foundation.

## De-atticization procedure

The de-atticization has to be requested from either the ESC or the
Board of Directors; the ESC will provide a technical clearance for the
de-atticization, as well as any needed corrections to the project to
comply to specific development customs of TDF community and to adhere
to the conventions practiced at TDF.

Once clearance has been granted, both ESC and BoD will vote on the
de-atticization of the specific repo.

If the vote turns out affirmative, the implementation part will be
handed over to Infra team, which can, based on common sense:

• Import the forked public repository;

• Or move the repository from attic to gerrit altogether and apply the
  needed corrections.

If needed, new mailing list, BugZilla and Ask/Discourse categories
will be instantiated.

## Proposed text for the nature of the code

The following text is proposed to be included in the README of any
atticized repository:

---

This repository contains FLOSS code that is not maintained and/or
actively developed. The code provided here is *NOT READY FOR
PRODUCTION*, as it lacks updated security auditing (and probably
contains insecure code) and Quality Assurance. Releases are *NOT*
anymore provided for this code.

---

## Proposed text for the un-atticization requirements

The following text is proposed to be included in the README of any
atticized repository:

---

This repository might be moved to active development under TDF’s
supervision through a specific procedure.

Please check that your modifications match the following requirements
(which needs to be all fulfilled):
* modified code is present in a publicly available git repository
* modified code is release with a free/open source license
* at least 3 developers, ideally not from the same entity, modified the code
* modifications efforts to the code are qualified as 5-10 non-trivial commits for each developer over a period of 3 months
* modified code is actively advocated by at least a member of TDF

If the requirements are fulfilled and you can guarantee to continue to
develop on the modified code, please get in touch with TDF ESC and
Board of Directors.

Full procedure available at [Insert URL to a wiki page with the
procedure here].

---

-%<------------------------------------------------------------------

Cheers,

-- Thorsten

Dear Thorsten, Emiliano, board, dear TDF members, all,

first of all, I’d like to state for those that are not into the current status quo that this proposal will mainly affect the “Online” project at TDF’s infra.

I have to say, as a contributor of LibreOffice Online and a member of TDF, this proposal makes me completely unhappy, although it was clear since day 1 of Collabora forking Online that some decision had to be taken on our end.

I have already said this many times but I want to repeat it: it has to be clear (and hopefully stated by legal contracts) to the companies working in the LibreOffice ecosystem that they cannot wake up one day and bring their development outside the LibreOffice project. They cannot stay with one foot inside the ecosystem, contributing to it, and with the other one bringing their development effort outside. This is something the next board should focus on.

Getting to this specific situation, Jan ‘Kendy’ Holešovský, in the last Q+A session for the next BoD, stated that “it was really hard for us [Collabora] to get contributors and volunteers under the TDF umbrella… and we tried hard […] now that we’re on GitHub we get several commits from random people just because it’s on GitHub” [1]. Kendy didn’t bring any data supporting this thesis but – for the sake of the argument – assume he’s true. Shouldn’t this have been a concern for the whole foundation, and not only for Collabora? It’s the foundation scope to bring new developers in. If GitHub can magically attract developers, also TDF, from my point of view, should move there.

There are indeed a few concerns I have to bring: have you ever wondered why the Nextcloud Server project on GitHub has 1.6k open issues? Why do they need so many tags, bots, and PEOPLE, employees that spend their time closing useless issues that are used as support requests?

What I’m trying to say is that a wider audience also comes with considerable disadvantages.

In his speech, Kendy also mentions that “we [Collabora] love LibreOffice”. I am sure that what he says is true, which is precisely why he (with the whole Collabora team) could help us understand why they renamed lool (LibreOffice Online) to cool (Collabora Online) also in the source code [2], removed the “This file is part of the LibreOffice project.” statement from the headers of the source [3] and changed the variable names [4].

In conclusion, I would like to emphasise the fact that I’m completely unhappy with the “attic” proposal as a solution for the Online situation and hope we can all work together to allow TDF to still consider Online a part of the LibreOffice suite.

All the best,

Marco

[1] 1:40:00 and on, https://www.youtube.com/watch?v=YL1NnGvbZT8
[2] https://github.com/CollaboraOnline/online/commit/f07ff8c7e0754babe9819163fb0edeacac326caf

https://github.com/CollaboraOnline/online/commit/ec8f28d75c62f2ea1e0bc147ac80b68a52336932
[3] https://github.com/CollaboraOnline/online/commit/0002fdfd6c21655bcba3fb69b291af4d3801ad79
[4] https://github.com/CollaboraOnline/online/commit/34b8ff08f6c417acbf62c256f0b9371d725c4e54

Il 17/12/21 12:16, Thorsten Behrens ha scritto:

Dear board, dear TDF members, all,

as mentioned a few times during board calls, Emiliano and me have been
drafting a proposal what to do with no-longer-active projects at TDF.

Here's the draft we're both happy with:

-%<------------------------------------------------------------------

## Introduction

It can happen, with a huge project like LibreOffice, that parts
of the project worked on by the community will become obsolete or
superseded by other projects. The following proposal will cope
with the need to let the code (and/or other form of text related
to the code) to be publicly available, while setting the correct
expectations around its availability, suitability for a
production environment, quality and security.

## What is the “attic”?

The “attic” is a special area of TDF infrastructure where part of
the code/documentation/translations can be parked, that is not
anymore actively developed. This will help setting the correct
expectations on its status of development, while not losing its
fundamental trait of being open source (so its code must be
publicly available).

In the present proposal, the “attic” would be a single host
inside TDF infrastructure, available in HTTP/HTTPS protocols,
responding to a URI similar to:
[https://attic.documentfoundation.org](https://attic.documentfoundation.org)

## Specificity of the “attic”

This “attic” space will have, at minimum, the following characteristics:

• It is supported by git – the well known CVS developed by Linus
  Torvalds initally and used to share the sources of the Linux
  kernel. Being supported by git will ease the forking of the code
  contained there;

• Any repositories inside it will be made “read only”, so no “push” or
  “pull request” mechanisms will be available: this allows changes to
  the code to be shared as it was the last time it was “atticisized”;

• Anonymous access to the repositories has to be made the default
  access method: we want the code present in the “attic” to be always
  available to everyone;

• It should have a recognizable URL – or internet address, less
  technically: this allows for the code present to be clearly
  separated by other actively developed code;

• A specific text explaining the nature of the code, its
  “de-atticization” requirements and how to get support on the code
  inside the repository to be present in the README of every
  repository. The text of these disclaimer, the de-atticization
  requirements will be discussed further on in the proposal. Regarding
  contacts to get support, the idea is to provide quick and ready
  information on who/where to ask for anything related to the code in
  the repository.

The proposed implementation of this space is by using
git-http-backend1. The proposal has already been evaluated by the
Infra team and the overhead for maintaining such a solution will be
“negligible”.

## Atticization process

The Engineering Steering Committee (ESC) of TDF, the Board of
Directors (BoD) or one or more of its Directors can propose the
“atticization” of a part of the project. That proposal will have to be
voted on successfully by both the ESC and the Board of Directors.

The specific code proposed (mostly, entire git-based repositories)
will be then effectively atticized by the Infra team.  Other than
moving the repository to the attic, these other changes will be
needed:

• Deactivation of specific -dev or -users mailing list;

• No new binary releases will be provided (older releases will persist
  in download archive);

• Changing eventual specific category on BugZilla to “Atticized repo –
  please do not use” (ed.: needs to be checked by Infra/QA/Ilmari);

• Possibly disable Ask/Discourse pertaining categories (ed.: needs to
  be checked by Infra/Sophie).

## De-atticization

A part of the project that is actually present inside the “attic” can
be moved back into active development, whenever sufficient interest
around the code emerges.

## De-atticization requirements

A repository can be de-atticized when it reaches the following requirements:

• A publicly available repository has to be present, collecting new
  modifications to the initial project. This repository needs to be
  based on the initial atticized repository;

• The modified code has to be open source/free software under an
  OSI-approved license;

• At least three different developers have committed changes to the
  forked repository, ideally not all of them affiliated to the same
  entity;

• Every developer should have pushed 5-10 non-trivial commits over the
  span of at least three months;

• The de-atticization proposal has to be supported by at least one
  member of The Document Foundation.

## De-atticization procedure

The de-atticization has to be requested from either the ESC or the
Board of Directors; the ESC will provide a technical clearance for the
de-atticization, as well as any needed corrections to the project to
comply to specific development customs of TDF community and to adhere
to the conventions practiced at TDF.

Once clearance has been granted, both ESC and BoD will vote on the
de-atticization of the specific repo.

If the vote turns out affirmative, the implementation part will be
handed over to Infra team, which can, based on common sense:

• Import the forked public repository;

• Or move the repository from attic to gerrit altogether and apply the
  needed corrections.

If needed, new mailing list, BugZilla and Ask/Discourse categories
will be instantiated.

## Proposed text for the nature of the code

The following text is proposed to be included in the README of any
atticized repository:

---

This repository contains FLOSS code that is not maintained and/or
actively developed. The code provided here is *NOT READY FOR
PRODUCTION*, as it lacks updated security auditing (and probably
contains insecure code) and Quality Assurance. Releases are *NOT*
anymore provided for this code.

---

## Proposed text for the un-atticization requirements

The following text is proposed to be included in the README of any
atticized repository:

---

This repository might be moved to active development under TDF’s
supervision through a specific procedure.

Please check that your modifications match the following requirements
(which needs to be all fulfilled):
* modified code is present in a publicly available git repository
* modified code is release with a free/open source license
* at least 3 developers, ideally not from the same entity, modified the code
* modifications efforts to the code are qualified as 5-10 non-trivial commits for each developer over a period of 3 months
* modified code is actively advocated by at least a member of TDF

If the requirements are fulfilled and you can guarantee to continue to
develop on the modified code, please get in touch with TDF ESC and
Board of Directors.

Full procedure available at [Insert URL to a wiki page with the
procedure here].

---

-%<------------------------------------------------------------------

Cheers,

-- Thorsten

Hi Marco,

Thank you for your questions!

There has been a lot of positive changes regarding the Online in the
last year; like that the CODE docker images have no limits of users or
documents any more; that the documentation is freely available to
anyone at

  https://sdk.collaboraonline.com/ ;

that a support channel for CODE has been set up:

  https://forum.collaboraonline.com/

and that we (Collabora) have started actively supporting the
LibreOffice Technology brand in Collabora Online:

  https://people.collabora.com/~kendy/tdf/collabora-online-about.jpg
  https://people.collabora.com/~kendy/tdf/nextcloud-office-about.jpg

and on our webpages:

  https://www.collaboraoffice.com/community-lot/

Regarding your concerns - please read inline:

Marco Marinello píše v Po 20. 12. 2021 v 20:34 +0100:

I have already said this many times but I want to repeat it: it has
to be clear (and hopefully stated by legal contracts) to the
companies working in the LibreOffice ecosystem that they cannot wake
up one day and bring their development outside the LibreOffice
project. They cannot stay with one foot inside the ecosystem,
contributing to it, and with the other one bringing their development
effort outside. This is something the next board should focus on.

Given that we are doing FLOSS (Free / Libre / Open Source Software)
here, I wonder how would you like to frame such a legal contract, given
that the "right to fork" is one of the basic Free Software freedoms?
And what if it was not a company, but another group (do you remember
IceWeasel?)

strategy is to listen to what the ecosystem companies or other
contributors are telling you; work with them, instead of against them;
treat them as partners, not as enemies. If you do that, there is no
reason for anybody to leave the community, move the code away, or fork.

In the Online case, we (as Collabora) were trying extremely hard not to
have to move the development outside of TDF infrastructure, and we have
done many steps to fulfill asks of various people. Unfortunately -
they were demanding more and more; and at some stage they wanted just
too much: to dismiss the agreement we had with TDF that LibreOffice
Online will be a source-only project, for *everyone* to build their
branded versions on, ie. it won't be a binary product that people can
download under LibreOffice name from TDF pages.

This agreement was in place to ensure that the economics work
correctly, and all ecosystem companies (not only Collabora) can build
their Online's on top of the shared code.

Getting to this specific situation, Jan 'Kendy' Holešovský, in the
last Q+A session for the next BoD, stated that “it was really hard
for us [Collabora] to get contributors and volunteers under the TDF
umbrella… and we tried hard […] now that we’re on GitHub we get
several commits from random people just because it’s on GitHub” [1].
Kendy didn’t bring any data supporting this thesis but – for the sake
of the argument – assume he’s true.

Sure - I was unprepared for the question, it was ad-hoc, so everything
I've said there was without the possibility to have the numbers at hand
in advance :slight_smile: Let me add the details now:

d0edfeabbdc969a9a66cf90976a63c2f4403a6d3 was the last commit that
happened on the TDF infrastructure. It covers work from 2015-03-03 to
2020-09-30. The amount of people who have contributed during those 5
years and 7 months was 85:

$ git log d0edfeabbdc969a9a66cf90976a63c2f4403a6d3 | grep '^Author:' | sed 's/^Author: //' | sed 's/ <.*//' | sort | uniq | wc -l
85

In the rest of the period, so from 2020-10-01 to now, the amount of
people who have contributed in the 1 year and 2 months was 75 (155 if I
include the translations - but that wouldn't be correct):

$ git log --invert-grep --grep=Weblate d0edfeabbdc969a9a66cf90976a63c2f4403a6d3.. | grep '^Author:' | sed 's/^Author: //' | sed 's/ <.*//' | sort | uniq | wc -l
75

Do you see the 5 years vs. 1 year proportion?

Shouldn’t this have been a concern for the whole foundation, and not
only for Collabora? It’s the foundation scope to bring new developers
in.

Definitely it should be a concern - and I've stressed this several
times on other occasions that the main reason why I am standing for the
Board is that I want to make TDF more welcoming (to get new
contributors) & friendly (to keep the existing ones). And by
contributors, I mean not only developers, but also translators,
designers, documentation authors, QA and other people actually
enhancing the project.

If GitHub can magically attract developers, also TDF, from my point
of view, should move there.

There are many pro's and con's; eg. we were criticized after the move
that GitHub is proprietary software & infrastructure.

Also I think gerrit works better for a C++ project rather than the
system of PR's known from Github.

But if you think even TDF should consider the option, please do feel
encouraged to research that & come up with a proposal to the ESC and
the Board!

There are indeed a few concerns I have to bring: have you ever
wondered why the Nextcloud Server project on GitHub has 1.6k open
issues? Why do they need so many tags, bots, and PEOPLE, employees
that spend their time closing useless issues that are used as support
requests?

What I’m trying to say is that a wider audience also comes with
considerable disadvantages.

I am actually not sure what should I conclude from this? Are you
arguing that Nextcloud is doing better on GitHub than TDF on its own
infra, or that it is doing worse?

Can you add how many open issues are at TDF? How many tags, bots etc.
do we have?

In his speech, Kendy also mentions that “we [Collabora] love
LibreOffice”. I am sure that what he says is true,

Yes, we do love LibreOffice, just have a look at the amount of commits
coming from Collabora to the LibreOffice repository :slight_smile:

which is precisely why he (with the whole Collabora team) could help
us understand why they renamed lool (LibreOffice Online) to cool
(Collabora Online) also in the source code [2], removed the “This
file is part of the LibreOffice project.” statement from the headers
of the source [3] and changed the variable names [4].

Unfortunately there is no way for me to win this argument.

If we keep those names & comments, it could be argued that we are
misusing the LibreOffice name - "why do you say that you are part of
the LibreOffice project when you are not on TDF infrastructure?"

But when we have removed it, it could be argued that we don't love
LibreOffice enough...

Luckily there are hard data that show where we stand - Collabora has
contributed 32.3% of commits that went to LibreOffice since the last
October; which is BTW on par with what we (or any other company) are
allowed in the bodies as the percentage of representatives, so it seems
to be a healthy number.

In conclusion, I would like to emphasise the fact that I’m completely
unhappy with the “attic” proposal as a solution for the Online
situation and hope we can all work together to allow TDF to still
consider Online a part of the LibreOffice suite.

I am still not sure I understand your reasons - why it is so important
to you to name this code "LibreOffice Online"?

The code is still Free Software under the same MPL license, as it was
under TDF. The code is flourishing on GitHub, so the FLOSS world wins;
and only few people actually care if it is named "LibreOffice Online",
or "Collabora Online".

Of course, we as Collabora are actually among those few who *do* care
if it is called Collabora Online or not, because that helps us to get
customers, and re-invest the income into the code; see more here:

  https://www.mail-archive.com/board-discuss@documentfoundation.org/msg04727.html

The last thing - have you noticed the recently announced "Nextcloud
Office"?

  https://nextcloud.com/blog/nextcloud-hub-2-brings-major-overhaul-introducing-nextcloud-office-p2p-backup-and-more/

The same Online code is now available under the "Nextcloud Office"
name...

Please ask yourself - what is the value of non-atticized LibreOffice
Online? What is better for FLOSS in general: One common code on GitHub
with multiple names (all promoting the LibreOffice Technology, but none
of them actually called "LibreOffice Online"), or 2 diverging forks,
one of them consuming TDF money, but called "LibreOffice Online"?

Thank you!

All the best,
Kendy

Hi Jan, all,

sorry for the late reply. Honestly, I was expecting someone else's
(Thorsten and Emiliano in first place, the current and upcoming board in
second place, the staff in third place and other community members in
fourth place) reply. But nothing came in so I assume it's on me to
re-reply here.

Hi Marco,

Thank you for your questions!

There has been a lot of positive changes regarding the Online in the
last year; like that the CODE docker images have no limits of users or
documents any more; that the documentation is freely available to
anyone at

  https://sdk.collaboraonline.com/ ;

It was clear to me that some more extensive documentation regarding
online had to be written, especially on the API part. I can acknowledge
you did a good job.

that a support channel for CODE has been set up:

  https://forum.collaboraonline.com/

and that we (Collabora) have started actively supporting the
LibreOffice Technology brand in Collabora Online:

  https://people.collabora.com/~kendy/tdf/collabora-online-about.jpg
  https://people.collabora.com/~kendy/tdf/nextcloud-office-about.jpg

Okay, this trademarks are not present in the version I built on my own a
while ago but I guess has been added later on or is simply available
only in the paid version.

and on our webpages:

  https://www.collaboraoffice.com/community-lot/

Regarding your concerns - please read inline:

Marco Marinello píše v Po 20. 12. 2021 v 20:34 +0100:

I have already said this many times but I want to repeat it: it has
to be clear (and hopefully stated by legal contracts) to the
companies working in the LibreOffice ecosystem that they cannot wake
up one day and bring their development outside the LibreOffice
project. They cannot stay with one foot inside the ecosystem,
contributing to it, and with the other one bringing their development
effort outside. This is something the next board should focus on.

Given that we are doing FLOSS (Free / Libre / Open Source Software)
here, I wonder how would you like to frame such a legal contract, given
that the "right to fork" is one of the basic Free Software freedoms?
And what if it was not a company, but another group (do you remember
IceWeasel?)

IANAL so I have no clue on how this kind of contract could be settled
but I want to say that is quite logical that you cannot both support and
oppose an entity. In Italy, the law states that if you leave your job
and create a company that will do the same job you were doing as an
employee, taxes will be much higher.

From my point of view, rather than legal contracts, a much better
strategy is to listen to what the ecosystem companies or other
contributors are telling you; work with them, instead of against them;
treat them as partners, not as enemies. If you do that, there is no
reason for anybody to leave the community, move the code away, or fork.

Clearly, this is also my view. However, listening should not mean that
the foundation does everything and only what is requested by the
companies in the ecosystem. This has to be clear.

The foundation should create contact between businesses and users, not
be the representative of a group of companies.

In the Online case, we (as Collabora) were trying extremely hard not to
have to move the development outside of TDF infrastructure, and we have
done many steps to fulfill asks of various people. Unfortunately -
they were demanding more and more; and at some stage they wanted just
too much: to dismiss the agreement we had with TDF that LibreOffice
Online will be a source-only project, for *everyone* to build their
branded versions on, ie. it won't be a binary product that people can
download under LibreOffice name from TDF pages.

This agreement was in place to ensure that the economics work
correctly, and all ecosystem companies (not only Collabora) can build
their Online's on top of the shared code.

"all ecosystem companies" = ["Collabora", "Allotropia (formerly CIB)"]

Although I didn't have the opportunity to take part in the discussion
before the decision was made, I can say I'm fully endorsing the
termination of the agreement (which was de facto terminated by Collabora).

I used to think, and will continue to, that keeping Online difficult for
everybody to build and vendor-provided only was a huge mistake and, most
of all, as you demonstrated, did not achieve the goal of "ensure that
the economics worked correctly". People didn't have the opportunity to
"download and try" the product as a part of the LibreOffice suite and,
therefore, did not buy any support/extra subscription for it.

Getting to this specific situation, Jan 'Kendy' Holešovský, in the
last Q+A session for the next BoD, stated that “it was really hard
for us [Collabora] to get contributors and volunteers under the TDF
umbrella… and we tried hard […] now that we’re on GitHub we get
several commits from random people just because it’s on GitHub” [1].
Kendy didn’t bring any data supporting this thesis but – for the sake
of the argument – assume he’s true.

Sure - I was unprepared for the question, it was ad-hoc, so everything
I've said there was without the possibility to have the numbers at hand
in advance :slight_smile: Let me add the details now:

d0edfeabbdc969a9a66cf90976a63c2f4403a6d3 was the last commit that
happened on the TDF infrastructure. It covers work from 2015-03-03 to
2020-09-30. The amount of people who have contributed during those 5
years and 7 months was 85:

$ git log d0edfeabbdc969a9a66cf90976a63c2f4403a6d3 | grep '^Author:' | sed 's/^Author: //' | sed 's/ <.*//' | sort | uniq | wc -l
85

In the rest of the period, so from 2020-10-01 to now, the amount of
people who have contributed in the 1 year and 2 months was 75 (155 if I
include the translations - but that wouldn't be correct):

$ git log --invert-grep --grep=Weblate d0edfeabbdc969a9a66cf90976a63c2f4403a6d3.. | grep '^Author:' | sed 's/^Author: //' | sed 's/ <.*//' | sort | uniq | wc -l
75

Do you see the 5 years vs. 1 year proportion?

Well, yes but no. A more deeper comparison should be done here, in my
honest opinion. If the 50% of the 75 people contributing in the last
year are former developers (e.g. myself), that ain't that big success...

Shouldn’t this have been a concern for the whole foundation, and not
only for Collabora? It’s the foundation scope to bring new developers
in.

Definitely it should be a concern - and I've stressed this several
times on other occasions that the main reason why I am standing for the
Board is that I want to make TDF more welcoming (to get new
contributors) & friendly (to keep the existing ones). And by
contributors, I mean not only developers, but also translators,
designers, documentation authors, QA and other people actually
enhancing the project.

If GitHub can magically attract developers, also TDF, from my point
of view, should move there.

There are many pro's and con's; eg. we were criticized after the move
that GitHub is proprietary software & infrastructure.

For an open source project to move to a platform owned by Microsoft, is
definitely not the kind of choice I can say I would endorse.

Also I think gerrit works better for a C++ project rather than the
system of PR's known from Github.

But if you think even TDF should consider the option, please do feel
encouraged to research that & come up with a proposal to the ESC and
the Board!

There are indeed a few concerns I have to bring: have you ever
wondered why the Nextcloud Server project on GitHub has 1.6k open
issues? Why do they need so many tags, bots, and PEOPLE, employees
that spend their time closing useless issues that are used as support
requests?

What I’m trying to say is that a wider audience also comes with
considerable disadvantages.

I am actually not sure what should I conclude from this? Are you
arguing that Nextcloud is doing better on GitHub than TDF on its own
infra, or that it is doing worse?

My experience with issues @ Nextcloud is definitely not idyllic... I
can't say it's only due to the fact they're on GitHub but I think this
contributes. There are many duplicates for any issue, some of them will
be closed as resolved by thinking the problem was solved when it was
not. Other are just kept there.

Can you add how many open issues are at TDF? How many tags, bots etc.
do we have?

We could but it would not be a fair comparison since are two completely
different product. Perhaps the number of open issues per SLOC could be a
good index.

In his speech, Kendy also mentions that “we [Collabora] love
LibreOffice”. I am sure that what he says is true,

Yes, we do love LibreOffice, just have a look at the amount of commits
coming from Collabora to the LibreOffice repository :slight_smile:

which is precisely why he (with the whole Collabora team) could help
us understand why they renamed lool (LibreOffice Online) to cool
(Collabora Online) also in the source code [2], removed the “This
file is part of the LibreOffice project.” statement from the headers
of the source [3] and changed the variable names [4].

Unfortunately there is no way for me to win this argument.

If we keep those names & comments, it could be argued that we are
misusing the LibreOffice name - "why do you say that you are part of
the LibreOffice project when you are not on TDF infrastructure?"

But when we have removed it, it could be argued that we don't love
LibreOffice enough...

Luckily there are hard data that show where we stand - Collabora has
contributed 32.3% of commits that went to LibreOffice since the last
October; which is BTW on par with what we (or any other company) are
allowed in the bodies as the percentage of representatives, so it seems
to be a healthy number.

I like to read the story in another way: Collabora worked hard to create
online, put the effort of many developers per year and now finally
wanted to see only his name on it, instead of LibreOffice. But is of
course just my personal point of view.

In conclusion, I would like to emphasise the fact that I’m completely
unhappy with the “attic” proposal as a solution for the Online
situation and hope we can all work together to allow TDF to still
consider Online a part of the LibreOffice suite.

I am still not sure I understand your reasons - why it is so important
to you to name this code "LibreOffice Online"?

The code is still Free Software under the same MPL license, as it was
under TDF.

... and has been cleared (at least to me) just on Sep 23, 2021, when
also the EULA was removed from the repo.

https://github.com/CollaboraOnline/online/commit/dad92dee2523f67c5d592727fbd9b0c9eb8e400a

The code is flourishing on GitHub, so the FLOSS world wins;
and only few people actually care if it is named "LibreOffice Online",
or "Collabora Online".

Of course, we as Collabora are actually among those few who *do* care
if it is called Collabora Online or not, because that helps us to get
customers, and re-invest the income into the code; see more here:

  https://www.mail-archive.com/board-discuss@documentfoundation.org/msg04727.html

I know how much you care about building an ecosystem around Collabora
Online (and not LOOL), see e.g. this issue
https://github.com/learnweb/moodle-mod_collabora/issues/16 that was
magically commented by someone @ Collabora after I shared the link to it
in the legal mailing list.

Using the Collabora product name prevented and prevents the customers
from acknowledging there are other companies that provide support for
Online, damaging, again, the ecosystem, instead of strengthening it.

The last thing - have you noticed the recently announced "Nextcloud
Office"?

  https://nextcloud.com/blog/nextcloud-hub-2-brings-major-overhaul-introducing-nextcloud-office-p2p-backup-and-more/

The same Online code is now available under the "Nextcloud Office"
name...

Please ask yourself - what is the value of non-atticized LibreOffice
Online? What is better for FLOSS in general: One common code on GitHub
with multiple names (all promoting the LibreOffice Technology, but none
of them actually called "LibreOffice Online"), or 2 diverging forks,
one of them consuming TDF money, but called "LibreOffice Online"?

It's because I ask myself this kind of question that I spend my time
writing on the board-discuss mailing list.

It is obvious, and I thought it was also in my previous mail, that
having two divergent forks wouldn't be the way out of this problem.

Also, my main problem is also not the source code but enabling the
foundation to still include Online as a product of the LibreOffice
line-up. Do you (or anyone else) have any proposal to achieve this goal?

Hoping that someone else is willing to take his contribution to this
discussion,

All the best,

Marco

Hi Marco,

since you specifically asked me to comment -

Marco Marinello wrote:

first of all, I'd like to state for those that are not into the current
status quo that this proposal will mainly affect the "Online" project at
TDF's infra.

Conversely, I believe it would be wise to structure the atticization
process (and its reversal) independently of the LibreOffice Online
question.

It is not the first, and not the last time, that code we host becomes
effectively unmaintained (for any number of reasons).

You further state:

In conclusion, I would like to emphasise the fact that I’m
completely unhappy with the “attic” proposal as a solution for the
Online situation and hope we can all work together to allow TDF to
still consider Online a part of the LibreOffice suite.

Let's please dis-entangle this (ideally discussing Online remedies in
a separate thread). You state you're unhappy with the attic proposal,
but don't provide any specific criticism (change this clause, avoid
that trap, etc). Is it that you would be fine with it, if --
hypothetically -- cppunit would become unmaintained? Or is there a
more fundamental problem with it, from your PoV? If yes, can you
suggest changes?

On the Online topic, I've got nothing much to add (beyond the fact
that the development from 2020 was rather regrettable). I'm also
biased (as likely you are, and others with strong opinion on the
question). Allow me one comment though:

Marco Marinello wrote:

Kendy wrote:
> Marco Marinello píše v Po 20. 12. 2021 v 20:34 +0100:
>> I have already said this many times but I want to repeat it: it
>> has to be clear (and hopefully stated by legal contracts) to the
>> companies working in the LibreOffice ecosystem that they cannot
>> wake up one day and bring their development outside the
>> LibreOffice project. They cannot stay with one foot inside the
>> ecosystem, contributing to it, and with the other one bringing
>> their development effort outside. This is something the next
>> board should focus on.
>>
> Given that we are doing FLOSS (Free / Libre / Open Source
> Software) here, I wonder how would you like to frame such a legal
> contract, given that the "right to fork" is one of the basic Free
> Software freedoms? And what if it was not a company, but another
> group (do you remember IceWeasel?)
>
IANAL so I have no clue on how this kind of contract could be
settled but I want to say that is quite logical that you cannot both
support and oppose an entity. In Italy, the law states that if you
leave your job and create a company that will do the same job you
were doing as an employee, taxes will be much higher.

This idea sadly runs counter to *everything* that matters for FLOSS
licenses and projects. Let's please put it to rest. Once the code is
open, everyone is free to take it, fork it, and do with it what they
please (according to the terms of the license, and perhaps by
rebranding).

All remedies I can think of are much worse than the disease you'd like
to cure. And for companies, it is trivially easy to circumvent any
sort of contract that binds a particular company, but not the general
public.

Cheers,

-- Thorsten

Hi Marco,

You called me on the topic thrice (as proposer, in the current Board and most probably in the next) so I think your email requires my answer now.

first of all, I'd like to state for those that are not into the current status quo that this proposal will mainly affect the "Online" project at TDF's infra.

Not only. I can also name the Android "LibreOffice Viewer", for example.

While I will keep replying to your kind inquiry to some extent, please understand that the proposal in no way aims to solve the issues you touched in the rest of your email, that are only tangent to the main goal of the proposal, which is:

"clearly explain that some code, hosted at TDF and which was worked on by the whole community, is indeed FLOSS code but it is not anymore worked on and can be unreliable for production, unless serious development/support work is put in it."

I have to say, as a contributor of LibreOffice Online and a member of TDF, this proposal makes me completely unhappy

Well thanks for stating it out, but I have to say unfortunately we cannot always have what we want.

In the LOOL specific case, it is pretty obvious that TDF itself, or its wonderful volunteers, cannot provide the same level of support that other ecosystem companies provided before the move, to a point where it is impossible to state that that code was suitable for production anymore.

To better explain my statement, let me uncover the fact that, some months after the move (and IIRC before the official freeze), Collabora has kindly offered to backport (for free) some security fixes from Collabora Online to the TDF-maintained internal LOOL instance, which weren't reported nor fixed by others in TDF venues. Stated that, it should be self-evident that, as of now, the community at large cannot support the Online code available at TDF. And we cannot, in full honesty, set expectations of a stable project anymore.

However:
1 - The code has always been open-sourced, so if anyone/any company had some interest in the project might have forked it and made it workable again (which didn't happen until now, to my knowledge);
2 - The attic proposal (with its de-atticization procedure) provide clear rules for resuming a project that was halted, something that the freeze didn't provide for, and sets some clear indication (albeit yet to approve/confirm and probably unsatisfactory to some) on how to consider if eventual development is deemed sufficient or not for its resume.

It's not the best approach/implementation, most probably, but it is a start. I hope everyone can find the time to propose modifications and/or underline their own issues with the proposal.

I have already said this many times but I want to repeat it: it has to be clear (and hopefully stated by legal contracts) to the companies working in the LibreOffice ecosystem that they cannot wake up one day and bring their development outside the LibreOffice project. They cannot stay with one foot inside the ecosystem, contributing to it, and with the other one bringing their development effort outside.

This is a pretty raw summary, but it is an oversimplification, to my perspective, and as any oversimplification, it does harm to one side or the other, or both. It also infers that the rules of the game were clear from the beginning, which I don't think holds true in this specific case, for a number of reasons; at least expectations has been falsely set (I assume in goodwill) on and from "both sides" and were never corrected during the years of development of the Online project.

A lot of hard to estimate, hard to balance, actions and decisions has happened during the time, and some actions/decisions that should have happened didn't really happen. I'm not pointing any fingers or guilt anyone in specific for what happened or not happened.

Lack of publicity of some discussions/decisions might have obfuscate the matter, leaving it as a dark, opaque discussion out of the reach and oversight of the community, to the point that even members cannot tell the full picture, yet as of now.

I'm positive that there is fair and logic reasoning supporting both "sides of the argument" (because, remember, we are all part of the same community and should have the same goals), but the net result was a lose-lose situation for everyone (users, community members, TDF itself, ecosystem companies, developers, etc.), to me. Also, in hindsight it is always simple to point out errors, while that's not that simple to avoid them happening in the first place.

We cannot avoid ecosystem companies to put substantial efforts (money, tens or sometimes even hundreds of k€) on LO code (and in fact this is normally a blessing for the project itself; to be more fair, ecosystem companies are used to push changes directly into LO master/main branch while developing changes in the first place). Whether these efforts are shared with the community or not, however, it is a decision that pertains only to said companies' managements, based on their business model (e.g. leveraging added value to attract customers that, in the end, can enrich the whole project and assure its sustainability), and provided that LO license permits them to decide.

The reality, here, is that the Online project was mostly an effort from one company (not completely, but mostly), and that is clearly shown by the fact that the project is surviving outside of TDF venues under the cares of said company. Whether this project was marketed as a community effort but most of the efforts then arguably came only from one company and costs of its development were not shared with TDF, well, that's some of the missed decisions and false expectations I was referring to before.

I wasn't involved in the discussion from the inception of the Online project, so my understanding of what happened back then is somehow intrinsically biased and mostly the result of a collection of others' opinions; but I have to admit my overall summary of the situation has changed since I became a Director (not drastically, but has changed anyways).

That said, we (unfortunately) cannot fix what already happened. What we can do is learn from past mistakes and assure that what was done wrong with the Online project will not happen again in the future.

Some Board Directors (also, potentially re-elected) have already proposed some actions to fix (or better, put in place) rules of engagement for community projects; this need to fix rules of engagement is not even consensual in the actual Board of Directors, and some of the (equally, potentially re-elected) Directors refuse the need, altogether with the proposed fixes, pointing out other factors as the root cause of the actual situation.

Fixing eventual rules of engagement can just be one aspect of the issue, however, and we have to implement different approaches to nurture ecosystem-provided efforts to strengthen the set of features for LibreOffice by participating to these efforts as TDF and as community, as such making sure that the added value provided by these efforts will become an indissoluble part of the project.

How to do that, well, that's a pretty daunting, hard task to do, additionally with a pretty holistic approach; while the Board has the responsibility to implement actions to foster that, the whole community is called to care about it. I'd like to hear feedback from members to pointers, ideas, actions to better focus on our common shared goal, while reducing to the bare minimum the frictions between different parts of our diverse community.

This is something the next board should focus on.

Well, I'd be pleased and at the same time scared to death if this would be the only hot topic the next Board has to deal with :wink:

Getting to this specific situation

Please excuse me if I will not go into details, for two main reasons:
* I don't think this is particularly helpful to further the discussion, and instead it potentially can affect negatively one side or the other. Let's just assume we *all together* did some *faux pas* and look out for the future;
* I don't have the knowledge, the skills and the time to go over these details, check their genesis, the possible deciding facts, and give my own informed thoughts about all of them. For what purpose, then? Would it change something in the actual situation?

In conclusion, I would like to emphasise the fact that I’m completely unhappy with the “attic” proposal as a solution for the Online situation

Again, it was not a proposal for the Online situation only; and while I have to admit that my position changed a lot about what follows, with a lot of unhappiness and unrest in my heart I also must say that for me there is no Online discussion at TDF anymore, since the move from Collabora.

and hope we can all work together to allow TDF to still consider Online a part of the LibreOffice suite.

I still consider a cloud/mobile solution to be key for the future of the project, but I'm not considering anymore the Online solution as incarnated by LOOL as part of that future. I see a different approach to the technological issue that I would like to see loved and cared for from the community and the Board of Directors; as part of my renewed commitment to TDF, I would try to push that effort in the priorities of TDF.

Cheers,

Hi Emiliano, all,

first of all, I'd like to state for those that are not into the current status quo that this proposal will mainly affect the "Online" project at TDF's infra.

Not only. I can also name the Android "LibreOffice Viewer", for example.

at least at this point in time, I (as somebody having contributed to LibreOffice Android Viewer during the last year) wouldn't see Android Viewer as a really good candidate for the attic.

While it's not the most actively developed part of LO, it is (other than LOOL) still receiving contributions. And while there hasn't been any official release for a long time, daily builds are still provided by TDF [1] and the fact that users are occasionally reporting bugs in Bugzilla suggests that the app is being used by those.

Can you possibly give a few more details on why you're considering it as another candidate for the attic?

If there are any specific technical issues with the app (like critical bugs that make the app useless) I'd be happy to hear about those. (Maybe those can be addressed.)

Of course, it's well possible that interest in LO Android Viewer may become even less in the future, in particular as the COOL-based Collabora Office app as a potential alternative becomes even more mature. But at least in the status quo, my personal opinion so far would be that it's not the time to put LO Android Viewer to the attic as of now.

Best regards,
Michael

PS: As a side note, given that Android Viewer is contained in the "core" git repo, just like the desktop version, it would have to be clarified what "putting to the attic" would mean in detail for that specific case.

[1] https://dev-builds.libreoffice.org/daily/master/current.html

Hi Michael,

Thanks for your prompt reply.

Can you possibly give a few more details on why you're considering it as another candidate for the attic?

Oh, that's quite simple and probably at the same time very naive: mainly because I was unaware of the facts you mentioned.

The absence of a release published in the Play Store (which is the main venue, to my perspective, to reach for users), its known limitations, the need of a reworking of the interface to get some interest back to the app and the appearance of a successful substitute app (the Collabora Office app you cited yourself) got me to the wrong conclusion, that it wouldn't be worked on and further supported, and no other interests were on my radar.

Happy to know I was wrong, and that has been worked on in the last year :slight_smile: Thanks to you (and by extension, to anyone else worked on it) for your efforts on the project :slight_smile:

But at least in the status quo, my personal opinion so far would be that it's not the time to put LO Android Viewer to the attic as of now.

Well, I have to agree with you; after your explanation, it seems it does not qualify for the attic.

PS: As a side note, given that Android Viewer is contained in the "core" git repo, just like the desktop version, it would have to be clarified what "putting to the attic" would mean in detail for that specific case.

Indeed, that's something we didn't envision in the proposal; thanks for pointing it out.

My first though about a general process to atticize core code is at least cumbersome and require much more work than leaving it there (and I can only understand high level development, as I am not a developer). What's your take?

Cheers,

Hi Emiliano,

thanks for the quick follow-up. :slight_smile:

The absence of a release published in the Play Store (which is the main venue, to my perspective, to reach for users), its known limitations, the need of a reworking of the interface to get some interest back to the app and the appearance of a successful substitute app (the Collabora Office app you cited yourself) got me to the wrong conclusion, that it wouldn't be worked on and further supported, and no other interests were on my radar.

Ah, I see and I would have agreed in case nothing had happened in the last years, since the app had actually been in a pretty much non-working state for a while.

My first though about a general process to atticize core code is at least cumbersome and require much more work than leaving it there (and I can only understand high level development, as I am not a developer). What's your take?

If something has been inactive for a while and it's not useful in its current state and there's no indication that this is going to change anytime soon (nobody is interested in working on it), I think it may be reasonable to just remove it (i.e. delete the corresponding source files).
Since everything is in git, the removal can easily be reverted anytime should there be renewed interest. The "core" git repo itself remains active anyway, so patches could be submitted to Gerrit the usual way and there would be no need for any specific step to reactivate anything from the infra side (as opposed to how it is in the scenario where a separate repository is used).

I think that would be in line with how we have been handling single features in the desktop version that were in a comparable state in the past - usually after discussing the removal in the ESC first.

Best regards,
Michael

Hi Michael,

Ah, I see and I would have agreed in case nothing had happened in the last years, since the app had actually been in a pretty much non-working state for a while.

Is there something we (from the side of TDF) can do about this, eg push a new release to the Play Store? If so, I can talk to Cloph (our release engineer) about getting an updated version out there...

Cheers,
Mike

Hi *,

Michael Weghorn wrote:

I think that would be in line with how we have been handling single features
in the desktop version that were in a comparable state in the past - usually
after discussing the removal in the ESC first.

I would support that proposal.

The attic process is for repository-level decisions. When it comes to
code in the core repo, let's stick to the light-weight process we have
already (as Michael said, larger/possibly controversial changes get
discussed in the ESC).

All the best,

-- Thorsten

Hi Mike,

Is there something we (from the side of TDF) can do about this, eg push a new release to the Play Store? If so, I can talk to Cloph (our release engineer) about getting an updated version out there...

Thanks for asking.
Whether it makes sense to push a new release to the Play Store is actually a good question, and I don't think I can answer that just by myself.

So far, when looking at LibreOffice Viewer and potential alternatives, my personal assessment was that it was worth spending some effort to improve it to have a reasonably well working solution and I think it is useful in its current state.

However, I don't really know whether it will make sense to keep it in the long run, in particular as alternatives (like the Collabora app) are further improved.

So the question is probably: Does it make sense to start doing official releases again now when we don't know whether/for how long we'll continue to do so?
I'm currently undecided on that myself, happy to hear other people's opinions...

Best regards,
Michael

Hi all,

as I was a person directly involved in the process that should have given to the LibreOffice community a usable LibreOffice On-Line I think I should add my comments to this thread.

Very brief summary of the events:

Back in March 2020, other new board members and I, started making enquiries in regards to why we weren't making available an up to date LOOL to the community. We were clearly "advertising" LOOL on the website but it wasn't in a easily usable state and I strongly believed we had to do our part to help e.g. schools and non-profits coping with remote working when the pandemic started hitting hard. After all, TDF has been created for the public benefit, and in this new situation with the lockdown, what would have been more beneficial to the general public than to support pupils, students, volunteers in nonprofits by providing a platform and sharing our knowledge, based on Free and Open Source Software? This would have allowed our Foundation and us, as citizens, to perform our civic duty to help and it would also have had a positive marketing effect for the members of the ecosystem. Unfortunately that opportunity is now lost, mostly in favor of proprietary vendors which just consolidate their position. It's sad. It's a lost opportunity for TDF and for the ecosystem.

As our enquiries weren't really answered I proposed a vote to get noticed. That finally got things in motion to evaluate the situation with LOOL, which in turn uncovered the understandable need the members of the ecosystem had for more visibility. To satisfy both needs in a fair way, work on the marketing plan was started, with the aim to satisfy everyone's interests. It's something we should have started much earlier.

It was also an agreed precondition to release LOOL in a more usable way and up to date so that we could do our part in providing a free on-line platform e.g. for schools and other non-profits.

Things seemed to be satisfactory for both Collabora and TDF, so both the marketing plan and the discussion to publish LOOL carried on until suddenly Collabora decided to announce the fork, just two weeks before our annual conference.

We already put a lot of effort to create and execute on a marketing plan and spent months in negotiations for LOOL's release in a way that would satisfy the wider community, without damaging economically a valuable member of our ecosystem, but unfortunately one party didn't fulfil its side of the agreement.

Collabora wrote most of the code, there seem to be no sizeable developers community around LOOL elsewhere and TDF has no internal developers to continue the development. This leaves us with two options: Collabora works with us on executing the marketing plan that includes LOOL, or members of the volunteer and enterprise community clearly state they want to work on a LOOL. If neither of those two options is actionable then we have to conclude that TDF has no LOOL to promote anymore, and it's another lost opportunity.

Sadly, the temporary freeze announced in 2020 did not help to find a solution. Since the beginning of the fork Collabora didn't respond to requests to find a mutually benificial solution to the issue. Instead it put its efforts in removing tags related to the "LibreOffice Project" and even renamed variables from LOOL* to COOL*, clearly indicating that they are not interested in reviewing their decision, so eventual backports to the original project are even more complicated from both a technical and relational point of view.

If in the next few months a small number of developers will express their interest to work on LOOL to fix bugs and/or take it in a different direction then it would make sense to re-open the repository. Closing it in my opinion was a mistake in the first place. It prevented people from contributing, so we don't even know if someone wanted to contribute, or if by now people just gave up.

If in feedback is received by either Collabora or the community then we should officially declare LOOL as end of life and stop promoting it directly, stop allowing third parties to benefit from this specific brand as they did for a decade and review the marketing plan to remove references to LOOL or third party products derived from it.

It is a real shame that a project which was presented during the 2011 LibreOffice Conference by a member of the community and supported by TDF over the years ended this way but at least it's a lesson learned that should help in:

1) Creating clear agreements with the projects we support/promote so that, even if a team/company writes the majority of the code, we will have clear indications of the benefits we can together bring to the community and the relevant expectations from both sides.

2) Making it very clear to current and future members of the commercial ecosystem that "The objective of the foundation is the promotion and development of office software available for use by anyone free of charge" so that it doesn't come as a surprise when TDF propose to fulfil its duties for projects that have been hosted and supported by TDF for so many years. TDF naturally welcomes new members of the ecosystem but the rules of engagement need to be defined as from point 1.

It is totally fine if someone wants to start his/her own projects based on LibreOffice and host them under his/her rules. However, I don't think it is fine to benefit from TDF and the work of its community for years, and then change the rules and walk away.

3) Employing internal developers which could help in maintaining LibreOffice and related projects so that we don't always need to depend on the goodwill of the members of the ecosystem or tenders to fix bugs, to write features that may be commercially uninteresting or too complex to handle for individual contributors.

4) Investing a lot more in marketing, communities and mentoring to diversify and expand our users and contributors base.

To conclude, I'd love to have LOOL back but now it's up to the wider community to show how much it matters to them.

We are now working on the 2022 budget, so now is the best time to speak out if you'd like specific projects to be supported.

TDF can and want to support contributors in many ways. If there is an interest to work on an online version, or in any other areas related to LibreOffice, let us know.

I am convinced that TDF does not compete against the commercial ecosystem, as some said.
TDF has goals and potentials that may have not even been expressed to their fullest extent yet but that leaves plenty of opportunities for organisations that understand we are members of a Foundation that focuses on "promotion and development of (FOSS) office software" for the benefit of all without expecting that someone pays for it (although donations are very welcome). Commercial organisation working with LibreOffice providing services to business users can be successful if they adapt their business model around what we do but they should not ask us hold back in fulfilling our duties toward our community.

Ciao

Paolo

To add to that: in the meeting where you proposed to change the
situation, you expressed a clear conviction that other open source
projects show that it is perfectly possible to have a similar paid
product and a free product side by side, without breaking the economics.
After it was suggested (among others by me) to come with good examples,
solid plans, before breaking anything, you said you would do that.
I'd like to mention that one of TDF's main goal is to foster a
sustainable developers community. So any proposed change in the way of
working, can of course only be considered if it comes with solid report
on that subject.

Still waiting...

Cor

(Possibly others may have time or interest to rebut other 'single side
framed' details of your mail)

Thank you for your valuable contribution Cor.

To add to that: in the meeting where you proposed to change the
situation, you expressed a clear conviction that other open source
projects show that it is perfectly possible to have a similar paid
product and a free product side by side, without breaking the economics.
After it was suggested (among others by me) to come with good examples,
solid plans, before breaking anything, you said you would do that.
I'd like to mention that one of TDF's main goal is to foster a
sustainable developers community. So any proposed change in the way of
working, can of course only be considered if it comes with solid report
on that subject.

Still waiting...

I'm not sure why you say you are still waiting.

A long time has gone by and you may have forgotten a few details for which you will find confirmation in many emails and board meeting minutes.

I didn't wait at the time and proposed, with full support from the board, to involve our marketing team to create the MarCom plan that has been running since then with, correct me if I'm wrong, also your contributions. I do fully understand, as I very clearly stated at the time, that LOOL should have been made available in a way that it would have been beneficial to the community without overlapping too much on the commercial interests of the major contributor of the project.

Since then, negotiations to deliver LOOL to the community with the full board have been ongoing until, unfortunately, the other party decided to leave the negotiating table and forked the project.

It is sadly too late for us to deliver LOOL to those in need during the early stages of the pandemic, as some of us wished, but there may at least be a chance of resuming talks with a valuable member of the ecosystem so that it can have an opportunity to fulfil its side of the agreement.

Ciao

Paolo

Hi,

(...)
I'd like to mention that one of TDF's main goal is to foster a
sustainable developers community. (...)

I'd recommend to read through paragraph 2 of the statutes. The goals of
TDF are written down there.

I'd recommend all members of the board to follow this goals very closely
and take care of TDF's assets and pay attention that they are not
diluted or (partially) damaged.

Regards,
Andreas

It's easy to spend a lot of words that do not give a single insight on
the question if your proposed changes are respecting the boards duty to
foster a sustainable meritocratic community.

Cheers,
Cor

Hi Andreas,

(...)
I'd like to mention that one of TDF's main goal is to foster a
sustainable developers community. (...)

I'd recommend to read through paragraph 2 of the statutes. The goals of
TDF are written down there.

Sorry for my rough summary, Andreas. I realized myself later, and
corrected it in the other mail.

Cheers,
Cor

Hi Andreas,

I'd recommend to read through paragraph 2 of the statutes. The goals of
TDF are written down there.

I'd recommend all members of the board to follow this goals very closely
and take care of TDF's assets and pay attention that they are not
diluted or (partially) damaged.

I'm sure all members of the board know quite well the articles of TDF's statutes.

The issue I see is that, in absence of expressed clear preferences from the board of trustees, some members of the board may apply their own interpretation of some selected articles.

It would be very helpful, and I would be very grateful, if apart from reminding us or Article 2 (maybe we could also add 8.4 and the new CoI Policy) you could also help the board of directors taking decisions by telling us what your preferences are.

In this specific matter what would you prefer that TDF does for your community?

- Would you like to have LOOL's repository to be re-opened so that you and others can contribute to it?
- Would you like to forget about it and focus more on other areas?
- Other choices?

I, as member of this community and member of the board, have already expressed my opinion but when it comes to voting I will (from the 18/02/2020) represent only 1 vote.

It's up to you and the rest of the community to send a clear message so that the members of the board will listen and vote for a proposal that matters to all of you.

Ciao

Paolo

Hi Paolo

Hi Andreas,

I'd recommend to read through paragraph 2 of the statutes. The goals of
TDF are written down there.

I'd recommend all members of the board to follow this goals very closely
and take care of TDF's assets and pay attention that they are not
diluted or (partially) damaged.

I'm sure all members of the board know quite well the articles of
TDF's statutes.

I'd be happy if so.

The issue I see is that, in absence of expressed clear preferences
from the board of trustees, some members of the board may apply their
own interpretation of some selected articles.

I know this from my involvement during some years.

It would be very helpful, and I would be very grateful, if apart from
reminding us or Article 2 (maybe we could also add 8.4 and the new CoI
Policy) you could also help the board of directors taking decisions by
telling us what your preferences are.

Yes, and there are the reasons stated why TDF has it's current financial
state, something to take care of (on a variety of grounds).

In this specific matter what would you prefer that TDF does for your
community?

- Would you like to have LOOL's repository to be re-opened so that you
and others can contribute to it?
- Would you like to forget about it and focus more on other areas?
- Other choices?

I'm not a software engineer by education thus I don't think that I'd be
able to contribute to LOOL.

But in my opinion the fork of LOOL from a member of the board was not
taken in the best interest of TDF/LibreOffice future.

I, as member of this community and member of the board, have already
expressed my opinion but when it comes to voting I will (from the
18/02/2020) represent only 1 vote.

I know this situation, one of the reasons I didn't run for the board
again some years ago.

It's up to you and the rest of the community to send a clear message
so that the members of the board will listen and vote for a proposal
that matters to all of you.

I'm for some reasons currently not a member of TDF's bodies anymore. I'm
not involved in any tasks here anymore. I use my available spare time
for volunteer work in other environments yet.

Regards,
Andreas