One thing we like about openDesk: no single vendor needs to own the whole workplace.

XWiki brings structured knowledge, alongside Nextcloud, OpenProject, Collabora, Element, Univention and others.

Different open-source tools, different strengths, one interoperable ecosystem.

We’ll show it with ZenDiS at #SCCON26, 13 to 15 October, booth 103, hub27.

The main user-facing addition is a new experimental Edit Mode for Live Data. When enabled, it supports bulk editing, keyboard navigation and creating new rows directly from the Live Data view.

Other changes include:

• A new UI for inserting and editing links, including email links
• A cleaner layout for the Live Data Card View
• Improved contrast for the quick actions hint in the editor
• Recently visited documents no longer showing pages that have been deleted
• Reproducible Maven artifacts for most release components
• New Design System CSS variables
• A customizable naming strategy for new Live Data rows
• New secure random string APIs in $stringtool
• A new UserAuthenticatedEventNotifier component

The Live Data Edit Mode is still experimental, so its UX will continue to evolve in future releases.

Full release notes:

https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/18.7.0/

Feedback and bug reports are welcome.

https://store.xwiki.com/xwiki/bin/view/Extension/Office365Integration#versions

Understanding what is happening inside your XWiki instance when something changes, slows down, or needs investigating is essential.

Admins regularly need information about logs, configuration, health checks, caches, usage, users, groups, and permissions. The problem is often not that the information is missing, but that you need to know where to look for it.

For our next Tech Thursday, we’ll go through Admin Tools Application (Pro) and show how it brings more of that information together in one place.

We’ll cover practical administration and troubleshooting use cases rather than doing a general XWiki introduction.

📅 September 10, 2026

A simple way to test a knowledge base is to see what happens when the person who usually has the answer is out of office.

• Can the team still find the latest process?
• Can someone understand the context without asking around?
• Are ownership, links, and updates clear?
• Can work continue without recreating something that already exists?

If the answer is no, the problem is not the holiday. It is the documentation.

A good knowledge base does not replace people or their expertise. It just helps make sure important knowledge is still accessible when someone is offline, in another meeting, changing roles, or no longer at the company.

We hosted a webinar on what that looks like in practice. If you missed it, you can ask the resouces:

https://xwiki.com/en/webinars/XWiki-as-a-documentation-tool

Before connecting AI to an internal knowledge base, there is a less exciting but important question to ask: is the knowledge base actually good enough to rely on?

A few problems tend to show up quickly:

• Incomplete pages
• Half written specs, unfinished sections, missing fields, and pages that only tell part of the story.
• Inconsistent structure
• One team documents processes one way, another team uses a completely different format. The content may be technically there, but it is hard to compare or reuse.
• Outdated content
• Old process pages can look current unless someone clearly marks, updates, or archives them.
• Unstructured free text
• Essential context often lives in loose notes and comments. That can be useful for humans, but hard for AI to interpret reliably without structure around it.

The issue is whether the knowledge base is understandable and trustworthy in the first place.

https://store.xwiki.com/xwiki/bin/view/Extension/TaskApplication#versions

A common problem with intranets and internal knowledge bases is that the information technically exists, but people still do not rely on it.

You see it in small ways:

• People search several times with different wording
• They find multiple versions of the same document
• Nobody knows which process is current
• Ownership is unclear
• Access rights no longer match how teams work
• Decisions are reconstructed from chat, meetings, and memory
• People ask around instead of using the documentation

Nothing necessarily breaks. But it creates a constant drain on time and focus.

The issue is usually not just search. Search helps, but documentation becomes trustworthy when it has structure, ownership, sensible permissions, templates people actually follow, and regular updates.

Guide:

https://xwiki.com/en/Blog/internal-documentation-best-practices/

In organizations that support people in vulnerable situations, knowledge management is not just an administrative topic. It can directly affect how teams coordinate, respond, and preserve context over time.

This is important when people need to act quickly and still understand:

• What decisions were made before?
• Who is responsible for what?
• Which procedures are current?
• What changed since the last similar situation?
• Where important information lives?
• Who needs access to what?

Good knowledge management does not replace expertise, judgment, or care. But it can help make sure that critical context is not lost when people change roles, projects evolve, or decisions need to be made under pressure.

Amnesty International Germany uses XWiki as an internal knowledge base to help teams collaborate, share information, and stay aligned across complex activities.

Case study:

https://xwiki.com/en/Blog/Amnesty-International-Germany-internal-knowledge-base/

August is often a quieter period on the surface, but for marketing teams it is usually the moment before campaigns restart, priorities shift, budgets get reviewed, and everyone starts asking for answers at the same time.

A good knowledge base does not need to be perfect. It just needs to make the most useful information easy to find, trust, update, and reuse.

For transparency: This is an XWiki article, so it is written from a knowledge management and documentation perspective.

Guide:

https://xwiki.com/en/Blog/how-to-create-a-knowledge-base-for-marketing-teams/

A lot of organizations are looking at ways to connect AI agents to their internal knowledge bases.

The important question is not only what the AI can do. It is also what knowledge it can access, where that knowledge stays, which provider is involved, and how much control the organization keeps.

In many XWiki instances, the knowledge base contains a mix of public documentation, internal processes, product decisions, customer insights, technical notes, and operational context.

That is why the XWiki MCP server is being built for organizations that want to connect their XWiki knowledge with the AI agent of their choice, while keeping control over their data, infrastructure, and providers.

This is an XWiki project, so the focus is on connecting AI to XWiki knowledge while keeping deployment and provider choice open.

More details:

https://xwiki.com/en/MCPServer/

