Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs

Hi Michael,

Thanks for summarizing my thoughts on your email (as far as I can understand from your message, we share exactly the same ideas).

I agree here that there are several areas like CJK and CTL (and not only for bug fixes) or ally that should deserve much more love from TDF and I'm sure our donors would be happy that we invest in this area too.

That would help also to grow this part of the community, which is very complicated to achieve when our version is difficult to use.

Totally agree.

That sounds like a good approach to me, in particular for areas where there's currently no specific interest from ecosystem companies or volunteers and that are unsuitable for tenders, but considered important for the community.
I would see that in line with how TDF already employs non-developer staff to take care of other important aspects not (sufficiently) covered by other contributors.

Totally agree.

I have the impression that a fundamentally important question is what the purpose/task of TDF-internal developers would be.

Yes, but it looks like the discussion is blocked one step before reaching a consensus on this very simple point. If the discussion stays as such, I have to say that I don't feel I am represented - as a TDF Member - by any member of the just elected board of directors (of course, those who have expressed their opinions).

If larger topics that TDF-internal developers were to work on were first agreed on in the bodies where ecosystem companies are present as well (like ESC and/or the board), my expectation would be that the development work from different sides should work together nicely, rather than creating any kind of destructive competition.
(Ecosystem company products profit from contributions made to LibreOffice as well, and having a better overall product should in my opinion also increase the range of potentially interested customers in general.)

Totally agree.

Of course, in case the main intention were for TDF to provide more business-like services (like an LTS version or creating an impression of "donate a certain amount of money and your pet bug will be fixed"), I see very well how that might interfere significantly with the business model of ecosystem companies.

Totally agree. But I don't see the issue, as ESC and BoD members could easily stop any project before it starts, when there is a potential risk of conflict. AFAIK, major development activities are scrutinized by both bodies, as they are ranked in order of importance, suggested, approved and transformed to tenders, or not considered for tendering.

Development activities which are not considered for tendering, or just ignored, could probably be developed by TDF without creating disruptions (or even discussions). I am rather sure that in 7 million lines of code (plus the open bugs) there are enough challenges for everyone.

Of course, given my complete lack of understanding of development, is too easy to find a technical angle to disprove what I just wrote, but it would also be disproving what many of the contributors - the community - think, and this would confirm my personal belief that TDF BoD does not represent the community as a whole, but only a portion of it.

Assuming members in the involved LibreOffice/TDF bodies found a way to work together constructively, my current impression is that this approach could be for the benefit of all.

Again, totally agree. Best regards, Italo

Hi Andreas,

Andreas Mantke píše v St 09. 02. 2022 v 19:58 +0100:

once I read this sentences the first time, I thought I was in a
different film in 2010. But maybe I didn't understand the situation
in OOo project at that time.

I may be wrong, it is a long time ago, but from what I remember, the
problem was not the domination per se [though please don't understand
me as supporting domination ;-)], but the unwillingness to communicate
& seek consensus how to improve the situation for contributors.

[This is also why I insist that "community" means the contributors -
the situation was perfectly fine for the users; they were getting their
builds for free & were happy.]

At that time:

* There was the CWS system that was forcing contributors to go through
  a complicated process even for the simplest fixes

    + unless you have found a friendly internal engineer who was kind
      enough to include your patch into their CWS
    + not to mention that the access to CWS was restricted for the
      outside for a long time in the first place

* CVS was a disaster for version control

    + and I've created a working, usable git import

    + yet Mercurial was favored, even though not ready for the
      OOo size
    + so the conversion was postponed and OOo was converted to
      Subversion as a temporary measure
    + then 2 years later converted to Mercurial
        - with a terrible penalty for the non-internal contributors,
          because Mercurial had to download 500MB of metadata for each
          branch [which might be OK'ish these days - but this was
          11 years ago and more]
    + only to be converted to Subversion again [at Apache]
    + and then finally to git

* the localization went through the .sdf files

    + I was not involved in this, so I have only vague memories it was
      a terrible pain for the l10n community

