Merged proposal for in-house developers at TDF

Hi,

Hi Michael,

Michael Weghorn píše v So 28. 05. 2022 v 21:21 +0000:

(...)

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

But maybe I'm totally wrong and have no knowledge of the real market
economy.

Regards,
Andreas

Hi Paolo,

The intention here (and I would very much like to support that idea),
is to come up with a merged proposal, which then gets broad support.

Broad support by whom?

Up until Collabora Productivity's general manager came out with his own proposal there wasn't much effort being put in it by others in the board.

This is an insinuation and specific framing, not fitting in "Please be helpful, considerate, friendly and respectful towards all other participants."

There has been input from all sides over the past months, and you choosing the ones that are 'constructive' and not working with the ones you find not 'constructive'. We had that discussion before.

You've been asked recently on this list to try to behave and respect the CoC. Please do try.

If there's changes you believe are problematic, please interact with
them.

As above the changes makes it a completely different proposal, just rename it.

Process-wise, my call to work out a proposal how to come to a joint
text (in a small circle) is still open.

I've asked many times but still no answer. Will you one day explain why you keep wanting to have this process behind closed doors?

The proposal was not to have any process behind close doors (again an insinuation..) but to work with Kendy (iirc) to merge all ideas brought in the discussion so that there is one proposal to discuss.

For 3 months there were no sides. The community contributed to the project and once it was ready the representative of a commercial contributor decided to propose a new document.

Similar as above: an insinuation, negative framing and not true.

Cor

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

And obviously, for tendering, TDF should choose projects that fit the
mission, no question about that.

All the best,
Kendy

Hi Andreas,

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

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

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

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.

Cheers,
Cor

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.

Regards,
Andreas

Hi Cor, all,

Hi Andreas,

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

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

And this means TDF need to decide and operate independent from any
commercial company. 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).

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
money). Tendering also preclude TDF (and its staff / developers etc.)
from gaining more knowledge about working on the source code etc.

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

Regards,
Andreas

+1

Paolo

Hi Andreas,

Andreas Mantke píše v St 01. 06. 2022 v 17:23 +0200:

>
> The difference is that once you hire a developer / developers, the
> development becomes a mandatory expense - TDF has to pay their wage
> every month.

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.

If you have a look at the history of TDF staff, you will see that only
very few people have ever left it. I am very pleased that we have
people working for TDF even for around 10 years, and most of the people
stay for loooong periods - which is great for continuity of course.

But I think you as the general manager of
a commercial company should know better (?).

Unfortunately you are very confused about my role in Collabora it
seems. My role is "People Development Manager" - which is a nice
sounding title for a mentor. I have no company shares, and no
executive role there.

Because a
commercial company has to calculate in unforeseeable problems and
realize a profit, the price for a tender is much higher.

On the other hand, the commercial company has to assume there are other
competing companies in the process, so every bid is (and has to be)
risky and as cheap as possible.

I am not directly involved, but I have heard that Collabora were
actually losing money on some tenders, so TDF got a much better deal
than it would do with internal developers. And it is not Collabora's
fault, it is one of the reasons why "tendering" exists as a tool in
general.

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

I am not a general manager, I have no personal interest in the tenders
and I have no shares from the tenders.

I have no CoI in the process of drafting the proposal.

I have large experience in development and in mentoring, so I have the
experience and skills needed for drafting the proposal.

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.

All the best,
Kendy

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.

Andreas also addressed the whole Board, not directly Jan Holesovsky.

As per §8.4 of the Statutes, "The Board of Directors prevents possible conflicts of interest within the foundation." and that statement is binding to the public (since it is in our Statutes), not only if complaints come from members of the Foundation or the community.

I'm explicitly being silent on the main topic of the thread or the alleged CoI (for the latter, it is responsibility of the Board, not Jan's nor Emiliano's, to determine if it exists).

Cheers,

