For many years, people worried about digital sovereignty in a Microsoft environment have used on-premise Sharepoint and the embedded Microsoft Office Online (MOO) editors to allow users to collaborate on internal documents with private or confidential data.

However – Microsoft has announced that Office Online Server will reach end of support and retirement on 31 December 2026 and users who want equivalent functionality will need to send their documents to Microsoft’s cloud. From 1 January 2027, organisations still using it will be running without security updates, bug fixes or technical support, in an era of increasingly aggressive AI driven cyber-attacks.

The good news is that for SharePoint environments, Collabora Online can provide an easy drop-in replacement: just install Collabora Online on a server, point SharePoint’s WOPI bindings at it, set the WOPI zone, and users can continue opening and editing their documents locally.

A deadline — and a direction of travel

The end of Office Online Server is part of a wider direction of travel from Microsoft: away from self-hosted control and towards Microsoft hosted Office 365.

For some organisations, that may be acceptable. For many, it creates serious questions. Public sector bodies, regulated industries, sovereign cloud providers, managed service providers and anyone else who values privacy and GDPR compliance cannot move document collaboration deeper into Microsoft’s cloud. Indeed, this was why they originally chose MOO on premise.

As well as those with regulatory needs, many organisations are concerned about moving their data and getting further tied into the Microsoft ecosystem.

Your customers still need document collaboration they control

For integrators and platform providers, the retirement of MOO creates both a challenge and an opportunity.

Namely – customers who rely on Office Online Server need a supported alternative today. Whether they are using it alongside SharePoint, or as part of a wider WOPI-based document workflow, with potentially complex templates, established business processes and existing storage platforms. Something good needs to fill the void.

Microsoft would of course like to steer these customers further into their steadily closing garden, but increasingly organisations are realising they need a solution that works with their infrastructure, not against it.

That is where Collabora Online comes to the rescue.

Collabora Online: the flexible alternative

Self-hosted, fully cloud-based, or as a hybrid model, Collabora Online is a powerful, open-source online office suite for organisations and platforms that need document editing under their own control.

For many MOO use cases, Collabora Online acts as a drop-in, WOPI-compatible alternative. Existing storage platforms can remain in place. Users can continue opening and editing their docx’s, xlsx’s and pptx’s in the browser.

Collabora Online is a natural fit for integrators, hosting providers, platform vendors and service providers who need to give their customers a credible path beyond Office Online Server.

With Collabora Online, you have:

• Self-hosted and private cloud deployment:
  • Keep document editing within infrastructure the customer controls.
• Open-source foundations:
  • Avoid replacing one closed dependency with another.
• Data sovereignty:
  • When you need strong control over where documents are stored, processed and edited.
• Integration with existing platforms:
  • Use our WOPI-like integration and connect document editing to established storage, permissions and workflows.
• Support for Microsoft Office file formats:
  • Allow users to continue working with familiar DOCX, XLSX and PPTX documents in the browser.
• Enjoy the improved features of Collabora Online:
  • Not just all of this, but there are many improvements that you can discover and enjoy in Collabora Online.

A strong fit for SharePoint and WOPI-based workflows

The retirement of Office Online Server is a reminder that digital sovereignty depends on more than storage location. It depends on the whole document stack: the file formats, the editing layer, the integration points, the support model and the long-term roadmap.

Microsoft’s direction is clear: the future of their office stack lives in the Microsoft 365 cloud, and the on-premises editing story is ending with Office Online Server. For customers comfortable with that trajectory, the path is well-signposted. But for those whose regulatory environment, data residency obligations, or long-term strategy requires a self-hosted option, following Microsoft into the cloud isn’t a choice they can make. Fortunately for anyone who has questions about handing the keys to their whole stack (literally?) to one external vendor, there is a credible, supported alternative.

Make Collabora Online your solution

If you have a looming MOO problem, now is the time to act. Audit your current OOS dependencies, and get in touch – we’d love to help you with a demo or integration support.

We can also provide a stop-gap solution for your requirements here, but beware: you may fall in love with a better, truly open solution, and end up in a fresh and exciting digitally sovereign world – which will ultimately free you from ever being forced to make such a change again.

Microsoft’s Office Online Server may be retiring, but self-hosted document collaboration does not have to. Keep online document editing under your control with Collabora Online.

The post Microsoft Office Online Server Ends 1 January 2027. Get the Self-Hosted Alternative Now appeared first on Collabora Online and Collabora Office.

Collabora Productivity employs a multi-layered security onion strategy that covers many areas. In Part 1, we explain how our security is built on rigorous organisational compliance, including ISO 9001 and ISO 27001 certifications. This framework is bolstered by continuous automated testing, such as large-scale continuous fuzzing campaign and regular static code analysis, that proactively identifies and fixes vulnerabilities before software is release.

