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


Hi Cor, all,

Am 01.06.22 um 11:48 schrieb Cor Nouws:
Hi Andreas,

Andreas Mantke wrote on 31/05/2022 19:49:

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

--
## Free Software Advocate
## Plone add-on developer
## My blog: http://www.amantke.de/blog


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