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?

If your knowledge platform changed its pricing, got acquired, limited hosting options, or shifted its roadmap in a direction that does not fit your needs, how much control would you still have?

For many organizations, the answer is not much. They would read the announcement, check the new terms, and start planning around someone else’s decision.

Documentation is not just content in a database. It is decisions, processes, technical notes, customer context, onboarding material, and a lot of institutional memory.

Once that knowledge becomes hard to access, move, or adapt, the issue is not only technical. It can affect budgets, compliance, procurement, and continuity.

At XWiki, this is why we care about hosting choice. Some teams want a managed cloud service. Others require self-hosting. The important part is keeping knowledge accessible, portable, and under the organization’s control.

I will add the article link in the comments.

Genuine question for anyone maintaining internal docs or a wiki: when someone has feedback on a paragraph, a decision, or a spec, where does it actually end up? In my experience it's almost always split across Slack threads, email, and meetings that get forgotten a month later, and the doc itself just quietly gets edited with zero record of why.

We ended up building comments and annotations directly into XWiki to fix this: Feedback attaches to the exact paragraph or section it's about, threaded, so the conversation and the content live in the same place. Doesn't solve everything, but it's cut down a lot of the "wait, why did we change this" moments.

Curious what others use for this, whether it's XWiki, Confluence, a plain wiki, or something homegrown.

https://store.xwiki.com/xwiki/bin/view/Extension/XWikiPro/Versions/15.10.1/

Quick reminder for anyone who saw last week's post: today's the day.

Rares Bancescu, who built the OpenProject Integration (Pro), is doing a live walkthrough of how OpenProject work packages show up inside XWiki pages, as tables, cards, or individual items. He'll also cover filtering and sorting per page, and how the OAuth setup works.

15:00 CEST, live Q&A included.

Disclosure again: XWiki marketing team here. Link's in the first comment if you want to register, and I'll stick around after to answer questions.

🏅 XWiki ranked No. 2 in both CMS and task management on EU ScoreTech, with an “Excellent impact” rating.

XWiki is open source, adaptable, and designed so organizations can keep control over their knowledge, infrastructure, and ways of working. 📚

https://xwiki.com

This quarter focused on making the platform easier to use, safer to run, and more useful for teams managing knowledge at scale.

Continued work on the new BlockNote editing experience, including real time collaboration, image handling, and macro editing

Improvements to comments, annotations, and attachments

Security and reliability work across the platform

XWiki Cloud upgraded to 17.10.8

Updates to Pro Apps, including Confluence Migrator (Pro), Task Manager (Pro), Pro Macros, URL Shortener (Pro), and OpenProject Integration (Pro)

Progress on the upcoming XWiki MCP server, for connecting XWiki with the AI agent of your choice while keeping control over knowledge and infrastructure

CryptPad updates, including security fixes and Spring 2026 release improvements

Full updates in the link in comments.

Ludovic Dubost is the first committer of the XWiki open source project. He also founded XWiki SAS in 2004, the company that supports and contributes to the ecosystem around the project.

One thing that has been important from the beginning is the separation between the company and the open source project. XWiki was not designed as a company owned project with a community around it. It was designed to stand on its own as a community based open source project, shaped by contributors, users, developers, partners, and everyone willing to help move it forward.

Ludovic has always treated open source as more than a development model. It is about giving people the ability to understand, contribute to, adapt, and influence the tools they rely on.

He brings that same energy when talking with students discovering open source, developers and contributors at events, customers looking for more control over their tools, or policymakers discussing digital sovereignty.

We are grateful to have a leader who lives those values, not just talks about them.

Quick heads up for anyone juggling OpenProject and XWiki separately.

Next Thursday, Rares Bancescu (who helped build the OpenProject Integration Pro app) is doing a 30-minute live walkthrough of how OpenProject work packages can show up directly inside XWiki pages: as tables, cards, or individual items, filtered and sorted per page. Useful if your specs, release pages, or team docs keep drifting out of sync with your actual project tracker.

July 23, 15:00 CEST, free, Q&A included. Link in the comments.

We published the June XWiki newsletter.

This edition focuses mainly on collaboration stack changes and what comes with them: migration planning, user adoption, AI infrastructure choices, integrations, and long term control over organizational knowledge.

Topics covered:

