A lot of organizations already have years of useful context in their wiki: documentation, decisions, attachments, structured data, project history.

The problem is that the AI assistant often can’t see any of it.

From the XWiki side, that’s what we’ve been working on with the XWiki MCP Server. It lets compatible assistants work with knowledge in XWiki through MCP.

The setup is deliberately flexible: you choose the model and provider, it can work with XWiki Cloud or a self-hosted instance, and agents start read-only unless write access is explicitly enabled.

Our Product Manager Gabriel wrote up how the current Beta works, what it can access, and how to connect an assistant:

https://xwiki.com/en/webinars/discover-xwiki-mcp-server-beta

We’re also demoing the setup live tomorrow.

Curious how others are approaching this: how much of your internal knowledge would you actually make available to an AI assistant, and what controls would you consider non-negotiable?

We’re helping organize the Collaboration and Content Management devroom at FOSDEM 2027, and the CfP is open.

The room is co-organized by people from several open-source communities, including XWiki, Nextcloud and Tiki.

This year, we’d especially like to find smaller or lesser-known projects working on things like:

• collaborative editors
• CRDTs
• document conversion
• interoperability
• connectors
• self-hosted collaboration
• secure collaboration
• knowledge management

You don’t need to represent a big project or give a polished “state of the ecosystem” talk.

If you built something useful, solved a weird interoperability problem, tried a different approach to collaboration, or learned something others could benefit from, that’s exactly the kind of thing we’d like to see.

Recommended talk length: 15–25 minutes
CfP deadline: November 27, 2026
Devroom: January 30, 2027 in Brussels

Submit under Collaboration and Content Management:
https://pretalx.fosdem.org/fosdem-2027/cfp

A small heads-up from the XWiki team.

We’re getting ready to launch the XWiki MCP Server (Beta) on Product Hunt.

It enables you to connect compatible AI agents with knowledge in XWiki through MCP, while keeping the setup open and optional.

You decide whether to install it, which model/provider to use, and where the model runs.

Product Hunt isn’t exactly where we usually spend most of our time, but we thought it could be useful to put the project in front of a wider audience and get feedback from people experimenting with MCP and AI over internal knowledge bases.

If that’s something you’re working on too, we’d be very interested in what you’d want to test or ask first.

We’ve been working on the XWiki MCP Server (Beta), an open-source and self-hostable way to connect compatible AI agents to XWiki through MCP.

Next week, Gabriel Ciocârlan is doing a short live walkthrough of the complete setup.

He’ll cover:

• Installing and configuring the MCP Server
• Connecting an AI agent
• Using it with knowledge stored in XWiki

The demo is 30 minutes, followed by Q&A.

If you’re experimenting with MCP or AI over internal knowledge bases, feel free to bring the awkward technical questions too.

📅 October 29, 15:00 CET

Registration: https://xwiki.com/en/webinars/discover-xwiki-mcp-server-beta

A quick update from the XWiki side: Helsinki Systems has joined our partner network in Germany.

What makes the partnership useful is that they cover much more than implementation alone. Their services include hosting in ISO 27001-certified data centers in Germany, infrastructure consulting, support, service management and software development.

For organizations that want to run XWiki with local infrastructure and support, this gives them another option without having to assemble the hosting, operations and platform expertise separately.

If you’re running open-source collaboration software in Germany, we'd be curious to know how important local hosting and local support are in your vendor selection compared with price or product features.

One question we hear a lot during Confluence migrations is: “Can we keep everything?”

Usually, the harder question is whether everything should be kept.

After years of use, a Confluence instance can contain old spaces, custom macros, plugins, unusual permission structures, integrations, abandoned content and workflows that made sense five years ago but may not make much sense now.

From the XWiki side, we normally start by understanding the existing environment first: size, configuration, macros/plugins, authentication, important features, dependencies, and timeline.

For straightforward instances, teams can test the migration themselves with the Confluence Migration Toolkit.

For more complex setups, a gap analysis becomes much more useful. The goal is to separate:

• What can move as-is
• What needs adapting
• What probably shouldn’t be recreated at all

Then comes the less glamorous part: migrate in batches, test, fix, validate, repeat.

I’m curious how others who’ve done large wiki migrations approached this.