Certified, Active Security

The security considerations for document handling encompass a huge number of areas. It brings to mind the famous Douglas Adam’s “Big, really big” quote, as security is fundamental to how we build and operate as a company. Security is core to our internal processes; and goes on to inform our software design and technical architecture through to our software development processes, implementation, continuous testing, security reporting and support.

We have another blog that covers ‘softer’ security measures found inside the Collabora Online (COOL) UI that provide advisory restrictions, such as cell protection, section editing and read-only locks. These are soft or advisory policies embedded into the document file itself. In this blog however, we are focusing on our approach to hard security, and the use of engineering controls building hard policy directly into the software which ensure your documents are safe when edited in COOL. This is built around a multi-layered security onion approach which also includes server-side document isolation, request signing, our constant automated testing, security maintenance and much more.

Certified and Audited Security: ISO Standards

At the core of Collabora Online (COOL) is over eight million lines of code. The codebase we re-use from Collabora Office is mature and proven technology over many years. So how do we avoid introducing mistakes as we continue to rapidly improve the product?

Any effective approach to security needs to start with the way a company operates and how it complies with recognised standards and legislation. Achieving ISO 9001:2015 certification and developing a Business Management System (BMS) combined with a Quality Management System (QMS) means that Collabora Productivity customers can trust that we have a consistent framework in place for continuously improving our processes, managing risks and improving efficiency.

A BMS is also particularly effective when integrated with dedicated security standards, which is why the company is also certified to ISO 27001:2022 and has an Information Security Management System (ISMS) in place.

An ISMS framework encompasses people, processes, and technologies that manages the overall security of Collabora Productivity’s systems and data. ISMS follows a risk-based approach, focusing on identifying and prioritising risks, implementing appropriate controls to mitigate them. As well as helping demonstrate compliance with regulatory requirements, ISMS indicates a continuous approach to improving security that addresses emerging threats.

Staff and Engineering Training

All staff at Collabora Productivity must complete compulsory training on the company’s BMS as well as general security awareness. The training covers security policies we have in place, preventative measures for security breaches and potential methods and strategies that attackers use to gain infrastructure access.

In addition, all Collabora engineers complete training that provides comprehensive instruction on the security implications of modern code development and deployment practices. Engineers gain an understanding of the tools for managing risk in the development process, such as version control, peer review and automated testing.

Collabora Productivity has a comprehensive security report handling and response process and fosters a culture which values and rewards the detection and mitigation of security vulnerabilities.

Annually, the company undergoes a thorough independent audit to confirm ongoing compliance to its ISO certifications. Internally, company leaderships reviews progress and assist in the improvement of processes and procedures. Our certification documentation is available on request and provides our partners and customers with confidence that the company is pursuing excellence with it’s company and security framework and approach.

Automated Testing

Part of the company’s continuous approach to security involves the use of automated software, which incorporates:

• Coverity Scan Static Analysis
• Crash Testing
• Fuzzing (OSS-Fuzz)

Coverity Scan Static Analysis

Collabora’s engineering team submits the software stack to Coverity Scan for Static Code Analysis regularly. We scan both C++ and JavaScript code, for automated defect detection and vulnerability identification.

Coverity Scan detects common low-level programming errors that can often result in a security vulnerability, including buffer and integer overflows, format string vulnerabilities and missing and insufficient validation data and string input. In Collabora’s codebase, Coverity typically captures unnecessary null checks and dereferenced points. This analysis is run against the latest development versions, which allows us to catch and fix defects well before they are released.

In regard to document security and bug-fixing, the engineering team operates two 24/7 document robustness testing campaigns:

Continuous Crash-testing

The primary purpose of using continuous crash testing is to assess the software resilience and recovery capabilities of Collabora Online. The testing process uses over 812,000 documents collected from multiple document sources, such as various bug tracking and defect management systems and internet forums. Excel documents alone amount to 545,000 files and it takes around four days for each test cycle to execute running on an Intel Xeon E5-2650 v4 (2.20GHz) CPU with 125GiBs memory.

For many formats we export the documents to multiple formats and reimport exported output. In this way, we are constantly verifying that no new code changes have been introduced that cause a crash on import of initial documents, export of those documents, and re-import of the exported documents. The findings are logged, and each failed import and export is reported. We extract the backtraces from the coredumps and address any issues that are found early in the development cycle.

A key component of Collabora’s continuous crash-testing programme is a long-term partnership with Adfinis—spanning over 12 years—which has invested in and donated hardware to advancing open-source document collaboration, digital sovereignty, and high-quality software reliability.

