Merged proposal for in-house developers at TDF

Board Discuss
#1

Hi all,

Paolo Vecchi píše v St 25. 05. 2022 v 16:03 +0200:

Could you please at least rename the file so that people don't get
confused?

Good idea, Paolo, thank you. The new version that merges the proposals
is in:

  https://nextcloud.documentfoundation.org/f/960049

as

  TDF-In-House-Developers-Proposal-v2.1.odt

All my changes are change-tracked, so it should make the review
easy. I've also removed some bits that are controversial, and OTOH not
blocking the hiring.

Hope this fits the community needs? - comments much appreciated!

All the best,
Kendy

#2

Hi Kendy,

   TDF-In-House-Developers-Proposal-v2.1.odt

what you wrote in that document has completely changed the logic of the proposal so please do rename that file in something that relates better to its content.

That document clearly contains another proposal which should go its own way instead of trying to make it pass as a "merged" proposal.

Hiring-another-mentor-controlled-by-ESC-v1.0.odt is probably a more indicated name for that new proposal.

Ciao

Paolo

#3

Hi Paolo, all,

Paolo Vecchi wrote:

That document clearly contains another proposal which should go its own way
instead of trying to make it pass as a "merged" proposal.

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.

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

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

Having the two sides that are apparently the furthest apart, telling
each other the text is not ok for the foreseeable future - is not my
idea of a working process.

Cheers,

-- Thorsten

#4

Hi Paolo,

Paolo Vecchi píše v Pá 27. 05. 2022 v 10:58 +0200:

Hiring-another-mentor-controlled-by-ESC-v1.0.odt is probably a more
indicated name for that new proposal.

Hiring: yes.

another-mentor: no; the proposal clearly says the primary role is
development.

    + The secondary mentoring / sharing the knowledge sub-role is
      in line with the TDF mission, and only 'kicks in' when a
      volunteer in the area appears.

    + Rationale: when there are volunteers to work on the area, it
      is not an abandoned area any more, so it is better to use the
      donation money to bring the volunteers up to speed, and start
      focusing on the next Target Area.

controlled-by-ESC: no; the proposal clearly says the Developer is
managed by TDF, and the Target Areas are ultimately decided by the
Board.

    + The role of ESC is important another way - it is necessary to
      avoid situation that the TDF in-house developer is "more equal"
      than the other developers; and the ESC is the only way how to
      make that happen.

    + Rationale: In the StarDivision times, we have already been in
      a situation when some developers were privileged, and it was
      hindering contribution both from volunteers and corporates.

All the best,
Kendy

#5

Hi,

Hi Paolo, all,

Paolo Vecchi wrote:

That document clearly contains another proposal which should go its own way
instead of trying to make it pass as a "merged" proposal.

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.

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?

Having the two sides that are apparently the furthest apart, telling
each other the text is not ok for the foreseeable future - is not my
idea of a working process.

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.

It's quite clear that there are 2 proposals now as the changes proposed completely change the initial one.

Cheers,

-- Thorsten

Ciao

Paolo

#6

Hi Kendy, all,

Good idea, Paolo, thank you. The new version that merges the proposals
is in:

   https://nextcloud.documentfoundation.org/f/960049

as

   TDF-In-House-Developers-Proposal-v2.1.odt

All my changes are change-tracked, so it should make the review
easy. I've also removed some bits that are controversial, and OTOH not
blocking the hiring.

thanks for this.
I think having Paolo's original proposal and this one in a form that's easy to compare is very helpful.

When getting over this, I've primarily looked at the places for which change-tracking was indicating changes.

Hope this fits the community needs? - comments much appreciated!

Some notes/thoughts:

After reading the discussion on the mailing list, I was surprised that the overall direction still seems very similar to the one in Paolo's unmodified proposal.

Various changes look like they were mostly of a stylistic kind, or to formulate things in a less controversial way, without changing the proposal of what should be done. I haven't spent much time thinking about every single one of those in detail, but they look mostly reasonable to me.

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.

Section "The solution: Hire a Targeted Developer": This sounds mostly good to me and if I understand correctly, also mostly fits with what I wrote earlier in the discussion. [1]
With the goal of improving areas that are neglected, having those developers take responsibility for specific "oversight/target areas" (by either improving them themselves or by mentoring others) looks like the right approach to me, and it IMHO makes sense to focus on mentoring others in case capable people interested in working on those areas show up. This way, TDF developers can potentially cover more areas over time, as work is shared.

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?
Is the idea something like "Targeted developer should spend N % of their time on "education purposes", so if that time isn't spent on mentoring other contributors, let's find other ways to do so?
(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.)

Section "Selecting Target Areas": This sounds reasonable to me (applying a similar process to the tendering one and have ESC suggest, but BoD ultimately decide on target areas).

