Merged proposal for in-house developers at TDF

[laszlo.nemeth]

Hi,

Sorry, I hope my late answer will be as friendly and productive as I intended it to be.

Hi all,

Hi Andreas,

Andreas Mantke píše v Út 31. 05. 2022 v 19:49 +0200:

I'd be curious to know what would be (from the point of TDF's mission
/
statutes) the difference between working on the source code by in-
house
developers and by tendering and paying a commercial company for doing
this work?

I only could see the difference that in one case TDF has full control
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.

The difference is that once you hire a developer / developers, the
development becomes a mandatory expense - TDF has to pay their wage
every month. Also when TDF switches targets, it has to pay for the
time the developers have to spend learning the new area.

On the other hand, the tendering is (and always has been) only budgeted
from the excess, as the last thing after all the other costs (staff,
marketing, infrastructure, etc. etc.) are covered - which gives TDF
much more freedom in the planning: it can decide not to tender at all,
if all the other costs give no room for that (and avoid hard decisions
where to cut - infrastructure? conference? or even jobs?).

I'm not sure if you're really thinking such simply or if you try to
throw smoke grenades further.

It seemed you try to create the impression that a contract of an
in-house-developer is always for livelong and thus a big mandatory
expense for a very long time. But I think you as the general manager of
a commercial company should know better (?).
The management of in-house developer is more lean and direct.

Instead if you tender the development tasks you have to publish and 
advertise the tender, evaluate the bids, evaluate the milestones and the
result(s). This is whole process consumes a lot of work time from TDF
staff, board members and/or volunteers, which will be lacking in other
important areas of the TDF/LibreOffice project then. Because a
commercial company has to calculate in unforeseeable problems and
realize a profit, the price for a tender is much higher. In addition the
number of commercial companies, able to work on such LibreOffice source
code tenders, is - spoken guarded - very clearly laid out. If we would
see such 'diversity' outside of the TDF world we would name it a
monopoly/oligopoly market and wouldn't expect a real competion.

Over all I think the above answer shows that the role of a general
manager of a commercial company, which has some interest in TDF
tendering development, has a huge CoI with the TDF role(s). Thus I'd
expect that this CoI should be solved asap and the appropriate measures
taken  to prevent TDF from further damage.

Jan 'Kendy' Holešovský is not a "general manager" of "a commercial company", but engineering manager of Collabora Productivity, and founder and board member of TDF (https://www.documentfoundation.org/governance/history/, https://www.documentfoundation.org/governance/board/), one of the most productive developers of LibreOffice (2673 core commits, and 1000+ in Online), volunteering in the board, ESC, in the certification committee and on LibO hackfests, and last but not least, one of my kindest ex-colleagues. He tried to explain the risk of in-house development compared to tendering, answering your question. Tendering *guarantees* the result for the money, in-house development doesn't, proofed by my experience, too. The risk is not only losing money, but losing opportunity to fix as many bugs as possible, and losing trust in TDF, reducing volunteering in development (also from volunteering employees and owners of free software developer companies).

I know this risk. I'm a contractor of a 2000-employee company. I develop LibreOffice and mentor (recently) 4 LibreOffice programmers, but mentoring previously a *dozen* other ones, who mostly failed in LibreOffice development. See my presentations about in-house LibreOffice development and mentoring:

http://libreoffice.hu/build-your-libreoffice-development-team/

http://numbertext.org/libreoffice/nemeth_libocon2019.pdf

If you check (the end of the) presentations, it's all about risk-minimization. Hiring has got its difficulties. For example, TDF wants a LibreOffice developer, but one of the applicants, the only certified LibreOffice developer with 15+ years experience is not sympathetic or she asks for too much, so TDF decides to hire someone with professional C++ experience, but without LibreOffice development experience. Why not? You may think naively, that within a few months you can get an experienced LibreOffice developer or development mentor, because LibreOffice is a C++ project. Time doesn't matter, because after having a professional LibreOffice developer, TDF will be able to solve everything. How many months are we talking about? 3, 6 months, or a few dozen, i.e. a few years? Or never? Who knows? In my experience, it depends on several factors, especially resilience and vocation of the applicant, i.e. luck of the employer. We had a quite productive beginner C++ programmer, solving simple LibreOffice bugs continuously from the first month, and medium ones after 1-2 years. But we lost a few senior C++ developers after 6-month continuous frustration, because we were expecting too much from them, i.e. medium LibreOffice developments. And it's very hard to find the long-term flow in LibreOffice development, regarded to the serious difficulties, so a good start doesn't guarantee the good continuation and long-term success (that is why resilience and vocation (i.e. growth mindset) are the key factors over the basic programming skills).

When we talked about these in the board a few months ago, I mentioned these risks, suggesting the following solutions: TDF needs to hire a professional LibreOffice developer (who can mentor the other one, too). TDF must expect monthly results from its developer(s). For example, according to my contract, I have to fix at least 6 issues reported in TDF's bug tracker. This means 2-3 medium-size fixes and 3-4 simple ones (sometimes meaningful parts of a major fix). With this TDF could prevent ineffective in-house development, and likely could prevent firing and hiring the developers month by month. Also risk management of in-house development could prevent frustrating volunteer developers (i.e. volunteering is not so attractive any more, if someone else, especially who doesn't deserve it, gets money for your voluntary work figuratively or really).

