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

Hi Andreas,

thanks again for providing a very good analysis of the issues which should be taken in consideration.

Now that finally the objection about the "app stores" has been clarified as the board published the decision the are only a few differences left between my original proposal and this new one.

1) I don't think is a good idea to try to find senior developers willing to mentor as we have already to that are doing an excellent job and are still growing. The new in-house developers may not need to be senior as it's good for TDF to invest in new developers with good experience and allow them to grow with us together with our mentors, the rest of the team and the community. They'll probably grow to become mentors but that shouldn't be the focus now.

2) The new part related getting into long term contract with external provider is premature as we will see who we find, what experience they have and then decide if other experts are needed to help them grow or deal directly with some complex parts as anyway specified in my proposal.

3) During the past year we worked on what TDF can and cannot do as a foundation under German laws and we found that we can do a lot more than previously thought including employing developers.

4) The rest seems to be an effort to have members of TDF's team controlled by the ESC or to impose limitations suggested by commercial contributors. It is clear in many part of the text of the other proposal but this sentence makes things clear for all:

"For avoidance of doubt, by no means the Targeted Developer or TDF leadership by tasking the Targeted Developer can overrule code-related decisions as decided by the ESC."

This could have been tolerated if the ESC were a properly regulated committee with a CoI Policy and a clear history of being a neutral ground for all.

IMHO recent interventions during ESC meetings disqualifies this committee from imposing decisions on any TDF body and employees.

Other elements like contracts with third parties, impositions from third party companies not to work on or something similar to LOOL or not to work on possible future projects that could be interesting for third party companies do not belong to a document related to employing developers. Those areas should be discussed publicly to create clear rules of engagement valid with any third party companies regardless if they are current or future contributors.

In the upcoming version 2.2 of my proposal I've added a paragraph that explicitly excludes that the in-house employees should be bound by any decision from the ESC.

I've read in full the other proposal and while, thanks to comments and suggestions, it seems to be converging back to my original proposal it still creates more issues than anything else.

Now that my initial concerns about a "merged" version have been proven right it would be great to finalise the original proposal if anyone can provide more contributions.

On 10/06/2022 20:13, Andreas Mantke wrote:
Hi all,

Am 10.06.22 um 12:03 schrieb Jan Holesovsky:
Hi Michael,

Thank you for the feedback!  I've updated the document accordingly, see

Michael Weghorn píše v Út 07. 06. 2022 v 14:07 +0000:

Quoting from my previous email:

(I think it definitely makes sense to get deeper into the topic and
cooperate with other organizations and free software projects.
I still think that the main focus should be to achieve practical
improvements in LO. Depending on the target area, I can think of
more or less way that this would naturally involve contributing to
other free software projects etc, but - given limited resource - I
personally wouldn't necessarily see contributing to other projects
or doing research as a main goal by itself, at least not in the
After all, it seems to be a matter of setting priorities how TDF
is spent, and one can decide one way or the other.
I can't judge how well each option fits with the "Development per se
not part of TDF mission" you mention, but to me, doing "development
se" doesn't seem to be less in line with the TDF mission than
money on tenders, as was mentioned elsewhere in one of the threads
I think, in the past, there used to be long discussions whether TDF can
or cannot have developers; so my hope that framing that in a way that
fits the mission by default can help here.

For the moment, I've added the "Developers per se..." there, but I
don't insist, can be further tweaked in whatever way needed, I think.

The board spent a lot of donation money for the LibreOffice development
(and other development tasks) during the last years.
There is no difference between spending money for source code
development and hiring in-house developers for doing such work. If
spending donation money for the development tenders is compatible with
the statutes and the charity status then there is no barrier for hiring
developers. The latter is the better choice because TDF get more impact
on the development process and gain more in-house knowledge. This would
also help TDF e.g. to more easily participate in the GSoC

The hope is that there will be many applicants, and that we'll have
possibility to choose two.  But if there is only one good
candidate, I
think we should not start another round of interviews until we
the experience - because the process is expensive & time consuming.

What about "... will not develop alternative implementations of
Source projects actively maintained by LibreOffice volunteer or
corporate contributors."?

LOOL could be an example, but there is eg. the Kohei's mdds (that
essential for the Calc core), or Moggi's maintenance of cppunit -
hosted on freedesktop, but using LibreOffice bugzilla for
That still seems a bit to be too generic to me.
For the moment, I've at least adapted it to the above, but happy to go
further there, if you can propose a wording please?

Also I was thinking of something like "TDF in-house developers will
encourage up-streaming in case their work ends up as a modification of
an external LibreOffice project." (to target things like PDFium etc.)

OK, I've added the explicit list as examples.

it is not in the interest of TDF / LibreOffice community to exclude
areas of development per se. If the LibreOffice community and the board
thinks the development of a product, a module etc. is important and
necessary for the future / the (further) growth of the program / the
community it had to be able to point his development resources (in-house
or else) into that direction. No commercial / free software company has
the right to distract the foundation from doing that. Thus it is not
appropriate to add such sentences to the proposal.

As above, if there must be an agreement with third parties then that must be valid for all and written in a document that has nothing to do with the employment of new members of the staff.

And from my impression the 'merged proposal' is a paper to prune TDF's
freedom and to support only commercial companies. But such a proposal is
never in the best interest of the foundation and the board should
abstain to vote for such a proposal.

IMHO that proposal isn't viable anymore for many reasons including those expressed above.

I hope we will finally get back to the original purpose of the proposal and approve it ASAP.




## Free Software Advocate
## Plone add-on developer
## My blog:

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:

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


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.