Merged proposal for in-house developers at TDF

Dear list,

Andreas Mantke wrote:

> Interestingly I cannot remember TDF ever tendering for LibreOffice
> Online work, can you please point me to the details?
TDF tendered in 2014/2015 the work for the Android editing, which was
explained to the board also as important for LOOL.

That seems to be a very technical argument (on both sides); in any
case I doubt that a discussion of something that happend 8 years ago
helps us in moving the developer hiring proposal forward.

As such, lets please get back to the topic.

Paolo Vecchi wrote:

With a very odd timing the 02/06/2022 Mr Meeks added to the ESC agenda,
during the meeting, the request to actually kill LOOL. From the emails on
board-discuss it seems clear that that he doesn't want that in-house
developers to even thinking about reviving LOOL to make sure TDF cannot
promote even a basic version of it.

Same here - mixing lots of other topics into this discussion is not
useful in us making progress.

It is also premature, since the ESC is still discussing the
matter. Debating the merits of the proposal should happen there, not
here (for the while). Unless the board wants to run its own, competing
motion for how to deal with the Online repo (which I would consider
nonconstructive).

Thanks,

-- Thorsten

Hi all,

Dear list,

Andreas Mantke wrote:

> Interestingly I cannot remember TDF ever tendering for LibreOffice
> Online work, can you please point me to the details?
TDF tendered in 2014/2015 the work for the Android editing, which was
explained to the board also as important for LOOL.

That seems to be a very technical argument (on both sides); in any
case I doubt that a discussion of something that happend 8 years ago
helps us in moving the developer hiring proposal forward.

As such, lets please get back to the topic.

Because the acting people from that years hasn't realy changed I think that gives a clearer view on their mindset and agenda. It's important to help understanding the whole process in this thread.

Paolo Vecchi wrote:

With a very odd timing the 02/06/2022 Mr Meeks added to the ESC agenda,
during the meeting, the request to actually kill LOOL. From the emails on
board-discuss it seems clear that that he doesn't want that in-house
developers to even thinking about reviving LOOL to make sure TDF cannot
promote even a basic version of it.

Same here - mixing lots of other topics into this discussion is not
useful in us making progress.

It is also premature, since the ESC is still discussing the
matter. Debating the merits of the proposal should happen there, not
here (for the while). Unless the board wants to run its own, competing
motion for how to deal with the Online repo (which I would consider
nonconstructive).

It is not constructive for the agenda of the acting members of the ESC. There are a lot active members with a CoI in the LOOL topic. Thus if they further act to force a decision in their direction and the board stops that not immediately it's according to the statutes time for the MC to step in (to prevent the foundation from further damage).

Regards,
Andreas

Hi Andreas, all,

Andreas Mantke wrote:

>As such, lets please get back to the topic.
>

Because the acting people from that years hasn't realy changed I
think that gives a clearer view on their mindset and agenda. It's
important to help understanding the whole process in this thread.

Hmm. I wonder how much of these discussions here really is about
frustrations of the past (and people not liking each other),
vs. interacting positively with new proposals.

I think it would be in everyone's interest (in particular in TDF's
interest), if we could discuss the merits of proposals and ideas
independent of who brought them in.

The ESC btw is such a place, and therefore still quite a pleasant
experience, with calm & constructive discussions between all
stakeholders.

All the best,

-- Thorsten

Hi Thorsten,

Dear list,

Andreas Mantke wrote:

Interestingly I cannot remember TDF ever tendering for LibreOffice
Online work, can you please point me to the details?

TDF tendered in 2014/2015 the work for the Android editing, which was
explained to the board also as important for LOOL.

That seems to be a very technical argument (on both sides); in any
case I doubt that a discussion of something that happend 8 years ago
helps us in moving the developer hiring proposal forward.

Something that had a clear start, progression and support from TDF during the past 7 years shows the risks we may incur when different interests influence TDF and our community.

As such, lets please get back to the topic.

Paolo Vecchi wrote:

With a very odd timing the 02/06/2022 Mr Meeks added to the ESC agenda,
during the meeting, the request to actually kill LOOL. From the emails on
board-discuss it seems clear that that he doesn't want that in-house
developers to even thinking about reviving LOOL to make sure TDF cannot
promote even a basic version of it.

Same here - mixing lots of other topics into this discussion is not
useful in us making progress.

Promoting an ineffective and expensive way to get some mentors and the proposal of killing LOOL are related as coming from a single person that might have conflicting interests and is not even a member of the ESC.

It is also premature, since the ESC is still discussing the
matter.

There isn't and hasn't been much debate going on and the ESC has been asked to vote today about killing LOOL.

Debating the merits of the proposal should happen there, not
here (for the while). Unless the board wants to run its own, competing
motion for how to deal with the Online repo (which I would consider
nonconstructive).

IMHO the ESC should deal with purely engineering issues, the intervention from a non ESC members shows that it has been abused as a "political" tool.

What happened during the past 2 ESC meetings should be thoroughly investigated to see if undue influence from a conflicted party is an acceptable behaviour.