Continuous OSS-Fuzz Testing

Fuzzing has become integral to modern software development and a highly effective way of discovering critical vulnerabilities. Collabora Productivity uses the testing technique to fuzz documents with the OSS-Fuzz service.

OSS-Fuzz was a response by Google to the Heartbleed OpenSSL bug and automatically generates and tests malformed, unexpected, or random inputs to identify potential crashes, memory leaks, and exploitable vulnerabilities. We apply around 50 different fuzzing targets created by Collabora engineers, involving 49 different file formats, including more for obscure file formats, such as Microsoft Visio’s older file format (VSD) and Microsoft Publisher (PUB).

Collabora’s OSS-Fuzz builds use four different types of engine (including libfuzzer and honggfuzz) and configurations (such as address, memory and undefined behaviour sanitiser) to create 200 custom fuzzing processes which are run every day of the year and rebuilt twice a day.

The configuration is statically built with no dynamic libraries, which is recommended for performance reasons by OSS-Fuzz, and has a series of other fuzzing specific considerations, such as running without a configuration layer.
Collabora is constantly developing the testing process. For example, we have improved our PDF export fuzzing, where we look for crashes at layout and export to PDF phrase. We have also added a custom mutator in an effort to force only legitimate XML input to pass to the fuzzer and uncover issues we have not seen before.

Our document fuzzing applies evolution algorithms which constantly ‘breeds’ new files with newly introduced code paths in order to find flaws. Fuzzing watches the paths that are executed and automatically attempt to extend code coverage. Historically fuzzing has contributed to uncovering many potential flaws in newly written code during the development phase.

We continuously check the results and alert the relevant committer people when a change triggers a problem and re-attempt fuzzing again on the document, so we do as many tests as are possible. Mitigations for the flaws are allocated to the originator initially, but the Collabora engineering team frequently perform fixes to ensure that we capture issues early and long before release.

More Security Layers to Explore

As we have demonstrated, security is fundamental to how we build Collabora Productivity. But while we comply with internationally recognised organisational compliance certifications, including ISO 9001 and ISO 27001 certifications, and practice continuous automated testing, there is much more to the company’s multi-layered security onion. In Part 2, we will explore the three main components of Collabora Online’s (COOL’s) architecture and how we carefully apply the principle of least privilege to each software layer and continue to bolster our ‘security onion’ with isolation measures

Evaluate Collabora Online for your organisation today and try a pilot deployment of a document editor that keeps your data entirely within your control.

The post Finding a Secure Document Editor for Your Organisation appeared first on Collabora Online and Collabora Office.

The post COOL Days 2026 Roundup: Product, Partners, Pizza and Progress in Hamburg appeared first on Collabora Online and Collabora Office.

All you need to deploy Collabora Online on your Kubernetes setup, is applying these configuration settings on your installation of Collabora Online. This is a test example ulitising Minikube.

For full deployment and installation guides please see the Collabora Online SDK. This covers Helm, Kubernetes Ingress Controller (both Nginx and HAProxy), issues with OpenShift, Pod Autoscaling and monitoring.

Install Collabora Online on Kubernetes for Minikube testing

With the increasing use of the Kubernetes, we are happy to provide an easy way to deploy our online on your Kubernetes setup.

Thanks to Collabora developer lpranam, Collabora Online can be setup with Kubernetes and also a key feature such as collaborative editing will work correctly. Therefore it is vital to ensure that all users editing the same document end up being served by the same pod. Using the WOPI protocol, the http/https URL includes a unique identifier (WOPISrc) for use with that document. Thus load balancing can be done by using WOPISrc – ensuring that all URLs that contain the same WOPISrc are sent to the same pod. We use a reverse proxy to achieve this load balancing mechanism. HAProxy provides the easiest way to achieve all are requirements for this setup.

Pre-installation checklist

1. running Kubernetes cluster
2. The helm command-line tool
3. The kubectl command-line tool

Configuration files can be found at: github.com/CollaboraOnline/online/tree/master/kubernetes/helm/collabora-online

Installation steps

1. Install HAProxy ingress controller
   kubectl apply -f https://raw.githubusercontent.com/haproxytech/kubernetes-ingress/master/deploy/haproxy-ingress.yaml
2. Prepare the namespace in the Kubernetes cluster with this command
   kubectl create namespace collabora
3. Install collabora online helm chart
   helm install collabora-online ./kubernetes/helm/collabora-online/

Accessing online service

The following steps may vary a little according to your cloud providers. Here we demonstrate how to access the online with a minikube setup on a local machine.

