Draft text: an "attic" proposal

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

Hi Andreas,

On 08/01/2022 12:44, Andreas Mantke wrote:

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.

I know the situation and that’s the reason why I put forward my candidacy.

Up to now I’ve been a mostly unknown deputy but many have shown with their votes that are in support of the ideas I want to bring forward and implement.

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.

As you are investing your time to send us your opinion may as well be a member so that you could participate by expressing your vote and improve things if you don’t like what you see.

True that we all have limited amount of time to dedicate to the many projects that we would like to support, I have chosen to dedicate my time to TDF and the LibreOffice community as I believe, among other reasons, it’s one of the projects that needs to be strong and present to reduce the dependence most have on monopolistic platforms.

We are getting there but we need everyone’s help including you.

Ciao

Paolo

Dear board, dear TDF members, all,

this proposal has sparked interesting discussions, that we should
continue. For the proposal at hand though, we've not received much if
any actionable feedback.

So I'd like to call for a vote soon, unless there's concrete input for
edits. Let's give this two more days.

All the best, Thorsten

I wrote:

Hi *,

quick comment on the below -

Paolo Vecchi wrote:

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.

I agree it's an opportunity lost. In many ways indeed - losing
LibreOffice Online's active developer base was not inevitable. That it
did happen in the end, after many people tried to solve the brewing
conflict, was to a considerable degree caused by part of the board
persistently threatening with unilateral action.

In terms of helping schools and non-profits, many things did happen (I
know for certain that Free Software, including LibreOffice, gained
noticeable user traction here in Germany). Regarding LibreOffice
Online though, that wouldn't have been something that TDF could have
hosted ourselves for the world at large. Implying then, that if only
TDF had offered free downloads of the server RPMs, we would have
managed to significantly dent the market share of the integrated cloud
vendors - seems to be quite naive to me.

I'd like to now decouple this discussion from the thread topic (which
is about a general attic process). If there's a need for further
discussion (I'd _much_ prefer forward-looking debates, rather than
re-litigating the past!), please all, start a new thread, and I'll
answer there.

All the best,

-- Thorsten

Hi Cor,

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.

while the comment doesn't add much to the debate of the "attic" proposal and seems to completely ignore the actual actions I and others have taken, not just proposed, it is an opportunity to provide my point of view on selected words from the Preamble of our Statutes that, IMHO, have been a bit abused and that has been bothering me for a while.

Too many times I've seen these 3 words "sustainable meritocratic community" being extrapolated from its context and mostly implying to mean "the economical sustainability of major code contributors".

It is obvious to all that developers are essential for the project as are all the great people that dedicate their time to translate, document, promote LibreOffice and also those that just use it for free without contributing back much as it shows we do something useful for millions of people.

The vast majority of people invest their spare time to make LibreOffice great for all but then there are also tasks that could be too complex for individuals or small group of volunteers to take on and that's why we have to tender out some of those tasks while, hopefully, in a near future we will have some of those tasks taken care of by internal developers funded by our supporter's donations.

As clearly expressed in the closing remarks of my previous email(1) TDF has objectives:

"The objective of the foundation is the promotion and development of office software available for use by anyone free of charge."

and (to mention it in full)

"The foundation promotes a sustainable, independent and meritocratic community for the international development of free and open source software based on open standards."

Those objectives should be pursued independently of the preferences of the members of the commercial ecosystem, which as independent entities are free to choose their business model and to contribute the way they can, while supporting the visibility (MarCom is a good example) of those contributors bringing value to the community (not only in terms of code) to allow them to prosper and contribute back to the project.

There are many individuals and organisations which independently created their own business models to help with development of LibreOffice, support deployments, train users and publish books. Some of them are listed on our "professional support" page, many could be totally unknown to us, and that's another area where we should further extend our MarCom plans.

AFAIK organisations delivering LibreOffice training haven't complained that we are making things too easy for users thus reducing their business opportunities as none of the publishers of books/manuals of LibreOffice complained that our documentation is so good that we make it difficult for them to find buyers for their books.

So I guess TDF is already fostering a "sustainable, independent and meritocratic community" but it's also at the beginning of a journey that, through actions like the MarCom plan and other initiatives that have been proposed, is extending the reach and support to our global community in all areas where our help is seen as necessary and useful to achieve our common objectives.

Having clarified my point of view with the above I hope we can now get back to evaluating if a way forward for LOOL can be found.

Ciao

Paolo

(1) https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00029.html

Hi Paolo,

Hi Andreas,

(...)

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.

As you are investing your time to send us your opinion may as well be
a member so that you could participate by expressing your vote and
improve things if you don't like what you see.

