Draft text: an "attic" proposal

[PaoloVecchi]

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

[thb]

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:

[thb]

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

[PaoloVecchi]

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

[andreasma]

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

[PaoloVecchi]

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

[thb]

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

[Lothar_K_Becker]

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

---

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

[PaoloVecchi]

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

[PaoloVecchi]

+1 on Lothar's proposal.

Paolo

[thb]

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

[thb]

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

[PaoloVecchi]

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"

[mmeeks]

Both sentences imply that the ESC have in praxis a blocking veto, independent of the decision by a board, for both procedures.

  In general, I think it is wise when (re-)starting an engineering project to get input from the engineering community who are represented in the ESC.

  Of course, the board is not obliged to do so, and it also appoints the ESC itself. If necessary it can stack it with yes-people.

  However, I would really suggest that making engineering decisions against the advice of the leaders of the teams that do the work is something that should give very serious pause for thought & consideration by a board.

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?

  Clearly the board as the ultimately authority has many avenues to ensure its will is done: changing the policy, changing the ESC composition, etc.

  But as a general scheme of action for a peaceful and sensible approach to the problem, I think the policy as proposed is fine.

  Regards,

    Michael.

[thb]

Hi Paolo,

Paolo Vecchi wrote:

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

Again, for this to be constructive, could you please suggest concrete
changes to the proposed policy?

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

Thanks. That is good to know.

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

Let's please finally decouple this discussion, Paolo. I'll refrain
from answering in this thread, that repeatedly conflates many things.

On the above: are you asking me to remove public documentation on how
to build the WASM port, and what it is? A private answer is fine, and
then we can continue this discussion (if there's anything left to
clarify) else-thread. This really has nothing to do with the
atticisation proposal.

Cheers,

-- Thorsten

[PaoloVecchi]

Hi Thorsten,

Again, for this to be constructive, could you please suggest concrete
changes to the proposed policy?

I did propose a concrete change which sparked this conversation. Here it is in case you missed it:

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

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

That should be added in the "## De-atticization requirements. The form could be along the line of:

- If the parties involved in the development of the project are commercial entities an agreement must be signed to make clear the final scope, the benefits to the community and the eventual limitations in publishing it following TDF's objectives.

Then, as explained in the same email:
"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."

That is the same agreement we should prepare, and eventually adapt, for "atticisided", current and new projects hosted by TDF.

The rationale should have been extensively explained in the thread.

Ciao

Paolo

[Lothar_K_Becker]

About the severity to overrule the ESC we are on the same side, a board should think twice or even more if doing so.

But without clarification these two sentences set the expectations that an ESC have a blocking decision which is in fact wrong as you say by your own. And in such a case to lean on exchanging the ESC afterwards is a questionable move then, isn‘t it?

So lets discuss on Friday as it is already on the board meeting agenda. Perhaps with a little clarification as I proposed we could improve this text of the procedure.

Thanks
Lothar

[thb]

I wrote:

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

There were two concrete proposals to amend the policy, that we'll
discuss during the board call on Friday. Thus, holding the vote for
the moment.

All the best,

-- Thorsten

[thb]

Hi *,

Paolo Vecchi wrote:

That should be added in the "## De-atticization requirements. The form could
be along the line of:

- If the parties involved in the development of the project are commercial
entities an agreement must be signed to make clear the final scope, the
benefits to the community and the eventual limitations in publishing it
following TDF's objectives.

It is notoriously hard to separate commercial from non-commercial
activities. I believe putting up more barriers to entry for people
wanting to contribute to TDF projects is not smart. But lets hear
others' opinion on that on Friday.

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

That is the same agreement we should prepare, and eventually adapt, for
"atticisided", current and new projects hosted by TDF.

Instead, the board can always decide on a case-by-case basis that more
formalities are needed.

Putting this burden on everyone **up-front** and **by default** (with
the added twist that people need to prove their contribution is not
commercial), I believe is a terrible idea. TDF would be well-advised
to have fewer, not more, hurdles for code contribution.

Let's discuss on Friday, all the best,

-- Thorsten