* the build system was a disaster by itself due to build.pl & dmake

    + and worse, the company had a different, internal one
        - so no interest in improving it for the contributors
    + but at least Bjoern has invented the gbuild while being an
      internal engineer, regardless of the internal pushback

        - he's a hero; and I have fond memories of other heroes who
          helped to make the contributing easier
        - still - the general approach of the company was to make
          the contribution hard.

* I'm sure there's more; but luckily I forgot :slight_smile:

So if you see any sign of an ecosystem company trying to make
contributing harder (like the above), please do shout - contributing
must be as easy as possible for everybody who wants to contribute!

All the best,
Kendy

Hi all,

Hi *,

Paolo Vecchi wrote:

It is important to understand that "community" means "contributors"; as
opposed to "users". "Users" are not part of the "community", until
they start contributing; via code, QA, translations, marketing under
the TDF umbrella, etc.

I'm sorry but I have to strongly disagree with your statement.

In fact Paolo wasn't disagreeing so much, just stressed that users
should be encouraged to become contributors.

I was actually disagreeing with a statement saying that users are not part of the community.

On the statement per se, that we (as in, TDF, and its board in
particular) predominantly need to care and listen to our contributors,
I would believe there's hardly any disagreement in the community.

Sure that we have to listen but that doesn't mean we have to do all what contributors say as some ideas passionately promoted by some contributors within the board turned out to be suboptimal and cost months of work and arguing.

I think that, as part of the on-boarding process, we should include a
session hosted by Florian and Mike Schinagl that clarifies to all why TDF
has been created, what its role is and what we should all keep in mind while
performing our duties as members of the board.

While it is important for the new board to know what TDF can, and
cannot do (and in fact Paolo will find an email in his inbox, where
Florian is announcing exactly such an onboarding), the role of the
board is the opposite - to lead, within the limits of the charitable
laws, where the community needs us to go.

From the exchanges I've seen it seems like it's really important to make clear what TDF is and what was set up to do.

Looking at the reasons why TDF was started almost 12 years ago
shouldn't be the sole guiding principle. Living in the past is not a
good board strategy.

While we should clearly evolve and grow, TDF has been setup for a specific reason and it has been incorporated on purpose as a Foundation (Stiftung) to preserve its guiding principles. It seems like it's more important than ever to remind ourselves of that and have a nice session with Florian and Mike Schinagl to tell us more about it.

The feedback we are receiving and the legal consultations we had confirm that employing developers to contribute directly to LibreOffice fits perfectly with TDF's purpose and objectives and allows to do more for our community.

Paraphrasing slightly what someone said quite a few years ago "Ask not what your community can do for you - ask what you can do for your community" so TDF should lead and do before expecting others to do.