I worked over 16 years for TDF/LibreOffice and its ancestor. I did a lot
of work in different areas of the OSS project during my spare time. But
if you do unpaid volunteer work you need some honest appreciation for
that. And I missed that, at least during the last period working for the
project. Thus I decided to make the necessary cut.

True that we all have limited amount of time to dedicate to the many
projects that we would like to support, I have chosen to dedicate my
time to TDF and the LibreOffice community as I believe, among other
reasons, it's one of the projects that needs to be strong and present
to reduce the dependence most have on monopolistic platforms.

But if I look at the situation around LOOL/COOL I got the impression
that it moves into a dominant market position of one player. Thus an
organization/corporation etc. will investigate if there are enough pros
to change over from one vendor (with lock in) to another vendor (with
also a dominant market position).

We are getting there but we need everyone's help including you.

Currently my spare time is completely used. I committed myself to a new
volunteer mission. And it is exiting to drive things forward in that
area. (my day has only 24 hours too ;-))

Regards,
Andreas

Hi all,

I would wait for an eventual vote until a few weeks after FOSDEM just in case more questions and/or interest about the future of LOOL come up.

That would also allow time to evaluate how an eventual "de-atticisation" or support for any additional project should be managed to avoid a repeat of this type of forks.

Any project benefiting from TDF's infra and brand should be bound, at least, to a backporting agreement during a minimum period of time (1 year?) especially if it becomes clear that a single team/organisation is mostly contributing.

That would show that the organisation cares about the LibreOffice community and gives enough time to evaluate if TDF should further invest in the project in terms of developers, marketing, etc.

This agreement, to be drafted by our legal team in collaboration with TDF's counsel, should be added to the proposal before voting as it should be part of the on-boarding process for projects we intend to support.

The agreement should not be an extremely long and complex legal document, which in some cases could be very difficult to enforce, but at least should also clarify the expectations from both parties and make it clear to the contributors what TDF's objectives are so that there will be no surprises for anyone.

Once that is in place I would agree to vote for the proposal.

Ciao

Paolo

Hi Paolo,

Paolo Vecchi wrote:

I would wait for an eventual vote until a few weeks after FOSDEM just in
case more questions and/or interest about the future of LOOL come up.

The attic proposal is only incidentally related to LibreOffice
Online. Do you have concrete suggestions on changing the actual
proposal?

This agreement, to be drafted by our legal team in collaboration with TDF's
counsel, should be added to the proposal before voting as it should be part
of the on-boarding process for projects we intend to support.

I very strongly suggest to *not* make that mandatory for every kind of
project we'd be interested in adopting. It would otherwise completely
kill the onboarding of that kind of small-but-useful tools we've taken
up in the years past (cppunit, libcmis, odf toolkit etc).

No volunteer in her right mind would sign binding, legal agreements of
that kind.

Instead, it can be left to the discretion of the board to ask for more
formal commitments, if it sees a need.

Best,

-- Thorsten

Hi Thorsten, Emiliano, all,

thanks for the reminder Thorsten, as the discussion goes on in different areas of using this status of attic, my feedback is more on the procedural aspect of it.

It says, Quote:
" …
snip

Atticization process

That proposal will have to be
voted on successfully by both the ESC and the Board of Directors.
snipp

snipp

De-atticization procedure

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

" End of Quote

Both sentences imply that the ESC have in praxis a blocking veto, independent of the decision by a board, for both procedures.
First of all let me ask, if this was intended and is a correct understanding or if I understood it wrong?

So, in case I understood it right, then

  • in reflecting our Statutes and RoP and its construction of the foundation, that the “last” ruling body is the board in an appropriate case of conflict and if needed in supervision of the meritocratic organisation* -
    I would propose to add for a better understanding:

"The last and ruling decision for the Atticization or De-atticization of a project in TDF is certainly by the board. If it is in contradiction to a preliminary vote of the ESC, it should be at least heard by the board for its arguments and it should be reflected from the board with an answer why the decision of the board is not following the ESC vote. "

Or something like this. I am not sure if it is good to vote on it without clarification of this item in any case. What do you think?

Best
Lothar

  • beside some very seldom things where the MC or at last the membership comes into the game, but here we are upon normal activities inside the foundation

Am 08.01.2022 um 17:50 schrieb Thorsten Behrens:

Dear board, dear TDF members, all,

this proposal has sparked interesting discussions, that we should
continue. For the proposal at hand though, we've not received much if
any actionable feedback.

So I'd like to call for a vote soon, unless there's concrete input for
edits. Let's give this two more days.

All the best, Thorsten

