On October 5, 2026, I gave a talk at CiviConf in Paris entitled On Desire Paths Through CiviCRM. It explored knowledge infrastructure as an institutional factor in CiviCRM’s success. CiviCRM is remarkably powerful software, but many potential users across Europe have yet to discover what it can do. The main challenge is less about access to the software and more about learning how to make it useful.

The software offers a wide range of features that help groups, associations, foundations and political organisations solve everyday organisational problems. Different users often find similar ways of working, but these paths are rarely mapped out. Wherever people use CiviCRM successfully, they tend to develop practical solutions, recurring workflows and proven configurations on their own. Yet this knowledge often remains within individual organisations, service providers or experienced users.

Making desire paths visible

In my talk, I used the image of desire paths: informal trails created when people repeatedly follow a route because it offers a practical way to reach their destination. What begins as an individual solution can become a shared path through repeated use.

Applied to CiviCRM, this means documenting not only its features but also proven ways of using them. These workflows need to be described, tested, shared and updated regularly. Only then can they become a resource that others can use.

This is more than a matter of good software documentation. First, it concerns how we organise the collective creation of knowledge. Second, it provides a starting point for a wider conversation among software users, implementation agencies and developers.

Drawing on Mancur Olson’s theory of collective action and Elinor Ostrom’s ideas about the role of institutions in governance arrangements, I argued in Paris that knowledge about how to use CiviCRM is a shared resource that exists beyond the program code. Creating and maintaining this resource requires institutions that make collective action possible and encourage it.

Starting documentation from actual use

Interestingly, during the sprint that followed the conference in Paris, I was able to connect these ideas directly with other work in the CiviCRM community. Dave Moreton presented his work on improving CiviCRM documentation and pointed to existing conceptual foundations. In 2025, he had worked with Alain Benbassat and Don Hirst on CiviCRM documentation at the Point Montara Lighthouse Sprint south of San Francisco. He describes their proposals in his blog post Documentation – Montara Sprint.

A corresponding structure can be seen at beta.docs.civicrm.org. It distinguishes between tutorials, how-to guides, reference information and explanations. This follows the Diátaxis approach, which recognises different needs when learning and using software.

This is particularly relevant to our work at polbeo. At polbeo Knowledge, we are developing a method to document recurring workflows in a consistent way. We start with a specific organisational task, describe the requirements and guide readers through a proven process towards a result they can verify.

The two approaches do not compete. They complement one another: Diátaxis distinguishes different types of documentation, while desire paths help us identify what needs to be documented. The method developed at polbeo aims to turn an identified desire path into a clear, repeatable guide.

From individual guides to a shared resource

This opens up an interesting possibility. If we design our documentation from the outset to be compatible with the CiviCRM community’s structure and quality standards, the guides created at polbeo need not be limited to our own customers.

They could feed directly into the community’s shared documentation. Conversely, we could build on existing community documentation for our workflows rather than writing everything again.

This requires attention not only to content quality but also to sources, prerequisites, software versions and ongoing maintenance. It also requires an appropriate process for reviewing, accepting and improving contributions.

For polbeo, this is not a side issue. We want to make CiviCRM easier to adopt by simplifying its provision and technical maintenance, while also documenting practical ways of using it.

The discussions in Paris strengthened my belief that this approach reaches well beyond our own company. The desire paths of individual users can become shared infrastructure that makes CiviCRM more accessible and supports its continued development.