I'll not comment on the quotes out of a press article, shown without
much context and lacking a link to the original source (which would be
good practice). The article
(https://www.theregister.com/2020/07/16/libreoffice_ecosystem_beyond_utterly_broken/)
was written in the context of the LOOL and MarComm plan discussions,
and the fallout around the LibreOffice Personal / LibreOffice
Community arguments. I recommend reading it in full.

I did not link the article on purpose as it really doesn't make the two person involved look good at all, it denigrates TDF, it reports misconceptions that have been clarified, it states that TDF cannot do things that are actually in the statutes and in general did not reflect the thoughts of the majority of the board.

It nearly got a quite strong public answer but some preferred to avoid it.

Finally, on the apparent contradiction between what Andreas (lawyer,
TDF founder, long-term board member) and Paolo state on what TDF is
permitted to do: this is part of an ongoing discussion with various
experts.

I would much prefer not discussing difficult legal matters on a public
list.

They are not difficult legal matters, they are just basic legal consultations that gave us confirmation that we can do much more that previously thought.

I'm quite sure that Andreas (lawyer, TDF founder, long-term board member) would agree with Paolo (nothing much apparently) if he were a board member in this term and participated to the legal consultations. There is also no contradiction as Andreas summarised well the final scope for the employment of the developers which is the same scope for our tenders.

Cheers,

-- Thorsten

Ciao

Paolo

Hi Italo,

Italo Vignoli píše v Čt 10. 02. 2022 v 16:31 +0100:

Yes, but it looks like the discussion is blocked one step before
reaching a consensus on this very simple point. If the discussion
stays
as such, I have to say that I don't feel I am represented - as a TDF
Member - by any member of the just elected board of directors (of
course, those who have expressed their opinions).

This is very sad to hear :frowning: I am afraid this is a product of the
unilateral & vigorous presentation of hiring developers as the only way
forward, regardless of what the ecosystem companies have to say.

> Of course, in case the main intention were for TDF to provide more
> business-like services (like an LTS version or creating an
> impression of
> "donate a certain amount of money and your pet bug will be fixed"),
> I
> see very well how that might interfere significantly with the
> business
> model of ecosystem companies.

Totally agree. But I don't see the issue, as ESC and BoD members
could
easily stop any project before it starts, when there is a potential
risk
of conflict. AFAIK, major development activities are scrutinized by
both
bodies, as they are ranked in order of importance, suggested,
approved
and transformed to tenders, or not considered for tendering.

If assurances like these were part of the proposal, I am sure it would
be much easier to discuss - at least for me personally. Thank you for
pointing this out!

And also Michael (W.) - thank you for your great summary!

All the best,
Kendy

Hi Kendy,

Hi Italo,

Italo Vignoli píše v Čt 10. 02. 2022 v 16:31 +0100:

Yes, but it looks like the discussion is blocked one step before
reaching a consensus on this very simple point. If the discussion
stays
as such, I have to say that I don't feel I am represented - as a TDF
Member - by any member of the just elected board of directors (of
course, those who have expressed their opinions).

This is very sad to hear :frowning: I am afraid this is a product of the
unilateral & vigorous presentation of hiring developers as the only way
forward, regardless of what the ecosystem companies have to say.

And I feel the same. Hiring developers is not the only way forward, it's one of them. We, as members, knows the ecosystem companies have needs and I (for myself) understand perfectly the market pressure. But here, as a member of TDF, we contribute with the ecosystem companies, not for them.

Of course, in case the main intention were for TDF to provide more
business-like services (like an LTS version or creating an
impression of
"donate a certain amount of money and your pet bug will be fixed"),
I
see very well how that might interfere significantly with the
business
model of ecosystem companies.

Totally agree. But I don't see the issue, as ESC and BoD members
could
easily stop any project before it starts, when there is a potential
risk
of conflict. AFAIK, major development activities are scrutinized by
both
bodies, as they are ranked in order of importance, suggested,
approved
and transformed to tenders, or not considered for tendering.

If assurances like these were part of the proposal, I am sure it would
be much easier to discuss - at least for me personally. Thank you for
pointing this out!

Their is even no written proposal at the moment, but only a discussion on the pros and cons and what it could bring to the project. But it seems impossible to discuss because the ecosystem companies won't allow it.
I'm sorry, I already wrote in a previous thread that TDF has failed to have a balanced position during the pandemic, caring of the charitable part of its duty, I hope we will not continue in that way because, again as a member, this is not how I feel represented.

And also Michael (W.) - thank you for your great summary!

yes, thanks Michael to have broaden my proposal and my ideas.
Cheers
Sophie

Hi Italo,

I have the impression that a fundamentally important question is what the purpose/task of TDF-internal developers would be.

Yes, but it looks like the discussion is blocked one step before reaching a consensus on this very simple point.

  It seems reasonable to explore what people should be hired to do - before hiring them =) That has the benefit of working out what skills are needed in the job advert and/or interview process for example. The 'discussion' here - I would not see as blocked, but problematic see later.

  There is a huge amount of need around LibreOffice development. It is easy to find a hundred different "top priority" issues each dear to the heart of a user, each user convinced that if only we had eg. 'Reveal Codes' in writer everyone would use LibreOffice.

  As for no-one listening to users - I spend my life listening to customers & partners & users - and trying to do what they want. Anyone jealous of some big pool of unconstrained money / development power in corporate contributors is mistaken. Nevertheless I still get impassioned complaints of why Collabora did X and not Y from intelligent, articulate, engaged community members.

  TDF in contrast while it has many constraints on what it can do - has few time constraints on its spending, which frees it to do more strategic long-term work. Thus it can invest more efficiently with some multiplying factor - via the educational / mentoring role into specific areas. I for one would support some targeted a11y / CTL mentoring - those seem like good areas that Sophie outlines - and ones where we can perhaps shine & grow the contributor community.

  However - there is a cliff-face of need here. It seems totally sensible to suggest that hiring internal developers without any plan of working out what they should work on seems premature. Part of why mentors are attractive is that their agenda is partly lead by what volunteers want to do. That can be steered of course by creating new easy-hacks / tasks / projects in directions they want to go - and/or learning on the job themselves by hacking on things.

  For myself, I would want to see some sensible mechanism that includes the views of those who contribute via donations as to what is important. Then again if we dedicate donations solely in-line with what donors want - I suspect certain key functions: admin, marketing might not get the attention they deserve: so again, there is no obvious solution here beyond the board getting wide input and deciding (as they do now).