Section "Project management" has this:

The Targeted Developer will have the same rules, rights and conditions
as any other volunteer or corporate contributor to the code under TDF
umbrella. Overlaps or prioritisations that find no clear conclusion
between the Targeted Developer and the ESC will be decided by an ESC
vote, as is standardized for any overlaps in the development of the
LibreOffice code, and applicable to all volunteer and corporate
developers. For avoidance of doubt, by no means the Targeted Developer
or TDF leadership by tasking the Targeted Developer can overrule
code-related decisions as decided by the ESC.

I completely agree to the first sentence.

However, the part that ESC has the ultimate decision in case of overlap or prioritisation replaces one in Paolo's proposal where BoD would have the ultimate decision there.

I think it would be in line with the previous section "Selecting Target Areas" if BoD would have the final say when it comes to prioritisation of target areas/tasks for the developer(s) (which I *thought* was what Paolo's proposal meant to say).

In case of different opinions on a more technical level I'd completely agree that ESC should be the committee that would have the final say, just as is the case for any other contributor. (The last sentence seems to fit well with this.)

As I understand it, your reply to Paolo [2] seems to be in line with this, but can you please clarify this?

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?
(Given that the section mentions that this will be re-evaluated after a year, I personally don't have a strong opinion on this either way, but if the budget to employ two targeted developers is there, I'd see no need to limit this to one.)

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

Best regards,
Michael

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

#7

Hi Paolo, all,

Paolo Vecchi wrote:

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

It was right there in one of my emails you were answering to; let me
paste it:

Thorsten wrote:

It is one option to make effective progress. As you state, it
appears that all people with an opinion have spoken up here; what's
now left to do, is to come up with a document, for which many (if
not all) directors can stand behind it. If community members like
Michael Weghorn or Michael Meeks would like to be part of that
working group, we should of course consider that, too.

What we ideally need, is *one* consolidated proposal. I'm grateful for
Kendy taking the initiative, and starting one.

It's quite clear that there are 2 proposals now as the changes proposed
completely change the initial one.

Then lets please interact with the changes, such that we can iterate
this to a single joint text.

Cheers,

-- Thorsten

#8

Hi Michael,

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

I think having Paolo's original proposal and this one in a form
that's
easy to compare is very helpful.

Thank you!

After reading the discussion on the mailing list, I was surprised
that
the overall direction still seems very similar to the one in Paolo's
unmodified proposal.

Indeed - I'm trying to find the middle ground...

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.

Section "The solution: Hire a Targeted Developer": This sounds
mostly
good to me and if I understand correctly, also mostly fits with what
I
wrote earlier in the discussion. [1]
With the goal of improving areas that are neglected, having those
developers take responsibility for specific "oversight/target areas"
(by
either improving them themselves or by mentoring others) looks like
the
right approach to me, and it IMHO makes sense to focus on mentoring
others in case capable people interested in working on those areas
show
up. This way, TDF developers can potentially cover more areas over
time,
as work is shared.

Perfect.

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?

Section "Selecting Target Areas": This sounds reasonable to me
(applying
a similar process to the tendering one and have ESC suggest, but BoD
ultimately decide on target areas).

Great.

Section "Project management" has this:

> The Targeted Developer will have the same rules, rights and
> conditions
> as any other volunteer or corporate contributor to the code under
> TDF
> umbrella. Overlaps or prioritisations that find no clear conclusion
> between the Targeted Developer and the ESC will be decided by an
> ESC
> vote, as is standardized for any overlaps in the development of the
> LibreOffice code, and applicable to all volunteer and corporate
> developers. For avoidance of doubt, by no means the Targeted
> Developer
> or TDF leadership by tasking the Targeted Developer can overrule
> code-related decisions as decided by the ESC.

I completely agree to the first sentence.

However, the part that ESC has the ultimate decision in case of
overlap
or prioritisation replaces one in Paolo's proposal where BoD would
have
the ultimate decision there.

I think it would be in line with the previous section "Selecting
Target
Areas" if BoD would have the final say when it comes to
prioritisation
of target areas/tasks for the developer(s) (which I *thought* was
what
Paolo's proposal meant to say).

In case of different opinions on a more technical level I'd
completely
agree that ESC should be the committee that would have the final
say,
just as is the case for any other contributor. (The last sentence
seems
to fit well with this.)

As I understand it, your reply to Paolo [2] seems to be in line with
this, but can you please clarify this?

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

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.

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

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

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

Very good point :slight_smile:

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

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

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

All the best,
Kendy

#9

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

#10

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

#11

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

#12

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

#13

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

#14

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

#15

+1

Paolo

#16

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

#17

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

#18

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

#19

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

#20

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

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.