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
below:
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
beginning.)
After all, it seems to be a matter of setting priorities how TDF
money
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
is
not part of TDF mission" you mention, but to me, doing "development
per
se" doesn't seem to be less in line with the TDF mission than
spending
money on tenders, as was mentioned elsewhere in one of the threads
already.
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
the
possibility to choose two. But if there is only one good
candidate, I
think we should not start another round of interviews until we
evaluate
the experience - because the process is expensive & time consuming.
What about "... will not develop alternative implementations of
Open
Source projects actively maintained by LibreOffice volunteer or
corporate contributors."?
LOOL could be an example, but there is eg. the Kohei's mdds (that
is
essential for the Calc core), or Moggi's maintenance of cppunit -
hosted on freedesktop, but using LibreOffice bugzilla for
bugreports.
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.
Regards,
Andreas
Ciao
Paolo
--
## Free Software Advocate
## Plone add-on developer
## My blog: http://www.amantke.de/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: https://www.documentfoundation.org/imprint
--
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
