[board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs

El 7/2/22 a las 15:16, Paolo Vecchi escribió:
> Hi all,
>
> many of you voted for me as you wanted me to promote and achieve the 
> goals set in my candidacy statement:
>
> https://listarchives.documentfoundation.org/www/board-discuss/2021/msg00279.html
>
> Point 1 is what leads me once again to share with the community my 
> intention to push forward point 3 and 4 so that you can all provide 
> your objective contributions to help me and the rest of the board in 
> doing the right things for TDF and our community.
>
> The following is a summary of the points that support the need and the 
> feasibility of the proposal:
>
> Enable TDF to contribute more code to LibreOffice with in-house 
> developers to address our donors specific needs
>
>   * As shown by Italo's slides at FOSDEM again and by others, TDF is
>     not contributing as much as it could
>   * Up to now no strategic decisions have been taken to make TDF a
>     more regular and active code contributor
>   * Members of the ecosystem and others also suggested that we should
>     spend more money in development
>   * Bugs, a11y issues and features can be harder to taken care of by
>     volunteers and are not always addressed by the ecosystem
>   * We need to build up internal skills and development capabilities
>     to speed up innovation
>   * Lack of suppliers diversification, mostly 2 at present, is a
>     suboptimal situation for TDF, LibreOffice and its community
>   * Internal developers can grow to cover areas like mentoring and QA
>     while also helping with new contributors support
>   * TDF needs to expand its internal capacity to deal with publishing
>     in app stores directly and manage variable levels of complexity
>     due to ever changing rules
>   * Some proposed projects could be developed internally instead of
>     outsourcing them, which helps to grow in-house skills and capacity
>     to address our donors needs
>   * Potential App Stores revenues may allow for more developers and to
>     invest in developing other projects
>   * Our development mentor together with the team should propose to
>     the BoD projects for internal development
>   * While internal projects may cover different areas tenders and ESC
>     proposals will be also evaluated to avoid effort duplication
>   * This is not "just" a new project, it's an essential and
>     strategical move for TDF to grow further in its second decade
>     which widens the horizon for new visions and opportunities to do
>     more and even better things for LibreOffice and our community
>   * Funds are available for at least 2 developers allowing us to start
>     employing them straight away
>   * Next steps: create and publish the job offers for developers and
>     on-board them ASAP
>
>
> The proposal will be publicly discussed this Friday 11 of February so 
> I'm looking forward to your constructive feedback to make it a better 
> proposal for all.
>
> In the meantime I hope you appreciated my efforts in relation to point 6:
>
> https://blog.documentfoundation.org/blog/2022/01/27/bug-bounties-finding-and-fixing-security-holes-with-european-commission-funds/
>
>
> Ciao
>
> Paolo
> --
> Paolo Vecchi - Deputy 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


I believe that the arguments in favor are way more than enough. TDF must 
set the course and have its own weight within ESC.
In addition, projects that are not attractive to the valuable members of 
the ecosystem could be divided into smaller parts and dealt with within 
the foundation itself.
We must avoid reaching an instance similar to LOOL, where one part 
simply closed the door. In that sense, influence and/or dependence on 
just two providers is not in the best interest of the foundation itself 
or the LibreOffice Community.