Counterproposal to the "actization" of LibreOffice Online

Board Discuss
#21

Hi Marco,

thanks a lot for your engagement and your contributions to the discussion.

Hi Paolo, hi all,

IMHO what is being called "infighting" has been an excellent exercise
of transparency and exchange of point of view.

I agree, a lot of new (at least for non-board people) information came
out from this thread, although the topics I proposed in the first email,
regarding, as per subject of the thread, counterproposal(s) to the
"actization" of LibreOffice Online, were barely discussed.

I hope that the provided additional information has helped you understand why I have replied the way I did.

(original:
https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00043.html

and with my answer:
https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00057.html)

Where we stand at present, IMHO, there is nothing much TDF can do to revive the LOOL project as most of the developers involved are Collabora's employees so they now only contribute to Collabora's GitHub repositories.

Unless the valuable member of the ecosystem changes its mind, other members of our community have other proposals and/or want to help us restarting the development of LOOL I don't see many other ways forward.

It would be great to have more comments from the rest of the community about it.

I also think, and I hope those that have written here will agree, is
clear that we need fixed and strong rules for projects hosted at TDF. I
hope source-only projects will not happen again.

Thank you for supporting this proposal which is very much linked to the above issue.

I've been proposing this for quite a while and I hope the new board will support it so that we won't find ourselves in the same situation in a few years time.

All the best,

Marco

Ciao

Paolo

#22

Hi Marco,

Marco Marinello wrote:

I hope source-only projects will not happen again.

In fact, if you just count by the number of projects, almost all code
that is hosted at TDF is source-only.

There's a lot to discover and weigh here, and it's a challenge (in the
wider context) that the entire FLOSS universe is struggling with since
a number of years. I don't think we'll be able to solve that
conundrum anytime soon.

So again, I suggest we focus, and solve questions one by one. Next up
is the general attic proposal. Let's move on with that.

Cheers,

-- Thorsten

#23

Hi all,

On 17/01/2022 13:08, Thorsten Behrens wrote:

Marco Marinello wrote:


I hope source-only projects will not happen again.


In fact, if you just count by the number of projects, almost all code
that is hosted at TDF is source-only.

There's a lot to discover and weigh here, and it's a challenge (in the
wider context) that the entire FLOSS universe is struggling with since
a number of years.

There is a lot to discover and we should fully evaluate what we are hosting.

Only a short while ago I discovered that the Android Viewer still gets contributions from Michael Weghorn:

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

As it seems like there is still interest from the community we should have a look at how we can help.

While we go through the discovery process we might find other projects that we need to review and maybe publish, like the Android Viewer, and some that may require to be under a formal agreement.

Ciao

Paolo

#24

Hi Marco! Thanks for contributing.

regarding, as per subject of the thread, counterproposal(s) to the
“actization” of LibreOffice Online, were barely discussed.

My apologies for the delay Marco, I had meant to comment on your proposal but got distracted!

I also think, and I hope those that have written here will agree, is
clear that we need fixed and strong rules for projects hosted at TDF.

I suggest being very cautious with making “strong rules” in a volunteer community. While superficially they seem good at the time, our experience at TDF has been that strong rules made under challenging condition turn out to be problematic when conditions have changed, and can then be used disruptively. The more rules there are, the more games can be played with them.

I especially liked something in your first idea:

TDF should publicly endorse
this choice, stating that the project is now hosted on Github and the
development is managed by a company of the ecosystem but is – at the end
of the day – always LibreOffice Online

I think this is the seed of a great approach which we could pursue in the context of the ingredient brand we have been evolving. It would need to be designed to apply to any relevant project, not just LOOL. We are more likely to see TDF’s mission advanced by encouraging and supporting fellow community members who try to innovate than by discussing what others should do and then looking for those others!

Cheers,

Simon

#25

Hi Simon,

I suggest being very cautious with making "strong rules" in a volunteer community. While superficially they seem good at the time, our experience at TDF has been that strong rules made under challenging condition turn out to be problematic when conditions have changed, and can then be used disruptively. The more rules there are, the more games can be played with them.

I believe Marco supported my proposal because he read my various emails where I was clarifying that the rules weren't at all directed at the volunteer community in general.

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

We surely don't want to make life difficult to individual volunteers contributing to LibreOffice and related projects.

For corporate contributors, shouldn't be a big issue as they already need to go through internal reviews to see what they can contribute and how so may as well make things clear for all and protect not only our community but also the corporate contributors that may inadvertently lead the community to believe that the whole project will be available for free and for all to use while they may have also other plans for portions of it.

