Am 10.06.22 um 12:03 schrieb Jan Holesovsky:
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
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
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.
Impressum (Legal Info)
: 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