If the discussion stays as such, I have to say that I don't feel I
am represented - as a TDF Member - by any member of the just elected
board of directors (of course, those who have expressed their opinions).

and:

> Of course, given my complete lack of understanding of development, is
> too easy to find a technical angle to disprove what I just wrote, but
> it would also be disproving what many of the contributors - the
> community - think, and this would confirm my personal belief that
> TDF BoD does not represent the community as a whole, but only a
> portion of it.

  It would be deeply unfortunate if the above was read as questioning the legitimacy and composition of the new board - and that before they have been seated and/or taken a single decision. It would be good to clarify that reading.

  I would note that everyone who stood for the board was elected - and perhaps acknowledging the complexity of what might look like simple decisions from the outside - is real & not imaginary. I wish them the best as they try to find the local maxima in some multi-dimensional problem space.

  As for finding new board members on the list to express a view you feel represents you: these long threads packed with trolling and misrepresentation on board-discuss are not a great way to interact I suspect. Why would a new board member want to engage in them while they find their feet ? Lets not be quick to preemptively despair of sensible decision making.

But I don't see the issue, as ESC and BoD members could easily stop
any project before it starts, when there is a potential risk of conflict.

  These days the we have created rules to exclude people from such decision making - which has the potential to significantly exacerbate conflict and division I feel.

  But you're right, in theory the BoD is sovereign.

  Regards,

    Michael.

Hi Paolo,

Paolo Vecchi wrote:

I was actually disagreeing with a statement saying that users are not part
of the community.

Then we have to agree to disagree.

Sole users (i.e. without contributing anything to the community) are
to my mind never part of a FLOSS project community.

The rest of your answer are mostly unproductive jabs at various
people, that I refuse to interact with.

Cheers,

-- Thorsten

Hi Italo,

thanks for your reply.

Of course, in case the main intention were for TDF to provide more business-like services (like an LTS version or creating an impression of "donate a certain amount of money and your pet bug will be fixed"), I see very well how that might interfere significantly with the business model of ecosystem companies.

Totally agree. But I don't see the issue, as ESC and BoD members could easily stop any project before it starts, when there is a potential risk of conflict. AFAIK, major development activities are scrutinized by both bodies, as they are ranked in order of importance, suggested, approved and transformed to tenders, or not considered for tendering.

I totally agree, extending that process to cover significant tasks that internal developers would work on may be a solution.

Development activities which are not considered for tendering, or just ignored, could probably be developed by TDF without creating disruptions (or even discussions).