About "commercial companies" of our LibreOffice developer community. Our 4-5 free software companies are much, much better, than OpenOffice.org's 1-company model. I have deep confidence in ourselves, because in my opinion, we are still idealistic and dedicated free software developers. I'm thankful to the founders and developers of these companies, founding TDF and establishing the position of LibreOffice. They took the personal financial risk to save LibreOffice, and never stopped volunteering in LibreOffice development and in TDF, so they deserve our greatest trust.

Also tendering and in-house development are not interchangeable. The planned in-house development with 1-2 developers is not a viable option for LibreOffice development without the development activity of a couple dozen developers of these 4-5 companies (Collabora Productivity, allotropia, Red Hat Linux, NISZ, etc.) and unaffiliated developers (https://www.documentfoundation.org/gethelp/developers/). Likely the planned in-house development could spare a few tenders per year for the same or double price. If we are extremely lucky, we could spare much more, but if one of the companies, e.g. my client terminates LibreOffice development (because its long-term "aim to leave the development for the community"), the price could be much higher for the LibreOffice community, because the 1-2 new in-house developers couldn't replace losing 5 or more developers. Check my previous numbers about the real risk: how my client tries to find and keep the good developers continuously.

I'm sure that TDF can minimize the risk of in-house development mentoring following the advice of our developer community, including advice of our highly appreciated free software companies, who primarily develop LibreOffice. But risk remains risk, and tendering still remains more important, because the best results of the possible future in-house development are still dwarfed by the code contribution of our free software companies. Fortunately, because the donations collected by TDF are largely due to the work of our free software companies. So not only LibreOffice, but TDF depends on our free software companies and vice versa. We depends on each other and we trust each other and we work together, and we can talk to each other, that is why we are a community.

Best regards,
László

P.S. It's not only oversimplification, but insinuation speaking about "commercial companies" instead of free software companies or naming their developers, suggesting that employers and employees represent only business interest. Check these:

“Our mission statement is to 'make open source rock'”. Collabora Productivity

“The company allotropia software GmbH provides services, consulting and products around LibreOffice and related opensource projects. Founded in 2020 with 5 long-time developers of the project, its stated mission is to make LibreOffice shine – in as many different shapes and forms as necessary to serve modern needs towards office productivity software.”

“to be the catalyst in communities of customers, contributors, and partners creating better technology the open source way” – Red Hat Linux

“mission of NISZ to promote the spread of open source solutions”.

It's all about free software. For example, I am not only a contractor, owner of a 1-person free software developer company, and volunteer of TDF, but I'm volunteering actively in free software development, too. See the new typographic features of LibreOffice 7.4 developed by me. Except the OOXML compatibility part, it's voluntary work:

https://wiki.documentfoundation.org/ReleaseNotes/7.4#New_typographic_settings

And I'm not alone, developers of our free software companies do similar amounts or more voluntary work for LibreOffice, showing their deep commitment. But also our paid work is all about free software and LibreOffice development. Whose interest is to create mistrust around us, dividing the community? I'm afraid, who doesn't know us and our work and does not even want to know us and our work.

[andreasma]

Hi all,

Hi all,

I think it is just fair to add some small details about the how a CoI
should be processed as food for thoughts and only for the sake of the
argument.

Thus I'd
expect that this CoI should be solved asap and the appropriate
measures
taken  to prevent TDF from further damage.

Are you, a TDF non-member, actually asking me, an _elected_ Board
Member, to step down?  That is a very ridiculous demand.

Removing a CoI does *not* need to result in a stepping down of a
director, nor there is the provision to do so. The Rules of Procedures
for the Board of Directors [1] and specifically the 1.3.2 version of
the CoI Policy that was amended just this year and that is linked at
that page are some nice starting points.

in some cases it could be solved with some smaller steps,
But the board in total (and every directory in person) take the
responsibility for the whole budget and every budget item. And if there
is a CoI regarding the budget, the appropriate measure would be the step
down. There is no possibility of 'cherry picking' regarding budget items
for any of the directors.

Regards,
Andreas

[PaoloVecchi]

Hi Laszlo,

thanks for your extensive explanation which I really appreciate as I appreciate your contributions both during your working hours and as a volunteer.

We surely are all working with passion to reach the same goal and we have specialisations that allow us to view things from different but complementary perspectives.

I know it is difficult to follow long threads where I provided further clarifications about my proposal but what you are saying has already been taken in consideration.

Young and passionate developers with the will to learn and adapt will not replace the tenders, they will start with focusing on areas that haven't been covered by others as much as we wished.

Finding senior C++ or experienced LibreOffice developers willing to mentor is very difficult and/or very expensive as they already have a good and very well paid position so even if they have a huge passion for LibreOffice and our community is unlikely we'll be able to match what some large corporations can offer.

As from my proposal: "The developers will not need to have a narrow specialisation in the proposed areas but a good understanding of them, willingness to learn and to adapt will be necessary characteristics of the candidates.

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

Thanks to the mentors that we already have in our team, if they have the passion and the right attitude, they will grow to become excellent developers and if they wish even join the ranks of mentors in the long run. Not all developers want to become mentors or do presentation in public, some just prefer to focus on the development side and we should enable our team to express their best skills the way they are most comfortable with.

There are surely risks in doing that but I believe there are even bigger risks in not doing it. The biggest risk that we have in doing it is that we invest in forming developers that then might go back on the market and anyway contribute. That's one of our goals anyway. If we get it right we'll have developers that start working on things that other volunteers may want to take on again as they see that things are moving in the right direction.

What is clear is that the process I started with my proposal allowed to bring to light areas that did not receive enough attention and now commercial contributors, volunteers and in-house developers will start working together to fix those areas.

I'm sure there will be a lot of fun to be had for everyone

Ciao

Paolo

[cornouws]

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.

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.

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 )

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

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

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.

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

