Merged proposal for in-house developers at TDF

Hi Simon,

On 03/06/2022 10:59, Simon Phipps wrote:

Hi!

On Fri, Jun 3, 2022 at 7:51 AM Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> wrote:

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.

You may have missed that my proposal already mentions something about it in page 9:

“Their general role will be to fix bugs and features in full, fixing bugs that are blockers for community contributors and to help evaluating which complex tasks should be tackled by external specialists.”

https://nextcloud.documentfoundation.org/s/sFtCk9wiMWbt2pB

It was an excellent idea to make the document editable, thanks Kendy, so I have added some words to this effect. Feel free to improve them!

Another reason why I did not want to share my proposal open for editing to anyone is that it might happen that someone writes something that should not be written in a public document.

Stating the name of a supplier and the way we would want to engage with them could reduce our bargaining power to get the best deal for TDF.

We will publish public tenders open to all ensuring that there will be a level playing field so that any organisation will be able to participate.

Cheers

Simon

Simon Phipps

TDF Trustee

Ciao

Paolo

It's a necessity. I have newbie level experience that I definitely hope to grow alongside all the other interesting tasks. Now I should look in the mirror, give myself a motivational slap in the face and quote László: "How many months are we talking about? 3, 6 months, or a few dozen, i.e. a few years? Or never?"

Ilmari

Hi Paolo,

...
Another reason why I did not want to share my proposal open for editing to anyone is that it might happen that someone writes something that should not be written in a public document.

We want a public discussion (of course not when it does not fit) but prevent people to write in a document because they may write something odd... after all there is this mailing list where * can write * ¯\_(ツ)_/¯ :smiley:

..
We will publish public tenders open to all ensuring that there will be a level playing field so that any organisation will be able to participate.

You may have missed something, but that is standing policy.

Cheers,

Hi Andreas,

Andreas Mantke píše v Čt 02. 06. 2022 v 18:34 +0200:

But seriously: you behave in a way which is unworthy for a leader of
an
OSS project. The TDF community consists not only from TDF members.
And
you denigrate all participants which are not TDF member. This damages
the whole LibreOffice/TDF community.

I'm afraid this is a misunderstanding. I meant to point out that TDF
has the members, the Board and elections for a reason, particularly
when we are talking strategic projects affecting the TDF future.

But after re-reading, I appreciate the paragraph might have sounded
arrogantly. If it offended you, please accept my apology.

All the best,
Kendy

Hi Cor,

Hi Paolo,

...
Another reason why I did not want to share my proposal open for editing to anyone is that it might happen that someone writes something that should not be written in a public document.

We want a public discussion (of course not when it does not fit) but prevent people to write in a document because they may write something odd... after all there is this mailing list where * can write * ¯\_(ツ)_/¯  :smiley:

When you send an email you are responsible for what you write and TDF might become responsible to take down the content from the archives if the content is offensive/illegal.

If you write something in my proposal then I'm also responsible for checking that you are not adding something that could be problematic.

..
We will publish public tenders open to all ensuring that there will be a level playing field so that any organisation will be able to participate.

You may have missed something, but that is standing policy.

We know that but it could be that Simon, with his comment, forgot about it.

Cheers,

Ciao

Paolo

Hi Ilmari,

Ilmari Lauhakangas wrote:

> [1] curious as in - how much weight should that carry, when writing
> the job posting / assessing skills?

It's a necessity. I have newbie level experience that I definitely hope to
grow alongside all the other interesting tasks.

Perhaps I misunderstood the need then - I took it as having general
technical expertise, such as reading code, assessing tests and
deliverables. Those in my experience are relatively generic skills,
and translate well across different areas of the project.

So that's not what you had in mind, but rather deep expertise, to the
level of 'I could have written the code myself'?

Cheers,

-- Thorsten

Hi Cor, all,

Hi Andreas,

Thanks for your answer,

I only could see the difference that in one case TDF has full control

I do not understand what you mean. What is full control over open
source code?

it means control not over the source code per se, but over the direction
of the development from a TDF point of view and the modules etc. TDF
think are useful or needed by the community (and the user of the program
and the donor).

