Whoa there fella! LO Online is the path for collaborative work--LO Desktop is not. Plain and simple!

Not worth the continued dev effort this would require--and this gets my immediate -1, with a strong push to set => WF

And, this really is a dupe of bug 73831 which likewise should be closed WF.

(In reply to V Stuart Foote from comment #1)
> Whoa there fella! LO Online is the path for collaborative work--LO Desktop
> is not. Plain and simple!
> 
> Not worth the continued dev effort this would require--and this gets my
> immediate -1, with a strong push to set => WF
> 
> And, this really is a dupe of bug 73831 which likewise should be closed WF.

Thanks @vstuart for looking into this enhancement request.

I do not agree with you simply referring to LO Online for collaborative work and disregarding LibreOffice desktop. 
(1) In a professional setting (e.g. working on complex documents in a team), users need a full-fledged/featured office suite *and* need to collaboratively work on such documents. The competition (MS Word, to a lesser extent Excel, Powerpoint) can do that and and this is an essential and very important feature for working groups.

(2) There are two use-cases for collaborative editing: Real-time collaboration and synchronization of changes (e.g. done offline). Both are equally important and IMHO it should be a goal to support both in LibreOffice.


BTW, this bug is not a duplicate of bug 73831, as that one refers only to Writer.

(In reply to Gerry from comment #2)
> I do not agree with you simply referring to LO Online for collaborative work
> and disregarding LibreOffice desktop. 
> (1) In a professional setting (e.g. working on complex documents in a team),
> users need a full-fledged/featured office suite *and* need to
> collaboratively work on such documents. The competition (MS Word, to a
> lesser extent Excel, Powerpoint) can do that and and this is an essential
> and very important feature for working groups.
If there are features missing from LibreOffice Online that'd be important for certain kinds of professional work, wouldn't it make more sense to add those instead?

(In reply to Aron Budea from comment #3)
> (In reply to Gerry from comment #2)
> If there are features missing from LibreOffice Online that'd be important
> for certain kinds of professional work, wouldn't it make more sense to add
> those instead?

For complex documents and spreadsheets, online office suites (including LibreOffice Online) are no real option and will not be for a very long time (or maybe never). LO Online needed no less than all the features of LibreOffice desktop while having no time-lag, offline-working capabilities and full interoperability with files saved/opened locally. 

The following scenario is no future scenario, but everyday office life; actually it is a very typical case: A colleague uploads the draft of a report to MS OneDrive (e.g. 200+ pages with full layout, several tables of contents (headings, figures, tables), several chapters with dozens of tables, figures/drawings, cross-references and hundreds of bibliographic references), and annexes. Five persons collaboratively work in MS Word desktop on this same shared document: One person reworks some chapters and copies lots of prepared and layouted text into these chapters and partly works offline on the document during a train ride, syncing changes back later. The second person improves the figures and tables and has to copy lots of stuff from local MS Excel and MS Powerpoint files and several images from the local file system. The third person reworks the bibliographic references with Zotero. The fourth person works on layout and table of contents. The fifth person does proof-reading and adds comments and changes in the track changes mode. 

Therefore, I am very surprised that you don't consider collaborative editing an important feature for a desktop office suites. In the 2020s, IMHO this is a must for any desktop office suite to be suitable for enterprises and professional team work. 

These are typical requirements that need the fidelity and feature-richness of a desktop office suite:
* Working with large, complex documents or big spreadsheets.
* High performance and no time lag with such large documents and spreadsheets.
* Full interoperability with files (documents, spreadsheets, drawings, images) that are saved locally, i.e. edit with external program; import/insert & export/save; copy & paste.
* Ability to work offline on the shared document/spreadsheet and sync back the changes later when online.
* Navigating and copy & pasting between several sections of a document, but also from other documents or objects from other office modules (tables from Calc, drawings from Draw, etc.)
* Ability to use LibreOffice extensions such as the bibliographic software Zotero.
* Ability of open several windows of the same file showing different sections next to each other.
* Ability to collaboratively work with files that are hosted on file sharing systems such as MS OneDrive, MS Sharepoint or others (i.e. there is no LO Online).

LibreOffice desktop is perfectly suited for complex documents like that, but it unfortunately does not support collaborative editing. In this regard, LibreOffice desktop substantially lags behind the competition of MS Office. This is sad, because LibreOffice is superior in so many ways when dealing with complex documents.

"Real-time, synchronous collaborative editing" sounds a bit far-fetched and really covered by LOOL. But in other words you want CMIS and versioning with a git-like workflow, actually Svante's work. That would be definitely great (see also bug 86433), although I would expect the integration to be server-side aka Git. And there is bug 76318 requesting more or less the same. => DUP

(In reply to Heiko Tietze from comment #5)
> "Real-time, synchronous collaborative editing" sounds a bit far-fetched and
> really covered by LOOL. But in other words you want CMIS and versioning with
> a git-like workflow, actually Svante's work. That would be definitely great
> (see also bug 86433), although I would expect the integration to be
> server-side aka Git. And there is bug 76318 requesting more or less the
> same. => DUP

The core of this enhancement request is that LibreOffice desktop supports collaborative editing on a shared document, i.e. saved on CMIS (like Nextcloud, Onedrive, Sharepoint, Google Drive, Alfresco, Kolab, etc.). 

Whether collaborative editing is real-time or synchronized when saving the file, is more of a detail. For example, MS Word 2019 (desktop) supports real-time editing, while MS Word 2016 (desktop) supports only synchronization when saving the file. Both approaches generally work fine. Synchronized editing is very similar (or identical?) to Svante's approach.

In terms of server-site support, it makes sense to support at least those CMIS that LibreOffice Online already supports (e.g. Nextcloud, Alfresco, Kolab, Zimbra, etc.). I don't know whether it is feasible to support collaborative editing on Onedrive, Sharepoint, Google Drive, etc.

Bug 76318 is an interesting approach, but it is not a duplicate of this bug report. The request is very different, because it is about adding git as just another CMIS protocol. BTW, In office settings, git is often neither available, nor used nor wished. Files are typically stored in CMIS.

I use a simple windows network file share for all the office work. Its not perfect but for a majority of people, using a shared folder in windows works. while i personally access the same from my ubuntu, i would love to having three people work on a calc file /writer file at once. 
The software could implement a constant saving feature so that all the online users are up to date and anyone going offline automatically gets the latest version. 

So, IMO before working on online sources which has a tonne of issues on its own, the team could implement the feature on local folders/shared folders where issues like latency and availability are lower

I might come back with a better answer mid of next month (after some releases), but allow me to just give a quick status update:

Within the TDF, I am working on parallel collaboration by adding the concept of changes (or operations) to our ODF Toolkit, see https://tdf.github.io/odftoolkit/docs/odfdom/operations/operations.html

To define changes is important, as when you are working in parallel you are working on local copies like when working with GIT. You have to be able to ask your coworkers for their changes to be able to merge them into your copy.

I have explained this in the earlier mentioned ACM paper the end of last year. It had been uploaded for free access at:
https://github.com/tdf/odftoolkit/blob/master/docs/docs/presentations/2019%20-%20ACM%20DocEng%20-%20The_Next_Millennium_Document_Format.pdf  

If someone is curious, I have even made the effort to summarize all my painful experiences and resulting ideas in two talks at the XML conference in Prague this year (I was lucky I was able to attend FOSDEM and XML Prague before Corona).
The first talk is about improving XML in general and is more about my painful journey in the past 20 years (started 1999 at StarOffice), while the second talk builds on top of the first, drafting a solution for the named problems:

* #1 Slide: https://www.xmlprague.cz/day2-2020/#xmlpp
* #1 Video: https://www.youtube.com/watch?v=pLwH4q-R55M
* #2 Slide:https://www.xmlprague.cz/day3-2020/#nmdf
* #2 Video:https://www.youtube.com/watch?v=dkTflH3yQZE

Regarding the upcoming work on the ODF Toolkit, Sebastian and I, have written in 3 days an "experience report proposal" - but we drafted only the problem to have a short talk at their conference to ask for feed-back instead explaining a full solution like in a real paper.
In other words, it was refused - it was indeed a bit shallow ;-) -  but might help to outline what we have in mind. NOTE: Only the third part is related to ODF, you might want to skip the first two: https://drive.google.com/file/d/1BZhOHgH58w2WWeyOdJc1M5o_Mz1MxjXR/view?usp=sharing

I changed the title of this enhancement request to „real-time and offline collaborative editing“ to not confuse with the terms used. Here are the terms used for collaborative editing:

*Collaborative editing* (synonyms: co-authoring, parallel editing) means that multiple users can work together on a document, spreadsheet or presentation, over the inter/intranet (e.g. saved in a CMIS). This term comprises *real-time* and *offline* collaborative editing.

*Real-time collaborative editing* (synonyms: real-time parallel editing, real-time co-authoring, simultaneous collaborative editing) means that multiple users can simultaneously edit the same document. If anyone else is working on the document, the user sees their presence and the changes they're making in real-time.

*Offline collaborative editing* (synonyms: offline parallel editing, asynchronous collaborative editing, synchronised collaborative editing) means that the user can keep working on the shared file, independently whether he/she is connected. When the user goes offline, the application switches from real-time collaborative editing to offline collaborative editing. If there are others editing the same document, they won't be able to see the changes while the user is offline. When the user goes back online, he/she will be notified of any changes that are available, and other users will see the changes made by the user.

Related to this enhancement request is Jan-Marek's post to the developer mailing list, in which he outlines the WASM port. The project ultimately aims at peer2peer real-time collaborative editing in Writer.

Email: Initial work on a LibreOffice WASM port (and more)
https://lists.freedesktop.org/archives/libreoffice/2020-December/086492.html

Project description: LibreOffice P2P
https://nlnet.nl/project/LibreOfficeP2P/

I felt free to add Jan-Marek to this bug, as he might be able to explain more their plans wrt collaborative editing and how the project relates to this bug.

Hi, I consider adding this enhancement "Support for real-time and offline collaborative editing in LibreOffice (desktop)" as tender idea/proposal to improve LibreOffice [1] at the TDF.

Since the proposal must respect the following structure, I need your input on cost estimate, contact and reviewers for this proposal. Thanks a lot!

    Cost Estimate: x week(s)
    Contact: Anakin Skywalker
    Reviewers: Luke Skywalker
    Short Description: …

[1] https://blog.documentfoundation.org/blog/2023/05/12/tender-ideas-and-proposals-to-improve-libreoffice/

Hmm, with "atticization" of LibreOffice Online, this is no longer feasible as a core component.

TDF, with ESC guidance, has ceded the feature space to TDF partner Collabora and the suggested enhancements are a fundamental capability of their Collabora Online offerings.

Development of LOOL is done barning a major shift in community participants. It certainly is nothing meriting TDF tender as that ship has sailed.

IMHO => WF

(In reply to V Stuart Foote from comment #12)
> Hmm, with "atticization" of LibreOffice Online, this is no longer feasible
> as a core component.
[...]
> IMHO => WF

Thanks @V Stuart Foote for your reply. I think that your have misunderstood this enhancement request. It is about LibreOffice Desktop being able to do real-time and offline collaborative editing of shared files. 

This feature is absolute business standard of MS Office Desktop for years and is used by millions of users everyday. LibreOffice Desktop is not able to do it and this is a huge drawback for LibreOffice desktop. Workgroups simply cannot consider LibreOffice Desktop as a competitor to MS Office, because of the lack of this feature.

The description of the feature is very simple: Someone puts a file on MS Onedrive/Sharepoint (or for LO on any other server / file share) and invites the workgroup and other people to edit the file. MS Word Desktop is capable to have multiple users working on the same file at the same time. This feature is severely lacking in LibreOffice Desktop.

And please do not come up with the argument that people should use Collabora Online instead. This enhancement request is about LibreOffice Desktop, which is the software governed by TDF.

Sure; so many things are possible, though whether they are a good idea is another question =) You missed a link to us trying this in 2012:
https://meeksfamily.uk/~michael/blog/2012-03-26-collaboration.html which at least is where my optimism for this approach died ;-) (despite the carefully selected screenshare).

I suspect Thorsten & Svante have a passion for this topic; and it's reasonable to  hope that they would be interested in coming up with some ball-park here; then again COOL adopts the "really easy" way of doing this, which it turns out is several person decades of work (and counting ;-) - so (absent any super clever new idea I'm unaware of) - I would expect this would be a huge effort cost-wise.

There is clearly a big tension here between feature depth & collaboration.

Nevertheless I would recommend not discarding the idea pre-emptively; but to look at the cost and scope of whatever estimation quite carefully. Then again - the idea of off-line collaborative editing - without a network is not obviously a helpful one ;-)

Thorsten ?

(In reply to Michael Meeks from comment #14)
> Nevertheless I would recommend not discarding the idea pre-emptively; but to
> look at the cost and scope of whatever estimation quite carefully. Then
> again - the idea of off-line collaborative editing - without a network is
> not obviously a helpful one ;-)
> 

Not disagreeing, that Collabora's Online approach was perhaps the only way to get full-featured realtime collaboration done in finite time. ;)

As an enhancement request, I believe though this report has merit.

*** Bug 157921 has been marked as a duplicate of this bug. ***

As suggested by Stephane, I am adding below what was described in Bug 157921 - Collaboration feature missing in Libreoffice: offline enhancement suggestion with user registration and peer to peer document updates

Description:
Presently one mayor drawback in working with LO in teams is a collaboration feature. Other projects have tried filling this gap with online solutions.
Unfortunately, they all fall behind what could allow LO making a breakthrough in this area and be adopted by the thousands of users who are struggling with other tools, being they paid, free, or opensource.

What I am suggesting is focusing on offline collaboration without having to make a change to the bulk of Libreoffice project.

Not being a programmer, I will just suggest what I see in the steps below.

Steps to Reproduce:
1. Probably a flat file format is necessary for this
2. Secondly, also a user registration in LO
3. Thirdly, files would have to run in a service which would come packaged within LO, such as Syncthing or similar (peer to peer)
4. Changes made to documents by several could be handled in the way anytype.io (an offline collaboration project, or a similar one) is doing.

Actual Results:
Presently such a collaboration is not possible.

Expected Results:
I expect this solution to deliver a collaboration software while keeping the richness and speed of the present Libreoffice product.

Some UX input at https://design.blog.documentfoundation.org/2024/07/17/peer-to-peer-collaboration-with-libreoffice/

(In reply to Heiko Tietze from comment #20)
> Some UX input at
> https://design.blog.documentfoundation.org/2024/07/17/peer-to-peer-
> collaboration-with-libreoffice/

As Heiko mentioned, the design team has worked on the design of "Peer-to-peer collaboration with LibreOffice", which is great and very much appreciated.

Let me add four typical use cases for collaborative editing in LibreOffice:

1. Use case "Microsoft environment"
The document is on MS Sharepoint or MS OneDrive. The following applications may edit the file simultaneously: MS Office (desktop clients), MS Office online, +LibreOffice (desktop), +Collabora Online.

2. Use case "content management system"
The document is on the groupware / content management system / cloud hosting, like NextCloud, Alfresco, ... The following applications may edit the file simultaneously: Collabora Online, +LibreOffice (desktop).

3. Use case "Google environment"
The document is on Google Drive. The following applications may edit the file simultaneously: Google Docs, +Collabora Online, +LibreOffice (desktop).

4. Use case "peer-to-peer"
The document is shared by a LibreOffice user (This is the use case that Heiko mentioned and that the design blog is elaborating on). The following applications may edit the file simultaneously: +LibreOffice (desktop), +Collabora Online.

The "+" means that this is the goal of this enhancement request, as +LibreOffice (and +Collabora Online) does not yet support it.

Overall, from my experience, use case 1 is currently by fare the most frequently used case. In many MS Office environments, this is an everyday use case. Use case 3 is IMHO also frequently used, too, but more often by private users / small business users or also by large corporate users (in the US). 

Use case 4 is entirely new and if the protocols become part of the ODF standard, Microsoft Office is also forced to support it. Maybe, Svante's idea of a standardized protocol to send ODF changes (ODFDOM changes) to other users is part of the technical solution.

Hi Gerry and Heiko and other contributors.
Let me expand on what Gerry just described drawing on what we already do in our organization. 
We prepare translations using a double, triple or more -columned table in LO Write.

0.The first translator begins translating or revising (since we also help ourselves with AI such as Deepl). S/he works not only on his or her portion, but on the whole text, unifying citations, abbreviations, coding some information (such as author names, foreign words, with character styles), while translating. Questions to other collaborators on difficulties need to be submitted constantly.

1.The second translator/reviser works following the first in order to correct possible mistakes and give feedback to the first translator on the work made in the remaining part of the translation. This one too will have questions for other reviewers.

2. A third revisor usually intervenes

3. Finally a mother-tongue reviewer

At the moment, in order to allow 1. to happen we are splitting the document, which means however that work concerning the whole document by 0. cannot be extended to sections on which have been already shared to 1. The same applies for global changes occurring between 1 and 2 and 2 and 3.

Also, questions asked to specific users (we have invented mentions to indicate for whom the question is (@george in each comment) have to wait until the text is sent to them, thus making it more difficult to remember the context.

A multiplication of files is another issue in this setting.
Another is the risk of a user opening a file somebody else is working on (but I noticed that sometimes you get a warning).

Now, as to Gerry's use cases.
We find LO stable, and rich enough for what we need, but we needed collaboration. So we tried MS Onedrive (1. in Gerry's description). It would not handle our files, it would slow down becoming unusable (we are working with books that can reach 600-800 pages, multiply that by the 3 or 4 columns). We tested Collabora Online (2.), even with a smaller file 300 pages in 2 or 3 columns, it slowed down plus it did not handle Languagetool, so it was not retained.

I believe that a wide integration is certaily desirable, but assuring that the coding of the changes does not disrupt the file (I hope I am being understandable): if 1. 2. or 3. can handle the file too it is certainly very good.
At the moment the peer to peer solution (4.) seems to us very interesting also because it renders the necessity of a server obsolete.

I see one possible difficulty (even I still think that peer to peer is best), but you may find a way round:
There should be a way to ensure that the changes are passed on even if LO is not open at the same time (if so the user desires). The computer has to be switched on I guess, but not the application necessarely (I think of users being one in Latin America and one in Australia: their changes would have to sync at some point and if one forgets to keep LO open they may rarely do, or users not working at the same time). I guess that people know they will have to coincide at some point in order for the changes to apply to their file and viceversa.

(In reply to Gerry from comment #21)
> Let me add four typical use cases for collaborative editing in LibreOffice:
Don't forget the existing possibility to _asynchronously_ work with documents stored on a CMIS. The proposal adds _simultaneous_ editing via LibreOffice desktop (and other apps).

(In reply to Daniele from comment #22)
> We prepare translations using a double, triple or more -columned table in LO
> Writer.
That's an interesting use case. Knowing the translation from other authors might help to find the best fitting words.

With respect to the P2P collaboration plan outlined by the LO design team, it appears that the TDF ODFToolKit project has done much of the groundwork for this by defining ODF Changes/Operations [1]. Operations (or changes) are used to transfer the user changes between editors, which is a prerequisite for collaborative work on a document.

Comment 8 describes the state in 2020, but the project is under active development. ODF JSON Changes (Collaboration) was released in 2022 and there have been several releases since then [2].

It would be great if the planned P2P collaboration feature builds on the groundwork done by the TDF ODFToolKit project. The approach is innovative and groundbreaking, and may even become part of the ODF specification, going far beyond what the competition is doing.

[1] Text Operations (or Changes)
https://tdf.github.io/odftoolkit/odfdom/operations/operations.html
[2] https://listarchives.odftoolkit.org/dev/msg00102.html