Thanks,

-- Thorsten

Ciao

Paolo

Hi Paolo,

[last comment from me on this sub-thread]

Paolo Vecchi wrote:

There isn't and hasn't been much debate going on and the ESC has
been asked to vote today about killing LOOL.

Whatever the outcome of the ESC discussion - moving to the attic is
not 'killing' a project (which is an unnecessarily charged word
anyway). Additionally, there has not been any commits to LOOL in
almost 2 years. The status quo is already the 'attic', for anything
but the name.

And now let's wait for the ESC to act (or not).

Cheers,

-- Thorsten

Hi Andreas,

Andreas Mantke píše v St 08. 06. 2022 v 19:53 +0200:

> Interestingly I cannot remember TDF ever tendering for LibreOffice
> Online work, can you please point me to the details?
TDF tendered in 2014/2015 the work for the Android editing, which was
explained to the board also as important for LOOL. Thus this project
was
payed from the LibreOffice donation money. The biggest part of this
work
(according to the prize) was done by Collabora productivity.
> [But I may be wrong - as said, I have nothing to do with TDF
> tending
> process, so maybe I've missed something?]
>
I made a research in an archive and found out that the document with
the
offer from Collabora was created by Jan Holesovsky with LibreOffice
4.2
on Oct., 6 2014.

Sure, if we are talking the Android editing, then of course, I know
what you are talking about.

The work consisted of 478 commits, 265 of them were clearly marked as
"android". The remaining 213 commits may still have been Android-only
(and the author just forgot to mark them that way), or may have
improved (the pre-existing, funded by CloudOn, Smoose and others)
LibreOfficeKit with functionality needed for the Android work (I'd need
to check commit by commit to tell you the exact number, so the 213 is
the upper bound - it could be less).

Anybody can check the reports, Collabora has published them previously:

  https://www.collaboraoffice.com/wp-content/uploads/2020/09/TDF0002-report-M1.pdf
  https://www.collaboraoffice.com/wp-content/uploads/2020/09/TDF0002-report-M2.pdf

LibreOfficeKit was indeed important for what has started as LibreOffice
Online thanks to the seed investment from IceWarp, but was just a part
of what was necessary for the LibreOffice Online development. The
completely missing bits, not existing previously & not paid by TDF,
were the server and the JavaScript renderer of the tiles.

To put the 213 commits to perspective, the server and JS bits were
12489 commits at the time of the Online repository move to GitHub. It
is hard to count the commits done to LibreOfficeKit (ie. to LibreOffice
core) before and after the TDF Android editing tender; but I suppose
there were thousands, and they are still part of LibreOffice, of
course.

None of the server & JS commits were paid by TDF, it was all funded by
IceWarp, Collabora itself & many others, and the price that TDF has
paid for the 213 commits was marginal compared to the other work that
made the Online happen. Please don't get me wrong though - I am really
grateful for that, every cent counts, and especially counted the 8
years ago; for people at Collabora, those were hard (but exciting)
times with very unpredictable future.

And for the avoidance of doubt - all these 213 commits were needed for
the Android work, none of them was done speculatively for a potential
Online use later.

More details here:

  https://collaboraonline.github.io/post/faq/#mobile-story

All the best,
Kendy

Hi all,

Hi Andreas, all,

Andreas Mantke wrote:

As such, lets please get back to the topic.

Because the acting people from that years hasn't realy changed I
think that gives a clearer view on their mindset and agenda. It's
important to help understanding the whole process in this thread.

Hmm. I wonder how much of these discussions here really is about
frustrations of the past (and people not liking each other),
vs. interacting positively with new proposals.

you may not understand that some people not share your idea of man.
Although some board members are really hard trying to frustrate
members/volunteers some participants work further for the good of the
community and the foundation. And they follow their intrinsic motivation
and work for their ideal. They don't want to see a prize tag on
everything. And maybe such a view and behavior is scary for some involved.

I think it would be in everyone's interest (in particular in TDF's
interest), if we could discuss the merits of proposals and ideas
independent of who brought them in.

It would be very good if those with management functions would lead the
discussion and wouldn't only stand at the sideline.

It seemed there are different proposals on the table and the board needs
to decide which direction to follow.

The ESC btw is such a place, and therefore still quite a pleasant
experience, with calm & constructive discussions between all
stakeholders.

You can discuss there, but you should abstain from double your impact by
participating further in the board discussion / decision.

And as a reminder: at least for free software companies has to be
excluded from the tender process at least for the 2022 budget, because
their staff / manager take responsibility for that whole budget
(including the tender items).

And further addition: the items in the 2022 budget are not fixed and
couldn't changed or adjusted by a further board vote (thus there could
and would be a budget for in-house developer available, if the board
decided so).

Regards,
Andreas

Hi all,

Hi Andreas,

Andreas Mantke píše v St 08. 06. 2022 v 19:53 +0200:

Interestingly I cannot remember TDF ever tendering for LibreOffice
Online work, can you please point me to the details?