money). Tendering also preclude TDF (and its staff / developers etc.)
from gaining more knowledge about working on the source code etc.

That does not have to be the case. Anyone is free to study the source etc. And help is all around.

So the positive and interesting aspect in this subject is to find the
areas where that is the case. And it's clear that those have been
defined. And combining development and mentoring is also good for
growing at least the developer base.

Then the only discussion is: what is a sensible way to effectively
manage in house developers/mentors. And, brushing in my opinion here:
the combined knowledge of code, development, and existing needs, is
best found in our ESC, with its broad composition, open meetings etc.

It should be very clear that only TDF (board, ED) are managing the
in-house developer. They are HR manager and the functional manager
(maybe including some senior staff member). The ESC has no mandate to

I respect your opinion, but I do not agree with it.
The ESC is the place where deep knowledge of the product and development is combined. No better place to manage development, I would say.

And in case there is a lot to choose from that is evenly easy/good to develop, I think board and ESC are well capable to come up with a mechanism to get input from the wider community. (Anyway, that would be my advice).

Then: I've mentioned repeatedly that I would love to see a clearly defined one or two year trial period. To learn how managing their work, see what can be done effective and what maybe not, finding combinations with mentoring maybe.

give any advise regarding their work or their area of work (in addition:
if I look at the ESC meeting minutes I could not confirm that there is a
real broad composition; seemed - beside TDF staff - only staff from
three commercial companies attend the meetings usually).

When we talk about power, it is of course the composition of the ESC that matters. If the members find something important is at stake (possibly encouraged by other members) they join. And even non ESC-members can join the meetings and have a saying.
And again, if we find during a trial period that the ESC is not managing the in house development well, the board is there to act - no doubt.

Finally a more general remark. I refuse to accept the thinking in commercial parties on one side against the foundation on the other side It is an artificial one. That TDF is doing well, makes great software, is also thanks to the commercial parties and is also in the benefit of the commercial ecosystem. Commercial entities that, by the way, are build by open source lovers. Maybe we need to learn how to co-exist and cooperate, rather then to fight

Cheers,

Cor

[cornouws]

Hi Paolo,

thanks for your extensive explanation which I really appreciate as I appreciate your contributions both during your working hours and as a volunteer.