HAproxy is installed as a NodePort service so to access any service through HAProxy we can use the node’s ip.

1. To get your node ip with minikube: minikube ip

example output

192.168.0.106

2. Each container port is mapped to a NodePort port via the Service object. To find those ports

kubectl get svc --namespace=haproxy-controller

example output

In this instance, the following ports were mapped:

• Container port 80 to NodePort 30536
• Container port 443 to NodePort 31821
• Container port 1024 to NodePort 30480

3. Now in this case to make our hostname available we have to add the following line into /etc/hosts:

192.168.0.106 coolwsd.public.example.com

COOL Controller Architecture Guide

Feedback and community

If you have feedback, or want to get involved somehow: here’s our cool-dev community!

The post How to easily deploy Collabora Online on your Kubernetes setup appeared first on Collabora Online and Collabora Office.

You may have seen documents change slightly between tools – sometimes that’s between different companies’ applications, sometimes it’s even the same company’s browser-based or desktop offering. A table moves, a font changes, something is missing, or a layout looks just a bit off.

It’s all because of differences between how documents are described by both editors and file formats. The good news is: modern document editors can be designed to handle the linguistic differences.

How document editors should translate

Modern document formats such as OOXML (.docx, .xlsx, .pptx …) and ODF (.odt, .ods, .odp …) are both highly capable and widely used. But like languages, they express certain details differently.

Each editor has a native file format, like a mother tongue. For Collabora Office, that is ODF, which is a truly open format with an open development process. For Microsoft that is OOXML, “a pseudo-standard that pretends to be open”.

Ideally, a well-designed document editor acts like a skilled translator. It ensures that documents open, display, and behave consistently, even when moving between formats.

To do this, the document editor uses what are known as import and export filters ensuring that features are handled correctly. This does however leave open the question of what to happens to features that are only available in one format and therefore cannot be ‘translated’ (similar to the ‘the’ from the above example).

A good way to illustrate this question is by showing what happens when it goes wrong. Microsoft opens and edits all files in the OOXML format. This means if you open an ODP with the total slide count in the template in PowerPoint for example, a feature OOXML does not have, it permanently throws away the information – even without trying to open or save the file as .pptx. PowerPoint’s mother tongue is OOXML, so it has no idea what <count> means.

This makes us sad! We like to know how much longer a presentation is going to go on for…

In the case of a feature missing between formats in the Collabora Office suite, we tend touse what we call ‘grab bags’ to temporarily store the document feature before saving it again in its original format. Ideally, PowerPoint would operate more like the Collabora Office suite, and recognise this as information it doesn’t fully understand but that should be retained somehow. Unfortunately that is not the case.

Regrettably, this principle is not well understood by many, even by those who are aware of the problem of dependency on Microsoft’s OOXML. Two of the first five issues raised in a new office suite’s GitHub repos are duplicate requests for the suite to default to ODF. Unfortunately the office suite in question is based on a document editor that primarily speaks OOXML and has poor ODF support, so the requests are unlikely to be actioned.

Not all technologies speak the same language

Many (most?) Microsoft Office users will have noticed that Microsoft Office features look and behave differently depending on if a document is opened in the browser, or using the desktop app. This is because the applications known to most as “Microsoft Office” are in fact two independently developed applications – Word Desktop and Word Web. Confusing the situation further, Microsoft appears to have multiple and slightly differing descriptions of how features operate between the two.

Technically, this is a different question to file format interoperability, but feature availability is nonetheless important and plays a significant role in the interoperability equation. There’s no point having a document editor that cannot edit your documents right? Microsoft disagrees it would seem: “Microsoft Word Web App lets you make basic edits and formatting changes to your document in a web browser. For more advanced features, use Word Web App’s Open in Word command […] some features work differently in the two environments.” (Accessed 31/03/2026)

Fortunately for users of the Collabora Office suite, with the newly released Collabora Office, they can enjoy one and the same editing and document rendering experience whether editing documents in-browser, or on their desktop thanks to the fully shared codebase between the two apps.

Achieving perfect interoperability

We’d like to say that we are perfect translators, understanding everything and converting 100% of documents flawlessly, but this would be untrue. What we can say is we are excellent at working with both Microsoft file formats and ODF.

Additionally, unlike most Microsoft format based editors, we think it is important to work well with both legacy document types, as well as the open future. Arguments suggesting that because we encourage usage of ODF, we must therefore not be appropriate for use with .docx or .xlsx are poor and don’t stand up to scrutiny. Just because we’re great at ODF doesn’t stop us being great at interop too.