TDF tendered in 2014/2015 the work for the Android editing, which was
explained to the board also as important for LOOL. Thus this project
was
payed from the LibreOffice donation money. The biggest part of this
work
(according to the prize) was done by Collabora productivity.

[But I may be wrong - as said, I have nothing to do with TDF
tending
process, so maybe I've missed something?]

I made a research in an archive and found out that the document with
the
offer from Collabora was created by Jan Holesovsky with LibreOffice
4.2
on Oct., 6 2014.

Sure, if we are talking the Android editing, then of course, I know
what you are talking about.

The work consisted of 478 commits, 265 of them were clearly marked as
"android". The remaining 213 commits may still have been Android-only
(and the author just forgot to mark them that way), or may have
improved (the pre-existing, funded by CloudOn, Smoose and others)
LibreOfficeKit with functionality needed for the Android work (I'd need
to check commit by commit to tell you the exact number, so the 213 is
the upper bound - it could be less).

Anybody can check the reports, Collabora has published them previously:

   https://www.collaboraoffice.com/wp-content/uploads/2020/09/TDF0002-report-M1.pdf
   https://www.collaboraoffice.com/wp-content/uploads/2020/09/TDF0002-report-M2.pdf

LibreOfficeKit was indeed important for what has started as LibreOffice
Online thanks to the seed investment from IceWarp, but was just a part
of what was necessary for the LibreOffice Online development. The
completely missing bits, not existing previously & not paid by TDF,
were the server and the JavaScript renderer of the tiles.

To put the 213 commits to perspective, the server and JS bits were
12489 commits at the time of the Online repository move to GitHub. It
is hard to count the commits done to LibreOfficeKit (ie. to LibreOffice

this confirms that TDF has payed a part of the Android and Online
development from donation money.

core) before and after the TDF Android editing tender; but I suppose
there were thousands, and they are still part of LibreOffice, of
course.

None of the server & JS commits were paid by TDF, it was all funded by
IceWarp, Collabora itself & many others, and the price that TDF has
paid for the 213 commits was marginal compared to the other work that
made the Online happen. Please don't get me wrong though - I am really
grateful for that, every cent counts, and especially counted the 8
years ago; for people at Collabora, those were hard (but exciting)
times with very unpredictable future.

And for the avoidance of doubt - all these 213 commits were needed for
the Android work, none of them was done speculatively for a potentiald
Online use later.

If I remember correctly I attended a presentation from Michael M. about
a LibreOffice online pre alpha version at the conference in Paris 2011.
And thus I'm not able to reconstruct that in 2014/15 the LibreOffice
online was speculatively.

The tender in 2014/2015 was justified not only with foundation work for
an Android version but also for an online version of LibreOffice. And it
was flagged that would be a necessary investment for the future of
LibreOffice (because mobile/online would be the future of office tools).

Although Collabora took money from the charity TDF to develop LOOL, it
forked this project and dry out the LOOL development under the TDF
umbrella. That is a self-centered behavior and a damage of the
foundation. Such a behavior is the opposite of a contribution to
TDF/LibreOffice.

Regards,
Andreas

Hi Michael,

Thank you for the feedback! I've updated the document accordingly, see
below:

Michael Weghorn píše v Út 07. 06. 2022 v 14:07 +0000:

> Please don't get me wrong - I believe the appstores is an important
> discussion, just don't want to block the hiring on that; as I think
> it
> is orthogonal to that.

I used to agree here.

In light of the recent BoD decision that TDF will publish LO in the
app
stores [1] however, I think it is fair to reconsider this, and
consider
development needed to keep LO in line with app store requirements as
a
potential target area for TDF-internal developers, unless that's
already
covered otherwise.

[...]

In that regard, the "App stores management" section in Paolo's
updated
proposal (v2.1) looks reasonable to me at first sight.

Makes sense, I've removed the deletion, the "App stores management" is
back.

> Ah - it is the extension of the rationale how the development
> itself
> fits the TDF mission, ie. doesn't make that much sense without the
> previous paragraph that starts "Why is it important to major on
> mentoring".
>
> So how about: "Development per se is not part of TDF mission, but
> it is
> expected that while a mentor is unable to actively contribute to
> public
> and professional education for whatever reason (eg. absence of
> volunteers) that they will be researching and increasing their
> experience by contributing to new ways to advance the free software
> and
> standards in their particular Target Areas."
>
> Does it make more sense this way?

I'm not sure. It's still a bit unclear to me what "researching and
increasing their experience by contributing to new ways to advance
the
free software and standards in their particular Target Areas" means
in
practice, s.a. questions in my previous emails.

I see - so this is to make sure the work of the developers fits the
charitable mission of TDF.

I have the impression that my personal understanding/perspective of
the
job of a targeted developer is a bit different from the one outlined
in
your proposal, and more in line with Paolo's when there are no
mentees
in the developer's target areas.
That would seem reasonable to me:

* If there are mentees in the target area, mentoring is the primary
focus (as outlined in your proposal).
* However, if there are no mentees, it's the primary focus to do
development in the target area.

Thank you, I've added this as clarification.

Quoting from my previous email:

> (I think it definitely makes sense to get deeper into the topic and
> cooperate with other organizations and free software projects.
> I still think that the main focus should be to achieve practical
> improvements in LO. Depending on the target area, I can think of
> more or less way that this would naturally involve contributing to
> other free software projects etc, but - given limited resource - I
> personally wouldn't necessarily see contributing to other projects
> or doing research as a main goal by itself, at least not in the
> beginning.)

After all, it seems to be a matter of setting priorities how TDF
money
is spent, and one can decide one way or the other.
I can't judge how well each option fits with the "Development per se
is
not part of TDF mission" you mention, but to me, doing "development
per
se" doesn't seem to be less in line with the TDF mission than
spending
money on tenders, as was mentioned elsewhere in one of the threads
already.

I think, in the past, there used to be long discussions whether TDF can
or cannot have developers; so my hope that framing that in a way that
fits the mission by default can help here.

For the moment, I've added the "Developers per se..." there, but I
don't insist, can be further tweaked in whatever way needed, I think.

> Indeed, I should clarify this; I think changing "Overlaps or
> prioritisations that find ..." to "Technical decisions that
> find..."
> could do?

Yes, sounds good to me; thanks for the clarification.

Applied.

> The hope is that there will be many applicants, and that we'll have
> the
> possibility to choose two. But if there is only one good
> candidate, I
> think we should not start another round of interviews until we
> evaluate
> the experience - because the process is expensive & time consuming.

Sounds reasonable.
If it helps finding a consensus (minimize differences between the 2
proposals at hand), I wonder whether it would make sense to rephrase
this, so that it becomes clear that having 2 would be preferred (and
just employing one if only one suitable candidate shows up is the
fallback), but for me personally, this explanation is enough and it
doesn't seem to make any difference in practice.

OK, I've changed the default to 2, fallback to 1; and added a note for
the Board to decide when no suitable candidate is found.

> What about "... will not develop alternative implementations of
> Open
> Source projects actively maintained by LibreOffice volunteer or
> corporate contributors."?
>
> LOOL could be an example, but there is eg. the Kohei's mdds (that
> is
> essential for the Calc core), or Moggi's maintenance of cppunit -
> hosted on freedesktop, but using LibreOffice bugzilla for
> bugreports.

