Update to today's call agenda

A survey form would be the best way to go about it.

Also note that - regardless of package availability - as conceived Libreoffice Online is beyond the scope of most individuals as it requires access to cloud infrastructure, familiarity with certificates and a willingness to manage web security. That's why I have proposed LiOn Pi, which is targeted at individuals.

At least a sysadmin would be willing to deal with, but as far as I know currently is hard enough even for such profiles.

Hi Heiko, all,

Heiko Tietze wrote:

So what I'd need for a survey is a couple of simple questions that
everybody can answer. My preferred type of question is
multiple-choice with additional "Other" option.

Thus my (perhaps unintuitive) suggestion to start discussing the
details on the design list - Daniel already listed a number of
different personas (members, certified professionals, and sysadmins),
and it is not unreasonable to assume they might have different needs.

Cheers,

-- Thorsten

The point has to do with the smooth process they/any must find when deploying such a solution.

On Fri, May 22, 2020 at 4:37 PM Daniel Armando Rodriguez <drodriguez@documentfoundation.org> wrote:

El 2020-05-22 10:33, Heiko Tietze escribiĆ³:

On 22.05.20 16:09, Simon Phipps wrote:

A survey form would be the best way to go a about it

Happy to support this but no idea how to start. Ordinary users cannot
answer ā€œWhatā€™s the best solution for you to get LOOL?ā€ neither ā€œWhich
kind of authentication do you prefer? [OpenFoo, LibreBar, PublicQux]ā€.
And isnā€™t the setup kind of a stack that needs to be installed with
(Next)Cloud, LOOL backend, and (COOL)-UI?

So what Iā€™d need for a survey is a couple of simple questions that
everybody can answer. My preferred type of question is multiple-choice
with additional ā€œOtherā€ option.

In this case our end user should understood, IMO, be Certified
professionals, members or IT responsible people.

So, maybe this thread can drop such questions as a result.

That is not acceptable. We should be serving the public, not a technical elitre.

S.

Hi all,

in September 2019, to get another project up and running (in which the
main component is NextCloud), I found myself working on LibreOffice Online.