While we prefer ODF dues to it’s openness and documentation, we support and develop OOXML, both for new features that come with new versions. As a company, we deliberately use both formats internally, and do not encounter issues in our regular working. With our support these minor dialectical difference don’t need to hold up real-world large-scale migrations either.

Among other efforts to improve interoperability, over the past year we have been focusing on validity testing of about 243 000 documents, spreadsheets and presentations in various formats converted to the corresponding OOXML format, with the goal of getting to zero. The following chart shows the progress over the last few months for spreadsheets and presentations.

You should be able to open a document, edit it, share it, and know it will behave as expected. This will only be fully achieved as the world moves to a truly open standard, and away from the Microsoft owned/governed semi-proprietary confusion.

Additionally your documents should behave the same in your browser, on your desktop, or in your pocket. This is now possible with shared-codebase programs like Collabora Online and Collabora Office.

In the meantime, we continue to deal with the reality of ubiquitous Microsoft-format legacy documents, and are pleased that the vast majority of users will not discover issues opening and editing Microsoft file types in their day to day work with Collabora Office.

If you want to see what that looks like in practice, we encourage you to try out the Collabora Office suite – and enjoy working across platforms and formats with confidence.

The post Interop EXPLAINED appeared first on Collabora Online and Collabora Office.

We don’t just work from a desk. We work from trains, coffee shops and waiting rooms. And yet for many, mobile document apps are a compromise. Perhaps useful to quickly open a file, check a detail, or make a small change, but often falling short when it comes to faithfully displaying the document you created elsewhere.

That matters more than it might seem, and means mobile apps are often ignored. When a document is part of a real workflow – a contract, a report, a spreadsheet, a presentation, a policy paper, a flow diagram, a bid, or a briefing – you need to trust that what you see on your phone or tablet is the same document your colleagues see on desktop or in the browser. Not an approximation. Not a simplified version. The same document.

That is where Collabora Office for Mobile comes in.

A common code base for desktop and mobile

Collabora Office for Mobile is not a separate, cut-down document viewer built around different assumptions. It uses the same core rendering engine as Collabora Office for desktop and Collabora Online in the browser.

That means documents are rendered consistently across the full Collabora Office suite. Whether you open a file on your desktop, in your browser, or on your phone while travelling, you are working from the same foundation. Layout, formatting, tables, images, charts, styles, and document structure are handled by the same underlying engine.

You can review a document on your phone and know that you are seeing the document as it really is. You can check a presentation before a meeting, review a spreadsheet while travelling, or read a report in the field without worrying that the mobile app has shifted something, hidden something, or interpreted it differently. When documents move between devices, that consistency matters.

Many document apps on the market prioritise convenience, but can introduce rendering differences depending on format, feature support, or the platform you are using. That may be acceptable for casual notes or lightweight editing. It is not acceptable when the document itself carries real operational, legal, or organisational importance. Collabora Office for Mobile is designed for those moments where accuracy matters just as much as access.

Why rendering consistency matters

Collabora Office for Mobile is especially valuable because it fits into a wider document workflow rather than sitting outside it. It works as the perfect accompaniment to Collabora Online and Collabora Office on desktop, helping form a complete and rounded office suite across devices.

This makes it particularly useful for people who are frequently away from their desks. Travelling employees can review meeting materials on the move. Field staff can access documents in operational environments. Engineering teams, logistics workers, consultants, inspectors, and public-sector teams can all open the documents they need with greater confidence that what they are viewing is accurate. In some contexts this is simply about convenience. In others, it is about mistakes.

A different UI for a different device

Of course, a mobile app cannot simply copy a desktop interface onto a phone screen and call it done.
Phones and tablets are very different environments. On a small display, screen space is limited, touch is your main input method, and the on-screen keyboard immediately competes for room with menus, toolbars, and document content. Designing a good office experience for mobile is difficult precisely because documents themselves have not become simpler, even if the screen has become smaller.

That is why we have invested heavily in optimising the mobile user experience.

It is also worth distinguishing between using Collabora Online on a mobile phone or tablet browser, and using the dedicated mobile app. In a mobile browser, users are still working through their EFSS or integration platform, so they will retain access to platform-specific features such as granular user-based permissions, @ing users in documents or comments, version-history lgging, etc. The dedicated mobile app on the other hand offers the same beautiful Collabora editing interface, but cannot include all of these integration-specific controls. This is not a limitation of the Collabora Office for Mobile app, but is because mobile apps operate within highly sandboxed environment. In practice, that means the app delivers the same document rendering and editing experience, while the browser remains the route to the wider EFSS workflow around the document.