That still seems a bit to be too generic to me.

For the moment, I've at least adapted it to the above, but happy to go
further there, if you can propose a wording please?

Also I was thinking of something like "TDF in-house developers will
encourage up-streaming in case their work ends up as a modification of
an external LibreOffice project." (to target things like PDFium etc.)

Normally, I'd expect that there doesn't have to be any such phrase
in
the proposal after all, as my expectation would be that the BoD
makes
sure to select appropriate target areas that don't create a conflict.

Honestly, I don't see why TDF would reasonably want to start creating
an
alternative for/fork of mdds or cppunit.
However, with the LOOL background, I understand to some extent that
there's the concern to explicitly have some "clause" here.
If necessary, my personal preference would be to have an explicit
list
of projects where there is actual concern right now (that can then
be
extended by BoD vote later as needed), because I think that in the
hypothetical case case of a "malicious" volunteer or corporate
contributor, the above clause could be misused in some way.
(Writing this feels a bit odd, and I don't claim it's realistic at
all
and I hope it weren't needed, but I'm wondering whether strictly
limiting the potential use of this clause makes sense to avoid
confusion
and help build a potential consensus...)

OK, I've added the explicit list as examples.

Once again - thank you for your feedback!

All the best,
Kendy

Hi Simon,

Simon Phipps píše v Pá 03. 06. 2022 v 09:59 +0100:

> Tendering and in-house development are not interchangeable, but
> they are
> interlinked. Keep in mind that the in-house devs would participate
> in
> running tenders.

Another valuable role for an in-house developer would be to manage a
more long-term relationship with specialist subcontractors, for
example a company with expertise in accessibility development. With a
longer-term expert subcontractor, TDF could then actually develop new
capabilities rather than simply fix bugs and stand still like AOO. By
adding to our list of approaches a managed but non-employee longer-
term relationship with outside firms that is not limited to a single
task, TDF would be able to both benefit from the flexibility of
tendering and also gain the benefit of long-term staffing.

Thank you very much, I've added this paragraph as a new Focus area, and
removed your comment that touched this area.

All the best,
Kendy

Hi Andreas,

Andreas Mantke píše v Čt 09. 06. 2022 v 20:48 +0200:

this confirms that TDF has payed a part of the Android and Online
development from donation money.

Interestingly, I don't recall any of the Collabora Productivity clients
(even proprietary companies) ever complaining that the code Collabora
develops for them end up in the open, as Free Software, and may be
reused later to build new stuff on top of that, and that it may help
other clients too.

The donation money were used to develop Android editing. The fact that
a small part of that work was later re-used for other developments is
irrelevant, this his how Open Source and Free Software works.