To double-check nobody is "secretly" working on that as well or is planning to do so, discussing/mentioning larger items first certainly won't hurt.
(But that doesn't only apply for work done by TDF developers; e.g. the weekly ESC call already has a "What’s cooking" section where that would fit well.)

I am rather sure that in 7 million lines of code (plus the open bugs) there are enough challenges for everyone.

Definitely!

Of course, given my complete lack of understanding of development, is too easy to find a technical angle to disprove what I just wrote, [...]

Best regards,
Michael

Hi *,

with the lively discussion ensuing here, it is perhaps worth sharing
my position ahead of the board call tomorrow:

Paolo Vecchi wrote:

Enable TDF to contribute more code to LibreOffice with in-house developers
to address our donors specific needs

I think it is worth considering, whether TDF should employ dedicated
developers. I'm not in general against it.

It is putting the cart in front of the horse though, to start with:

* we want TDF to contribute more code to LibreOffice

and then follow with

* therefore we must employ two developers

I believe it is more productive to start thinking about what we want
to achieve, in order to fulfill our mission. It is therefore
encouraging to read some good thoughts about that (RTL/CTL, a11y, and
other under-developed areas with little ecosystem contributions).

The board can then ponder what is the best way to achieve those goals,
relative to other demands. It is possible, but by no means certain,
that actually hiring specialised staff is indeed the most economic way
forward (e.g. for an area like a11y).

It should be noted though, also to manage expectations, that mastering
even a small area in LibreOffice takes many years to learn. So hiring
for a role has long-term implications then on which kind of tasks,
features or bugfixes can be done in-house.

Cheers,

-- Thorsten

Hi Thorsten,

Sole users (i.e. without contributing anything to the community) are
to my mind never part of a FLOSS project community.

Just to mention it, the KDE Code of Conduct [1] contains this:

Our community is made up of several groups of individuals and
organizations which can roughly be divided into two groups:

* Contributors, or those who add value to the project through
  improving KDE software and its services
* Users, or those who add value to the project through their
  support as consumers of KDE software

and I remember that the importance of users was emphasized at some in-person event I attended (probably Akademy) as well.

Of course, one could try to make a distinction between users that contribute something back and those who do not, but I don't know whether that would be particularly helpful, or even easy.
(E.g. is a user that only uses the software for themselves not part of the community, but one who recommends it to others is, because they "spread the word"? - And maybe one of those starts getting active in some "official" area in the LibreOffice project, or migrates their company from a proprietary office suite to an LTS version from an ecosystem company,...)

Best regards,
Michael

[1] https://kde.org/code-of-conduct/

I am not questioning the legitimacy and composition of the board, I am questioning the behaviour of its members.

Hi Thorsten!

Thanks for your positive contribution which I agree with completely (although I do have a comment, see below).

On Thu, Feb 10, 2022 at 5:09 PM Thorsten Behrens <thb@documentfoundation.org> wrote:

Hi *,

with the lively discussion ensuing here, it is perhaps worth sharing
my position ahead of the board call tomorrow:

Paolo Vecchi wrote:

Enable TDF to contribute more code to LibreOffice with in-house developers
to address our donors specific needs

I think it is worth considering, whether TDF should employ dedicated
developers. I’m not in general against it.

It is putting the cart in front of the horse though, to start with:

  • we want TDF to contribute more code to LibreOffice

and then follow with

  • therefore we must employ two developers

I believe it is more productive to start thinking about what we want
to achieve, in order to fulfill our mission. It is therefore
encouraging to read some good thoughts about that (RTL/CTL, a11y, and
other under-developed areas with little ecosystem contributions).

The board can then ponder what is the best way to achieve those goals,
relative to other demands. It is possible, but by no means certain,
that actually hiring specialised staff is indeed the most economic way
forward (e.g. for an area like a11y).

For Accessibility, my preference would be to tender for a specialist organisation to either triage accessibility bugs or implement capabilities for a fixed period followed by a performance review and re-tendering (possibly for a longer period). By doing that we would avoid having to also develop in-house engineering management and product accessibility expertise. This is beyond the current tendering practice in that we would ask the successful applicant to also direct and design their work.

It should be noted though, also to manage expectations, that mastering
even a small area in LibreOffice takes many years to learn. So hiring
for a role has long-term implications then on which kind of tasks,
features or bugfixes can be done in-house.

Cheers,

– Thorsten

I disagree. This is the result of BoD members pointing fingers to each other without even trying to start a discussion and reach consensus.

I would have applauded a reaction to the message that has opened this thread which was integrating the proposal with some additional thoughts and suggestions, to specify which could be the areas where a developer hired by TDF could work for the common benefit of the project.

Sorry, but I haven't seen anything like this so far.

Hi Sophie, hi all,

And I feel the same. Hiring developers is not the only way forward,
it's one of them. We, as members, knows the ecosystem companies have
needs and I (for myself) understand perfectly the market pressure. But
here, as a member of TDF, we contribute with the ecosystem companies,
not for them.

I agree. you simply wrote what I was thinking to add. thanks.

Their is even no written proposal at the moment, but only a discussion
on the pros and cons and what it could bring to the project. But it
seems impossible to discuss because the ecosystem companies won't
allow it.
I'm sorry, I already wrote in a previous thread that TDF has failed to
have a balanced position during the pandemic, caring of the charitable
part of its duty, I hope we will not continue in that way because,
again as a member, this is not how I feel represented.

...and I fully agree again.

Cheers,
Marina

Hi Michael, all,

  It seems reasonable to explore what people should be hired to do -
before hiring them =) That has the benefit of working out what skills
are needed in the job advert and/or interview process for example. The
'discussion' here - I would not see as blocked, but problematic see
later.