I wrote:

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].

---

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

Hi Thorsten,

Hi Paolo,

Paolo Vecchi wrote:

I would wait for an eventual vote until a few weeks after FOSDEM just in
case more questions and/or interest about the future of LOOL come up.

The attic proposal is only incidentally related to LibreOffice
Online.

The attic proposal, isn't only incidental, you and Emiliano volunteered to put together such proposal to deal with LibreOffice OnLine issue.
The fact that it may then be used for other projects in future is an added bonus.

  Do you have concrete suggestions on changing the actual
proposal?

Well, yes. That's what the rest of the email you replied to was about.

This agreement, to be drafted by our legal team in collaboration with TDF's
counsel, should be added to the proposal before voting as it should be part
of the on-boarding process for projects we intend to support.

I very strongly suggest to *not* make that mandatory for every kind of
project we'd be interested in adopting. It would otherwise completely
kill the onboarding of that kind of small-but-useful tools we've taken
up in the years past (cppunit, libcmis, odf toolkit etc).

This is not about components but entire projects like LOOL which have been, or will be, hosted and promoted by TDF.

I'm not even suggesting that each individual proposing a project should sign it, only when the project is being proposed by or it becomes controlled mostly by a single company.

Eg. I wouldn't have asked the person that presented a prototype of LOOL in 2011 to sign the agreement but I would have started proposing it when in 2013 that same person incorporated the company that became LOOL's main contributor.

Another example could be LOWA (LibreOffice WebAssembly), which is a promising project developed mostly by Allotropia AFAIK.

That's why months ago I've asked you to lead by example by officially present the project to TDF in a couple of pages stating the objectives and what TDF could expect to deliver to the community while Allotropia pursues, rightly, its commercial interests. If you followed up we would have had already a document on which to base the agreement we need to welcome other projects.

It is great that companies invest in complex projects based on LibreOffice but, if those projects are to be hosted, promoted or even economically sponsored by TDF, we have to set the right expectations for the community and have a mutually beneficial agreement in place.

Failing to do so will lead exactly to the same outcome we have seen with LOOL.

No volunteer in her right mind would sign binding, legal agreements of
that kind.

You may have missed a bit of the email where I say:

"The agreement should not be an extremely long and complex legal document, which in some cases could be very difficult to enforce, but at least should also clarify the expectations from both parties and make it clear to the contributors what TDF's objectives are so that there will be no surprises for anyone."

Once again, as clarified above, this would apply only to companies or when the project previously run by volunteers becomes controlled by a legal entity.

Instead, it can be left to the discretion of the board to ask for more
formal commitments, if it sees a need.

If a rule is in place it will be easier for the board to spot when they have to act.

As a generic rule of thumb we could set a threshold of 50% (?) of the contributions to the project by a single company at which point the board should start negotiations with the company. That would also help TDF understanding if the contributor is really interested in delivering the project following TDF's objectives or it's just interested in benefiting from TDF's infrastructure and LibreOffice's brand.

Best,

-- Thorsten

Ciao

Paolo

+1 on Lothar's proposal.

Paolo

Hi Paolo,

let's stay focused -

Paolo Vecchi wrote:

> Do you have concrete suggestions on changing the actual
> proposal?

Well, yes. That's what the rest of the email you replied to was about.

Can I see the adjustments/changes to the proposal then please?

I'm not even suggesting that each individual proposing a project should sign
it, only when the project is being proposed by or it becomes controlled
mostly by a single company.

That then seems entirely unrelated to a putative attic process?

Another example could be LOWA (LibreOffice WebAssembly), which is a
promising project developed mostly by Allotropia AFAIK.

That's why months ago I've asked you to lead by example by officially
present the project to TDF in a couple of pages stating the objectives and
what TDF could expect to deliver to the community while Allotropia pursues,
rightly, its commercial interests. If you followed up we would have had
already a document on which to base the agreement we need to welcome other
projects.

Let's discuss that else-thread please. Again, new projects are a
different area entirely. And as one of the people funding LOWA, I find
it irritating that my contributions are met with demands, instead of
gratitude. I've not yet asked TDF anything in return.

Meanwhile, I'd be most happy if people interested in LOWA would come &
join our FOSDEM talk about it:

https://fosdem.org/2022/schedule/event/lowa/

Cheers,

-- Thorsten

Hi Paolo,

let's stay focused -

Paolo Vecchi wrote:

> Do you have concrete suggestions on changing the actual
> proposal?

Well, yes. That's what the rest of the email you replied to was about.

Can I see the adjustments/changes to the proposal then please?

