New draft of the proposal for in-house developers

[Something went wrong when copy-pasting Lionel's email address to "CC" in the previous email, I've forwarded it to him in private.]

Hi Julien,

thanks a lot for the input!

Michael

PS: I've fixed Lionel's email address now, something went wrong when I copy-pasted it into my previous email.

Hello,

Here are some thoughts about Base.

Some years ago, there was some decision to reduce our Java dependency (a very good thing).

Main point was to replace HSQLDB part by another database (there are good ones like MySQL/MariaDB and Postgresql) but which also allowed embedding, with a compatible license and with a not dead community, so Firebird was chosen.

In addition to Lionel (who is the Base expert for those who don't already know it), there have been 2 people who mainly worked on it: Andrzej J.R. Hunt and Tamas Bunth. The last one had even implemented a tool to migrate automatically from HSQLDB to Firebird.

Andrzej left Firebird part long time ago and Tamas left some years after him (just to be clear, I see no pb here, each one has his life/constraints/desire/whatever)

In parallel, Firebird has been put "in production" as by default embedded database and automatic migration set as by default. A lot of bugtrackers have been created and even if some part has been fixed, there were too much.

So I first put in experimental automatic migration part then Firebird by default + creation part (you can still open a Firebird embedded in non experimental).

Now we use HSQLDB 1.8 which is quite old and Firebird support is not ready, the pb is Lionel has far less availability and there's no one who replaced him. I gave a try to tackle some bugs but I'm not brainy enough to fix harder ones.

Firebird is not the only pb, charts aren't displayed anymore in reports and the whole reports part is dependent on old Java external components.

There are also address books pbs:

- Mac one  (eg : leaks but not only this, Alex may tell more about this I suppose)

- Thunderbird one can't be used anymore after Mork->Sqlite migration.

I also think about Base stumbling on some specific functions added to standard SQL by some databases which can be workaround sometimes but not always.

So yes, hiring 1 or 2 people on Base part could be relevant unless we'd like to abandon Base. Just to put it clearly here too, I'm not speaking for me since I already got a job and above all, wouldn't be able to do this job, I'm rather thinking about Lionel (if he agrees of course! :-)).

I really think a strong decision (hiring people or abandon it) should be made instead of letting it rot.

PS1: I'm adding Robert and Alex here since they're the main QA for Base part and may provide extra info.

PS2: Lionel, don't hesitate to complete (or correct if I made some mistakes) what I said.

Hi *,

So yes, hiring 1 or 2 people on Base part could be relevant unless we'd like to abandon Base.

Only one hint: I have created a database for a company in Germany (Firebird internal → will be moved to PostgreSQL server). Donation of 3000,- € special for Base has been transfered 2022-01-20.

This could be a little start.

There has been much done for Firebird in the last months. But Java dependency will be there with ReportBuilder.

Regards

Robert

Hi all,

See my comments inline under Julien’s.

Le 25/03/2022 à 09:18, Julien Nabet a écrit :

Firebird is not the only pb, charts aren’t displayed anymore in reports and the whole reports part is dependent on old Java external components.

Yes, the issue of charts in reports no longer being displayed is now a very old regression bug.

There are also address books pbs:

  • Mac one (eg : leaks but not only this, Alex may tell more about this I suppose)

At least now, a connection to macAB is possible without crashing in the TDF-provided version - haven’t tried Collabora’s versions yet.