I don't think the discussion is even at this point. Reading the messages I can only see some board members just questioning every single commas used by the others, fighting in public without even realising that all this drama is only bringing away community members interested to share more ideas and proposals for solving this deadlock we are experiencing.

  As for no-one listening to users - I spend my life listening to
customers & partners & users - and trying to do what they want. Anyone
jealous of some big pool of unconstrained money / development power in
corporate contributors is mistaken. Nevertheless I still get
impassioned complaints of why Collabora did X and not Y from
intelligent, articulate, engaged community members.

...and again, it's not always "Collabora vs others" discussion. There's a discussion, not even a concrete proposal on how TDF could contribute more code, there are other opinions shared and an attempt to really act like a community that tries to shape its own projects. Can we stop to reduce every possible discussion to the "ecosystem vs all the others"?

We are all part of the same project, many of us were part of it from day 0, some officially, others unofficially, but we were all there.
Can we stop to act like kids and try to really cooperate like adults?

  As for finding new board members on the list to express a view you
feel represents you: these long threads packed with trolling and
misrepresentation on board-discuss are not a great way to interact I
suspect. Why would a new board member want to engage in them while
they find their feet ? Lets not be quick to preemptively despair of
sensible decision making.

This way to act is not only affecting the board members. It has a negative impact on the full community and on all the potential new contributors that are just scared away by all those dramas.

  These days the we have created rules to exclude people from such
decision making - which has the potential to significantly exacerbate
conflict and division I feel.

...talking about trolling, I was indeed missing yet another comment against the CoI policy.

Cheers,
Marina

Hi Michael (W.),

I absolutely agree with what you wrote.
My deepest thank you for being so open-minded!

Of course, in case the main intention were for TDF to provide more business-like services (like an LTS version or creating an impression of "donate a certain amount of money and your pet bug will be fixed"), I see very well how that might interfere significantly with the business model of ecosystem companies.

Totally agree. But I don't see the issue, as ESC and BoD members could easily stop any project before it starts, when there is a potential risk of conflict. AFAIK, major development activities are scrutinized by both bodies, as they are ranked in order of importance, suggested, approved and transformed to tenders, or not considered for tendering.

I totally agree, extending that process to cover significant tasks
that internal developers would work on may be a solution.

Development activities which are not considered for tendering, or just ignored, could probably be developed by TDF without creating disruptions (or even discussions).