Then surely once some rules are in place there will always be someone in bad faith that tries to circumvent them if at the time seems more convenient for them but at least we'll have to deal with a case where we know what the community was supposed to get out of it instead of wasting months in fruitless negotiations.

At present I don't have development plans for a new commercial project based on LibreOffice but if I had one I would ask TDF to work together to shape an agreement where I state the objective of the project, my plans to make it commercially sustainable (if that is an end goal as it may not be necessary the case/needed) and what the community could expect out of it under the TDF umbrella. Then it's up to the board and the community to decide if we should invest in the project.

(The above specific example would lead to a special situation as, being a member of TDF's board of directors, it would be even more important for me to present a clear project and let the rest of the board decide about it, without me or my business partners ever intervening, to avoid being perceived as more equal than others)

Wouldn't any company find it not just natural but essential to do that to protect their long term investments and show that it can be trusted by the community?

Ciao

Paolo

#26

Hi Simon,

This has led to progress grinding to a halt through mistrust....
If TDF is to satisfy its mission this has to stop. The new Board has a huge opportunity and responsibility to put all this behind them and lead positively. It must shun divisiveness

  Thanks for your apt and helpful analysis & reflection on the way ahead. As a counter-point to some other perspectives: I am really grateful that you take the time to intervene positively in our community, to provide the benefit of your wide experience, as well as this sort of incisive and clear perspective that helps to cut through the clouds of confusion.

  I too hope the new board will be able to start afresh with new vigor on the task of making LibreOffice a welcoming and pleasant place to contribute for all.

  Thanks,

    Michael.

#27

Another perspective on that: "You rushed into the board with proposals
that would allow non-contributors to start competing with one of the
major contributors, by making use of the LibreOffice brand."
And .. then you were surprised that it wasn't welcomed with applause :slight_smile:

Cor

#28

Another perspective on that: "You rushed into the board with proposals
that would allow non-contributors to start competing with one of the
major contributors, by making use of the LibreOffice brand."
And .. then you were surprised that it wasn't welcomed with applause :slight_smile:

Cor

#29

Hi,

only for background information I recommend to read:
blog.documentfoundation.org/blog/2015/01/27/the-document-foundation-announces-the-results-of-the-android-tender/

and e.g. the annual report 2013 of TDF, page 9/10

Regards,
Andreas

#30

Hi *,

discussions that don't make progress towards agreement are a waste of
everyone's time.

If this is about personal gripes, the best way to sort things out is a
phone or video call.

Otherwise, let's please circle back to the topic at hand (atticisation
of LibreOffice Online, and what to do about it - arguing over past
events ain't gonna get us anywhere here).

Cheers,

-- Thorsten

#31

Hi Simon,

Il 17/01/22 18:15, Simon Phipps ha scritto:

I especially liked something in your first idea:

TDF should publicly endorse
this choice, stating that the project is now hosted on Github and the
development is managed by a company of the ecosystem but is – at the end
of the day – always LibreOffice Online

I think this is the seed of a great approach which we could pursue in the context of the ingredient brand we have been evolving. It would need to be designed to apply to any relevant project, not just LOOL. We are more likely to see TDF’s mission advanced by encouraging and supporting fellow community members who try to innovate than by discussing what others should do and then looking for those others!

beware that the four bullet points I mentioned in the first email are not intended to be split.

#32

Hi Thorsten,

Hi *,

discussions that don't make progress towards agreement are a waste of
everyone's time.

I agree.

I proposed an agreement but nobody picked up.

If this is about personal gripes, the best way to sort things out is a
phone or video call.

Otherwise, let's please circle back to the topic at hand (atticisation
of LibreOffice Online, and what to do about it - arguing over past
events ain't gonna get us anywhere here).

No. I started a new thread, as requested, not to be confused with *your*
thread regarding the actization proposal.

If you want replies on that, please ask for them in your own thread.

-Marco

#33

Hi Cor,

I'm sorry to say it in public but I'm honestly appalled by your comment which shows your insensitivity to the matter that is being discussed and is providing an example of how disinformation works.

Maybe you missed the point here.

Some of us actually worked hard to prepare the ground to help others
trying to act in a fair and balanced way but after months of work and
negotiations someone decided that solidarity wasn't a priority.

Another perspective on that: "You rushed into the board with proposals
that would allow non-contributors to start competing with one of the
major contributors, by making use of the LibreOffice brand."
And .. then you were surprised that it wasn't welcomed with applause :slight_smile:

Cor

I would suggest you to read the directors emails and RedMine tickets about LOOL since March 2020 to discover that the most ethical and professional thing you could do is to apologise to the members of the community for your unfortunate comment.

Ciao

Paolo

#34

Hi Marco!

On Tue, Jan 18, 2022 at 9:06 AM Marco Marinello <lists@marcomarinello.it> wrote:

Hi Simon,

Il 17/01/22 18:15, Simon Phipps ha scritto:

I especially liked something in your first idea:

TDF should publicly endorse
this choice, stating that the project is now hosted on Github and the
development is managed by a company of the ecosystem but is – at the end
of the day – always LibreOffice Online

I think this is the seed of a great approach which we could pursue in the context of the ingredient brand we have been evolving. It would need to be designed to apply to any relevant project, not just LOOL. We are more likely to see TDF’s mission advanced by encouraging and supporting fellow community members who try to innovate than by discussing what others should do and then looking for those others!

beware that the four bullet points I mentioned in the first email are not intended to be split.

Thanks for the comment - I do understand, it is irritating when people cherry-pick a larger comment. Neverless, it’s for a reason here. The other three bullets were specifically about LibreOffice Online and I agree with Thorsten and others that it’s best to separate the attic-isation process from the specific use case, so I have focussed on your first bullet which I believe could form the basis for a general case.

Cheers!

Simon

–

#35

Hi Marco,

Marco Marinello wrote:

No. I started a new thread, as requested, not to be confused with *your*
thread regarding the actization proposal.

Indeed, sorry for the imprecise wording. Counter-proposal discussion
here. :wink:

Cheers,

-- Thorsten

#36

Hi all,

On 18/01/2022 11:33, Simon Phipps wrote:

Hi Marco!

On Tue, Jan 18, 2022 at 9:06 AM Marco Marinello <lists@marcomarinello.it> wrote:

Hi Simon,

Il 17/01/22 18:15, Simon Phipps ha scritto:

I especially liked something in your first idea:

TDF should publicly endorse
this choice, stating that the project is now hosted on Github and the
development is managed by a company of the ecosystem but is – at the end
of the day – always LibreOffice Online

I think this is the seed of a great approach which we could pursue in the context of the ingredient brand we have been evolving. It would need to be designed to apply to any relevant project, not just LOOL. We are more likely to see TDF’s mission advanced by encouraging and supporting fellow community members who try to innovate than by discussing what others should do and then looking for those others!

beware that the four bullet points I mentioned in the first email are not intended to be split.

Thanks for the comment - I do understand, it is irritating when people cherry-pick a larger comment. Neverless, it’s for a reason here. The other three bullets were specifically about LibreOffice Online and I agree with Thorsten and others that it’s best to separate the attic-isation process from the specific use case, so I have focussed on your first bullet which I believe could form the basis for a general case.

I would say that the 4 bullet points are linked to the atticisation discussion as are related to the standard process of de-atticisation and for new projects led by commercial contributors.

As in this case, members of the community are wondering what they are getting back from the investment that they and TDF made on LOOL and at present we are unable to offer answers as we didn’t clarify the process and the rules in advance.

Is there any other suggestions on how to deliver LOOL to our members of the community?

Ciao

Paolo

–
Paolo Vecchi - Deputy Member of the Board of Directors
The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE
Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts
Legal details: https://www.documentfoundation.org/imprint

#37

Hi,

Personally, I'm not interested in playing zero-sum games (taking
development away from the ecosystem, and re-patriating it into
TDF). Instead, we need to work much more on creating win-win setups,
and supplementing each other.

