Hi,
Sorry, I hope my late answer will be as friendly and productive as I
intended it to be.
On 2022-06-01 17:23, Andreas Mantke wrote:
Hi all,
Am 01.06.22 um 11:11 schrieb Jan Holesovsky:
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.
Regards,
Andreas
--
## Free Software Advocate
## Plone add-on developer
## My blog: http://www.amantke.de/blog
--
To unsubscribe e-mail to:
board-discuss+unsubscr...@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
--
László Németh, Member of the Board of Directors
The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE
Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts
Legal details: https://www.documentfoundation.org/imprint
--
To unsubscribe e-mail to: board-discuss+unsubscr...@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