If I remember correctly I attended a presentation from Michael M.
about
a LibreOffice online pre alpha version at the conference in Paris
2011.

The prototype from 2011 was using a different approach (remote desktop
in a browser) and no code from that approach was used in online.git.

All the best,
Kendy

Hi Kendy,

Thank you for the feedback! I've updated the document accordingly, see
below:

Thanks a lot!

I'm not sure. It's still a bit unclear to me what "researching and
increasing their experience by contributing to new ways to advance
the
free software and standards in their particular Target Areas" means
in
practice, s.a. questions in my previous emails.

I see - so this is to make sure the work of the developers fits the
charitable mission of TDF.

I have the impression that my personal understanding/perspective of
the
job of a targeted developer is a bit different from the one outlined
in
your proposal, and more in line with Paolo's when there are no
mentees
in the developer's target areas.
That would seem reasonable to me:

* If there are mentees in the target area, mentoring is the primary
focus (as outlined in your proposal).
* However, if there are no mentees, it's the primary focus to do
development in the target area.

Thank you, I've added this as clarification.

[...]

I think, in the past, there used to be long discussions whether TDF can
or cannot have developers; so my hope that framing that in a way that
fits the mission by default can help here.

For the moment, I've added the "Developers per se..." there, but I
don't insist, can be further tweaked in whatever way needed, I think.

Re-reading the sentence now with those changes in place, I'm wondering whether I just previously misunderstood what was meant:
Is "researching and increasing their experience by contributing to new ways to advance the free software and standards in their particular Target Areas" actually the part that includes working on LibreOffice code?

If so, the prioritization makes total sense to me as is.

(I was previously assuming that this is yet another activity besides doing direct mentoring and the development task, something that would be done to have a larger "mentoring" share of some kind if there weren't "enough" mentees at hand, and I didn't really understand what that would be in practice, so wondering whether it would be justified to spend resources on that.)

If it helps finding a consensus (minimize differences between the 2
proposals at hand), I wonder whether it would make sense to rephrase
this, so that it becomes clear that having 2 would be preferred (and
just employing one if only one suitable candidate shows up is the
fallback), but for me personally, this explanation is enough and it
doesn't seem to make any difference in practice.

OK, I've changed the default to 2, fallback to 1; and added a note for
the Board to decide when no suitable candidate is found.

Thanks, looks good to me.

What about "... will not develop alternative implementations of
Open
Source projects actively maintained by LibreOffice volunteer or
corporate contributors."?

LOOL could be an example, but there is eg. the Kohei's mdds (that
is
essential for the Calc core), or Moggi's maintenance of cppunit -
hosted on freedesktop, but using LibreOffice bugzilla for
bugreports.

That still seems a bit to be too generic to me.

For the moment, I've at least adapted it to the above, but happy to go
further there, if you can propose a wording please?

Looks better to me already. What I had in mind was an explicit list, something like:

"TDF in-house developers will not compete with commercial contributors and will not develop alternative implementations of the following Open Source projects actively maintained by LibreOffice volunteer or corporate contributors: Collabora Online, mdds, cppunit" [add more here if more are an area of concern]

Also I was thinking of something like "TDF in-house developers will
encourage up-streaming in case their work ends up as a modification of
an external LibreOffice project." (to target things like PDFium etc.)

Sounds good.

Thanks again,
Michael

Hi all,

Hi Michael,

Thank you for the feedback! I've updated the document accordingly, see
below:

Michael Weghorn píše v Út 07. 06. 2022 v 14:07 +0000:

(...)

Quoting from my previous email:

(I think it definitely makes sense to get deeper into the topic and
cooperate with other organizations and free software projects.
I still think that the main focus should be to achieve practical
improvements in LO. Depending on the target area, I can think of
more or less way that this would naturally involve contributing to
other free software projects etc, but - given limited resource - I
personally wouldn't necessarily see contributing to other projects
or doing research as a main goal by itself, at least not in the
beginning.)

After all, it seems to be a matter of setting priorities how TDF
money
is spent, and one can decide one way or the other.
I can't judge how well each option fits with the "Development per se
is
not part of TDF mission" you mention, but to me, doing "development
per
se" doesn't seem to be less in line with the TDF mission than
spending
money on tenders, as was mentioned elsewhere in one of the threads
already.

I think, in the past, there used to be long discussions whether TDF can
or cannot have developers; so my hope that framing that in a way that
fits the mission by default can help here.

For the moment, I've added the "Developers per se..." there, but I
don't insist, can be further tweaked in whatever way needed, I think.

The board spent a lot of donation money for the LibreOffice development
(and other development tasks) during the last years.
There is no difference between spending money for source code
development and hiring in-house developers for doing such work. If
spending donation money for the development tenders is compatible with
the statutes and the charity status then there is no barrier for hiring
developers. The latter is the better choice because TDF get more impact
on the development process and gain more in-house knowledge. This would
also help TDF e.g. to more easily participate in the GSoC

The hope is that there will be many applicants, and that we'll have
the
possibility to choose two. But if there is only one good
candidate, I
think we should not start another round of interviews until we
evaluate
the experience - because the process is expensive & time consuming.

