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

Hi Lothar,

Lothar K. Becker píše v Čt 10. 02. 2022 v 11:12 +0100:

It was one of my first and foremost task as chair - and let me add it
was hard time consuming work - that everybody was heard and could
speak, it is simply not true, that contributors wasn't heard.

I am sorry, I didn't mean to offend you. I've seen it myself in the
public parts of the calls I were attending how hard a job it must have
been for you given the conditions, and I am sure you *yourself* made
everything to listen very carefully - thank you for that!

And the same way - I want thank everyone who were carefully listening &
considering, instead of just pushing their agenda.

All the best,
Kendy

Hi,

Some parts of LibreOffice are not covered by the ecosystem…
Although we sometimes have customers who ask for improvements :
May be those topics below are not fashionable but they contribute to give some credibility to LibreOffice

  • VBA compatibility

  • Basic bugs

  • Base enhancement

  • Python support

  • Math equation

  • Slide transition

  • documents signature support (CNG api)

  • All most annoying bugs…

All the best

Le jeu. 10 févr. 2022 à 11:30, Jan Holesovsky <kendy@documentfoundation.org> a écrit :

Hi Lothar,

Lothar K. Becker píše v Čt 10. 02. 2022 v 11:12 +0100:

It was one of my first and foremost task as chair - and let me add it
was hard time consuming work - that everybody was heard and could
speak, it is simply not true, that contributors wasn’t heard.

I am sorry, I didn’t mean to offend you. I’ve seen it myself in the
public parts of the calls I were attending how hard a job it must have
been for you given the conditions, and I am sure you yourself made
everything to listen very carefully - thank you for that!

And the same way - I want thank everyone who were carefully listening &
considering, instead of just pushing their agenda.

All the best,
Kendy


To unsubscribe e-mail to: board-discuss+unsubscribe@documentfoundation.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.documentfoundation.org/www/board-discuss/
Privacy Policy: https://www.documentfoundation.org/privacy

Hi Regis,

Regis Perdreau píše v Čt 10. 02. 2022 v 11:21 +0100:

Some parts of LibreOffice are not covered by the ecosystem...
Although we sometimes have customers who ask for improvements :

If you talk about customers - it sounds like there is a company willing
to pay to fix those. With my Collabora hat on, I'd love somebody from
our company to talk to those customers to see what we can offer them.

But with my TDF hat on - why should TDF, paid by donations from real,
living people, use those donations to employ developers to fix stuff
for enterprises?

May be those topics below are not fashionable but they contribute to
give some credibility to LibreOffice

- VBA compatibility
- Basic bugs
- Base enhancement
- Python support
- Math equation
- Slide transition
- documents signature support (CNG api)
- All most annoying bugs...

I didn't check how many of these were proposed for tendering - but I
think some of these were. Can you please add the missing ones as
proposals, so that it is possible to rate them & see which of them are
in line with the TDF goals & TDF can tender them?

Thank you very much!

All the best,
Kendy

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.

That's indeed a very important, and perhaps an under-used approach to
increase overall contributions in the project!

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.

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.

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.

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.

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.

Cheers,

-- Thorsten

Hi all,

* Members of the ecosystem and others also suggested that we should
    spend more money in development
  * Bugs, a11y issues and features can be harder to taken care of by
    volunteers and are not always addressed by the ecosystem
  * We need to build up internal skills and development capabilities to
    speed up innovation

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.

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.

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

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

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.

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.

However, I must admit I don't know the ecosystem company perspective first-hand, so would be interested in learning more about specific concerns.

Best regards,
Michael

Thank you for your support Michael!

I confirm that my proposal does not contemplate at all offering LTS version or any other services in exchange for donations.

Ciao

Paolo

Hi Kendy,

Hi Paolo,

Paolo Vecchi píše v St 09. 02. 2022 v 19:56 +0100:

He asked himself quite a few interesting questions:
"Without sharing too much, there are some moral questions popping up
for
me. Who owns the community? Who owns ownCloud itself? And what
matters
more, short term money or long term responsibility and growth? Is
ownCloud just another company or do we also have to answer to the
hundreds of volunteers who contribute and make it what it is today?"

Shouldn't we all ask ourselves the same questions?

Awesome - so now you finally understand how hard a decision it was for
us (Free Software lovers & contributors for decades) to move the LOOL
development to GitHub - because it was the result of asking & pondering
the same questions. Thank you for that!

I'm not sure it's as awesome as you may think.

What NextCloud seems to have done is practically the contrary to what Collabora did.

I never talked with Frank about it, and even if it happened I wouldn't share it without his permission, but his own published thoughts seem to indicate that for him his Open Source ethos wasn't fully respected in a company that was going "too commercial" that's why I wondered "Was Frank feeling that the commercial drive was clashing with his Open Source ethos?"

I don't think I ever heard Frank saying that NextCloud users were not part of the community or complaining that there were too many freeloaders like others do.

We have any a couple of public threads that you may find useful to view the LOOL issue from both sides.
They are linked here:

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

The clear summary anyway is that LOOL, conceived as a project that should have been delivered to the community, has been forked as commercial interests prevailed regardless of the agreements in place, the negotiations that were still ongoing and the marketing plan, which included LOOL, being developed.

Particularly:

* TDF does not own the community, TDF is an organization designed to
   make the community (let me repeat, "community" = "group of
   contributors") strong & flourishing.

I reported verbatim Frank's questions.
He probably was wondering if a community should be "owned" by a commercial organisation.

Then see my previous email in regards to the definition of "community":
https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00167.html

* TDF does not own LibreOffice itself; it owns the brand, but the code,
   translations, etc. is owned by the particular contributors (ie. by
   the community) - to the level of lines of code, strings of
   translations, icons painted, test cases provided, etc.

Also NextCloud GmbH doesn't own the code it produced or the code, translations, etc. produced by contributors.
It doesn't even own its brand as a foundation owns it.

TDF has been created as the home of LibreOffice and its community.

See the rest of the email you omitted, towards the end:

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

* Long term responsibility & growth matter more - and when the LOOL's
   (sub-)community didn't grow under TDF, it was time to move on. The
   decisions shouldn't be about donation money.

When in the early days a SUSE employee proposed to TDF the LOOL project he was developing more contributors came along.

It seems like at some point contributions stopped. We may need to investigate to help us understanding what went wrong and avoid similar mistakes in future.

Did some contributions stop because some thought that they were contributing to a company instead of a community?
Did the contributors get employed by Collabora so it looked like nobody else was interested in contributing?
Was the project too complex for many individual contributors to deal with?
Other factors at play?

And regarding the last one: "Is TDF just another foundation or do we
also have to answer to the hundreds of volunteers who contribute and
make it what it is today?" is for us, the new board, to improve -

Well, removing the name of a commercial organisation that Frank was leaving behind and replacing it with the non for profit and independent TDF frames things in a very different way.

Anyway of course we have to focus on the millions of users and hundreds of contributors that form our community and support us in various ways with code, localization, marketing, infrastructure, QA, design, word of mouth, events and activities, donations and in many more ways.

because from what I can see, TDF was not listening to the contributors
the last 2 years too much.

As Lothar said members of the board listened and had to work very hard to fix many issues and to get the relevant information showing that TDF can do much more that it has been thought including investing in developers.

Let's improve it together!

Yes but let's keep in mind that members of TDF's board of directors, while performing their duties, need put first the interests of TDF and its wider community and not focus mostly on "subsets".

All the best,
Kendy

Ciao

Paolo

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.