This was totally a pain. The lack of any consistent documentation (until
May 5 in the INSTALL file there was just written "Left as an exercise to
the reader") was one of the biggest problems. The only way was to rely
on old blog posts found on the internet.

Another totally undocumented topic (obviously I refer to the official
documentation on wiki.documentfoundation.org) was the configuration of a
reverse proxy to work with LOOL, essential since configuring LOOL to use
a non-self signed certificate is even harder.

I experienced how the community was once helpful (e.g. addressing me to
the l10n-docker-nightly and explaining the branches) and once, let's
say, less helpful (quote from the IRC "and why do you think we
(Collabora) would want to help you in creating a competing product?").
Needless to say, this has left me stunned: certainly if I write to the
community I don't expect someone to judge if I'm able to declare a
variable in Javascript or not.

Since then, however, much has been done: Online now has at least a
decent documentation which covers the build of a stable version of the
docker container. Many information are though still missing, a reliable
evaluation of the resources needed to have a stable instance and how
many users it could serve, for example. Clustering LOOL even seems to be
an untouched topic for now (to the public, at least).

Therefore, I totally endorse Paolo's proposal. TDF should, in my
opinion, definitely release working stable binaries of online. Many many
associations out there don't have the money or simply don't need a
professional support just the same way it happens for the client version.

I even agree with Simon: deploying online is horribly hard. I've been
working on some Ansible playbook since a while and I think they could be
soon released. The aim is to provide sysadmins (even myself) an easy way
to deploy LOOL. If we have on the Docker HUB an arm64/amrhf image,
having it working on a RaspberryPi would be just a side effect.

All the best,

Marco

Hi Marco,

Therefore, I totally endorse Paolo's proposal. TDF should, in my
opinion, definitely release working stable binaries of online. Many many
associations out there don't have the money or simply don't need a
professional support just the same way it happens for the client version.

Thanks for bringing this forward and good to see a future contributor
possibly :wink:

What you say, is a clear statement, that we all - the full community -
will think and discuss about when the 'start document', that has been
decided in today's board meeting. I hope that can be ready soon, since
it's a very important and hot topic. I hope you also appreciated the
other parts of the meeting of course.

Greetings,
Cor

Cor Nouws kirjoitti 22.5.2020 klo 22.15:

Hi Marco,

Therefore, I totally endorse Paolo's proposal. TDF should, in my
opinion, definitely release working stable binaries of online. Many many
associations out there don't have the money or simply don't need a
professional support just the same way it happens for the client version.

Thanks for bringing this forward and good to see a future contributor
possibly :wink:

Marco has already written docs in the wiki for some months:
https://wiki.documentfoundation.org/Development/BuildingOnline
https://wiki.documentfoundation.org/Configuring_a_reverse_proxy_for_LOOL

Ilmari

Hi,

This was totally a pain. The lack of any consistent documentation (until
May 5 in the INSTALL file there was just written ā€œLeft as an exercise to
the readerā€) was one of the biggest problems. The only way was to rely
on old blog posts found on the internet.

Until recently the consensus was that TDF releases source tarballs for LOOL. So there was no demand to write documentation how to create packages, how to build a ā€œproductā€.

On the other hand it is fully documented in the source code in README files how to build as a developer, if someone wanted to hack on the code.

The docker/l10n-docker-nightly.sh is also quite self-explanatory. (For those, who donā€™t know what it is: it builds a docker image from source.)

Another totally undocumented topic (obviously I refer to the official
documentation on wiki.documentfoundation.org) was the configuration of a
reverse proxy to work with LOOL, essential since configuring LOOL to use
a non-self signed certificate is even harder.

As TDF did not release binaries, I donā€™t know who would look for such documentation in TDF wiki. Collabora published documentation for CODE, e.g.:

https://www.collaboraoffice.com/code/apache-reverse-proxy/
https://www.collaboraoffice.com/code/nginx-reverse-proxy/

But there are other good sources of information, too, from integrators.

I even agree with Simon: deploying online is horribly hard. Iā€™ve been

I disagree. Itā€™s a myth. Yes, it can be hard, when firewalls, load balancers, 50000 users etc. are involved. Itā€™s the case when one needs professional support. But for the hobbyist, how hard is it to install CODE with a few clicks in Univention, or to follow my ā€œ5 minuteā€ guides?

https://www.collaboraoffice.com/code/quick-tryout-owncloud-docker/

https://www.collaboraoffice.com/code/quick-tryout-nextcloud-docker/

Regards,
Andras

Hi!

I disagree. Itā€™s a myth. Yes, it can be hard, when firewalls, load balancers, 50000 users etc. are involved. Itā€™s the case when one needs professional support. But for the hobbyist, how hard is it to install CODE with a few clicks in Univention, or to follow my ā€œ5 minuteā€ guides?

Iā€™m sure you have done a great job for suitably-skilled people wanting a quick evaluation, but the truth is that approach only takes you to the point where the questions start. I have tried to get a LiOn system running at home and have not succeeded in getting anything I can leave running for my family, unlike the Asterisk-based phone system we are using (on a Pi) or the NextCloud appliance we have installed (Pi-based).

This is the LiOn problem TDF needs to fix first to get a TDF-centric user- and skill-base established.

S.

That's a missleading, those profiles can help us to reach the endusers.

My personal take is we should get a product as easy to deploy as WordPress, for instance, to let the end user take the control of their own cloud.

Thank you for valuable input Marco

What makes my worry is the response you got about C'bora under TDF's IRC

And I take you words "an easy way to deploy LOOL" should be provided by TDF, as TDF's mission is to offer a free product to the end user. And that offer should allow a painless implementation.

He has really done a great job, but TDF cannot depend on the goodwill of the members for a product to be implemented. All documentation should be provided to make life a lot easier for everyone.

Hi,

Hi!

I disagree. Itā€™s a myth. Yes, it can be hard, when firewalls, load balancers, 50000 users etc. are involved. Itā€™s the case when one needs professional support. But for the hobbyist, how hard is it to install CODE with a few clicks in Univention, or to follow my ā€œ5 minuteā€ guides?

Iā€™m sure you have done a great job for suitably-skilled people wanting a quick evaluation, but the truth is that approach only takes you to the point where the questions start. I have tried to get a LiOn system running at home and have not succeeded in getting anything I can leave running for my family, unlike the Asterisk-based phone system we are using (on a Pi) or the NextCloud appliance we have installed (Pi-based).

If there were binaries for Pi, probably installation would be easy. In fact, I think that Pi support would be a nice community project and would not hurt any commercial interest.

Regards,
Andras

There is already an armht/arm64 LibreOffice, both the one the Raspbian folks distribute and a more up-to-date version in Debian (thanks Rene!).

There is also a work-in-progress Debian package, https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice-online (again thanks to Rene).

But Iā€™m told itā€™s just too hard to unpick all the Javascript packages to make it Debian-installable.

So, if you can help get that sorted maybe we can have some easy LiOn Pi after all! The ideal would be something that runs from the GUI as a NextCloud plug-in that, given the location and credentials of a freshly installed Pi, would squirt LiOn into it and configure both ends to use it.

Cheers!

Simon

Hi,

This was totally a pain. The lack of any consistent documentation (until
May 5 in the INSTALL file there was just written "Left as an exercise to
the reader") was one of the biggest problems. The only way was to rely
on old blog posts found on the internet.

Until recently the consensus was that TDF releases source tarballs for LOOL. So there was no demand to write documentation how to create packages, how to build a "product".

It's not about creating a product but implementing a solution, that's the key.

On the other hand it is fully documented in the source code in README files how to build as a developer, if someone wanted to hack on the code.

The docker/l10n-docker-nightly.sh is also quite self-explanatory. (For those, who don't know what it is: it builds a docker image from source.)

Another totally undocumented topic (obviously I refer to the official
documentation on wiki.documentfoundation.org) was the configuration of a
reverse proxy to work with LOOL, essential since configuring LOOL to use
a non-self signed certificate is even harder.

As TDF did not release binaries, I don't know who would look for such documentation in TDF wiki. Collabora published documentation for CODE, e.g.:

https://www.collaboraoffice.com/code/apache-reverse-proxy/
https://www.collaboraoffice.com/code/nginx-reverse-proxy/

But there are other good sources of information, too, from integrators.

From the community you may want to make implementations that, for example, do not show warnings. If the implementer is willing to deal with that, why not let them?

Another hot topic, for me at least is to provide vendor neutral information.

I even agree with Simon: deploying online is horribly hard. I've been

I disagree. It's a myth. Yes, it can be hard, when firewalls, load balancers, 50000 users etc. are involved. It's the case when one needs professional support. But for the hobbyist, how hard is it to install CODE with a few clicks in Univention, or to follow my "5 minute" guides?

https://www.collaboraoffice.com/code/quick-tryout-owncloud-docker/
https://www.collaboraoffice.com/code/quick-tryout-nextcloud-docker/

Vendor neutral point applies here too.

And I am aware that without C'bora/CIB there would probably be no LOOL, but we are TDF.

Hi Daniel,

What makes my worry is the response you got about C'bora under TDF's IRC

It would be good to hear what you think of today's board meeting, and
what has been presented there about community health and ecosystem.
(Well, we tried to chat later, but kitchen duties were calling me :wink: )

And I take you words "an easy way to deploy LOOL" should be provided by
TDF, as TDF's mission is to offer a free product to the end user. And
that offer should allow a painless implementation.

That is a reasonable possible way of looking at it, for sure.
TDF's mission speaks about "software made available for everyone ..
freely and without restrictions". So indeed you can read that as
'binaries for business use without payment', but just as reasonable as
'code for all individuals without restrictions'. Or maybe even
interpretations in between :slight_smile:

So that's the good thing for primary the board, but if needed the whole
community: our freedom to look at what is really wise to do for TDF's
mission.
Maybe the Ecosystem & Sustainability presentation gives some good input
to further talk about that aspect of how our world looks. So lets do that :slight_smile:

greetings,
Cor

Hi Daniel,

What makes my worry is the response you got about C'bora under TDF's IRC

It would be good to hear what you think of today's board meeting, and
what has been presented there about community health and ecosystem.
(Well, we tried to chat later, but kitchen duties were calling me :wink: )

What I think is no one can get such answer from TDF channel, period.

And I take you words "an easy way to deploy LOOL" should be provided by
TDF, as TDF's mission is to offer a free product to the end user. And
that offer should allow a painless implementation.

That is a reasonable possible way of looking at it, for sure.
TDF's mission speaks about "software made available for everyone ..
freely and without restrictions". So indeed you can read that as
'binaries for business use without payment', but just as reasonable as
'code for all individuals without restrictions'. Or maybe even
interpretations in between :slight_smile:

No one is talking of the first, and I'm reading it over and over again with different wording.

So that's the good thing for primary the board, but if needed the whole
community: our freedom to look at what is really wise to do for TDF's
mission.
Maybe the Ecosystem & Sustainability presentation gives some good input
to further talk about that aspect of how our world looks. So lets do that :slight_smile:

If TDF offer a product for free, and states the commercial suport is up the ecosystem companies what's the problem?
Whoever is looking for such support will knock their doors.

Hi Daniel,

It would be good to hear what you think of today's board meeting, and
what has been presented there about community health and ecosystem.
(Well, we tried to chat later, but kitchen duties were calling me :wink: )

What I think is no one can get such answer from TDF channel, period.

I understand what you mean, sure. I have no idea about that conversation
in a whole, so can't judge. But at least it's a fair representation of
the status quo at that moment, from that point of view.

That is a reasonable possible way of looking at it, for sure.
TDF's mission speaks about "software made available for everyone ..
freely and without restrictions". So indeed you can read that as
'binaries for business use without payment', but just as reasonable as
'code for all individuals without restrictions'. Or maybe even
interpretations in between :slight_smile:

No one is talking of the first, and I'm reading it over and over again
with different wording.

That is what happens: depending on ... whatever, you get a different
reading.
Maybe I got your words wrong. Then sorry for that. But the ideas about
free binaries for all use are there. So it's something we cannot ignore.

So that's the good thing for primary the board, but if needed the whole
community: our freedom to look at what is really wise to do for TDF's
mission.
Maybe the Ecosystem & Sustainability presentation gives some good input
to further talk about that aspect of how our world looks. So lets do
that :slight_smile:

If TDF offer a product for free, and states the commercial suport is up
the ecosystem companies what's the problem?
Whoever is looking for such support will knock their doors.

No one else then we bear responsibility to respect the statues.
"... The foundation furthers a sustainable, independent and
meritocratic community which develops Free / Libre and Open Source
Software based on open standards through international collaboration."

So please let's investigate how it works out in practice :wink:

Cheers,
Cor

Ah well, sure, but maybe it's better to wait for the information, write
up, that has been promised by Paolo, Michael, Franklin and Thorsten in
today's meeting.
So let me shut up for now :slight_smile:

Cheers,
Cor

Thanks for your feedback and your support Marco.

Thanks also for your support and the edits on the wiki page which is
making it a lot easier for other people to start working on their own
builds:

https://wiki.documentfoundation.org/Development/BuildingOnline

I see that it is getting constantly improved and if it can be automated
with Ansible then anyone with basic skills can build his/her own LOOL.

I read that unfortunately you received an answer that is surely
unacceptable. Collabora has been one of the major contributors to the
project and they employ quite a few of the developers, it seems like one
of them forgot that he is contributing to an Open Source project on
which the company has/is investing but from which is also benefiting to
pay his wage. I'm sure the answer has been due to a moment of
distraction and that the person in question realised his mistake.

I believe Friday's discussion has been a very important milestone for LOOL.
It has brought together several contributors which are working hard to
complete the documentation needed to make LOOL available also to the
less experienced part of the community and I'm sure that many other will
join in now that several complex items have been clarified and simplified.

As from my summarised proposal lots more needs to be done and thanks to
the feedback coming from you and the rest of the community we are
working now to refine the details of the project.

Let's keep the conversation going as I'd like to see LibreOffice On-Line
becoming the obvious choice for on-line collaboration for both the
community and the enterprise market.

Ciao

Paolo