What about "... will not develop alternative implementations of
Open
Source projects actively maintained by LibreOffice volunteer or
corporate contributors."?

LOOL could be an example, but there is eg. the Kohei's mdds (that
is
essential for the Calc core), or Moggi's maintenance of cppunit -
hosted on freedesktop, but using LibreOffice bugzilla for
bugreports.

That still seems a bit to be too generic to me.

For the moment, I've at least adapted it to the above, but happy to go
further there, if you can propose a wording please?

Also I was thinking of something like "TDF in-house developers will
encourage up-streaming in case their work ends up as a modification of
an external LibreOffice project." (to target things like PDFium etc.)

OK, I've added the explicit list as examples.

it is not in the interest of TDF / LibreOffice community to exclude
areas of development per se. If the LibreOffice community and the board
thinks the development of a product, a module etc. is important and
necessary for the future / the (further) growth of the program / the
community it had to be able to point his development resources (in-house
or else) into that direction. No commercial / free software company has
the right to distract the foundation from doing that. Thus it is not
appropriate to add such sentences to the proposal.

And from my impression the 'merged proposal' is a paper to prune TDF's
freedom and to support only commercial companies. But such a proposal is
never in the best interest of the foundation and the board should
abstain to vote for such a proposal.

Regards,
Andreas

Hi Andreas,

thanks again for providing a very good analysis of the issues which should be taken in consideration.

Now that finally the objection about the "app stores" has been clarified as the board published the decision the are only a few differences left between my original proposal and this new one.

1) I don't think is a good idea to try to find senior developers willing to mentor as we have already to that are doing an excellent job and are still growing. The new in-house developers may not need to be senior as it's good for TDF to invest in new developers with good experience and allow them to grow with us together with our mentors, the rest of the team and the community. They'll probably grow to become mentors but that shouldn't be the focus now.

2) The new part related getting into long term contract with external provider is premature as we will see who we find, what experience they have and then decide if other experts are needed to help them grow or deal directly with some complex parts as anyway specified in my proposal.

3) During the past year we worked on what TDF can and cannot do as a foundation under German laws and we found that we can do a lot more than previously thought including employing developers.

4) The rest seems to be an effort to have members of TDF's team controlled by the ESC or to impose limitations suggested by commercial contributors. It is clear in many part of the text of the other proposal but this sentence makes things clear for all:

"For avoidance of doubt, by no means the Targeted Developer or TDF leadership by tasking the Targeted Developer can overrule code-related decisions as decided by the ESC."

This could have been tolerated if the ESC were a properly regulated committee with a CoI Policy and a clear history of being a neutral ground for all.

IMHO recent interventions during ESC meetings disqualifies this committee from imposing decisions on any TDF body and employees.

Other elements like contracts with third parties, impositions from third party companies not to work on or something similar to LOOL or not to work on possible future projects that could be interesting for third party companies do not belong to a document related to employing developers. Those areas should be discussed publicly to create clear rules of engagement valid with any third party companies regardless if they are current or future contributors.

In the upcoming version 2.2 of my proposal I've added a paragraph that explicitly excludes that the in-house employees should be bound by any decision from the ESC.

I've read in full the other proposal and while, thanks to comments and suggestions, it seems to be converging back to my original proposal it still creates more issues than anything else.

Now that my initial concerns about a "merged" version have been proven right it would be great to finalise the original proposal if anyone can provide more contributions.

Hi all,

Hi Michael,

Thank you for the feedback!  I've updated the document accordingly, see
below:

Michael Weghorn píše v Út 07. 06. 2022 v 14:07 +0000:

(...)

Quoting from my previous email:

(I think it definitely makes sense to get deeper into the topic and
cooperate with other organizations and free software projects.
I still think that the main focus should be to achieve practical
improvements in LO. Depending on the target area, I can think of
more or less way that this would naturally involve contributing to
other free software projects etc, but - given limited resource - I
personally wouldn't necessarily see contributing to other projects
or doing research as a main goal by itself, at least not in the
beginning.)

After all, it seems to be a matter of setting priorities how TDF
money
is spent, and one can decide one way or the other.
I can't judge how well each option fits with the "Development per se
is
not part of TDF mission" you mention, but to me, doing "development
per
se" doesn't seem to be less in line with the TDF mission than
spending
money on tenders, as was mentioned elsewhere in one of the threads
already.

I think, in the past, there used to be long discussions whether TDF can
or cannot have developers; so my hope that framing that in a way that
fits the mission by default can help here.

For the moment, I've added the "Developers per se..." there, but I
don't insist, can be further tweaked in whatever way needed, I think.

The board spent a lot of donation money for the LibreOffice development
(and other development tasks) during the last years.
There is no difference between spending money for source code
development and hiring in-house developers for doing such work. If
spending donation money for the development tenders is compatible with
the statutes and the charity status then there is no barrier for hiring
developers. The latter is the better choice because TDF get more impact
on the development process and gain more in-house knowledge. This would
also help TDF e.g. to more easily participate in the GSoC