TDF now chooses the projects for the tenders, so already does have
that influence.

a) TDF could choose projects for tenders, but is dependent of commercial
free software companies that want to work on that project and in TDF's
direction. If there is no will or ability to work on a project there
will be no development.

b) TDF has very low impact on the price of the development (because the
market is oligopoly/monopoly).

c) currently there is an impact potentialization of commercial free
software companies from a combination of ESC and board membership. They
have a determining impact in both bodies and that is not really healthy
for a foundation, including and relying not only on developers (but also
community members, which help end users, write documentation, did
marketing etc.).

And this means TDF need to decide and operate independent from any
commercial company.

I think it is fair to include also the organizations that use
LibreOffice (and make use of services of commercial organizations for
support/improving) as part of our wide community.

They could participate in person in the same way as every community
member did. But currently they have no right to stop a development, that
TDF and its community think is important.

And in addition: the commercial companies are not the most important
ones in the community. They are part of it, but there were/are a lot of
people that were/are doing a lot of work (sometimes very tedious),
without TDF/LibreOffice wouldn't be successful.
I got the impression that it would be a step forward, if some developer
and software companies would value highly the work of the non-developer
for the project. It's important to recognize, that LibreOffice is an end
user product and not something running on a server, managed by an admin.

And also: TDF is founded thanks to (also, among others) the massive
help of our commercial ecosystem.

TDF with in-house developer could avoid a situation
like the one with LOOL (I'm not sure that this opinion is common ground
inside the current board).

I'm not sure.
LOOL started thanks to tedious hard work with great risk, pushed by
the need to make it an success in the market. For me (having seen
commercial and idealistic activities in many areas) it's hard to
imagine that a voluntary driven foundation can have the same
understanding of and interaction with a business market. But we're
diverging a bit too much, if we redo all the previous discussions on
that matter here, I think. (covering some highlights at a beer, looks
better to me :wink: )

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.

and has not to pay for the benefit of a commercial company. And
thus in
the first case could get reach more targets / tickets done than in the
latter case from my point of view.

It is indeed an interesting question to look at effectiveness of
TDF-spendings. In case it is clear that in house development would
result better work for the foundations goals, that is something we
cannot easily ignore. (I would not be able to set some data there :wink: )
But of course other aspects to consider there are: how can TDF be
growing the ecosystem, which I think is one of the most important
challenges of the LibreOffice project, and not compete with the
ecosystem.
(Different subject, that as far as I am concerned will be at the table
to work on soon.)

I stated already in another email that tendering produces a lot of
overhead and consumes a lot of TDF/community resources (and also extra

I think you underestimate the costs/overhead of having in house
developers. And for their work too, it is necessary to plan the
activity, evaluate milestones and check the results of in-house
developers.
I think you also underestimate the advantages commercially driven
organizations have. (Mind that I'm not at all suggesting that
commercial organizations are the best choice for everything :wink: ).

But TDF has to do the same for its current staff. Thus it should have
some experience in this field.

But please read the mail from László: explanation by real life examples.

This shows only that life is not always easy. But I think he and others
were able to get enough experience and to work on the LibreOffice code
with passion and success.

Thus if TDF never starts with contracting in-house developer, it will
never be able to improve the source code and operate independent from
the number software companies in the eco system (and there free
development resources).

This is all not to say that there is no room for in house development
(as I repeatedly stated). During this discussion (and in fact quite
early) various areas are noted that are (for obviously market reasons,
I would say) badly covered by commercial ecosystem. So focus on that,
definitely helps, without competing with our commercial ecosystem.

Because there are members of at least four software companies from the
eco system in the board I see no real market for tenders (see my email
to this list from June, 3.

But then still: learning managing in house development, cannot be
underestimated. Also many will try to get their most important
features, pet-bugs fixed etc.. Needs to be handled in a acceptable way
too...

Yes, like the process of tendering (from the ESC listing/voting to the
approval of the contractor work). That process has a big footprint on
the especially the personal resources of the project.

Regards,
Andreas

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