On tablets, Collabora Office for Mobile provides a much more desktop-like interface, giving users more familiar controls and a layout that makes better use of the larger screen. This is particularly important for users who want continuity between desktop and tablet workflows, or who use a tablet as a serious work device rather than just a companion screen.
On phones, the interface becomes more responsive and adaptive. Menus and controls can step back when needed so that the document itself gets more space, especially once the keyboard is open and the user is typing. That sounds simple, but getting the balance right is not easy. Too many controls on screen, and the document becomes cramped and frustrating to use. Too few, and editing becomes awkward. A good mobile office app needs to know when to stay visible and when to get out of the way.

The goal is not to pretend that a phone is a desktop replacement in every scenario. The goal is to make sure that when you do need to act on a document from your mobile device, the experience is clear, capable, and dependable.

Accessibility matters too

A modern office suite also has to work well for everyone. That includes users who rely on accessibility tools and assistive technologies.

Collabora Office for Mobile includes strong accessibility support, including screen reader functionality, helping more users work with documents effectively on mobile devices. That is important not only from an inclusion perspective, but also from a practical one. Mobile access should not come at the expense of usability.

One suite, across every screen

The real value of Collabora Office for Mobile is not just that it works on phones and tablets. It is that it fits into a larger picture.

Desktop, browser, and mobile should not feel like separate worlds with different document behaviour and different levels of trust. They should be different ways of accessing the same office experience, adapted sensibly for each device.
That is what Collabora Office for Mobile helps deliver – the same document engine, thoughtful mobile design, practical editing, strong accessibility, and a natural companion to the rest of the Collabora Office suite.

Ready for document editing in your pocket? Try it out today!

The post Collabora Office for Mobile: Your Documents, Fully Rendered on the Go appeared first on Collabora Online and Collabora Office.

A quick, practical explanation of Git?

Developed in 2005, Git is the system most modern open-source software uses to manage code.

At its simplest, Git answers three questions:

• What changed?
• Who changed it & when?
• How does this relate to everything that came before?

But the important thing isn’t just tracking changes – it’s how Git enables collaboration.

Everyone has the whole project

With Git, every developer can have a full copy of the codebase on their own machine.

Not just the latest version – the entire history.

That means no single server is “the” source of truth, work doesn’t stop if a service goes offline, and it enables developers to work independently, offline, and in parallel
Each copy is complete and verifiable.

Work happens in many repositories

Instead of everyone editing the same version of the code at once, Git encourages work to happen on clones. There are many reasons for this, but essentially it enables developers to try new features and fixes on the code, without potentially causing disruption to others.

Copies can be short-lived or long-running, shared or private. They’re simple to create, easy to merge, and easy to discard.

Parallel development is the standard operating procedure.

Git makes independence normal - not exceptional

Git isn’t just a version control system; it’s a different way of thinking about collaboration.

With Git:

• Everyone can have a complete copy of the codebase
• Every copy usually includes the entire history, in a cryptographically linked chain
  
  • This makes it extremely difficult to smuggle in malicious changes unnoticed. You can’t quietly rewrite the past – any alteration breaks this chain of links and is immediately detectable.
• Every developer can work on their own code, at their own pace
• A single developer can pull code from multiple remote sources
• Code can flow between repositories, not just “up” or “down”

This is what makes Git a real powerhouse in the programming world. Each commit hash uniquely defines the full history up to that point and the entire repository state. Provenance is built in. Trust is verifiable. Collaboration doesn’t depend on a single server or a single workflow.

Built-in resilience and disaster recovery

One of the most overlooked strengths of Git’s distributed model is resilience. Because every clone is a complete copy of the project – including its full history – the future of the codebase does not depend on a single server, organisation, or hosting provider to survive.

If a hosting platform disappears, the project does not disappear with it. If a company changes direction, the code remains available. If infrastructure fails, development can continue from any full copy.

Traditional software vendors often rely on expensive source code escrow agreements as a safeguard in case a supplier collapses. With open-source software managed by Git, this protection comes baked into the technical architecture for everyone.

Disaster recovery is no longer a contingency plan, it is the default state of the system.

This resilience matters deeply for governments, enterprises, and long-term infrastructure projects. Software that underpins critical systems must not depend on a single point of failure – organisational or technical.

More forks than a restaurant ?

In some git-based development flows, the process of creating your own repository to work on new features and fixes independently is called forking.

On platforms like GitHub, it’s a prominent button at the top of the page because it’s a normal part of how distributed development works.

At the time of this screenshot for example, there were 978 forked copies of the Collabora Online source code – most of them made by developers eager to contribute back to the goodness – we love that!

Multiple remotes, multiple maintainers, multiple priorities, connected by shared code, shared history, bonds of friendship and collaboration powered by the Git synchronisation protocol. The choice of hosting and infrastructure becomes an almost irrelevant detail, with developers choosing the tools and processes that best support their work.