[PaoloVecchi]

Hi Thorsten,

It is notoriously hard to separate commercial from non-commercial
activities.

It may be hard but to simplify things, as a first step, I would ask the submitter of a new project if they do it on behalf of a commercial entity or as a single contributor.

The past could give us some hints. Eg. TDF hosted a project called LOOL to which a few individuals contributed, when noticing that contributions were mostly coming from a commercial entity then that should tell us we need to look into it and evaluate risks and benefits for our community.

I believe putting up more barriers to entry for people
wanting to contribute to TDF projects is not smart.

I believe that leaving things unchecked isn't that smart either and we have seen the results.

I would not think it's smart to let me contribute to LibreOffice code unchecked as I haven't developed complex applications for the past 2 decades.
That's why even for individual contributors we have "barriers" that do automated checks and other developers that review the code submitted.

Companies would understand some "barriers" as they are used to do due diligence checks even before starting to contribute with new projects and code.
The point of those "barriers" are not only to make sure that TDF's ensure it protects LibreOffice and its community but to allow organisations to understand that by contributing they are engaging with an entity that has duties and objectives it has to fulfil.

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

That is the same agreement we should prepare, and eventually adapt, for
"atticisided", current and new projects hosted by TDF.

Instead, the board can always decide on a case-by-case basis that more
formalities are needed.

Unfortunately it seems like the board didn't realise that a big issue was brewing for quite a few years as clear rules were not set.

True that while a project is being developed most focus on making it work and successful but then there must also be some non developers that look at the situation and raise a red flag when they see eventual issues forming.

This is what I did as my second serious warning in regards to activities that I believed needed some corrections just a month after I joined the board.

Now we have a case that clearly tell us that the board should set a rule where projects that are controlled for more than 50% by a single commercial organisation need to be reviewed and we need to evaluate what risks it may pose for our community and our investments and implement eventual corrective actions which could include the drafting of a clear agreement.

Putting this burden on everyone **up-front** and **by default** (with
the added twist that people need to prove their contribution is not
commercial), I believe is a terrible idea. TDF would be well-advised
to have fewer, not more, hurdles for code contribution.

You may have missed that in my previous emails I clearly stated that the "burden" is not up-front, is not by default and people do not need to prove their contribution is not commercial.

I actually said: "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."

I've also mentioned 2 clear examples:

1) A great contributor to LibreOffice, and incidentally one of TDF's founders, presented a potentially great project in 2011. Excellent! Let's support the project, host it on our infrastructure and promote it as it seems a great contribution to LibreOffice and it will surely deliver great new features to our community.

In 2013 the contributor incorporates a company and most of the contributions started to come from there. Great! We are all very pleased that LibreOffice and its community enabled a contributor to find a business model that helps delivering more innovation but... how will at this point the need to generate revenue affect the project that we host? I suppose nobody thought of that question.

I understand that back then it was seen as a non issue because every one was working with the same goal of making LibreOffice the best Open Source office suite but not having clear rules for corporate contributions led to the current situation.

2) Another great contributor to LibreOffice, and incidentally one of TDF's founders, had another brilliant idea that has been presented as a potential alternative way to have LibreOffice in a browser back in 2015. That same great contributor, which has been merging his code to LibreOffice core, is now presenting this technology through his new company.

I'm sure that the company has fully evaluated the implications of working with TDF, which has duties in relation to it own investments and clear objectives, also in light of issue 1 above but AFAIK there is still no clear definition of the relationship between TDF, the company in question and what the community can expect to receive "for use by anyone free of charge".

I'm also sure that we don't want to find ourselves having the same arguments we had in relation to LOOL because there was no clear agreement in regards to what our community can freely use and what the company considers to be essential differentiations that allows them to be commercially successful.

I hope is now clear to you that the proposal shows that there is no intention to burden anyone with anything that doesn't go beyond protecting each parties interests and investments.

Let's discuss on Friday, all the best,

-- Thorsten

Happy to discuss that in the public part of the meeting and to get feedback from both individuals and corporate contributors.

Ciao

Paolo