Merged proposal for in-house developers at TDF

Hi Andreas,

Andreas Mantke píše v Ne 05. 06. 2022 v 19:12 +0200:

If I remember correctly TDF has paid a big part of work on the basics
of
LOOL. And maybe some former / current board member recognize which
company was paid for that work from donation money.

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

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

All the best,
Kendy

Hi Kendy, all,

Removal of section "App stores management": As mentioned earlier, I
agree that it makes sense to separate the app store topic from the
current proposal of hiring developers, and focus on areas that are
currently not receiving enough attention otherwise.

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.

(By now, the underlying decision to publish in the app store has already been taken separately. Unless ecosystem members still plan to keep LO up to date with app store requirements for publishing their own LO derivatives, or this is already covered by the team, it seems that this might become an "unmaintained" area. But of course, I am lacking the background of the decision and what was discussed there.)

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

The following passage in that section is a bit unclear to me:

It is also expected that while the Targeted Developer 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.

Can you clarify what that means in practice?

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

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.

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.

Section "Bootstrapping":
The initial proposal suggests to employ 2 developers, while the
modified
one suggests to "start with hiring a single Targeted Developer
initially, with the option to expand this to two if multiple
suitable
candidates present at the interview stage".
What's the practical difference of the initial proposal of planning
to
hire two developers (and then only employing one, if only one
suitable
candidate shows up) and the new proposal?
Does this mostly mean that there will be no further job
advertisement
once a first developer has been employed, or is there more to it?

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.

Section "Concerns expressed by the commercial contributors" has this
under 1):

TDF in-house developers will not compete with commercial
contributors and will not develop alternative implementations of
other Open Source projects.

IMHO, this is a bit too generic, since e.g. "developing (something
in)
LibreOffice" could be seen as developing an alternative to
OpenOffice.org, which is an open source project.

Very good point :slight_smile:

In case that was primarily directed at something specific (e.g. LTS
versions or LOOL): Can that be made more specific? (LTS is already
covered by 4), anyway.)

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

Best regards,
Michael

[1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00610.html

Hi all,

Hi Andreas,

Andreas Mantke píše v Ne 05. 06. 2022 v 19:12 +0200:

If I remember correctly TDF has paid a big part of work on the basics
of
LOOL. And maybe some former / current board member recognize which
company was paid for that work from donation money.

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.

Regards,
Andreas

Hi Andreas,

Hi all,

Hi Andreas,

Andreas Mantke píše v Ne 05. 06. 2022 v 19:12 +0200:

If I remember correctly TDF has paid a big part of work on the basics
of
LOOL. And maybe some former / current board member recognize which
company was paid for that work from donation money.

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.

thanks for the reminder.

Since then Collabora also benefited a lot from TDF's marketing, infrastructure and community support.

That was all part of the discussion which has been ignored during the negotiation to get LOOL made available to the community but then they unilaterally decided to move to GitHub and not backport any fixes or features.

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.

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

I guess anyone can forget to have created the documents that lead to the financing and support by TDF and the community of one of their major projects.

Now that Kendy has been reminded from where LOOL came from he will probably vote differently the request to kill it in the ESC.

Regards,
Andreas

Ciao

Paolo

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