The hope is that there will be many applicants, and that we'll have
the
possibility to choose two.  But if there is only one good
candidate, I
think we should not start another round of interviews until we
evaluate
the experience - because the process is expensive & time consuming.

What about "... will not develop alternative implementations of
Open
Source projects actively maintained by LibreOffice volunteer or
corporate contributors."?

LOOL could be an example, but there is eg. the Kohei's mdds (that
is
essential for the Calc core), or Moggi's maintenance of cppunit -
hosted on freedesktop, but using LibreOffice bugzilla for
bugreports.

That still seems a bit to be too generic to me.

For the moment, I've at least adapted it to the above, but happy to go
further there, if you can propose a wording please?

Also I was thinking of something like "TDF in-house developers will
encourage up-streaming in case their work ends up as a modification of
an external LibreOffice project." (to target things like PDFium etc.)

OK, I've added the explicit list as examples.

it is not in the interest of TDF / LibreOffice community to exclude
areas of development per se. If the LibreOffice community and the board
thinks the development of a product, a module etc. is important and
necessary for the future / the (further) growth of the program / the
community it had to be able to point his development resources (in-house
or else) into that direction. No commercial / free software company has
the right to distract the foundation from doing that. Thus it is not
appropriate to add such sentences to the proposal.

As above, if there must be an agreement with third parties then that must be valid for all and written in a document that has nothing to do with the employment of new members of the staff.

And from my impression the 'merged proposal' is a paper to prune TDF's
freedom and to support only commercial companies. But such a proposal is
never in the best interest of the foundation and the board should
abstain to vote for such a proposal.

IMHO that proposal isn't viable anymore for many reasons including those expressed above.

I hope we will finally get back to the original purpose of the proposal and approve it ASAP.

Regards,
Andreas

Ciao

Paolo

Hi all,

Hi Andreas,

Andreas Mantke píše v Čt 09. 06. 2022 v 20:48 +0200:

this confirms that TDF has payed a part of the Android and Online
development from donation money.

Interestingly, I don't recall any of the Collabora Productivity clients
(even proprietary companies) ever complaining that the code Collabora
develops for them end up in the open, as Free Software, and may be
reused later to build new stuff on top of that, and that it may help
other clients too.