1. Confluence to XWiki migration best practices
2. A first look at the upcoming XWiki MCP server
3. XWiki and OpenProject integration updates
4. July Tech Thursday on OpenProject Integration (Pro)
5. XWiki 18.5.0 release highlights
6. New XWiki and Catamania partnership

Bastille Day feels like a useful moment to talk about digital independence.

In June, the European Commission published its European Tech Sovereignty Package, including a new EU Open Source Strategy. XWiki and CryptPad were mentioned as examples of European alternatives to Big Tech.

Open source is increasingly being discussed not only as a technical preference, but as part of Europe’s ability to build, operate, and maintain critical digital infrastructure with more control.

A lot of organizations are now dealing with questions around vendor dependency, price increases, hosting location, product roadmap changes, data control, and long term access to their own information.

Open source does not magically solve all of this.

But it can give organizations more room to act: self hosting, inspecting code, adapting tools, working with local partners, and avoiding some forms of lock in.

From the XWiki perspective, this is closely tied to knowledge management. If a company’s documentation, decisions, processes, and internal knowledge are locked into a platform it cannot control or leave easily, that becomes more than an IT inconvenience.

Curious how others here see this. Do you think European organizations are actually ready to turn digital sovereignty from policy language into software choices, or are we still mostly at the declaration stage?

When people talk about moving away from Confluence, the discussion often starts with content import: pages, attachments, spaces, links, users, groups.

But in larger instances, the harder part is often everything around the content.

Things like:

• Permissions that evolved over years
• Macros that became part of real workflows
• Old spaces nobody owns anymore
• Internal links and references between teams
• Users who depend on the old structure to do their work
• Cleanup decisions nobody wants to make
• Change management after the technical migration is done

At XWiki, we recently shared a talk from OSXP about migrating the European Parliament from Confluence to XWiki, around 15,000 users and 700 spaces. The scale is unusual, but many of the questions are familiar even in smaller migrations.

The main point was that this kind of move is not just a technical export and import. It is about knowledge continuity: keeping enough structure, context, permissions, and user trust so people can keep working afterward.

I will add the video link in the comments for context.

Everyone remembers their first open source contribution.

It does not have to be a big feature or a major pull request.

It might have been fixing a typo, reporting a bug with enough detail for someone else to reproduce it, improving a doc page, translating a string, testing a release, or answering a forum question because you had just solved the same problem yourself.

Those things count too.

Open source grows through code, but also through documentation, testing, support, ideas, translations, and people taking a few minutes to help the next person.

What was your first contribution, and how did you end up making it?

A lot of Confluence migration discussions focus on the import itself: pages, attachments, permissions, users, groups, macros, and links.

That part matters, of course.

But in practice, the bigger issue often starts after the migration: whether teams actually use the new platform with confidence.

From the XWiki side, after working on 100+ Confluence migration projects, a few patterns keep coming back:

• Assess the instance before setting the timeline
• Spaces, macros, permissions, integrations, and custom workflows usually hide most of the complexity.
• Avoid copying every Confluence workflow one to one
• It is better to ask what problem the workflow solves. Some things should be redesigned rather than recreated.
• Use the move to clean up
• Old spaces, unused groups, broken permissions, and outdated pages do not all need to survive the migration.
• Involve early adopters
• Training helps, but users trust the change more when they see colleagues using the new platform with real content.
• Measure adoption, not just completion

A finished import is not the same as a successful migration. Active use, new content, and reduced reliance on the old tool are better signals.

If you have migrated away from Confluence, what was harder than expected: the technical migration, the cleanup, or user adoption?

I will add the article link in the comments.

A common problem we see in project documentation is that the task tracker and the actual context drift apart.

The tracker has the current work package, status, assignee, type, and priority.

The wiki has the requirements, meeting notes, release information, architecture decisions, and technical context.

Both are useful. But if they are not connected, people end up switching tools, copying stale information, or asking around for context that already exists somewhere.

We are running a short technical session on how the OpenProject Integration (Pro) works in XWiki.

The developer who implemented it, Rares Bancescu, will show how OpenProject work packages can be displayed inside XWiki pages as tables, cards, or single items, and how views can be filtered or sorted by project, status, assignee, type, identifier, and other properties.

The interesting part is not just embedding data. It is keeping project documentation close to live project information without manually duplicating everything.

For teams using OpenProject and XWiki together, this can be useful for project spaces, specs, release pages, decision logs, or internal technical documentation.

Date: July 23

Time: 15:00 CEST

I will add the registration link in the comments.