Re: Please take personal conflict off-list (was: [board-discuss] Merged proposal for in-house developers at TDF)
hello Paolo, On 02.06.22 19:55, Paolo Vecchi wrote: > > Also thanks to Andreas comment about the ESC minutes I had a look at > last week and today's minutes and it seems like Michael Meeks is already > implementing his proposal, transposed mostly by copy/paste by Kendy in > his own proposal (which BTW hasn't been renamed yet), with some > unexplained urgency and without anyone informing the board. if memory serves (and i'm sorry to say i missed last week's meeting due to a public holiday), the ESC discussed this topic because there was an urgency expressed on this list [1] regarding the hiring of in-house developers/mentors by TDF. one of the questions with this plan is which problem domains the in-house developers would be working on, that is, which are the areas that are actively used but under-maintained currently, so that for example expertise in such areas could be considered when evaluating applicants. hence the question was brought to the ESC to draw on the experience of its members in diverse areas of the code base, and the ESC attempted to come up with a list of such under-maintained areas in a collective effort, in order to expedite the TDF hiring process. the current version of the list, imperfect and unfinished as it is, is public in the TDF Wiki. also there was a follow-up discussion on the public mailing list, with about half a dozen people with various backgrounds - including several community members who are not in the ESC - provided additional input that can been taken into account. in case the board no longer considers hiring to be urgent, or is not interested in advice prepared by the ESC and sourced from the developer community, i think the ESC (who i don't speak for, this is just my personal opinion) would be most happy to stop discussing this topic and come back to it at a later date; please advise us of your preference in this regard. best regards, michael [1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00540.html -- 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
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Paolo, Paolo Vecchi wrote on 02/06/2022 22:59: 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 You need help? :) clarifications about my proposal but what you are saying has already been taken in consideration. IMO only partly. It is useful explanation to set realistic expectations. 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. It is indeed an important outcome of the discussion that there are ways to complement, and not to compete with the commercial ecosystem. 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 I love your optimism (well, not always), but as you can read in Lászlo's mail: there's huge uncertainty. 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. That is true. However more mentoring power is needed to. So if we can combine the two, it's better I would say. 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 You are thinking about a contract that forbids people to switch? ;) 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. Let me not take that too negative, but I assume developers are driven by the wish to make cool stuff. And there are enough opportunities for that in the source/product. 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. IMO there is clearly room for that. See my mail from 23:17 CET I'm sure there will be a lot of fun to be had for everyone ;-) Could well be - let's hope it works out fine. 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 : cor4off...@jabber.org -- 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
Re: [board-discuss] Merged proposal for in-house developers at TDF
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
Re: [board-discuss] Merged proposal for in-house developers at TDF
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
Re: Details about CoI - Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi all, Am 02.06.22 um 16:14 schrieb Emiliano Vavassori: Hi all, I think it is just fair to add some small details about the how a CoI should be processed as food for thoughts and only for the sake of the argument. Il 02/06/22 12:32, Jan Holesovsky ha scritto: Thus I'd expect that this CoI should be solved asap and the appropriate measures taken to prevent TDF from further damage. Are you, a TDF non-member, actually asking me, an _elected_ Board Member, to step down? That is a very ridiculous demand. Removing a CoI does *not* need to result in a stepping down of a director, nor there is the provision to do so. The Rules of Procedures for the Board of Directors [1] and specifically the 1.3.2 version of the CoI Policy that was amended just this year and that is linked at that page are some nice starting points. in some cases it could be solved with some smaller steps, But the board in total (and every directory in person) take the responsibility for the whole budget and every budget item. And if there is a CoI regarding the budget, the appropriate measure would be the step down. There is no possibility of 'cherry picking' regarding budget items for any of the directors. 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
Re: [board-discuss] Merged proposal for in-house developers at TDF
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
Re: Please take personal conflict off-list (was: [board-discuss] Merged proposal for in-house developers at TDF)
Hi Thorsten, On 02/06/2022 19:02, Thorsten Behrens wrote: Dear list, Kendy & Andreas, let me repeat my earlier request to keep the interaction on this list friendly and productive. In particular, don't offend, and try not to be offended. This part of the thread is not making progress towards coming up with a final, merged proposal for in-house developers. thanks for defusing a conversation that was going in the wrong direction but I think that Andreas has brought to the discussion quite a few very good points. It's rather unfortunate that Kendy did not reply in a constructive manner to several of Andreas, IMHO, valid objections to his proposal, some of which go along the lines of what I was about to reply. Also thanks to Andreas comment about the ESC minutes I had a look at last week and today's minutes and it seems like Michael Meeks is already implementing his proposal, transposed mostly by copy/paste by Kendy in his own proposal (which BTW hasn't been renamed yet), with some unexplained urgency and without anyone informing the board. That just reinforced my belief, shared apparently also by Andreas, that a body in which third party companies seem to be able to impose their will should not direct TDF's employees in any way at all. I've asked the board to evaluate the situation to see if further actions should be taken. Thanks a lot, -- Thorsten Ciao Paolo -- 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
Please take personal conflict off-list (was: [board-discuss] Merged proposal for in-house developers at TDF)
Dear list, Kendy & Andreas, let me repeat my earlier request to keep the interaction on this list friendly and productive. In particular, don't offend, and try not to be offended. This part of the thread is not making progress towards coming up with a final, merged proposal for in-house developers. Thanks a lot, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi, Am 02.06.22 um 12:32 schrieb Jan Holesovsky: Hi Andreas, Andreas Mantke píše v St 01. 06. 2022 v 17:23 +0200: Am 01.06.22 um 11:11 schrieb Jan Holesovsky: The difference is that once you hire a developer / developers, the development becomes a mandatory expense - TDF has to pay their wage every month. 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. If you have a look at the history of TDF staff, you will see that only very few people have ever left it. I am very pleased that we have people working for TDF even for around 10 years, and most of the people stay for lng periods - which is great for continuity of course. hey, you showed that you have either no knowledge about staff contract regulations or you try to throw smoke grenades and trick the community again. But I think you as the general manager of a commercial company should know better (?). Unfortunately you are very confused about my role in Collabora it seems. My role is "People Development Manager" - which is a nice sounding title for a mentor. I have no company shares, and no executive role there. The Collabora website shows that you are one of the managers of this commercial company: https://www.collaboraoffice.com/about-us/ And thus it is very obvious that you have no interest in the amount of TDF tenders (for working on LibreOffice source code). You should not try to take the community and the public for a fool. Such behavior disqualified for a role in the board of TDF. Because a commercial company has to calculate in unforeseeable problems and realize a profit, the price for a tender is much higher. On the other hand, the commercial company has to assume there are other competing companies in the process, so every bid is (and has to be) risky and as cheap as possible. Please stop kidding: I currently know only two commercial companies that are able to bid on LibreOffice source code tender. Thus there is no competing market yet. It's more of a monopoly / oligopoly market. And nearly everyone knows about the formation of prices in such market from her / his daily experience. I am not directly involved, but I have heard that Collabora were actually losing money on some tenders, so TDF got a much better deal than it would do with internal developers. And it is not Collabora's fault, it is one of the reasons why "tendering" exists as a tool in general. If that loosing money on tenders would be true, it is clear that you have a CoI with your roles at Collabora and at TDF. 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). I am not a general manager, I have no personal interest in the tenders and I have no shares from the tenders. See above. I have no CoI in the process of drafting the proposal. I have large experience in development and in mentoring, so I have the experience and skills needed for drafting the proposal. And maybe Collabora is also very happy that you have such experience and you are involved in writing proposals for them too? Thus I'd expect that this CoI should be solved asap and the appropriate measures taken to prevent TDF from further damage. Are you, a TDF non-member, actually asking me, an _elected_ Board Member, to step down? That is a very ridiculous demand. A apologize for lèse majesty. You stated correctly that I'm a nobody (not seriously speaking). But seriously: you behave in a way which is unworthy for a leader of an OSS project. The TDF community consists not only from TDF members. And you denigrate all participants which are not TDF member. This damages the whole LibreOffice/TDF community. You should draw the appropriate measures now and avert further damage from TDF/LibreOffice (community). 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
Details about CoI - Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi all, I think it is just fair to add some small details about the how a CoI should be processed as food for thoughts and only for the sake of the argument. Il 02/06/22 12:32, Jan Holesovsky ha scritto: Thus I'd expect that this CoI should be solved asap and the appropriate measures taken to prevent TDF from further damage. Are you, a TDF non-member, actually asking me, an _elected_ Board Member, to step down? That is a very ridiculous demand. Removing a CoI does *not* need to result in a stepping down of a director, nor there is the provision to do so. The Rules of Procedures for the Board of Directors [1] and specifically the 1.3.2 version of the CoI Policy that was amended just this year and that is linked at that page are some nice starting points. Andreas also addressed the whole Board, not directly Jan Holesovsky. As per §8.4 of the Statutes, "The Board of Directors prevents possible conflicts of interest within the foundation." and that statement is binding to the public (since it is in our Statutes), not only if complaints come from members of the Foundation or the community. I'm explicitly being silent on the main topic of the thread or the alleged CoI (for the latter, it is responsibility of the Board, not Jan's nor Emiliano's, to determine if it exists). Cheers, [1]: https://wiki.documentfoundation.org/TDF/BoD_rules -- Emiliano Vavassori syntaxerror...@libreoffice.org OpenPGP_signature Description: OpenPGP digital signature
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Andreas, Andreas Mantke píše v St 01. 06. 2022 v 17:23 +0200: > Am 01.06.22 um 11:11 schrieb Jan Holesovsky: > > > > The difference is that once you hire a developer / developers, the > > development becomes a mandatory expense - TDF has to pay their wage > > every month. > > 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. If you have a look at the history of TDF staff, you will see that only very few people have ever left it. I am very pleased that we have people working for TDF even for around 10 years, and most of the people stay for lng periods - which is great for continuity of course. > But I think you as the general manager of > a commercial company should know better (?). Unfortunately you are very confused about my role in Collabora it seems. My role is "People Development Manager" - which is a nice sounding title for a mentor. I have no company shares, and no executive role there. > Because a > commercial company has to calculate in unforeseeable problems and > realize a profit, the price for a tender is much higher. On the other hand, the commercial company has to assume there are other competing companies in the process, so every bid is (and has to be) risky and as cheap as possible. I am not directly involved, but I have heard that Collabora were actually losing money on some tenders, so TDF got a much better deal than it would do with internal developers. And it is not Collabora's fault, it is one of the reasons why "tendering" exists as a tool in general. > 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). I am not a general manager, I have no personal interest in the tenders and I have no shares from the tenders. I have no CoI in the process of drafting the proposal. I have large experience in development and in mentoring, so I have the experience and skills needed for drafting the proposal. > Thus I'd > expect that this CoI should be solved asap and the appropriate > measures > taken to prevent TDF from further damage. Are you, a TDF non-member, actually asking me, an _elected_ Board Member, to step down? That is a very ridiculous demand. All the best, Kendy -- 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