To double-check nobody is "secretly" working on that as well or is
planning to do so, discussing/mentioning larger items first certainly
won't hurt.
(But that doesn't only apply for work done by TDF developers; e.g. the
weekly ESC call already has a "What’s cooking" section where that
would fit well.)

I am rather sure that in 7 million lines of code (plus the open bugs) there are enough challenges for everyone.

Definitely!

Of course, given my complete lack of understanding of development, is too easy to find a technical angle to disprove what I just wrote, [...]

Thanks again,
Marina

Hi Thorsten, all,

It is putting the cart in front of the horse though, to start with:

* we want TDF to contribute more code to LibreOffice

and then follow with

* therefore we must employ two developers

Whether or not that's an adequate summary of Paolo's proposal is not up to me to judge, but...

I believe it is more productive to start thinking about what we want
to achieve, in order to fulfill our mission. It is therefore
encouraging to read some good thoughts about that (RTL/CTL, a11y, and
other under-developed areas with little ecosystem contributions).

The board can then ponder what is the best way to achieve those goals,
relative to other demands. It is possible, but by no means certain,
that actually hiring specialised staff is indeed the most economic way
forward (e.g. for an area like a11y).

... I completely agree that having a clear goal and considering the pros and cons of different approaches to get there before taking a decision definitely makes sense.

Best regards,
Michael

Hi all!

Their is even no written proposal at the moment, but only a discussion
on the pros and cons and what it could bring to the project. But it
seems impossible to discuss because the ecosystem companies won’t allow it.

And yet it seems here we are discussing it! It’s fun to do things that aren’t allowed :slight_smile:

The OP did indeed not make a written proposal, but there still a Board Motion to hire two developers despite this. Personally (and I don’t work for any “ecosystem company” or TDF or belong to a local group) I don’t feel either the OP’s proposal or any other response commenting on it here represents me.

I volunteered here because I think LibreOffice is massively important to the free/open source software movement, as well as to the freedom of citizens globally, including especially non-English-speaking and differently-able people. I want to see TDF spend its money in the service of that global movement to the maximum extent it has allowed itself to in its bylaws. I especially believe TDF needs to act to allow individuals to avoid the need to use centralised services for making, reading and sharing documents of all kinds.

Right now TDF is not doing so, despite being given millions of euros by end-users. My concern is thus not with the desire to spend donated money on donor problems - we should do more of it, and better, and not let any corporate interest stop us. My concern is with accepting as agreed the proposal that TDF should hire developers and afterwards address what they would do, how and under whose supervision. I can see significant risks from doing so and I do not want in any way to endorse that premature proposal.

So sure, let’s have a pros and cons discussion. I have already chipped in positively elsewhere and look forward to being able to amplify other positive ideas, But first let’s take the political and premature motion off the table so that no-one feels their contribution is either supporting or opposing it. It has led to an essential discussion becoming yet another divisive fight and that’s got to stop.

Cheers!

Simon

Hi Michael, all,

There is a huge amount of need around LibreOffice development. It is easy to find a hundred different "top priority" issues each dear to the heart of a user, each user convinced that if only we had eg. 'Reveal Codes' in writer everyone would use LibreOffice.

True, and I think there is consensus that not everybody's personal "top priority" issue can be handled, no matter what steps are taken in the end.

As for no-one listening to users - I spend my life listening to customers & partners & users - and trying to do what they want. Anyone jealous of some big pool of unconstrained money / development power in corporate contributors is mistaken. Nevertheless I still get impassioned complaints of why Collabora did X and not Y from intelligent, articulate, engaged community members.

To mention it explicitly: Thanks for all that you and Collabora are doing for LibreOffice, that's much appreciated and I think nobody here is expecting Collabora to solve all problems by itself.

TDF in contrast while it has many constraints on what it can do - has few time constraints on its spending, which frees it to do more strategic long-term work. Thus it can invest more efficiently with some multiplying factor - via the educational / mentoring role into specific areas. I for one would support some targeted a11y / CTL mentoring - those seem like good areas that Sophie outlines - and ones where we can perhaps shine & grow the contributor community.