We surely are all working with passion to reach the same goal and we have specialisations that allow us to view things from different but complementary perspectives.

I know it is difficult to follow long threads where I provided further

You need help?

clarifications about my proposal but what you are saying has already been taken in consideration.

IMO only partly. It is useful explanation to set realistic expectations.

Young and passionate developers with the will to learn and adapt will not replace the tenders, they will start with focusing on areas that haven't been covered by others as much as we wished.

It is indeed an important outcome of the discussion that there are ways to complement, and not to compete with the commercial ecosystem.

Finding senior C++ or experienced LibreOffice developers willing to mentor is very difficult and/or very expensive as they already have a good and very well paid position so even if they have a huge passion for LibreOffice and our community is unlikely we'll be able to match what some large corporations can offer.

As from my proposal: "The developers will not need to have a narrow specialisation in the proposed areas but a good understanding of them, willingness to learn and to adapt will be necessary characteristics of the candidates.

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

Thanks to the mentors that we already have in our team, if they have the passion and the right attitude, they will grow to become excellent developers and if they wish even join the ranks of mentors in the long

I love your optimism (well, not always), but as you can read in Lászlo's mail: there's huge uncertainty.

run. Not all developers want to become mentors or do presentation in public, some just prefer to focus on the development side and we should enable our team to express their best skills the way they are most comfortable with.

That is true. However more mentoring power is needed to. So if we can combine the two, it's better I would say.

There are surely risks in doing that but I believe there are even bigger risks in not doing it. The biggest risk that we have in doing it is that we invest in forming developers that then might go back on the market

You are thinking about a contract that forbids people to switch?

and anyway contribute. That's one of our goals anyway. If we get it right we'll have developers that start working on things that other volunteers may want to take on again as they see that things are moving in the right direction.

Let me not take that too negative, but I assume developers are driven by the wish to make cool stuff. And there are enough opportunities for that in the source/product.

What is clear is that the process I started with my proposal allowed to bring to light areas that did not receive enough attention and now commercial contributors, volunteers and in-house developers will start working together to fix those areas.

IMO there is clearly room for that. See my mail from 23:17 CET

I'm sure there will be a lot of fun to be had for everyone

Could well be - let's hope it works out fine.

Cheers,
Cor

[mst]

hello Paolo,

Also thanks to Andreas comment about the ESC minutes I had a look at
last week and today's minutes and it seems like Michael Meeks is already
implementing his proposal, transposed mostly by copy/paste by Kendy in
his own proposal (which BTW hasn't been renamed yet), with some
unexplained urgency and without anyone informing the board.

if memory serves (and i'm sorry to say i missed last week's meeting due to
a public holiday), the ESC discussed this topic because there was an
urgency expressed on this list [1] regarding the hiring of in-house
developers/mentors by TDF.

one of the questions with this plan is which problem domains the in-house
developers would be working on, that is, which are the areas that are
actively used but under-maintained currently, so that for example
expertise in such areas could be considered when evaluating applicants.

hence the question was brought to the ESC to draw on the experience of its
members in diverse areas of the code base, and the ESC attempted to come
up with a list of such under-maintained areas in a collective effort, in
order to expedite the TDF hiring process.

the current version of the list, imperfect and unfinished as it is, is
public in the TDF Wiki.

also there was a follow-up discussion on the public mailing list, with
about half a dozen people with various backgrounds - including several
community members who are not in the ESC - provided additional input that
can been taken into account.

in case the board no longer considers hiring to be urgent, or is not
interested in advice prepared by the ESC and sourced from the developer
community, i think the ESC (who i don't speak for, this is just my
personal opinion) would be most happy to stop discussing this topic and
come back to it at a later date; please advise us of your preference in
this regard.

best regards,
michael

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

[ilmari]

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.

Ilmari

[thb]

Hi Ilmari, all,

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

That's a possibility, yeah. But just curious [1], is that currently a
bottleneck for tenders? Since there's you, Cloph, Hossein and Xisco
already, with cumulative many years of development experience.

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

Cheers,

-- Thorsten

[webmink]

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.

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!

Cheers

Simon

–

[PaoloVecchi]

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

[ilmari]

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

[cornouws]

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 * ¯\_(ツ)_/¯

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

[Jan_Holesovsky1]

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

[PaoloVecchi]

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 * ¯\_(ツ)_/¯ 

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

[thb]

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

[andreasma]

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 )

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

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

[Jan_Holesovsky1]

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

[michaelweghorn]

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

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

[andreasma]

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

[PaoloVecchi]

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