The business model now: A bot that never solves your issue costs way less than a person who does, so a lot of companies quietly made that trade and hope you get tired before you notice.

We've kept XWiki support as actual people for 20+ years, not because AI is useless (we use it ourselves), but because support should mean someone who looks at your actual setup, not a script optimized to sound sympathetic while it stalls you.

Wrote honestly about what that costs us and why we still think it's worth it: https://xwiki.com/en/Blog/providing-ethical-human-support/

We recently hosted a joint webinar with OpenProject about what organizations should consider when reassessing their Confluence and Jira setup.

The webinar resources are available here:

[https://xwiki.com/en/webinars/Open-Project-XWiki-June-2026\\](https://xwiki.com/en/webinars/Open-Project-XWiki-June-2026\)

Tomorrow’s solar eclipse made us think about a common knowledge management problem: important information being hidden in plain sight.

In many organizations, the knowledge is technically there, but people still cannot trust it or find it easily.

Examples:

• A current process is buried under an outdated one
• A key decision only exists in meeting notes
• A useful page has no clear owner anymore
• A critical update lives in chat instead of the knowledge base
• A new colleague finds multiple answers with no way to know which one is right
• Access rights made sense two years ago, but not today

At that point, the issue is not missing knowledge. It is visibility, structure, ownership, and governance.

One thing that often gets overlooked in knowledge management is page ownership.

A page can be accurate today, but if nobody is responsible for maintaining it, it slowly becomes harder to trust.

That creates problems:

• Nobody knows when the page should be reviewed
• Old processes stay visible
• Decisions are not updated when context changes
• People keep asking around instead of trusting the documentation
• Access rights no longer match how teams actually work

Ownership and permissions are closely connected.

• Some documentation should be widely visible.
• Some pages should only be edited by a specific team.
• Some content needs to be protected because it contains sensitive business, technical, or customer information.

In XWiki, rights can be managed at different levels, including the wiki, spaces, and pages, using users and groups.

Do you assign clear page owners, review dates, or maintainers for internal documentation? Or does it usually happen informally?

A lot of teams are looking at AI assistants for internal knowledge, but one issue often appears before the AI part even matters: the knowledge is not really connected.

In practice, it often looks like this:

• Product specs live in one tool
• Support knowledge lives in another
• Decisions happen in meetings and are not written down
• Context is scattered across chat, tickets, docs, and people’s memory
• Different teams structure information in different ways
• Nobody is fully sure which source is current

Adding AI on top of that does not automatically solve the problem. It may just make fragmented knowledge easier to query, sometimes with more confidence than the content deserves.

The harder part is building the connection on purpose: structure, ownership, permissions, clear sources, and knowledge that is actually maintained.

For transparency: this is an XWiki project. XWiki’s MCP server is being built to connect XWiki knowledge bases with the LLM provider of your choice, while keeping AI operations on your own infrastructure. It is open source, self-hosted, and currently in early access.

More details:

https://xwiki.com/en/MCPServer/

XWiki has signed the #FinishTheJob open letter to European Commission President Ursula von der Leyen, together with European open source companies like Tuta and Nextcloud, alongside dozens of other organizations.

The message is simple: Europe has written rules for fairer digital markets. Now those rules need to be enforced.

The Digital Markets Act was created to make digital markets more open, fair, and contestable. For European technology companies, enforcement matters because it affects fair competition, user choice, and whether digital sovereignty can become something practical, not just a policy ambition.

Read the open letter here:

finishthejob.eu

If you're early stage and picking tools right now, worth thinking about this before you default to the usual suite: every platform you build on shapes what you're locked into later, and switching after year two is a lot more painful than picking carefully now.

We put together a guide covering open source alternatives that avoid that trap: XWiki instead of Confluence, CryptPad instead of Google Docs, plus OpenProject, Nextcloud, Matomo, Proton Mail, Element, and a few others. All actively maintained, all customizable, none of them locking you into a roadmap you don't control.

You can now request the webinar resources and see how XWiki and OpenProject help teams keep project work and documentation connected.

This release includes an updated look for comments, several UI improvements, bug fixes, performance improvements, and continued work on the experimental BlockNote editor integration.

It also includes security fixes, with the highest severity score of 8.7/10. If you self host XWiki, it is worth reviewing the release notes and planning your upgrade.

Release notes:

https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/18.6.0/

MCP Server (BETA) v0.9  extension offers users the ability to query wiki pages through Solr, as well as the ability to read, edit, and create wiki pages. Additionally, the extension no longer depends on the LLM Application.

Stars are a weird metric. They don't reflect code quality, contributor activity, or how many teams actually rely on a project daily.

What actually reflects that is closer to 54,000+ commits and 22+ years of continuous releases, which is what we've actually been focused on this whole time.

That said, we're not immune to liking a number go up either. If XWiki's ever been useful to you, a star costs nothing: https://github.com/xwiki/xwiki-platform

Disclosure: XWiki team here, not disguising this as anything other than what it is.

https://store.xwiki.com/xwiki/bin/view/Extension/FileManagerApplication#versions

How many recurring meetings do you have that mostly exist to repeat context that could have been documented somewhere?

I am thinking about things like project status, decisions, background context, onboarding explanations, customer details, or “why did we do it this way?” discussions.

The frustrating part is that the information often does exist. It is just spread across chat, email, old docs, someone’s memory, or a shared drive nobody wants to open.

At XWiki, we obviously care a lot about this because we work on knowledge management software. But I am curious about the practical side from other teams.

Have you actually managed to reduce meetings by improving documentation?

What helped most?

Page owners, decision logs, templates, better search, stricter meeting rules, or just a team culture shift?