However - there is a cliff-face of need here. It seems totally sensible to suggest that hiring internal developers without any plan of working out what they should work on seems premature. Part of why mentors are attractive is that their agenda is partly lead by what volunteers want to do. That can be steered of course by creating new easy-hacks / tasks / projects in directions they want to go - and/or learning on the job themselves by hacking on things.

I completely agree that TDF has different constraints than other contributors and that could allow, among others, for doing more strategic work, rather than only focusing on single bugs that are important to specific users.

I'm not so sure, though, whether mentoring alone will be enough to ensure that otherwise neglected areas will sufficiently be taken care of.
For that to work, there at least need to be capable people willing to be mentored and to work on those topics, and having a certain amount of time to do so. I'm skeptical whether having more mentors alone will necessarily also provide for that.

I am wondering whether dropping a strict distinction between the two roles (developer, mentor) might help here. My expectation would be that a TDF developer currently "responsible" for a certain area would also be a great mentor in case people willing to work on that show up.
And once other contributors are willing to take care of specific areas, I believe it makes sense to allow them to work on that and have TDF staff focus on something else.

I think some flexibility depending on how things develop would nicely be able to deal with both scenarios: the one where other contributors interested in a specific topic show up, as well as the one where they don't.

For myself, I would want to see some sensible mechanism that includes the views of those who contribute via donations as to what is important. Then again if we dedicate donations solely in-line with what donors want - I suspect certain key functions: admin, marketing might not get the attention they deserve: so again, there is no obvious solution here beyond the board getting wide input and deciding (as they do now).

While I understand that details need to be sorted out on how to prioritize potential development topics to be worked on, I believe it should be doable to find a way.

But I don't see the issue, as ESC and BoD members could easily stop
any project before it starts, when there is a potential risk of conflict.

These days the we have created rules to exclude people from such decision making - which has the potential to significantly exacerbate conflict and division I feel.

But you're right, in theory the BoD is sovereign.

In my previous email, I wrote:
"Assuming members in the involved LibreOffice/TDF bodies found a way to work together constructively, my current impression is that this approach could be for the benefit of all."

I admit that this will probably be very hard if members of the involved LibreOffice/TDF bodies don't find a way to work together constructively, but rather "fight against each other". But I think that's a problem on a completely different level, and I don't see how TDF can properly serve it's purpose then anyway, regardless of the specific question around TDF-internal developers being discussed here...

Best regards,
Michael

Hi,

Hi Andreas,

Andreas Mantke píše v St 09. 02. 2022 v 19:58 +0100:

once I read this sentences the first time, I thought I was in a
different film in 2010. But maybe I didn't understand the situation
in OOo project at that time.

I may be wrong, it is a long time ago, but from what I remember, the
problem was not the domination per se [though please don't understand
me as supporting domination ;-)], but the unwillingness to communicate
& seek consensus how to improve the situation for contributors.

it seemed there are different worlds for developer and other community
members.

I and others had the impression that the project domination by one
company at that time wasn't healthy and that the engagement of this
dominant player would end very soon (because of their business
management model).

This was the reason why we get involved in the LibreOffice project from
day one.

We, the majority of the German speaking community members, left the OOo
project and had to fight against accusatory mails from employees etc.

But we withstand this violating situation and invested a lot of our
spare time and resources to make the German language project vital.

Thus I think it is important for community members, which remember the
situation of 2010, to avoid a situation, where only or nearly only one
company dominates the project and especially one area of the project.

The incorporation of a foundation was meant to avoid such situation. But
currently I think, the idea behind this action was not shared by all TDF
members and maybe we had to have set stricter rules to avoid cluster
risk in the TDF bodies.

And one thing which I take with me from this discussion is the evidence
that it is (nearly?) impossible to wear two hats at the same time.

Regards,
Andreas