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 ;-) Ciao Paolo On 02/06/2022 20:50, laszlo.nem...@documentfoundation.org wrote:
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.pdfIf 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_settingsAnd 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
-- Paolo Vecchi - 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
OpenPGP_signature
Description: OpenPGP digital signature