[1]: https://wiki.documentfoundation.org/TDF/BoD_rules

Hi,

Hi Andreas,

Andreas Mantke píše v St 01. 06. 2022 v 17:23 +0200:

The difference is that once you hire a developer / developers, the
development becomes a mandatory expense - TDF has to pay their wage
every month.

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.

If you have a look at the history of TDF staff, you will see that only
very few people have ever left it. I am very pleased that we have
people working for TDF even for around 10 years, and most of the people
stay for loooong periods - which is great for continuity of course.

hey, you showed that you have either no knowledge about staff contract
regulations or you try to throw smoke grenades and trick the community
again.

But I think you as the general manager of
a commercial company should know better (?).

Unfortunately you are very confused about my role in Collabora it
seems. My role is "People Development Manager" - which is a nice
sounding title for a mentor. I have no company shares, and no
executive role there.

The Collabora website shows that you are one of the managers of this
commercial company:

https://www.collaboraoffice.com/about-us/

And thus it is very obvious that you have no interest in the amount of
TDF tenders (for working on LibreOffice source code).

You should not try to take the community and the public for a fool. Such
behavior disqualified for a role in the board of TDF.

Because a
commercial company has to calculate in unforeseeable problems and
realize a profit, the price for a tender is much higher.

On the other hand, the commercial company has to assume there are other
competing companies in the process, so every bid is (and has to be)
risky and as cheap as possible.

Please stop kidding: I currently know only two commercial companies that
are able to bid on LibreOffice source code tender. Thus there is no
competing market yet. It's more of a monopoly / oligopoly market. And
nearly everyone knows about the formation of prices in such market from
her / his daily experience.

I am not directly involved, but I have heard that Collabora were
actually losing money on some tenders, so TDF got a much better deal
than it would do with internal developers. And it is not Collabora's
fault, it is one of the reasons why "tendering" exists as a tool in
general.

If that loosing money on tenders would be true, it is clear that you
have a CoI with your roles at Collabora and at TDF.

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

I am not a general manager, I have no personal interest in the tenders
and I have no shares from the tenders.

See above.

I have no CoI in the process of drafting the proposal.

I have large experience in development and in mentoring, so I have the
experience and skills needed for drafting the proposal.

And maybe Collabora is also very happy that you have such experience and
you are involved in writing proposals for them too?

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.

A apologize for lèse majesty. You stated correctly that I'm a nobody
(not seriously speaking).

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.

You should draw the appropriate measures now and avert further damage
from TDF/LibreOffice (community).

Regards,
Andreas

Dear list, Kendy & Andreas,

let me repeat my earlier request to keep the interaction on this list
friendly and productive.

In particular, don't offend, and try not to be offended. This part of
the thread is not making progress towards coming up with a final,
merged proposal for in-house developers.

Thanks a lot,

-- Thorsten

Hi Thorsten,

Dear list, Kendy & Andreas,

let me repeat my earlier request to keep the interaction on this list
friendly and productive.

In particular, don't offend, and try not to be offended. This part of
the thread is not making progress towards coming up with a final,
merged proposal for in-house developers.

thanks for defusing a conversation that was going in the wrong direction but I think that Andreas has brought to the discussion quite a few very good points.

It's rather unfortunate that Kendy did not reply in a constructive manner to several of Andreas, IMHO, valid objections to his proposal, some of which go along the lines of what I was about to reply.

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.

That just reinforced my belief, shared apparently also by Andreas, that a body in which third party companies seem to be able to impose their will should not direct TDF's employees in any way at all.

I've asked the board to evaluate the situation to see if further actions should be taken.

Thanks a lot,

-- Thorsten

Ciao

Paolo

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.

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

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 :wink:

Ciao

Paolo

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 :wink: )

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 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 :slight_smile:

Cheers,

Cor

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? :slight_smile:

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? :wink:

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 :wink:

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

Cheers,
Cor

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

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

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