On 23/02/2022 16:01, Paolo Vecchi wrote:
Thanks to your comments I started writing a more structured proposal
Thanks for doing that that - it helps. There are some good things about
this proposal that are reasonable.
You can find the draft which starts outlining various concepts and lists
some of the issues we have to address here:
https://nextcloud.documentfoundation.org/s/fM8pCesPnF2JjN4
It's a bit sad it is a PDF, and without any heading numbering, so
rather hard to interact with; an ODT that allowed comments / patching
would be better. Instead I'll quote the text from the document as if
you've mailed it here to comment on it.
I think my biggest concern is ultimately around managing the process of
who decides what TDF should invest in - this is potentially extremely
contentious and emotive over time, as are all ~zero sum resource
decisions. Your proposal has:
> The focus of the in-house developers will be set on specific areas
> suggested for them by TDF’s team in consultation with the ESC and,
> in case of unresolved conflicts, the board."
Our current tendering process is open to everyone to make suggestions
(although estimation bandwidth has to be provided by the ESC). It is
ultimately approved (with the input of the ESC) by the elected board.
I strongly prefer an open process like this that includes the community
and is accountable to them. Of course it's great to have more input from
the staff on priority areas - but I hope they're already well connected
to the tendering process and the ESC.
In contrast - the huge advantage of mentoring as an approach is that
whomever wants to work on something gets help in proportion to their
ability. That tends to solve the problem of working out what to do
fairly - while giving some ability to steer via the creation of
easy-hacks in specific areas etc.
Then I have a few other points:
> In the graph above the committers have been grouped in Commercial
> (companies specialised in selling LibreOffice development and
> products), Corporate (companies and institutions contributing
> voluntarily)
I'm intrigued by this distinction; can you specify which entities
are in which bucket and why ?
> TDF has to develop a strategy which includes the employment
> of internal developers which will both increase the speed of
> development and will help with the on-boarding of new external
> commercial, corporate and volunteer contributors.
Why do you believe that in-house developers (vs. say mentors) will
help with on-boarding new contributors if that is not their focus? My
suspicion is that mentoring is hard and "doing it yourself" is
superficially easy in the short term.
> TDF could start with posting for job positions where experience in
> a11y, RTL, CJK, CTL are to be considered desired skills to see
> if we can already find specialists in areas that have been neglected
> for a while
This is at least a realistic approach if these are the areas to
invest in - then hiring for a specific skill-set looks reasonably
achievable.
> There are many small bugs or small features that, if developed by
> tendering the project, could cost as much as the yearly salary of a
> good developer if adding together the effort of creating the
> tender, the actual cost of the development and the verification of
> the deliverables
Clearly for small tasks - the costs and overhead of the tendering
process are (apparently) grossly excessive. Why this is quite so bad is
unclear to me (having not been involved) - the tenders often arrive
pre-written by the community; the estimation is not done by TDF, only
deciding on bids & procuring, but the flow seems very high latency and
burdensome somehow. Perhaps with a more technical board this term that
is easier to fix.
> Commercial contributors confirm that tenders issued by TDF form a
> negligible part of their income
Collabora publishes numbers on this at the conference each year -
between 0% and 5% of income depending; but still, 5% is not insignificant.
> and the quantity of bugs, features and updates that may require
> tendering or paid for services by the commercial contributors is
> still so vast that it will not affect noticeably their income
While it is true that there may be an inexhaustible amount of work and
TDF will never reduce that by doing some of it, I'm not sure that is
really relevant.
Tendering has been used by TDF to help stimulate, diversify and sustain
the commercial ecosystem around LibreOffice since the beginning. TDF has
a fairly fixed amount of cash - if there is less of that to spend, that
will have a non-trivial impact.
Worse than that though is the possible for TDF to significantly harm
the market for bug-fixing far in excess of any work it can do - by
creating the idea that there is a "free" way to have issues addressed
through political machination at TDF.
That needs extremely careful framing and communication to avoid
drastically lengthening all consultancy horizons around LibreOffice:
which are already lengthened by the "perhaps if we wait, someone else
will fix it for us for free" problem.
You seem to outline some ideas here but I'd like to see those
substantially toughened - there needs to be clear, bright lines between
TDF & ecosystem. Partly that is why I like focused mentoring.
RTL/CTL and a11y seem like good areas to look at IMHO - I agree with
the reasons outlined. Indeed - these are areas that have already
appeared in ESC lists as I understand it.
I agree that in-house staff can potentially make tender execution
happen at-pace, which could be positive for complex things too in the
bigger picture: though I suspect the execution issues around tendering
are structural rather than necessary.
> It should be added that in the tendering process related meta bugs
> don’t seem to be considered as part of the tenders as the
> ramifications represented by interlocking bugs could be seen as very
> difficult to evaluate and to quote.
There is some degree of seeing in-house developers as a panacea here:
cheap, effective, can handle all complexity immediately, are trivial to
manage & motivate (I didn't see any technical leadership or management
provision) etc.
LibreOffice presents some spectacular engineering challenges - and if a
problem is complex and risky to tender it is certainly going to be
complex and risky to deliver - and/or may easily take a nearly unbounded
time, or even fail completely.
> As determined in the past months TDF has in-house competences that
> would allow us to start publishing LibreOffice Community in the
> Windows and Apple app stores at a nominal price.
This is controversial. It doesn't belong in this proposal but will
expand on that in a separate mail.
ATB,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