Improvements can be exchanged, and collaboration can happen without requiring everyone to follow the same internal processes or timelines.

At the same time, in ecosystems with many development paths, trusted editors play a critical role in curating, integrating, and supporting coherent, branded, secure releases.

The post Distributed by Design: How Modern Open Source Works appeared first on Collabora Online and Collabora Office.

Sovereignty or Legacy, You Choose

There is a lot of energy right now around European digital stacks. Self-hosted infrastructure. Local control. Reduced dependence on American cloud vendors. And all of that matters.

It seems to be a pattern that people take other people’s software that they have not written, and will struggle to support and put their brand on it, and wrap a European flag around it

But we should be honest about one thing – you are not sovereign if Microsoft still defines the fundamental design of your application, as well as your document formats.

You can move the server. You can change the branding. You can even swap out one vendor for another. But if the office layer at the heart of your stack is still at root built around Microsoft’s file formats, then they still set the rules that matter most. Your documents live inside a model you do not control, cannot meaningfully govern, and have no real power to shape.

That is not digital sovereignty. That is a hosting decision.

Self-hosting is not the same as sovereignty

A self-hosted office suite built around OOXML may reduce dependency on Microsoft 365 as a service. It may reduce exposure to American hyperscalers. It may tick some procurement boxes. But it does not solve the deeper problem – after all, you could do this with SharePoint 2019 till recently.

OOXML is Microsoft’s document model, standardised after the fact. Microsoft’s own documentation clearly describes .docx .xlsx and .pptx as formats to “support the features and behavior of Microsoft Office” while noting that ODF and Open XML reflect different application behaviours and feature sets. These are not neutral containers floating above the market, they reflect the architecture, priorities and direction of the organisations that created them.

That matters because formats are not just a way to save files. They encode the document model itself: what features exist, how layouts behave, how compatibility is judged, what gets preserved, and what gets lost. If you open an .odp presentation with the total slide count in the template in Microsoft PowerPoint, or save the file as a .pptx for example, PowerPoint and the .pptx file format simply throw away the information. If you want that feature back, good luck with the Microsoft support forums…

In short, if your strategy is to architect your software around Microsoft’s models, you can play with the UI styling and colours, but your product direction is being decided elsewhere.

You can call that interoperability, you can call it compatibility, for legacy workflows, it is certainly important and necessary. But you cannot call this strategy sovereignty.

Don’t get confused by marketing

There is nothing wrong with saying a product has strong OOXML interoperability – we all work on it. The mistake is turning that into the main sovereignty story.

ONLYOFFICE, for example, leans heavily on this message. Its public materials describe its editor as using OOXML natively, with all files converted into the format “when opening and editing files”.

Quoting directly: “If the file format is different from OOXML, it will still be converted to the corresponding OOXML […] As the formats are fundamentally different, some data (such as charts, tables, autoshapes or images) and formatting can be lost due to the simple reason that some formats […] treat them differently than OOXML standard does.”

That’s great if you want to centre your digital strategy around Microsoft, but absurd as the centrepiece of a digital sovereignty pitch.

True interoperability is: “We can work with the legacy world.”

And true sovereignty says: “We won’t build our future around the proprietary past.”

If your product story begins and ends with how closely you follow Microsoft’s formats, then your roadmap is still architected by Microsoft.

The post You Are Not Sovereign If Microsoft Still Architects Your Documents appeared first on Collabora Online and Collabora Office.

Protect

Some of the most important security features are the simplest ones: preventing the wrong change in the wrong place.

The simplest way to achieve this is to impose read-only access over some documents. Complimenting read-only control, Collabora Online also offers restriction of specific commands such as copying or printing documents. Unlike other document editors however, Collabora Online enforces these controls at the server side, helping ensure that restrictions are not just cosmetic interface choices. Combined with another server-enforced option of watermarking documents with user-specific details (not merely pasting ‘Confidential’ wording over the document), integrators and their end-users enjoy meaningful protection of the editing of documents, especially relevant in larger organisations to add confidence documents aren’t being downloaded or shared en-masse.

In many cases however, it is useful for users to be able to edit some parts of documents, but not others. In spreadsheets, features such as cell protection and sheet protection help teams preserve the integrity of critical information. That matters in budgeting, reporting, procurement, and operational planning, where some users may need to input or review data without altering formulas, structures, or approved sections. In practice, this helps turn a spreadsheet from a loose working file into a more controlled business document.

In written documents, section editing with optional password protection for individual paragraphs or longer ‘sections’ achieves the same goal. With section editing in Writer, the inverse may also be achieved such that sections in read-only documents can be made editable if needs be.