There are a couple of other Mac-specific issues (tdf#50626, tdf#64641) with the macOS addressbook.

  • Thunderbird one can’t be used anymore after Mork->Sqlite migration.

Yes, that’s an issue for everyone - note that system support for Sqlite3 on macOS is included by default in the system, but that doesn’t help much if it can’t be made to talk to LO over the SDB bridge.

This ties in to a lack of built-in support for SQLite in LO in general.

It is likely that any such integration would be perceived by users as a very welcome addition (and not just for Moz addressbook support), but my understanding is that this would not be trivial to implement, as it would be basically be like redoing all of the work for Firebird over again, but this time for SQLite. Given that we are already in a mess with Firebird, having a 2nd mess with incomplete SQLite support might not be the best allocation of resources.

Much as I hate to say it, if resources were to be allocated to Base development, I would much prefer :

  • fixing old regressions, e.g. the chart bug in the report builder;

  • making embedded Firebird the functional equivalent of embedded hsqldb - currently, it is like some awkward reject, shivering in the cold and dark - lots of incremental improvements to be made here;

  • migrating the Java report generator code to C++ - there used to be a native report writer, and it got killed off in favour of Java - however, this would not be a small endeavour.

Of course, if the general thinking in the “dev community” is that database front end support is a dead duck, then it seems unlikely that even TDF would engage resources in it.

Personally, I would find that incredibly sad, and it would take away my raison d’être for using LO, but I’m not going to be King Canute either.

Alex

Thanks Paolo.

No more feedback on the draft from me. Just that IMO having in-house developers in TDF is a must since we have seen something like “why do you think we (C*a) would want to help you in creating a competing product?” when someone asked for help in our developer’s IRC channel. So please do it as soon as possible. The proposal does not need to be 100% perfect; let’s be down to earth and make it better and better.

Regards,

Franklin

Paolo Vecchi <paolo.vecchi@documentfoundation.org> 於 2022年3月23日 週三 下午10:08寫道:

Hi all,

following the initial consultation in regards to the first draft I’ve
included some of the recommendations and comments received.

You can find the new version here:

https://nextcloud.documentfoundation.org/s/d5fF4eCK4JHtpHj

The changes are in italic.

Some of the comment received included preferences for mentors instead of
developers or to further outsource some tasks.
Those preferences will be covered by duly prepared proposals written by
the proponents so they will not be covered in the document I shared.

Other comments received, also from fellow members of the board, stated
that my proposal lacked of clear developers and project management
procedures so I’ve added in page 10 what I see, at least initially, as
the simplest approach but suggestions for improvements are very welcome.

Please do remind me if I forgot to include your constructive feedback!

Ciao

Paolo


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

Thank you for your support for the proposal Franklin.

And thank you again for all your work during last term that contributed in making this proposal possible.

Ciao

Paolo

On 25/03/2022 15:26, Franklin Weng wrote:

Thanks Paolo.

No more feedback on the draft from me. Just that IMO having in-house developers in TDF is a must since we have seen something like “why do you think we (C*a) would want to help you in creating a competing product?” when someone asked for help in our developer’s IRC channel. So please do it as soon as possible. The proposal does not need to be 100% perfect; let’s be down to earth and make it better and better.

Regards,

Franklin

Paolo Vecchi <paolo.vecchi@documentfoundation.org> 於 2022年3月23日 週三 下午10:08寫道:

Hi all,

following the initial consultation in regards to the first draft I’ve
included some of the recommendations and comments received.

You can find the new version here:

https://nextcloud.documentfoundation.org/s/d5fF4eCK4JHtpHj

The changes are in italic.

Some of the comment received included preferences for mentors instead of
developers or to further outsource some tasks.
Those preferences will be covered by duly prepared proposals written by
the proponents so they will not be covered in the document I shared.

Other comments received, also from fellow members of the board, stated
that my proposal lacked of clear developers and project management
procedures so I’ve added in page 10 what I see, at least initially, as
the simplest approach but suggestions for improvements are very welcome.

Please do remind me if I forgot to include your constructive feedback!

Ciao

Paolo


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

Franklin Weng

中華民國軟體自由協會理事長
LibreOffice 導入專家
LibreOffice 法人代表文件基金會董事會副主席、認證委員會委員

Hi Paolo,

Hi all,

following the initial consultation in regards to the first draft I've
included some of the recommendations and comments received.

You can find the new version here:

https://nextcloud.documentfoundation.org/s/d5fF4eCK4JHtpHj

The changes are in italic.

Some of the comment received included preferences for mentors instead
of developers or to further outsource some tasks.
Those preferences will be covered by duly prepared proposals written
by the proponents so they will not be covered in the document I shared.

Other comments received, also from fellow members of the board, stated
that my proposal lacked of clear developers and project management
procedures so I've added in page 10 what I see, at least initially, as
the simplest approach but suggestions for improvements are very welcome.

Please do remind me if I forgot to include your constructive feedback!

I'd suggest to add to the benefits of in-house developers, that it
enables TDF to coach e.g. (more) GSoC students.

Regards,
Andreas

Hi Paolo,

The list is too long to follow. I have few questions here that I don’t find them addressed in the document:

Is that hiring annualy or long term?

( Apologize if this is clear to others. But I don’t know how hiring is done in TDF. )

What’s the lost / cost to TDF if someday the board or future board want to dismiss the developer, in case something bad happens or it doesn’t work out?

After hiring in-house developer, TDF might become a scapegoat directly, for not fixing users bugs.
What would the expected response be?

Is there any preventive measure for the unfair situation mentioned by Michael Stahl[1],
in which enterprise users who deployed for free, and eventually they don’t contribute, then endanger the sustenance of the project?

[1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00290.html

Sincerely,
Mark

Paolo Vecchi <paolo.vecchi@documentfoundation.org> 於 2022年3月23日 週三 下午10:09寫道:

Hi Mark,

On 25/03/2022 23:39, Mark Hung wrote:

Hi Paolo,

The list is too long to follow. I have few questions here that I don’t find them addressed in the document:

Yes the discussion has been taking place over a long period of time and across many threads so it is difficult to get all the answers in an easy way.

To try to make it easier to follow a discussion and the various proposals the “Decidim startup proposal” has been presented for approval in the budget and I hope it will find a full consensus within the board to invest on it.

Is that hiring annualy or long term?

( Apologize if this is clear to others. But I don’t know how hiring is done in TDF. )

It’s a long term employment project, that’s why I asked the board to not consider it as a budget line (like tenders) but as a long term strategic investment.

What’s the lost / cost to TDF if someday the board or future board want to dismiss the developer, in case something bad happens or it doesn’t work out?

The cost to TDF could be 0 or quite a lot, like in any organisation, depending on why the board would want to dismiss an employee.
Employment contracts allow for “trial periods” as far as I know, not an HR expert, where if we see that the new employee doesn’t fit with the organisation he/she can be fairly dismissed while if the new employee and TDF are both happy then I don’t see why there should be any issue with a long term employment.

After hiring in-house developer, TDF might become a scapegoat directly, for not fixing users bugs.
What would the expected response be?

We do what we can with the resources that are made available by users/donors.
Whatever we do there will be complains but I think having the internal resources to tackle issues that otherwise would not progress is an important step forward.

What I hope is that people like you will notice that the proposal tries to create opportunities for better interaction and mutual support in tackling difficult issues.

I’ve read some of your and Shinji’s presentations and that’s one of the many reasons why native languages are at the top of the list of my proposal, together with a11y, as it seems like the vast majority of the global population isn’t yet well served by LibreOffice.

2 in-house developers will not solve all the problems for all the users especially when, as you and Shinji rightly pointed out in your presentations, you must be a native speaker to understand and fix some issues. The xkcd in page 8 of your AsiaCon 2019 presentation is spot on in this case as even having the top developers in-house there is a limited amount of fixes/algorithms they can push if they don’t have your support.

Could you suggest action points and priorities that I can add to the proposal so that we can see how to tackle together some of the issues that are stopping you from contributing and further improving CJK support?

Is there any preventive measure for the unfair situation mentioned by Michael Stahl[1],
in which enterprise users who deployed for free, and eventually they don’t contribute, then endanger the sustenance of the project?

[1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00290.html

It is unfair that millions of LibreOffice users that have the luck of being able to contribute don’t do it as they don’t seem to appreciate the efforts that each one of us put into the community.

It would be even more unfair if we weren’t contributing to LibreOffice for the hundreds of millions of users that are not so lucky and would have no other options.

Of course unfortunately there will be cases where some try to abuse the system and it would be great if we spot all those cases. Most will be spotted while others will go through but hopefully they will be benefiting the majority of users and not specific business cases where companies/institutions could have contributed to it.

Your question lead also to other questions:

What about the tenders we pay for with donors money which could also fix enterprise issues/features?
Should we reject tenders that are not fixing bugs and features that are clearly not for a personal use of LibreOffice?
Should we consider that Japan is a quite wealthy country so language issues should be funded by local enterprises and institutions?

As you see the issue could become much more complex than just having a few fixes slipping through the net.

Our Next Decade Manifesto does not take in consideration the capacity to contribute of each individual, LibreOffice is free of charge for all without distinction.

Funding TDF so that we can all invest in many areas, in and with many communities, is essential and I’m sure that by giving TDF more internal resources to help each others we will also increase the willingness of people to donate (in many ways, not just money) and with a larger user base many organisations will see that is better also for them to invest in improving and supporting LibreOffice and its community.

Sincerely,
Mark

Ciao

Paolo

Paolo Vecchi <paolo.vecchi@documentfoundation.org> 於 2022年3月23日 週三 下午10:09寫道:

Hi all,

following the initial consultation in regards to the first draft I’ve
included some of the recommendations and comments received.

You can find the new version here:

https://nextcloud.documentfoundation.org/s/d5fF4eCK4JHtpHj

The changes are in italic.

Some of the comment received included preferences for mentors instead of
developers or to further outsource some tasks.
Those preferences will be covered by duly prepared proposals written by
the proponents so they will not be covered in the document I shared.

Other comments received, also from fellow members of the board, stated
that my proposal lacked of clear developers and project management
procedures so I’ve added in page 10 what I see, at least initially, as
the simplest approach but suggestions for improvements are very welcome.

Please do remind me if I forgot to include your constructive feedback!

Ciao

Paolo


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

Mark Hung

- making embedded Firebird the functional equivalent of embedded
hsqldb - currently, it is like some awkward reject, shivering in the
cold and dark - lots of incremental improvements to be made here;
- migrating the Java report generator code to C++ - there used to be
a native report writer, and it got killed off in favour of Java -
however, this would not be a small endeavour.

FWIW the firebird and report generator things are the two base issues
that I'm aware of and would love to see progress on.

- fixing old regressions, e.g. the chart bug in the report builder;

This one I'm unaware of. Is this bug#87012 or another?

Of course, if the general thinking in the "dev community" is that
database front end support is a dead duck

FWIW I don't think base a dead duck or that it needs to be excised, but
maybe it's fair to designate it as an area of concern.







Hi Paolo,

Paolo Vecchi <paolo.vecchi@documentfoundation.org> 於 2022年3月27日 週日 上午12:34寫道:

Hi Mark,

On 25/03/2022 23:39, Mark Hung wrote:

Hi Paolo,

The list is too long to follow. I have few questions here that I don’t find them addressed in the document:

Yes the discussion has been taking place over a long period of time and across many threads so it is difficult to get all the answers in an easy way.

To try to make it easier to follow a discussion and the various proposals the “Decidim startup proposal” has been presented for approval in the budget and I hope it will find a full consensus within the board to invest on it.

Is that hiring annualy or long term?

( Apologize if this is clear to others. But I don’t know how hiring is done in TDF. )

It’s a long term employment project, that’s why I asked the board to not consider it as a budget line (like tenders) but as a long term strategic investment.

I wonder if other alternatives have been considered. Ex, tender for a dedicated developer ( to a company or a person ) that under TDF’s board / ESC command, for 1-2 year term, or other forms of one-time development

service. ( I’m not sure if this is legally feasible. ) The way seems less risky to me.

A short term one can still be strategic move to make TDF contribute more code and spend more money on development.

I advice to take the short term approach if the risk can not be managed.

The similar question is about the number of developer hired in the rationale section.

If TDF have more money next year, will the number increased? If we need more, can the fund be raised?

Why the number is 2 instead of 1?

What’s the lost / cost to TDF if someday the board or future board want to dismiss the developer, in case something bad happens or it doesn’t work out?

The cost to TDF could be 0 or quite a lot, like in any organisation, depending on why the board would want to dismiss an employee.
Employment contracts allow for “trial periods” as far as I know, not an HR expert, where if we see that the new employee doesn’t fit with the organisation he/she can be fairly dismissed while if the new employee and TDF are both happy then I don’t see why there should be any issue with a long term employment.

Bad things like

  • The newly hired developer do not get well with other core developers or contributors, being toxic to the community, or turning other developers or contributors away.
  • The performance or capability doesn’t meet the expectation, the number of bug fixes is low, or the developer unable to handle multiple unrelated areas.

may happen.

After hiring in-house developer, TDF might become a scapegoat directly, for not fixing users bugs.
What would the expected response be?

We do what we can with the resources that are made available by users/donors.
Whatever we do there will be complains but I think having the internal resources to tackle issues that otherwise would not progress is an important step forward.

What I hope is that people like you will notice that the proposal tries to create opportunities for better interaction and mutual support in tackling difficult issues.

I’ve read some of your and Shinji’s presentations and that’s one of the many reasons why native languages are at the top of the list of my proposal, together with a11y, as it seems like the vast majority of the global population isn’t yet well served by LibreOffice.

2 in-house developers will not solve all the problems for all the users especially when, as you and Shinji rightly pointed out in your presentations, you must be a native speaker to understand and fix some issues. The xkcd in page 8 of your AsiaCon 2019 presentation is spot on in this case as even having the top developers in-house there is a limited amount of fixes/algorithms they can push if they don’t have your support.

Could you suggest action points and priorities that I can add to the proposal so that we can see how to tackle together some of the issues that are stopping you from contributing and further improving CJK support?

I’ve fixed most of the issues that I felt important and go back to review tdf#83066 from time to time. I did not fix all of CJK issues for various reasons. Ex, I don’t agree with some expected results. Some issues seem to be corner case or document specific. I assume other people can also contribute if they think the unresolved issues important. Personally, I feel that tdf#75790 is a real feature gap for Japanese users. I tried to pick it up when I was available without good progress.

Is there any preventive measure for the unfair situation mentioned by Michael Stahl[1],
in which enterprise users who deployed for free, and eventually they don’t contribute, then endanger the sustenance of the project?

[1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00290.html

It is unfair that millions of LibreOffice users that have the luck of being able to contribute don’t do it as they don’t seem to appreciate the efforts that each one of us put into the community.

It would be even more unfair if we weren’t contributing to LibreOffice for the hundreds of millions of users that are not so lucky and would have no other options.

To be more specific, my concern is the possiblity of turning contributors away.

Besides the situation aforementioned, I would not have become a contributor, if someone had fixed CJK issues for me 8 years ago.

What if you add two developers but lose more or get less?

What if you want to fix more bugs but the number of bug fixed become less?

I felt these should be addressed.

Of course unfortunately there will be cases where some try to abuse the system and it would be great if we spot all those cases. Most will be spotted while others will go through but hopefully they will be benefiting the majority of users and not specific business cases where companies/institutions could have contributed to it.

Your question lead also to other questions:

What about the tenders we pay for with donors money which could also fix enterprise issues/features?

I’m ok if the main focus is the general public or focus areas in foavor of the disadvantages.

Should we reject tenders that are not fixing bugs and features that are clearly not for a personal use of LibreOffice?

I assume the selection of the tender is oversee by the ESC and the board. It should be transparent and benefit the general public or focus areas in favor of the disadvantages instead of enterprises who have the ability to pay for themselves.

Should we consider that Japan is a quite wealthy country so language issues should be funded by local enterprises and institutions?

No, we don’t do that based on whether a country is wealthy or not.

Japanese community as a whole should be treated as the general public.

OTOH, requests from the enterprises should be conidered carefully.

Whether the issue is under CJK category is not the only thing needs to be considered.

Judgement is needed in order not to be abused, that is independent of the country or the language.

As you see the issue could become much more complex than just having a few fixes slipping through the net.

Our Next Decade Manifesto does not take in consideration the capacity to contribute of each individual, LibreOffice is free of charge for all without distinction.

Funding TDF so that we can all invest in many areas, in and with many communities, is essential and I’m sure that by giving TDF more internal resources to help each others we will also increase the willingness of people to donate (in many ways, not just money) and with a larger user base many organisations will see that is better also for them to invest in improving and supporting LibreOffice and its community.

Sincerely,
Mark

Ciao

Paolo

Paolo Vecchi <paolo.vecchi@documentfoundation.org> 於 2022年3月23日 週三 下午10:09寫道:

Hi all,

following the initial consultation in regards to the first draft I’ve
included some of the recommendations and comments received.

You can find the new version here:

https://nextcloud.documentfoundation.org/s/d5fF4eCK4JHtpHj

The changes are in italic.

Some of the comment received included preferences for mentors instead of
developers or to further outsource some tasks.
Those preferences will be covered by duly prepared proposals written by
the proponents so they will not be covered in the document I shared.

Other comments received, also from fellow members of the board, stated
that my proposal lacked of clear developers and project management
procedures so I’ve added in page 10 what I see, at least initially, as
the simplest approach but suggestions for improvements are very welcome.

Please do remind me if I forgot to include your constructive feedback!

Ciao

Paolo


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

Mark Hung

-- 
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](https://www.documentfoundation.org/imprint)

Bad things like

  * The newly hired developer do not get well with other core developers
    or contributors, being toxic to the community, or turning other
    developers or contributors away.
  * The performance or capability doesn't meet the expectation, the
    number of bug fixes is low, or the developer unable to handle
    multiple unrelated areas.

may happen.

Being hired as TDF staff is not equal to becoming a government official or a tenured professor. It is not a position protected for life.

To be more specific, my concern is the possiblity of turning contributors away.

Besides the situation aforementioned, I would not have become a contributor, if someone had fixed CJK issues for me 8 years ago.

Such a negative outcome can be avoided by using the same approach as with the other areas that receive contributions from TDF staff. The key is communicating that we need collaborators and will train new volunteers.

Ilmari

Hi Mark

On 27/03/2022 08:34, Mark Hung wrote:

Hi Paolo,

Paolo Vecchi paolo.vecchi@documentfoundation.org 於 2022年3月27日 週日 上午12:34寫道:

Hi Mark,

It’s a long term employment project, that’s why I asked the board
to not consider it as a budget line (like tenders) but as a long
term strategic investment.

I wonder if other alternatives have been considered. Ex, tender for a dedicated developer ( to a company or a person ) that under TDF’s board/ ESC command, for 1-2 year term, or other forms of one-time development

service. ( I’m not sure if this is legally feasible. ) The way seems less risky to me.

Expert support is not excluded and it might be necessary for complex items where there local expertise like with CJK is necessary.

A short term one can still be strategic move to make TDF contribute more code and spend more money on development.

I advice to take the short term approach if the risk can not be managed.

Our ED and the rest of the team will help in evaluating the risks and I’m sure they’ll be able to make them manageable.

At the end everything we have been doing involves risks and up to know we managed quite well

The similar question is about the number of developer hired in the rationale section.

If TDF have more money next year, will the number increased? If we need more, can the fund be raised?

These are ideas that have been circulating and can be developed further.

Once the developers settled in and structured their work for themselves in collaboration with the rest of the team we could look at marketing campaigns to attract further funding so that we could even include freshly graduated students/interns that could learn how to work on a complex project like LibreOffice.

Why the number is 2 instead of 1?

Because 2 is the first prime number and a good start to create a development team.

Only 1 developer could find himself/herself overwhelmed but 2 could start exchanging ideas, tasks and processes to improve their productivity.

What’s the lost / cost to TDF if someday the board or future
board want to dismiss the developer, in case something bad
happens or it doesn’t work out?

The cost to TDF could be 0 or quite a lot, like in any
organisation, depending on why the board would want to dismiss an
employee.
Employment contracts allow for “trial periods” as far as I know,
not an HR expert, where if we see that the new employee doesn’t
fit with the organisation he/she can be fairly dismissed while if
the new employee and TDF are both happy then I don’t see why there
should be any issue with a long term employment.

Bad things like

  • The newly hired developer do not get well with other core
    developers or contributors, being toxic to the community, or
    turning other developers or contributors away.

That would mean those developers won’t finish their trial period. We need team players with passion and not primadonna.

  • The performance or capability doesn’t meet the expectation, the
    number of bug fixes is low, or the developer unable to handle
    multiple unrelated areas.

may happen.

The important thing is the process and the attitude they show in problem solving. Some may be more productive in an area more than another and it will be our task to get the best out of them. If things don’t work out then we’ll see that quite quickly.

Could you suggest action points and priorities that I can add to
the proposal so that we can see how to tackle together some of the
issues that are stopping you from contributing and further
improving CJK support?

I’ve fixed most of the issues that I felt important and go back to review tdf#83066 from time to time. I did not fix all of CJK issuesfor various reasons. Ex, I don’t agree with some expected results. Some issues seem to be corner case or document specific. I assume other people can also contribute if they think the unresolved issues important. Personally, I feel thattdf#75790 is a real feature gap for Japanese users. I tried to pick it up when I was available without good progress.

Then we should work together to see how we can make progress happen with the new developers and/or by using specialists that can unblock the situation and allow you to keep contributing.

Is there any preventive measure for the unfair situation
mentioned by Michael Stahl[1],
in which enterprise users who deployed for free, and eventually
they don’t contribute, then endanger the sustenance of the project?

[1]
https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00290.html

It is unfair that millions of LibreOffice users that have the luck
of being able to contribute don’t do it as they don’t seem to
appreciate the efforts that each one of us put into the community.

It would be even more unfair if we weren’t contributing to
LibreOffice for the hundreds of millions of users that are not so
lucky and would have no other options.

To be more specific, my concern is the possiblity of turning contributors away.

Besides the situation aforementioned, I would not have become a contributor, if someone had fixed CJK issues for me 8 years ago.

But there are still many areas where contributions have been lacking for various reasons including the fact that they may be too complex to be tackled by a single volunteer. Also in this case the volunteers could help us in identifying how to unblock the situation and allow them to keep contributing.

What if you add two developers but lose more or get less?

What if you want to fix more bugs but the number of bug fixed become less?

We already have fewer developers contributing to fix a range of bugs so adding 2 may help in reducing complexity for some issues and get more to start contributing.

Adding more resources to development and fixing issues that are stopping hundreds of millions of users from using effectively LibreOffice should lead to more users and possibly more contributors.

I felt these should be addressed.

Of course unfortunately there will be cases where some try to
abuse the system and it would be great if we spot all those cases.
Most will be spotted while others will go through but hopefully
they will be benefiting the majority of users and not specific
business cases where companies/institutions could have contributed
to it.

Your question lead also to other questions:

What about the tenders we pay for with donors money which could
also fix enterprise issues/features?

I’m ok if the main focus is the general public or focus areas in foavor of the disadvantages.

Should we reject tenders that are not fixing bugs and features
that are clearly not for a personal use of LibreOffice?

I assume the selection of the tender is oversee by the ESC and the board. It should be transparent and benefit the general public or focus areas in favor of the disadvantages instead of enterprises who have the ability to pay for themselves.

I do agree but sometimes it seems some “enterprise” features slip through the net of the proposed tenders.
AFAIK there is no fixed rule for it.

Should we consider that Japan is a quite wealthy country so
language issues should be funded by local enterprises and
institutions?

No, we don’t do that based on whether a country is wealthy or not.

Japanese community as a whole should be treated as the general public.

OTOH, requests from the enterprises should be conidered carefully.

Whether the issue is under CJK category is not the only thing needs to be considered.

Judgement is needed in order not to be abused, that is independent of the country or the language.

I agree with you.

As you see the issue could become much more complex than just
having a few fixes slipping through the net.

Our Next Decade Manifesto does not take in consideration the
capacity to contribute of each individual, LibreOffice is free of
charge for all without distinction.

Funding TDF so that we can all invest in many areas, in and with
many communities, is essential and I’m sure that by giving TDF
more internal resources to help each others we will also increase
the willingness of people to donate (in many ways, not just money)
and with a larger user base many organisations will see that is
better also for them to invest in improving and supporting
LibreOffice and its community.

Sincerely,
Mark

Please do come to the Board meetings to ask more questions and provide your feedback.

Ciao

Paolo

Hi Franklin,

we have seen something like "why do you think we (C*a) would want to
help you in creating a competing product?" when someone asked for help
in our developer's IRC channel.

  I'm flattered by what I assume is this new C*a contraction of Collabora =)

  Collabora helps its competitors every day - primarily by contributing tons of code to LibreOffice that they can use. Also by working collaboratively with other engineers from competing companies. We give feedback, advice and help on the code - as we do for volunteers - typically in some rough proportion to their estimated contribution.

  We're somewhat less sympathetic to silly questions (RTM) or to attempts by others to leech our time away to support their needs & customers without contributing meaningfully (as/when/if that happens).

  As I regularly say: working on the LibreOffice code is fun - and I'd really recommend actively contributing to the code to everyone so they can get a real feel for how that works first-hand.

  Regards,

    Michael.

tdf#117162 apparently. Seems to work again now with:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=70f3a94949cce612be9eff14fca94976acfc61a4
https://cgit.freedesktop.org/libreoffice/core/commit/?id=78f7bd90b96ac168fdacd1e0cb0693ab3861872a
which maybe helps to unblock things a little in the short term

Hello,

I've read most of the feedback emails, and I want to add these points:

1. The good thing about this proposal is that it addresses many of the declared concerns from the ecosystem companies. This is important because the ecosystem companies and their programmers have a big role in the LibreOffice development. The in-house developers will complement the companies' efforts.

2. Any action in this area may have some drawbacks. While it is good to provide means of minimizing possible problems, it is also good to talk about the price of NOT doing that action. In this case, facing hundreds of issues from 5 to 10 years ago that are still there is a real problem that we should not ignore. Addressing these issues will also benefit ecosystem companies.

3. Some of the mentioned problems and requirements for hiring an in-house developer such as management, accountability and things like that are also relevant for other recruiting attempts. But, I think this proposal should only target things that are specific to hiring developers, and not the general management principles and practices.
On the other hand, because the in-house developers are supposed to work mostly on maintenance tasks that were ignored for a while, clear practices and performance indicators can be defined to guide and measure the success of the developers throughout the projects assigned to them. Adding these to the "project management" section of the proposal can help address the possible concerns.

Regards,
Hossein

Hi Hossein,

thanks for your feedback and support.

I'll follow up shortly with you to see if your experience in joining the team as Developer Community Architect could provide further insights on how to best integrate and manage new in-house developers.

Ciao

Paolo

Hi,

I'm touched that Julien thought of me to be employed to work on Base,
but being fully occupied, and beyond, by my own business, I'm not
available for employ (at reasonable market rates for a programmer).

I do think that the whole scripting ecosystem, and doing SQL
database-driven data entry, analysis, screen-ready and print-ready
reporting etc is a strategically important feature, and my business
became dependent on that. I would gladly enter a consortium or some
other system to pool resources to finance a developer whose job it is
to fix user-blocking bugs, deep issues that only get worse with time
like:

* dependency on HSQLDB1.8
* finishing Firebird integration well,
* dependency on a local copy of an external reporting engine that
   hasn't been updated in ages
* fundamentally fix predictability of the order of events in Base
   scriptable GUI controls (it is a mess of race conditions)
* better PostgreSQL support (such as table/view/... design)

Hi *,

I would gladly enter a consortium or some
other system to pool resources to finance a developer whose job it is
to fix user-blocking bugs,

Next little hint: Donation of 2000,- € to Document Foundation, special Base, 2022-10-11. Have created a database for a second company in Germany.

Regards

Robert