Date: prev next · Thread: first prev next last
2022 Archives by date, by thread · List index


Hi Franklin,.

Why is this better than working with the version Collabora (who actually
contribute to TDF's work) maintain? Why should TDF hire developers to
maintain code for the Taiwanese government?

Sincerely.

Simon


On Fri, Jun 24, 2022 at 5:47 AM Franklin Weng <franklin@goodhorse.idv.tw>
wrote:

Hi,


Here I have a proposal: to have LOOL respository sync to another
LOOL-derived suite:

https://github.com/OSSII/oxool-community

OxOOL is developed by OSSII in Taiwan, derived from LOOL.  It has
commercial version, which is several versions advanced to community
version, while the community version is also open sourced.  Currently
National Development Council Taiwan, the main dominant unit of ODF policy
in Taiwanese government, uses (forks) this community version into
"NDCODFweb":

https://github.com/NDCODF/ndcodfweb

which is also mainly supported by OSSII.

Besides NDCODFWeb and some other Taiwanese government units, OxOOL is also
used in different companies and products.  For example, it is integrated
into ASUS cloud Omnistor Office (
https://www.asuscloud.com/omnistor-office/), OpenFind SecuShare Pro (
https://www.openfind.com.tw/taiwan/secusharepro.html).  It is migrated
into Pou Chen Group (https://www.pouchen.com) and some other big
anonymous companies.  Also, it is deployed in UNAU (
https://www.unau.edu.ar/la-universidad/ ).

OxOOL v4 will be released in a month and can be a good and useful base to
LOOL, also good to the LibreOffice community.

I'm not a representative of OSSII, but the GM of OSSII told me that they
are happy to share the community version.

In this proposal there are two ways to relive LOOL:

1. To sync current LOOL with patches from OxOOL community v4, which may
technically take more time and efforts.

2. Start a new repository from OxOOL community v4, which I'll say that it
is actually a "fast forward" from current status since OxOOL is also
derived from LOOL, though a bit far before. It will be technically easier
than 1., just that maybe some community people may feel uneasy or unhappy
with this way.

Both ways are okay for me, as long as LOOL can be relived.  However no
matter which way, IMO TDF needs to employ in-house developers (independent
from *any* ecosystem member) for rerunning LOOL.  The second option, which
is my prefer option, is a lot easier technically and in-house developers
would just need to (cowork with community members and OSSII to) maintain
LOOL repository.

Features in OxOOL commercial version are mostly (customized) requests from
customers and hence may not necessarily need to be backported (to community
version), but the GM of OSSII also promised that OxOOL Commercial version
functions (which they think good / necessary to be back ported) and
bugfixes will be back ported to LOOL (and OxOOL community version too).

Of course, after reliving LOOL all developers are welcomed to contribute
to LOOL.

Details can be discussed with OSSII.

Regards,
Franklin


-- 
*Simon Phipps*
*TDF Trustee*

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.