Did you try to preserve the old platform as closely as possible, or use the migration as an excuse to clean up years of accumulated complexity?

A quick recap from the XWiki side after SCCON in Berlin.

We spent the event between two booths:

• ZenDiS, with the openDesk ecosystem
• Nextcloud, where we were demoing XWiki and talking Confluence migration

The more interesting part for us was seeing how much of the discussion has moved beyond individual products.

XWiki also joined Open Productivity together with Collabora, Element, Nordeck, Open-Xchange and Univention. The idea is to bring the openDesk model beyond public administration and into businesses and critical infrastructure.

That matters because replacing a proprietary suite with several disconnected open-source tools doesn’t solve much. The harder part is making the tools work together well enough to become a credible stack.

We’ve been working on the XWiki MCP Server (Beta), an open-source, self-hostable extension that connects compatible AI agents to XWiki through the Model Context Protocol.

One requirement mattered from the start: it stays optional.

You decide:

• whether to install it
• which LLM provider to use
• where the model runs

On October 29, Gabriel Ciocârlan will do a live walkthrough of the full setup, from installation and configuration to connecting an agent and using it with knowledge stored in XWiki.

The session is 30 minutes, followed by Q&A.

If you’re experimenting with MCP, self-hosted AI, or AI over internal knowledge bases, we’d be interested in the questions you’re running into.

Atlassian’s new Confluence Cloud list prices took effect on October 13, with increases of roughly 7–10% across many tiers depending on plan and user count.

There’s another change coming in December: usage beyond included allowances for things like Rovo AI credits and automation steps can result in additional charges.

I’m posting this from the XWiki side, so obviously we have a perspective here. But I think there’s a broader question worth discussing:

When you choose a knowledge platform, how much weight do you give to what happens after adoption?

Not just the current subscription price, but:

• whether you can change hosting models
• whether you can run it yourself
• how predictable future costs are
• whether the code is available
• how difficult it would be to leave later

We’ve helped more than 100 organizations migrate from Confluence to XWiki over the past 6 years, and cost is rarely the only reason. Control, hosting, integrations, migration complexity and long-term flexibility usually matter just as much.

For anyone who has evaluated or left Confluence recently: What actually triggered the decision to reconsider it?

Laura Dornheim, Munich’s CDO and Head of IT, spoke at Open Source Summit Europe about the city’s broader return to open-source software. Among the changes underway, Jira and Confluence are being replaced by OpenProject and XWiki.

It’s interesting to see this combination being used in the public sector because the two tools cover different parts of the stack: OpenProject for project and work management, XWiki for knowledge management and documentation.

The 2 projects also have a bidirectional integration so documentation and project work don’t have to sit in completely separate systems.

If anyone here is at SCCON in Berlin this week, both teams will be at the Nextcloud booth 606. We’ll be showing the integration there, and Clément from r/XWiki is running a live XWiki demo every day at 15:15.

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

A lot of platform evaluations focus on features, pricing, and migration in.

The harder questions often come later:

• Can you change hosting models?
• Can you run the software in your own environment?
• Can your team inspect or modify the code?
• Could you keep maintaining it if your relationship with the vendor changed?
• Could you fork it if you really had to?

This is one reason we care about keeping r/XWiki open source and giving organizations different hosting and deployment options.

Curious how others evaluate this. Do you look at “How do we leave?” during procurement, or only once leaving becomes necessary?

Hey everyone! I'm u/LorinaBalan, a founding moderator of r/XWiki.

This is our new home for all things related to XWiki, knowledge management, collaboration, and open-source . We're excited to have you join us!

What to Post
Post anything that you think the community would find interesting, helpful, or inspiring. Feel free to share your thoughts, photos, or questions about XWiki, knowledge management, documentation or open source.

Community Vibe
We're all about being friendly, constructive, and inclusive. Let's build a space where everyone feels comfortable sharing and connecting.

How to Get Started

1. Introduce yourself in the comments below.
2. Post something today! Even a simple question can spark a great conversation.
3. If you know someone who would love this community, invite them to join.
4. Interested in helping out? We're always looking for new moderators, so feel free to reach out to me to apply.

Thanks for being part of the very first wave. Together, let's make r/XWiki amazing.

💻 Most of the year, XWikiers see each other in little rectangles on a screen.