TDF must make its choices as corporate contributors have to make theirs.

Fortunately corporate contributors have business models that allows them to grow without counting on TDF tenders so, while tenders will be still made to deal with complex development that other contributors are unable to tackle, we need to become capable of managing some of the project so that we are not always dependent on third parties that may not find a specific project fun or commercially interesting.

That sounds like a good approach to me.

There's definitely things that TDF can do much better than any
ecosystem company. There's also definitely things that ecosystem
companies are likely better suited for, than TDF. The same is true for
our volunteer community

True and that's why there is room for all to have fun and participate to make LibreOffice and related project great.

+1

One obvious area where there's very little commercial incentive to do
things is a11y. At the same time, that would be something very
charitable to fund & further! If there's budget for funding internal
development, a11y would be very high on my list of topics to focus on.

That's something that has been on the list to do for a long time.
I haven't noticed anything related to it in the ESC ranking or maybe it's simply not marked clearly enough.

If it isn't there then we should ask the ESC to propose fixes in that regards?

I think one point here is that doing a proper proposal for a tender requires having a rough understanding of the subject to be tendered, be able to define a reasonable scope and also give a rough estimation of how much work that will be. In other words, it either requires somebody who already has an overview and a good idea what to suggest, or somebody investing time to come up with something.

Regarding a11y, as somebody who started looking into that topic, but without a clear idea on anything more specific for tendering, I had created this suggestion for tendering some (still to be selected) bugs from the a11y meta bug in Bugzilla: [1]

