Hi Michael,
thanks for your feedback.
On 25/02/2022 10:22, Michael Meeks wrote:
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.
I did my best to create a proposal that will allow TDF, the wider community and the various ecosystems to grow in an independent and meritocratic way.
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.
Until we have a Decidim instance running where we can test the best ways to collect feedback from the community, the mailing list seems to be the best way to collect and summarise the comments.
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.
TDF’s team is already participating to ESC meetings and with dedicated internal developers participating to those meetings they will add a different point of view to issues resolution and will be able to move faster on focus areas or small bugs, as they won’t need to go through the tendering process, while at the same time verifying with ESC eventual overlaps.
Many members of the ESC are employed by commercial contributors, are involved in proposing tenders to the board and are actually working on them when they win the bid so it will be easy to understand what overlaps and what doesn’t.
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.
IMHO it isn’t “in contrast”, it’s in addition to what is being done by TDF presently. As written in reply to Michael Weghorn:
“Learning by doing (fixing bugs) will help those developers in helping others following the same path while getting rid of issues that commercial contributors and volunteers have overlooked.”
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 ?
Looking at the raw data on the dashboard I wanted to understand a bit more about the trends and the composition of code contributors macro categories.
The why is in the document:
“Differentiating the type of committers is important as TDF’s developers will in general bring benefits to all but in some situations might be seen as being in competition against the commercial contributors so we need to evaluate what effect they may have on their business models while allowing TDF to grow.”
As you have noticed I took “the top 10 contributors over the past 5 full years” as it’s the period when contributors numbers start to stabilise.
The macro categories can be easily worked out but here they are:
Commercial contributors:
- Collabora
- CIB->Allotropia
Corporate contributors:
- RedHat
- Assigned (a bit of a mix but volumes don’t change much the result)
- NISZ
- SIL
- Munich
Volunteers:
- Unknown (no official affiliation)
and TDF own contributions.
I believe lots should be done to see if the “unknown” category could be better understood and find out how we can help groups of contributors in that macro category but that’s something I still have to work as a separate project with the help of the team.
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.
As from previous answer:
“Learning by doing (fixing bugs) will help those developers in helping others following the same path while getting rid of issues that commercial contributors and volunteers have overlooked.”
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.
Will see who will come forward and see what skill sets they have.
When I used to be a developer I also liked to take a break from some complex project and I would dedicate at least one day a week to other projects to learn new things and new approaches to problems.
It did work very well for me and my productivity, maybe it works also for others.
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.
From the tendering point of view I see “a more technical board” more of an issue than a benefit as non negligible number of the “technical” members of the board are also employed by the commercial contributors.
We have a great Conflict of Interest Policy in place, surely the members of the board employed by the companies that will bid on those tenders will not want to get involved in tendering and I’m sure they will propose very soon new transparency measures to make sure that everyone sees that all is done following the rules.
Don’t get me wrong, it’s great to have developers within the board as it has been since the creation of TDF but, IMHO, as TDF has grown and changed quite a lot it would have been also great to have more people that bring point of views that are not strictly related to code contributions.
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.
See the rest of the sentence.
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.
The methods tested up to now to stimulate and diversify the number of more commercial contributors haven’t brought the desired result as it seems like mostly 2 companies bid for those tenders so we’ll have to work harder on it.
We surely need more contributors like NISZ and Munich so there is a lot of work to be done in involving the public sector in LibreOffice.
While during last term the board has been kept busy by other equally important items, during this term this should be one of our main focus.
The proposal to employ in-house developers has been made taking in consideration both the increased amount in donations and reserves so rest assured, as written several times, that TDF will continue to invest also in tenders.
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.
I’m concerned by your comment as you seem to put in doubt the neutrality and the dedication to the wider community of TDF’s team.
Reading it in another way someone may even think that “political machination” tried to stop TDF to fully express its potential for serving the wider community.
Naturally not many people came up with those thoughts so I guess they really aren’t an area of concern for most.
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.
That could be the case for home users but not for the type of organisations that could invest the needed amount of money to fix bugs with a specific SLA.
TDF will not offer those type of services.
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.
I understand your point of view but there must be also a clear a bright line between what TDF can do to support the ecosystem and what the commercial contributors can ask from TDF which is a Foundation with clear rules that it must follow.
Your demand makes it look like TDF should settle only for mentoring because having developers might affect your revenues as commercial contributor and that doesn’t fit at all with the rules that our Foundation must follow.
As written many times, mentoring and even QA are things that developers will do as well but in the meantime they should start looking at the Focus Areas to improve LibreOffice.
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.
These are areas that need serious work and ASAP as we are not only letting down people with incomplete accessibility features, we are also also stopping more than a billion people from using LibreOffice as their languages are not properly supported.
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.
I believe you are fully aware that foundation like public organisations need to follow processes that allow for accountability and transparency.
Surely in-house developers will be able to help speed up the tendering process and make it better for everyone as they will be able to verify and contribute to the specifications while also verify the quality of the deliverables. That’s another win-win situation for all.
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.
I’m not sure where you read that a couple of developers will solve all the issues.
It’s a part of a wider strategy which will help TDF in growing and fulfil its mission.
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.
We do what we do because we like to tackle complex problems so it’s a challenge we should be happy to accept. We’ll find a way to divide complex problems in lots of simple ones and fix them with the help of commercial contributors and external expert providers.
Not doing anything about it would be an actual failure.
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.
It hasn’t been controversial for a long time.
Members of the ecosystem were even pushing to let a third party organisation manage the app stores and the revenues.
As it isn’t an issue for the members of the ecosystem to offload that service to another organisation, I’m sure they will be even happier for TDF to do it and for the revenues to be invested in improving LibreOffice and help the wider community.
ATB,
Michael.
Ciao
Paolo
