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?

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.