Thanks for your answer,
Andreas Mantke wrote on 01/06/2022 20:13:
Am 01.06.22 um 11:48 schrieb Cor Nouws:
Andreas Mantke wrote on 31/05/2022 19:49:
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
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
And this means TDF need to decide and operate independent from any
I think it is fair to include also the organizations that use
LibreOffice (and make use of services of commercial organizations for
support/improving) as part of our wide community.
And also: TDF is founded thanks to (also, among others) the massive help
of our commercial ecosystem.
TDF with in-house developer could avoid a situation
like the one with LOOL (I'm not sure that this opinion is common ground
inside the current board).
I'm not sure.
LOOL started thanks to tedious hard work with great risk, pushed by the
need to make it an success in the market. For me (having seen commercial
and idealistic activities in many areas) it's hard to imagine that a
voluntary driven foundation can have the same understanding of and
interaction with a business market. But we're diverging a bit too much,
if we redo all the previous discussions on that matter here, I think.
(covering some highlights at a beer, looks better to me ;) )
and has not to pay for the benefit of a commercial company. And thus in
the first case could get reach more targets / tickets done than in the
latter case from my point of view.
It is indeed an interesting question to look at effectiveness of
TDF-spendings. In case it is clear that in house development would
result better work for the foundations goals, that is something we
cannot easily ignore. (I would not be able to set some data there ;) )
But of course other aspects to consider there are: how can TDF be
growing the ecosystem, which I think is one of the most important
challenges of the LibreOffice project, and not compete with the
(Different subject, that as far as I am concerned will be at the table
to work on soon.)
I stated already in another email that tendering produces a lot of
overhead and consumes a lot of TDF/community resources (and also extra
I think you underestimate the costs/overhead of having in house
developers. And for their work too, it is necessary to plan the
activity, evaluate milestones and check the results of in-house developers.
I think you also underestimate the advantages commercially driven
organizations have. (Mind that I'm not at all suggesting that commercial
organizations are the best choice for everything ;) ).
But please read the mail from László: explanation by real life examples.
This is all not to say that there is no room for in house development
(as I repeatedly stated). During this discussion (and in fact quite
early) various areas are noted that are (for obviously market reasons, I
would say) badly covered by commercial ecosystem. So focus on that,
definitely helps, without competing with our commercial ecosystem.
But then still: learning managing in house development, cannot be
underestimated. Also many will try to get their most important features,
pet-bugs fixed etc.. Needs to be handled in a acceptable way too...
money). Tendering also preclude TDF (and its staff / developers etc.)
from gaining more knowledge about working on the source code etc.
That does not have to be the case. Anyone is free to study the source
etc. And help is all around.
So the positive and interesting aspect in this subject is to find the
areas where that is the case. And it's clear that those have been
defined. And combining development and mentoring is also good for
growing at least the developer base.
Then the only discussion is: what is a sensible way to effectively
manage in house developers/mentors. And, brushing in my opinion here:
the combined knowledge of code, development, and existing needs, is
best found in our ESC, with its broad composition, open meetings etc.
It should be very clear that only TDF (board, ED) are managing the
in-house developer. They are HR manager and the functional manager
(maybe including some senior staff member). The ESC has no mandate to
I respect your opinion, but I do not agree with it.
The ESC is the place where deep knowledge of the product and development
is combined. No better place to manage development, I would say.
And in case there is a lot to choose from that is evenly easy/good to
develop, I think board and ESC are well capable to come up with a
mechanism to get input from the wider community. (Anyway, that would be
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 :)
Cor Nouws, member Board of Directors
The Document Foundation, Kurfürstendamm 188, 10707 Berlin
Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts
Legal details: http://www.documentfoundation.org/imprint
GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28 A038 E49D 7365 B134 80A6
mobile : +31 (0)6 25 20 7001
skype : cornouws
blog : cor4office-nl.blogspot.com
jabber : email@example.com
To unsubscribe e-mail to: firstname.lastname@example.org
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.documentfoundation.org/www/board-discuss/
Re: [board-discuss] Merged proposal for in-house developers at TDF · Cor Nouws
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy