Draft document for TDF in-house developers proposal

Dear all,

thanks for the feedback received in the first iteration of this project that started here:

https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00141.html

Thanks to your comments I started writing a more structured proposal with an extended explanation of why I believe TDF should start creating its own development team and what that team will enable us to do.

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

I haven't added an extensive list of bugs or improvements in the main document as I think we should, with your feedback and with TDF's team, create a set of addendum for each area.

Regardless of the progress of this proposal I will ask the board to involve TDF's team to formalise a selection of issues/bugs that need attention in the listed areas so that, depending on the level of readiness of the developers, they can straight away start working on them. I naturally ask all of you to help the team by sharing your point of view in this thread.

Job descriptions will contain the listed areas of expertise, the availability and selection of the candidates will naturally contribute in determining which areas will be tackled first.

Please do let me know what you think of the draft proposal and how it could be improved.

Ciao

Paolo

Hi Paolo,

thanks a lot.

I haven't added an extensive list of bugs or improvements in the main document as I think we should, with your feedback and with TDF's team, create a set of addendum for each area.

Regardless of the progress of this proposal I will ask the board to involve TDF's team to formalise a selection of issues/bugs that need attention in the listed areas so that, depending on the level of readiness of the developers, they can straight away start working on them. I naturally ask all of you to help the team by sharing your point of view in this thread.

By "formalise a selection of issues/bugs", do you mean to to create a list of specific tickets that should be worked on in the mentioned areas? If so, I'm wondering whether that's already needed at this point of the process of trying to find a consensus on the general direction.

I'd expect that creating a proper, ranked list of issues would be a large task by itself, and with the "TDF developer should be(come) the topic expert" approach, I'm wondering whether it wouldn't be enough to identify potential areas to be worked on for now.
For the areas mentioned in your proposal, existing meta bugs/Bugzilla keywords might be a good starting point:

* RTL/CTL: meta bug tdf#43808 [1]
* CJK: meta bug tdf#83066 [2]
* a11y: meta bug tdf#101912 [3], and "accessibility" keyword [4]
* MSO interop: meta bug tdf#107585 [5]
* regressions: "regression" keyword [6]

FWIW, for a11y, a blind user with whom I got into contact via LO's a11y mailing list has also made a personal ranking of issues related to using LO with the NVDA screen reader on Windows that he'll most probably be happy to share with anybody who's interested.

Please do let me know what you think of the draft proposal and how it could be improved.

I'm not familiar with what such kind of document for BoD discussions/decisions should look like in general and I don't want to go too much into detail about specific passages; just a few personal thoughts:

I think the proposal has many good points. I'm not sure whether it already addresses all the concerns others have brought up earlier, but others can certainly speak for themselves best. In any case, I think it would be essential to continue discussing in a constructive way and try to find a consensus together, and having having this document as a basis for discussion now seems very helpful.

My own focus for having developers would be less to "compensate eventual other drops in contributions" (p. 4), since I think the goal there should rather be to ensure an environment where others, including ecosystem companies, are happy to start/continue contributing (more) - which is also explicitly listed as a goal.

Regarding app stores (p. 5), IIRC, Michael (Meeks) suggested to separate that topic from the current discussion, which I think makes sense.
I think it would make sense to focus on identifying non-controversial areas that should be worked on (e.g. what's listed as "Focus areas" from page 6 on) and then see how internal developers could help there, but also leave room to discuss potential alternative solutions.

Regarding interoperability with MSO (p. 6), I don't have the impression that this is in general a neglected topic that would necessarily need special attention from TDF side at this point (in addition to what's already happening e.g. via tenders).

The "Knowledge Sharing" section (p. 5) has this:

The additional positive side of creating a team of in-house developers is that TDF will be able to
accumulate and share knowledge and become the neutral forum where all contributors can
exchange information and learn how to contribute better and more to LibreOffice.

It's not clear to me what exactly is meant by this. I don't see any general need to find a different/additional "forum" to exchange information in addition to what developers already have right now, at least nothing that would directly be related to the question whether or not TDF hires internal developers. (IMHO, TDF developers should in general just participate by the same means that other developers do, though of course they might have a stronger focus on supporting others in learning how to contribute better.)

Best regards,
Michael

[1] https://bugs.documentfoundation.org/showdependencytree.cgi?id=43808&hide_resolved=1
[2] https://bugs.documentfoundation.org/showdependencytree.cgi?id=83066&hide_resolved=1
[3] https://bugs.documentfoundation.org/showdependencytree.cgi?id=101912&hide_resolved=1
[4] https://bugs.documentfoundation.org/buglist.cgi?f1=keywords&list_id=1423830&o1=substring&query_format=advanced&resolution=---&v1=accessibility
[5] https://bugs.documentfoundation.org/showdependencytree.cgi?id=107585&hide_resolved=1
[6] https://bugs.documentfoundation.org/buglist.cgi?f1=keywords&limit=0&list_id=1423829&o1=substring&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_format=advanced&resolution=---&v1=regression

Hi Michael,

thanks for the extensive contribution! :slight_smile:

Hi Paolo,

thanks a lot.

I haven't added an extensive list of bugs or improvements in the main document as I think we should, with your feedback and with TDF's team, create a set of addendum for each area.

Regardless of the progress of this proposal I will ask the board to involve TDF's team to formalise a selection of issues/bugs that need attention in the listed areas so that, depending on the level of readiness of the developers, they can straight away start working on them. I naturally ask all of you to help the team by sharing your point of view in this thread.

By "formalise a selection of issues/bugs", do you mean to to create a list of specific tickets that should be worked on in the mentioned areas? If so, I'm wondering whether that's already needed at this point of the process of trying to find a consensus on the general direction.

I'd expect that creating a proper, ranked list of issues would be a large task by itself, and with the "TDF developer should be(come) the topic expert" approach, I'm wondering whether it wouldn't be enough to identify potential areas to be worked on for now.

Yes the initial plan is to look at the general areas and then the team will work out with the developers which bugs they can start tackling on their own, with mentoring and/or with experts support.

For the areas mentioned in your proposal, existing meta bugs/Bugzilla keywords might be a good starting point:

* RTL/CTL: meta bug tdf#43808 [1]
* CJK: meta bug tdf#83066 [2]
* a11y: meta bug tdf#101912 [3], and "accessibility" keyword [4]
* MSO interop: meta bug tdf#107585 [5]
* regressions: "regression" keyword [6]

Thank you for the pointers, I've already added them to v1.5. Let's see how many other suggestions we'll receive and then I'll probably create dedicated addendum for each area.

FWIW, for a11y, a blind user with whom I got into contact via LO's a11y mailing list has also made a personal ranking of issues related to using LO with the NVDA screen reader on Windows that he'll most probably be happy to share with anybody who's interested.

Are those issues that could be filed as bugs?
The interest is surely there, let me check the best way to have it posted somewhere so that it will be evaluated for internal development and/or tendering.

Please do let me know what you think of the draft proposal and how it could be improved.

I'm not familiar with what such kind of document for BoD discussions/decisions should look like in general and I don't want to go too much into detail about specific passages; just a few personal thoughts:

I think the proposal has many good points. I'm not sure whether it already addresses all the concerns others have brought up earlier, but others can certainly speak for themselves best. In any case, I think it would be essential to continue discussing in a constructive way and try to find a consensus together, and having having this document as a basis for discussion now seems very helpful.

That is the whole point of the document :wink:

At present it contains general guidelines and things we could/should do but with feedback like yours we can start adding more details that will help in guiding us.

My own focus for having developers would be less to "compensate eventual other drops in contributions" (p. 4), since I think the goal there should rather be to ensure an environment where others, including ecosystem companies, are happy to start/continue contributing (more) - which is also explicitly listed as a goal.

The focus is surely to increase the number of contributors and to help ecosystem companies in being successful with business models that bring benefits to them, TDF, LibreOffice and the wider community.

In the document you'll notice that I also wrote "clearly indicates that we need to work to foster new contributors with the help of new in-house developers and mentors."

The in-house developers are actually part of the strategy to help current and new contributors. 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.

Regarding app stores (p. 5), IIRC, Michael (Meeks) suggested to separate that topic from the current discussion, which I think makes sense.
I think it would make sense to focus on identifying non-controversial areas that should be worked on (e.g. what's listed as "Focus areas" from page 6 on) and then see how internal developers could help there, but also leave room to discuss potential alternative solutions.

The first part of the document presents the general strategy and the app stores are part of it. Surely we should start with creating an initial team that starts working on the "Focus Areas" but once they are settled and productive we should consider fulfilling our mission for users that are locked into app stores or just find it more convenient to used them instead of downloading LibreOffice Community from our site.

The topic isn't that controversial as it has been discussed at length in public and within the board.
Even if my preference is to have TDF running the app stores, so that we can reinvest not only in development but also in other projects that help the wider community, there are still 2 proposals for business entities that would do just that and the members of the ecosystem are perfectly fine with it.

Regarding interoperability with MSO (p. 6), I don't have the impression that this is in general a neglected topic that would necessarily need special attention from TDF side at this point (in addition to what's already happening e.g. via tenders).

The link that you provided for the metabug seems to show that there are a couple of bugs or three that need some attention.

The "Knowledge Sharing" section (p. 5) has this:

The additional positive side of creating a team of in-house developers is that TDF will be able to
accumulate and share knowledge and become the neutral forum where all contributors can
exchange information and learn how to contribute better and more to LibreOffice.

It's not clear to me what exactly is meant by this. I don't see any general need to find a different/additional "forum" to exchange information in addition to what developers already have right now, at least nothing that would directly be related to the question whether or not TDF hires internal developers. (IMHO, TDF developers should in general just participate by the same means that other developers do, though of course they might have a stronger focus on supporting others in learning how to contribute better.)

Our goals include "Science and research, particularly in the field of computer science" so the creation of a dedicated development team will allow us to push deeper into areas of research and contribution to LibreOffice development and with those acquired skills we can extend further our other goal which is "Public and professional education".

Over time that could lead to the creation of new events and training material that can be shared to help further potential contributors.

Best regards,
Michael

Ciao

Paolo

Hi Paolo,

thanks for your reply and additional explanations!

Yes the initial plan is to look at the general areas and then the team will work out with the developers which bugs they can start tackling on their own, with mentoring and/or with experts support.

That sounds reasonable.

FWIW, for a11y, a blind user with whom I got into contact via LO's a11y mailing list has also made a personal ranking of issues related to using LO with the NVDA screen reader on Windows that he'll most probably be happy to share with anybody who's interested.

Are those issues that could be filed as bugs?
The interest is surely there, let me check the best way to have it posted somewhere so that it will be evaluated for internal development and/or tendering.

The ranking was actually for bugs that are already in either LO Bugzilla or NVDA's Github issue tracker.
For the LO Bugzilla, this was a subset of the bugs *directly or indirectly* blocking the general a11y meta bug tdf#101912 that I mentioned in my previous email. [1]
More exactly, it were the tickets set as *directly* blocking for the Windows-specific a11y meta bug tdf#60251, the general a11y meta bug tdf#101912 or the sidebar a11y meta bug tdf#103440; Bugzilla query: [2]
(Note how the first link contains direct and indirect dependencies, while the second doesn't, so the second is a subset of the first one.)
For NVDA's issue tracker, it were those bugs that have a LibreOffice/OpenOffice-related tag/label.
Many issues have been reported in both issue trackers and the table maps those to each other.

My own focus for having developers would be less to "compensate eventual other drops in contributions" (p. 4), since I think the goal there should rather be to ensure an environment where others, including ecosystem companies, are happy to start/continue contributing (more) - which is also explicitly listed as a goal.

The focus is surely to increase the number of contributors and to help ecosystem companies in being successful with business models that bring benefits to them, TDF, LibreOffice and the wider community.

In the document you'll notice that I also wrote "clearly indicates that we need to work to foster new contributors with the help of new in-house developers and mentors."

Yes, that's what my "which is also explicitly listed as a goal" was referring to (but which maybe wasn't really clear in my email), and I think that's definitely an important aspect. And from what I understood, this also seemed to be uncontroversial in the BoD meeting about the topic.

The in-house developers are actually part of the strategy to help current and new contributors. 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.

That sounds very good to me.

Regarding app stores (p. 5), IIRC, Michael (Meeks) suggested to separate that topic from the current discussion, which I think makes sense.
I think it would make sense to focus on identifying non-controversial areas that should be worked on (e.g. what's listed as "Focus areas" from page 6 on) and then see how internal developers could help there, but also leave room to discuss potential alternative solutions.

The first part of the document presents the general strategy and the app stores are part of it. Surely we should start with creating an initial team that starts working on the "Focus Areas" but once they are settled and productive we should consider fulfilling our mission for users that are locked into app stores or just find it more convenient to used them instead of downloading LibreOffice Community from our site.

The topic isn't that controversial as it has been discussed at length in public and within the board.
Even if my preference is to have TDF running the app stores, so that we can reinvest not only in development but also in other projects that help the wider community, there are still 2 proposals for business entities that would do just that and the members of the ecosystem are perfectly fine with it.

Thanks for the explanation. My main concern was that "trying to do too many things at the same time" would potentially make finding a consensus harder.

Regarding interoperability with MSO (p. 6), I don't have the impression that this is in general a neglected topic that would necessarily need special attention from TDF side at this point (in addition to what's already happening e.g. via tenders).

The link that you provided for the metabug seems to show that there are a couple of bugs or three that need some attention.

Certainly! There is certainly enough work to engage a multitude of developers in this area (and others). My thought was that - other than other topics mentioned - it generally seems to be less of a "niche" area in which there is generally little interest from others at the moment. Which of course doesn't necessarily disqualify it to be something that TDF might still want to put more focus on.
(Besides the possibility to work on that by employing TDF developers, that topic might alternatively also fit the regular tender process better than other topics; both approaches certainly have their pros and cons.)

Our goals include "Science and research, particularly in the field of computer science" so the creation of a dedicated development team will allow us to push deeper into areas of research and contribution to LibreOffice development and with those acquired skills we can extend further our other goal which is "Public and professional education".

Over time that could lead to the creation of new events and training material that can be shared to help further potential contributors.

Thanks for the additional explanation, that sounds reasonable.

Best regards,
Michael

[1] https://bugs.documentfoundation.org/showdependencytree.cgi?id=101912&hide_resolved=1

[2] https://bugs.documentfoundation.org/buglist.cgi?f1=blocked&list_id=1424027&o1=anywordssubstr&query_format=advanced&resolution=---&v1=60251%20101912%20103440

Hi *,

Michael Weghorn wrote:

> > Regarding interoperability with MSO (p. 6), I don't have the
> > impression that this is in general a neglected topic that would
> > necessarily need special attention from TDF side at this point (in
> > addition to what's already happening e.g. via tenders).
>
> The link that you provided for the metabug seems to show that there are
> a couple of bugs or three that need some attention.

Certainly! There is certainly enough work to engage a multitude of
developers in this area (and others). My thought was that - other than other
topics mentioned - it generally seems to be less of a "niche" area in which
there is generally little interest from others at the moment.

Indeed. The other areas both have a lot of bugs, and almost no fixing
activity. For interop, there's a lot of bug filing
(i.e. community/user interest), but also a lot of bug fixing going
on. The query from Michael currently shows 1973 open, vs. 3055 fixed.

So I agree that beyond the ESC-ranked focus projects, it appears no
intervention from TDF is currently necessary there.

Cheers,

-- Thorsten

Indeed, interop is very far from a neglected topic. Would definitely not include it as a focus area.

Ilmari

Hi Ilmari,

thanks for the feedback.

Indeed, interop is very far from a neglected topic. Would definitely not include it as a focus area.

Ilmari

Is the whole Interoperability area that is well looked after or just MSO?

Any other file formats that need to be improved?

I was also looking at https://www.documentliberation.org and wondering if that would/should be part of the interoperability area that needs more attention.

Ciao

Paolo

Probably some non-MSO formats would fit the category of not being very active, but I don't perceive them as a high priority area based on what users talk about.

Ilmari

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.

Regarding app stores (p. 5), IIRC, Michael (Meeks) suggested to separate that topic from the current discussion, which I think makes sense.
I think it would make sense to focus on identifying non-controversial areas that should be worked on (e.g. what's listed as "Focus areas" from page 6 on) and then see how internal developers could help there, but also leave room to discuss potential alternative solutions.

  Agreed.

once they are settled and productive we should consider fulfilling our
mission for users

  I think arguing that our mission requires us to do something or other in app-stores is controversial, particularly for a fee:

The proposal draft says:
> 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.

  Even if it is the right thing to do - and I think strategically it is an important move to consider how the project gets income in this way I would not say that:

The topic isn't that controversial as it has been discussed at length in public and within the board.

  discussing something at length normally is a good sign of it being somewhat controversial =)

  Last I heard there was still a significant push from some to make all software free of price in every forum.

> Even if my preference is to have TDF running the app stores, so
> that we can reinvest not only in development but also in other
> projects that help the wider community,

  I expect that all proposals here take into account the bigger picture of delivering improvements for LibreOffice; the differences being mostly over structure, control, jurisdiction etc.

> there are still 2 proposals for business entities that would do just
> that and the members of the ecosystem are perfectly fine with it.

  So - I see no necessity to make the proposal more controversial than it needs to be, by pre-deciding that TDF should employ resources to be focused on this: which could be seen to prejudice this decision in line with your preference. I would recommend removing that piece.

  Anyhow - otherwise, as I've said - modulo some deep concerns over decision making on how the new staff are deployed, and this unnecessary angle, I'm mildly supportive (for what it is worth).

  Regards,

    Michael.

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

Hi Michael,

thanks for your feedback.

> 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 ?

The macro categories can be easily worked out but here they are:

Commercial contributors:

  * Collabora
  * CIB->Allotropia

Corporate contributors:

  * RedHat

last i worked there, LibreOffice was a fully supported part of Red Hat Enterprise Linux that customers could and did file enhancement requests for.

  * Assigned (a bit of a mix but volumes don't change much the result)

err, no: these are people who are not contributing as part of their employment, although they *may* be paid Google Summer of Code interns.

the way it works is that or people who contribute at different times with different employers, their contributions for their employer are counted for their employer, while their contributions with no employer are counted as "Assigned".

  * NISZ
  * SIL
  * Munich

Volunteers:

  * Unknown (no official affiliation)

and TDF own contributions.

> 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."

i think what Michael meant is: how do you get an experienced developer to spend 3 hours discussing a problem with a newbie spread across a longer time period and giving them hints to fix it and review their work, instead of simply fixing it themselves in a single session in half the time, if their job title is "developer" and not "mentor".

> 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.

how do you expect to grow the number of companies who bid for tenders if there are not more tenders? N companies bidding for a tender means that N companies spend significant time doing estimations, but N-1 companies get 0 income for that effort.

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.

i guess you aren't familiar with the history of this project, but this was very common in OpenOffice.org times: when a beta was released, suddenly a bunch of people came out of the woodwork to complain very loudly on public lists why bug X or bug Y had not been fixed and how this could possibly be given that this bug is obviously so severe that the product is unusable.

in many cases what happened then is that Sun fixed the bug before the release - a bug which was actually found by some enterprise user who deployed "free" OOo and paid a consultant to file the bug in IssueZilla and then make a noise about it, without paying any developer to actually fix the bug.

Hi Paolo, all,

...
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

Thanks for sharing that!

From the various quotes/texts under ‘Rationale’, there are some that I consider real arguments to consider hiring developers and others expressing random support, but no arguments.
To me, most pressing is improving the work in areas that are badly covered now, so bugs, accessibility issues and maybe some features.
Another option, though it is to be seen of that can be realistically combined with the first, is areas like mentoring and new contributors support.
Various things I read are a sort of: we need in house developers because we need them. It’s an argument too, but not the type I’m looking for.

Then taking – as example – this one: “This drop in contributions, taking the Commercial group back to the 2018 levels, clearly indicates that we need to work to foster new contributors with the help of new in-house developers and mentors.” On what grounds is the statement that this ‘clearly indicates that..’ made? Of course, it could be a possible way to achieve that goal, yes, could be.
A goal that “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” also will come with some requirements and/or circumstances to make that work, I guess. And also that hiring by TDF is (likely to be) a very/the most effective way to achieve those.
I struggle to understand “The additional positive side of creating a team of in-house developers is that TDF will be able to accumulate and share knowledge and become the neutral forum where all contributors can exchange information and learn how to contribute better and more to LibreOffice.” I think this is not meant to say that the current LibreOffice development/team is not providing that?

Among the various concerns that have been shared, and not only by commercial contributors.., for me the most problematic are having a good and realistic process to steer the work, and without possibly introducing in-house fighting left and right, as well as effectiveness of the spending, knowing the challenges for larger/complex code work.

As expressed before, I’m willing to support a clearly defined trial since I consider that a good way to learn what is realistic and what is just wishful thinking.

Cheers,
Cor