Merged proposal for in-house developers at TDF

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

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

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

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