I'm not even suggesting that each individual proposing a project should sign
it, only when the project is being proposed by or it becomes controlled
mostly by a single company.

That then seems entirely unrelated to a putative attic process?

Another example could be LOWA (LibreOffice WebAssembly), which is a
promising project developed mostly by Allotropia AFAIK.

That's why months ago I've asked you to lead by example by officially
present the project to TDF in a couple of pages stating the objectives and
what TDF could expect to deliver to the community while Allotropia pursues,
rightly, its commercial interests. If you followed up we would have had
already a document on which to base the agreement we need to welcome other
projects.

Let's discuss that else-thread please. Again, new projects are a
different area entirely. And as one of the people funding LOWA, I find
it irritating that my contributions are met with demands, instead of
gratitude. I've not yet asked TDF anything in return.

Meanwhile, I'd be most happy if people interested in LOWA would come &
join our FOSDEM talk about it:

https://fosdem.org/2022/schedule/event/lowa/

Cheers,

-- Thorsten

Hi Thorsten,

see below.

Hi Paolo,

let's stay focused -

Paolo Vecchi wrote:

   Do you have concrete suggestions on changing the actual
proposal?

Well, yes. That's what the rest of the email you replied to was about.

Can I see the adjustments/changes to the proposal then please?

The proposal, as stated in my previous emails, is related to the eventual "de-atticisation" of the project.

I'm not even suggesting that each individual proposing a project should sign
it, only when the project is being proposed by or it becomes controlled
mostly by a single company.

That then seems entirely unrelated to a putative attic process?

It is if we want to move a project like LOOL, of in future other projects, from the "attic" into a TDF hosted and promoted project as we should have in place checks that avoid the repeat of the LOOL issue.

The original proposal with "three different developers ...ideally not all of them affiliated to the same entity" does not fully exclude that the proposal could come from an organisation, which in principle would be fine for me, but in this situation the proposed agreement should be in place before welcoming the project back.

Another example could be LOWA (LibreOffice WebAssembly), which is a
promising project developed mostly by Allotropia AFAIK.

That's why months ago I've asked you to lead by example by officially
present the project to TDF in a couple of pages stating the objectives and
what TDF could expect to deliver to the community while Allotropia pursues,
rightly, its commercial interests. If you followed up we would have had
already a document on which to base the agreement we need to welcome other
projects.

Let's discuss that else-thread please. Again, new projects are a
different area entirely. And as one of the people funding LOWA, I find
it irritating that my contributions are met with demands, instead of
gratitude.

I'm not really sure why you feel irritated.

Of course your company's contributions are more than welcome and, as written quite a few times, TDF should facilitate and, if seen as beneficial by the corporate contributor, help in supporting and promoting the project.

The proposal was meant to ask if your project would benefit from being supported by TDF and in which ways.

It is important to set the right expectations for the community to avoid the repeat of the issues we had with LOOL once LOWA is production and market ready.
That's why I believe that the proposal for both the "de-atticisation" process and new projects are linked to the same need to have an agreement in place if the main player is a company.

As both a company director and a member of TDF's board I'm sure you have a clear understanding of the need from one side to protect your investments and on the other side to do what is best for TDF and the LibreOffice community.

Having articles stating "The LibreOffice team has been working on a port to browser-hosted WebAssembly"(1) or the page you created on TDF's wiki describing the WASM project(2) without specifying who leads it and what could be the eventual distribution limitations, may suggest to some that the project is hosted and developed by/for TDF, that's the reading some may have of the "LibreOffice team/developers/other variants", and that will be bound to TDF's objective to make it "available for use by anyone free of charge".

If TDF's objectives are not fully compatible with your company's plan for the LibreOffice based project that is leading, then it would great to work on the proposed document that will be eventually used for LOOL's "de-atticisation" process if the interested party is a company and by your own company to set clear expectations for the community and to protect your investments.

I've not yet asked TDF anything in return.

Once again I express my sincere gratitude for the contributions you personally and your company provided to the LibreOffice project and community.

There are other companies that develop LibreOffice based products which never asked for anything in return, which in some cases may have chosen to use their own brands and host projects in their own infrastructures and I don't see a issue with that even if it would be nice to work all together under clear rules.

Please do evaluate the above if you think TDF could contribute in making your LibreOffice based project suitable for use under TDF's objectives and a great success for your company.

Cheers,

-- Thorsten

Ciao

Paolo

1) https://www.theregister.com/2021/02/16/libreoffice_team_working_on_port/
2) https://wiki.documentfoundation.org/Development/WASM
NOTE: the link leading to build instructions on TDF's wiki page comes up with a "Secure Connection Failed"