I must admit that I wasn't too disappointed that the suggestion didn't make it into the top list in the ESC voting. Given that more time would have been required to further analyze bugs in question and select a reasonable subset for the tendering, I am not sure whether the overhead (on all involved sides) would much outweigh the effort, or whether it makes more sense for me to spend time in trying to improve a11y myself.

I think tendering works best for items where the scope is clear beforehand, while here it would be much easier to say:
"Here is a ranked list of a11y issues, spend X days on fixing as many as you can.", which to my knowledge doesn't really fit the tender model particularly well.

Maybe others have better ideas on potential a11y topics to tender or there are better ways to handle this, that's just the story behind the above-mentioned proposal... (which is the one clearly related to a11y in the list of proposals that ESC was voting on, [2]).

Best regards,
Michael

[1] https://wiki.documentfoundation.org/Development/Budget2022#Fix_accessibility_issues
[2] https://wiki.documentfoundation.org/Development/Budget2022

#38

Hi Michael,

thanks for your email, your support and contributions.

Your comments regarding the complexity of proposing "tender ready" specifications vs just doing it is pretty much in line with my experience as sometimes it's easier/faster for me to do things than explaining what to do to someone that is not already in the loop.

With A11y could and should be different as it's something on which we should actively deal with but at present we may not have the necessary resources to review all the proposals so some may surface on the ESC ranking list while others may not.

The proposal I made to employ developers should help also in having the internal competences necessary to interact with specialists like you which can tell us "I'm happy to deal with those specific A11y related bugs but I don't have enough time to deal with these others, could you help?" and then a decision can be made to help fixing those bugs directly or help with the drafting of the technical specifications required for eventual tenders.

That would not mean that anyone could ask to help them fixing their bugs, or we'll run out of resources quite fast, but specific general interest areas like a11y should be given a priority as it's one of those areas where we can make a real difference for people.

It could take a while to get new developers on-board but in the meantime do tell us when you are able to refine the proposal as it may then be picked up by ESC or a member of staff for further evaluation.

Ciao

Paolo

#39

Hi Paolo,

It could take a while to get new developers on-board but in the meantime do tell us when you are able to refine the proposal as it may then be picked up by ESC or a member of staff for further evaluation.

thanks! My personal plan is to continue looking into a11y as I find time and I'm of good hope this will give me enough insights to come up with a refined proposal to be considered in the ESC voting for next year's tenders.

Michael

#40

Hi Michael!

On Wed, Jan 19, 2022 at 10:34 AM Michael Weghorn <m.weghorn@posteo.de> wrote:

I think tendering works best for items where the scope is clear
beforehand, while here it would be much easier to say:
“Here is a ranked list of a11y issues, spend X days on fixing as many as
you can.”, which to my knowledge doesn’t really fit the tender model
particularly well.

Maybe others have better ideas on potential a11y topics to tender or
there are better ways to handle this, that’s just the story behind the
above-mentioned proposal… (which is the one clearly related to a11y in
the list of proposals that ESC was voting on, [2]).

You are right that TDF’s current tendering approach is designed for well-understood tasks that the ESC members know is needed but do not want to do. I too was always disappointed how few of the accessibility tasks on the list fell into that category while I was on the Board. It seemed that things needed sufficient specialist experience that writing a satisfactory tender was sometimes the first task that needed doing!

Thus (and as you imply) the best approach might be for TDF to have an accessibility specialist define the work and then execute on it, instead of having the ESC do so directly. While this doesn’t fit today’s tendering process well, maybe we need to retain an accessibility expert, give them a budget and have them specify tasks (with ESC agreement) and then either perform them, lead a team performing them or select a contractor to perform them.

Cheers,

Simon

–

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.