Date: prev next · Thread: first prev next last
2022 Archives by date, by thread · List index


Hi Andreas,

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

it means control not over the source code per se, but over the direction
of the development from a TDF point of view and the modules etc. TDF
think are useful or needed by the community (and the user of the program
and the donor).

TDF now chooses the projects for the tenders, so already does have that influence.

And this means TDF need to decide and operate independent from any
commercial company.

I think it is fair to include also the organizations that use LibreOffice (and make use of services of commercial organizations for support/improving) as part of our wide community.

And also: TDF is founded thanks to (also, among others) the massive help of our commercial ecosystem.

     TDF with in-house developer could avoid a situation
like the one with LOOL (I'm not sure that this opinion is common ground
inside the current board).

I'm not sure.
LOOL started thanks to tedious hard work with great risk, pushed by the need to make it an success in the market. For me (having seen commercial and idealistic activities in many areas) it's hard to imagine that a voluntary driven foundation can have the same understanding of and interaction with a business market. But we're diverging a bit too much, if we redo all the previous discussions on that matter here, I think. (covering some highlights at a beer, looks better to me ;) )

and has not to pay for the benefit of a commercial company. And thus in
the first case could get reach more targets / tickets done than in the
latter case from my point of view.

It is indeed an interesting question to look at effectiveness of
TDF-spendings. In case it is clear that in house development would
result better work for the foundations goals, that is something we
cannot easily ignore. (I would not be able to set some data there ;) )
But of course other aspects to consider there are: how can TDF be
growing the ecosystem, which I think is one of the most important
challenges of the LibreOffice project, and not compete with the
ecosystem.
(Different subject, that as far as I am concerned will be at the table
to work on soon.)

I stated already in another email that tendering produces a lot of
overhead and consumes a lot of TDF/community resources (and also extra

I think you underestimate the costs/overhead of having in house developers. And for their work too, it is necessary to plan the activity, evaluate milestones and check the results of in-house developers. I think you also underestimate the advantages commercially driven organizations have. (Mind that I'm not at all suggesting that commercial organizations are the best choice for everything ;) ).

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

This is all not to say that there is no room for in house development (as I repeatedly stated). During this discussion (and in fact quite early) various areas are noted that are (for obviously market reasons, I would say) badly covered by commercial ecosystem. So focus on that, definitely helps, without competing with our commercial ecosystem.

But then still: learning managing in house development, cannot be underestimated. Also many will try to get their most important features, pet-bugs fixed etc.. Needs to be handled in a acceptable way too...

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

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

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

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

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

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

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

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

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

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

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

Cheers,

Cor

--
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  : cor4office@jabber.org


--
To unsubscribe e-mail to: board-discuss+unsubscribe@documentfoundation.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.documentfoundation.org/www/board-discuss/
Privacy Policy: https://www.documentfoundation.org/privacy

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: 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.