Control

Secure editing however is not about universally blocking change. It is about making sure the right people have the right level of access at the right time.

This is where platform integrations really matters. Integrating with Collabora Online, partners can enable custom per-user, per-document permissions, secure sharing controls, and granular guest access without breaking the connection between editing and the wider content system. The strength here is not that Collabora Online adds an additional control model to the storage platforms, but that it fits into it. Thanks to the WOPI-like protocol, permissions remain tied to the environment that already governs the document, instead of being redefined in the document editor.

Sensitive personal information, HR records, procurement documents, legal drafts, or citizen case files should not need to leave the managed environment just to be edited or reviewed. The more steps, services, and exports involved, the harder it becomes to maintain control. Collabora Online helps partners offer a cleaner model – keeping the workflows centralised, and access policy in one place.

Review

Because accountability is a security feature too.

In Writer, per-user tracked changes make it much easier to understand who changed what, and when. Changes are not only highlighted in red, but are tracked on a per-user basis. Each user has their own colour, and mousing over the change will show you who made the addition or deletion, and when. For review-heavy workflows, that is not just helpful for collaboration, it seriously strengthens auditability. In contracts, policies, internal approvals, and public-sector drafting, teams need a clear record of proposed edits and editorial responsibility. Named changes help make the review process visible rather than opaque.

Our newly released document comparison tool adds a further powerful layer here. Being able to compare two documents, and immediately highlight differences is invaluable anywhere precision matters, but especially in legal and contract workflows. Instead of relying on manual checks or trusting that nothing has been altered between versions, users can now see exactly what has been changed.

Version history also contributes to this broader accountability story. With the integration’s file storage layer and Collabora Online working in tandem, this is an important part of the overall secure workflow that integrators can offer end-users. Together, these powerful review features create a much stronger review chain most competitors can offer.

Signing

Unfortunately, document signing is one of the clearest examples where secure workflows break down.

Many organisations now end up sending all of their most sensitive documents to a third-party signing service, adding an additional storage layer (and jurisdiction?), another vendor relationship, and ending any on-premise or data-sovereignty promises (where is your document signing platform based?) Built-in PDF signing based on a document hash and not it’s content – directly from your document editor offers a better path. It allows integrators to support signing inside the document workflow rather than handing documents and data to someone else.

That matters for both privacy and process. Sensitive agreements, approvals, and public-facing forms should not be exported into a disconnected workflow just to get a signature. It also helps organisations simplify compliance-sensitive processes by reducing unnecessary exposure and keeping the entire document lifecycle within the integrator’s own platform.

The post How Collabora Online Helps Integrations Build Safer Document Workflows appeared first on Collabora Online and Collabora Office.

There is a question that every organisation storing data in Microsoft 365 should be asking, but most never do: can Microsoft access your files, emails, and documents without your knowledge or consent?

The answer, by default, is yes – and Microsoft will even sell you a feature to do something about it.

The Feature That Should Never Have Been Necessary

Customer Lockbox exists because, without it, access to your data is governed entirely by Microsoft’s own internal policies and processes – not by you.

Microsoft’s standard position is that it operates on a “Zero Standing Access” principle: engineers don’t have persistent access to customer data, and access is granted on a just-in-time, least-privilege basis. That sounds reassuring. But here is the critical distinction: those controls are Microsoft’s controls, not yours. The gatekeeper is the same organisation that also wants access to your data. You are not in the room when that decision is made. You may not even be notified that it happened.

Customer Lockbox changes this by adding the customer as a required approver. It shifts the control point from Microsoft’s internal process to your organisation’s administrators. In other words, it gives you the ability to consent.

Consent however shouldn’t be a premium feature.

That Microsoft has packaged the ability to approve access to your own data as an optional add-on – available only to customers willing and able to pay for it – tells you a great deal about how the company thinks about data privacy.

Privacy Should Be the Default, Not a Product

The deeper issue here is one of design philosophy. A company that genuinely places privacy at the centre of its product decisions builds oversight, transparency, and consent into the default experience. It does not reserve these things for paying subscribers.

Our approach at Collabora Productivity is rooted in a different set of assumptions. Our products are built on open-source foundations, designed for self-hosted deployment, and architected so that your data stays where you put it – on infrastructure you control, with access policies that you define. We don’t provide a back-door support channel through which a third party can request access to your documents. There is no premium tier required to retain meaningful sovereignty over your files.

Because that is what software should look like when the organisation building it genuinely thinks privacy matters.

The post Who Has the Keys to Your Data? appeared first on Collabora Online and Collabora Office.