seemed it is really hard to understand the content of my message. ;-(

But I'm tired to repeatedly try to explain things with the same result.
Otherwise that could be judged as a constant negative message by a
reader of this list.

The donation money were used to develop Android editing. The fact that
a small part of that work was later re-used for other developments is
irrelevant, this his how Open Source and Free Software works.

And I abstain from commenting this, because it seemed we don't share the
same view about the behavior in question this topic.

Regards,
Andreas

Hi Andreas,

On Sat, Jun 11, 2022 at 6:49 PM Andreas Mantke <maand@gmx.de> wrote:

But I’m tired to repeatedly try to explain things with the same result.
Otherwise that could be judged as a constant negative message by a
reader of this list.

Since I currently have no relevant affiliation to prevent me speaking up and given this reference to my earlier admonition, I will remind you that you started this negative approach about how TDF is acting illegally when you and I were on the Board together last decade. You repeatedly intervened at Board meetings with comments that the things the rest of the Board were discussing or deciding were in breach of the rules or the law. When asked to provide evidence to support your assertions, you never produced any, and when asked to propose alternative actions, you never did. Your actions seriously delayed the Board from taking necessary actions on behalf of the Foundation as they sought a consensus you repeatedly blocked.

The Board at that time sought advice and found it had the discretion to take all the actions against which you were warning. The negative framing should have stopped then. Instead, despite leaving both the Board and the Foundation, you have continued to snipe from the sidelines at every opportunity, always critical and never building on the contributions of others. Again, I recommend you withdraw.

Sincerely,

Simon

Hi Simon,

I will remind you that you started this negative approach about how TDF is acting illegally when you and I were on the Board together last decade.

I'm honestly struggling to see how your comments can be thought as positive.

And how should users and members should voice their unsettlement, without risking to be stopped at every corner and called out for violations of CoC.

Regards,

Hi Emilliano,

On Sun, Jun 12, 2022 at 9:31 AM Emiliano Vavassori <syntaxerrormmm@libreoffice.org> wrote:

Hi Simon,

Il 11/06/22 20:02, Simon Phipps ha scritto:

I will remind you
that you started this negative approach about how TDF is acting
illegally when you and I were on the Board together last decade.

I’m honestly struggling to see how your comments can be thought as positive.

They are to help newcomers like you become aware that the complaints being made are not in fact new or related to the current situation but date back to a dispute that is many years old and still unresolved due to personal enmities. I am sorry you do not find this helpful, but being aware of the true history of the project (especially at a time when there are voices trying to reframe history) is very important and refusing to do so may lead to incorrect assumptions and the acceptance of untrue framing.

And how should users and members should voice their unsettlement,
without risking to be stopped at every corner and called out for
violations of CoC.

By entering into a dialogue. By hearing and evolving compromises with other members through selecting positive elements of their contributions. By collaborating together even when uncomfortable. By respecting the honest contributions of long-time contributors. This place is hardly a close venue.

How should members voice their concerns when they see entryists harming the project and old unsettled grudges being repeatedly raised regardless of how they are answered?

Sincerely,

Simon

Hi Simon,

They are to help newcomers like you become aware that the complaints being made are not in fact new or related to the current situation but date back to a dispute that is many years old and still unresolved due to personal enmities.

That is still setting a (partial, angled) framing of the situation (as Andreas was doing, to some extent).

What still worries me is that said frictions are still there after a lot of years and weren't solved, and honestly I don't buy it is a constellation of personal issues, rather than a misunderstanding on how effectively implement the shared goals we all should have.

I am sorry you do not find this helpful, but being aware of the true history of the project (especially at a time when there are voices trying to reframe history) is very important and refusing to do so may lead to incorrect assumptions and the acceptance of untrue framing.

I didn't say I found it useless, I said it wouldn't really still help with moving the general balance of the discussion towards a positive outcome, which was the main objections to Andreas' mails.

By entering into a dialogue. By hearing and evolving compromises with other members through selecting positive elements of their contributions.

I'd generally agree, but what I can read from the thread is that some discussions and objections are less likely to be acknowledged and recognized, and taken as a basis to work on a positive compromise, mostly because that is not coming from a long-time contributor. That's not the case for Andreas, who you are confirming he is akin to the Foundation since a lot of time.

How should members voice their concerns when they see entryists harming the project and old unsettled grudges being repeatedly raised regardless of how they are answered?

Let's start by acknowledging that if there are objections and they are even consistently confirmed from long relationships and from short ones, possibly something to discuss is there.

Cheers,

Hi Simon,

On 12/06/2022 11:17, Simon Phipps wrote:

Hi Emilliano,

On Sun, Jun 12, 2022 at 9:31 AM Emiliano Vavassori <syntaxerrormmm@libreoffice.org> wrote:

Hi Simon,

Il 11/06/22 20:02, Simon Phipps ha scritto:

I will remind you
that you started this negative approach about how TDF is acting
illegally when you and I were on the Board together last decade.

I’m honestly struggling to see how your comments can be thought as positive.

They are to help newcomers like you become aware that the complaints being made are not in fact new or related to the current situation but date back to a dispute that is many years old and still unresolved due to personal enmities.

I was a newcomer in 2020 and I didn’t get much help from you or other old members of the board in understanding the past to take decision for the future of TDF.

I had to spend a lot of time reading lots of minutes of past meetings and keep asking difficult questions to get to the point where I could clearly see that some decisions being passed down to us (eg TDC) had issues that haven’t been considered.

It is good to have people like Andreas that point out issues that should be evaluated by newcomers before they fall into a group thinking situation that does not help with addressing problems and moving forward.

I am sorry you do not find this helpful, but being aware of the true history of the project (especially at a time when there are voices trying to reframe history) is very important and refusing to do so may lead to incorrect assumptions and the acceptance of untrue framing.

It is important to learn about the past to plan for the future. Discovering some details that are not widely publicised helps in fixing some issues that have been overlooked.

TDF is not just a small group of friends developing LibreOffice any more, it is now a larger organisation that needs to apply some rules so that it creates a level playing field for everyone that wants to contribute in many ways, not only with code which for some seems to be the only measure if some people or organisations are more equal than others.

And how should users and members should voice their unsettlement,
without risking to be stopped at every corner and called out for
violations of CoC.

By entering into a dialogue. By hearing and evolving compromises with other members through selecting positive elements of their contributions. By collaborating together even when uncomfortable. By respecting the honest contributions of long-time contributors. This place is hardly a close venue.

Compromises and unanimity in decisions would be great but are not always possible as some points of view are too far apart.

Some cling very hard onto their acquired positions and it is very difficult and frustrating to get them to understand that times have changed and that is not only their code that makes TDF, our community and LibreOffice great for all.

Even when compromises have been agreed some decide to walk away and not contribute back to a project like LOOL that isn’t made up only by code but also by lots of contributions from the rest of our community.

How should members voice their concerns when they see entryists harming the project and old unsettled grudges being repeatedly raised regardless of how they are answered?

“Entryists” bring also fresher, different point of views and ask the questions that some don’t want to hear. “Entryists” helped in stopping a project you promoted that would have been damaging for TDF and our community, “entryists” tried to bring clarity on what LOOL really was and found out that reality was different from what was promoted, “entryists” got finally a CoI Policy in place for the board and (IMHO) should implement it also for the ESC, “entryists” are still working on lots of other improvements that will help TDF serve better its community.

So yes, “entryists” should look at both side of the arguments, dig deeper in their merits and then promote the required changes.

I hope you noticed the usefulness of “entryists” and that you will help them with unbiased information in future instead of attacking them because they haven’t conformed with your views.

Sincerely,

Simon

Simon Phipps

TDF Trustee

Ciao

Paolo