Draft text: an "attic" proposal

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

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

---

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