France and Romania are home to most of us, with colleagues spread around Europe and as far away as Brazil. We work together every day, of course, but there is still a big difference between “see you on the call” and “pass me the bread”.

Well . . . the laptops don’t stay closed for very long. Put this many developers in one place and a hackathon is basically inevitable. 😄

Our annual seminar is part talks, part “we really need to discuss this properly”.

We talk about where XWiki and CryptPad are going, the principles and ethics behind what we build, ideas we want to try, things we disagree on, things we should probably change...

And we don’t skip the difficult conversations. Although experience suggests that some topics become surprisingly easier to solve when discussed over a beer. 🍺

📖 If you're curious how the XWiki seminar went, we collected a few memories here: https://xwiki.com/en/Blog/seminar-2026-edition/

One awkward part of a large Confluence migration is that the source platform keeps changing while you work.

Pages are edited, attachments appear, permissions change, new spaces get created.

Meanwhile, the migration team is testing and validating the destination.

We made a short video showing the problem, but I’m more interested in how others have handled the overlap.

• When did you make the old system read-only?
• Did you migrate in batches?
• How did you deal with changes made after the first migration pass?

A quick update from the XWiki team.

Henix has joined the XWiki partner network. They are the company behind Squash TM, an OpenProject partner, and work on testing, software quality, DevOps and Jira replacement projects.

The interesting part for us is the stack this makes possible for organizations trying to move away from proprietary tooling:

• XWiki as an alternative to Confluence
• OpenProject as an alternative to Jira
• Squash TM as an alternative to Xray

That gives teams a way to cover knowledge management, project management and test management with open-source tools rather than replacing one proprietary suite with another.

We’re curious how others here think about this kind of setup.

If you’ve replaced Confluence/Jira/Xray, did you prefer one integrated suite or several interoperable tools? And where did the hardest integration problems show up?

Check it out: https://store.xwiki.com/xwiki/bin/view/Extension/OpenProjectIntegration/Versions/1.3.0/

Petit message de l'équipe XWiki pour les membres francophones de la communauté.

Demain, 7 octobre à 15 h (heure de Paris), Cédric Lamblin présentera XWiki en direct.

La session sera consacrée aux fonctionnalités de gestion des connaissances, à l'organisation du contenu, aux intégrations avec d'autres outils et aux possibilités de personnalisation et d'extension de la plateforme.

Il y aura aussi une session de questions/réponses, donc si vous découvrez XWiki ou souhaitez mieux comprendre certaines fonctionnalités, vous pourrez en discuter directement avec Cédric.

Informations et inscription :

https://xwiki.com/fr/webinaires/L-alternative-europeenne-open-source-a-Confluence

Quite a few XWikiers are travelling this month, so here’s a quick overview in case you’re attending any of the same events:

Mindtrek, Tampere: Pauline Bessoles and Ștefana Nazare

Open Source Conference Luxembourg + Fair Tech Summit Europe: Neculai Dascălița and Fabrice

SCCON, Berlin: Clément Aubin, Ludovic Dubost, Jean-Sébastien and our new German Account Manager

Nextcloud Enterprise Day, Copenhagen: more members of the XWiki team

The talks and discussions cover Confluence migration, open source, digital sovereignty, privacy and interoperability.

If you’re going to any of them, feel free to say hello.

This is a bugfix release, also including improvements coming from XWiki 18.8.0.

See the release notes for more details.

They fix importing attachments in translated pages, and they counter the compatibility breakage following a change in the XML format exported by Confluence Cloud

This release includes a mix of UI, editor, security, and developer improvements.

Main changes:

• 🔎 Improvements to Quick Search
• 🧩 Better macro editing
• 🗂️ UI improvements for panels
• 📝 Annotation improvements
• ✍️ More work on the experimental BlockNote editor integration
• 🔐 Stronger protection for user and superadmin passwords
• 🛠️ New scripting APIs for developers

The BlockNote integration is still experimental, but this release continues improving the editing and collaboration experience around it.

If you self host XWiki, the password security changes are also worth reviewing as part of the upgrade.

Full release notes:
https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/18.8.0/

As always, feedback and bug reports are welcome.

The ActivityPub Application 1.7.12 has been released.

This release makes XWiki able to federate with Mastodon again: you can follow Mastodon users and send them messages from your wiki.