Free tools, agile and self-management
In good Swiss fashion, when we need to think, we lock ourselves away in a chalet and eat lots of cheese. Here, during Octree 2025 week, from left to right: Renato, François, Tim, Xavier, Thomas (represented by his cat), Guillaume, Hadrien and Mathilde.
As a multi-disciplinary team producing digital tools for others, we've always needed both cross-disciplinary and specific applications. In addition to budgetary constraints, we had to make ethical choices: how could we promote open source and free software while gaining in efficiency?
Negotiating a permanent transformation
Agile (before it became a political slogan) is a manifesto followed by 12 simple principles but which require a great deal of experience to apply correctly. One of these principles is, for example, the following:
"The best architectures, requirements and designs emerge from self-organized teams."
- The Agile Manifesto
By tools freewe understand all technological tools (applications, software) that are protected by a license guaranteeing that they remain common property that everyone is free to modify, reproduce and repair. We differentiate these from proprietary software, which leads to user subjection and dependency.
Self-management, which we often call distributed governance to give the term a new lease of life, can be described as follows:
"Self-management is opposed to heterogestion, which is the way of running businesses, the economy, politics, or society without the involvement of those directly concerned."
- De L'Autogestion, Théories et Pratiques, collective work
At Octree, our self-management is based on theholacracy and draws on other methods such as sociocracy and liberating structures and peer coaching and more. However, it's one thing to self-manage using methods, and quite another to change our tools to be based on free software. If we really want to have integrity in our defense of the digital commons, it also means stopping cauterizing dependency-based business models and replacing them with interdependency-based models. So we need to make this deeper transformation: replacing our proprietary tools with open source and free tools.
"Self-management presupposes tools that can be self-managed."
- André Gorz
Our tools are still far from being 100% open source, as this process of continuous improvement unfolds over years. The choice of tools is guided by our needs: are they costly? Do they create long-term dependency? Can the application be used both internally and externally? Is it possible to integrate other tools or even custom developments? Does it help reduce the overall number of tools in use, thereby lowering the team’s cognitive load? Does it strengthen cross-disciplinary collaboration, or does it hinder collective intelligence? And above all, is the application sustainable or are we relying on a project already in decline?
To differentiate between these issues, we have isolated 2 aspects of our work.
general aspects
Necessary for the smooth running of Octree, including internal & external communications, administration, archiving, governance and information management. Typical features include calendar, chat, social networks, shared drive, email, accounting...product aspects
Necessary for the smooth running of productive teams, these tools enable you to design interfaces, plan releases, make decisions, test developments and monitor project progress. Typical features include versioning (Git), UX design, virtual whiteboard...
The purpose of this article is not to offer ready-made solutions for other organizations or fields of activity, as each approach is unique. Rather, by sharing our own approach to change, we aim to make visible the organization and infrastructure that enable us to operate efficiently and with agility across diverse domains (from democratic participation and recycling management to energy systems and shared mobility) while drawing on our varied professional expertise (IT engineering, UX designers, product owners, visual communication). We also hope to encourage other tech cooperatives to share their own practices of self-management and agile collaboration through the tools they use.
The team stack: shared reference points
Green: open source; black: proprietary.
From left to right: Passbolt, Bexio, Odoo, Mastodon, Buffer, Linkedin, Glassfrog, Matrix, Gitlab, Kdrive, Notion, Figma and Whimiscal.
General tools are shared by most team members, making them common points of reference that are, whenever possible, linked to collective competencies. This aspect is far from trivial in a shared governance model, as it relies on a constantly evolving ideal: themost complete rotation of the roles making up the team. In our case, Notion can be used by all as a shared wiki, but also by the following roles Agile Coach, Product Owner, Customer Relationship, Secretary, Communication or even Business Development. The tools fully shared by all team members areMatrix, KDrive, Notion and Glassfrog, for our governance. These tools will also be the first to be used by new team members. This base enables us to cover a broad spectrum of our activities.
Matrix: instant communications | present.
Kdrive: collective archiving over time.
Notion: current activities | present and near future.
Glassfrog: Governance | present.
The others are considered to be global tools, as their use is part of a timeframe that escapes defined project cycles.
The product stack: tailored to specific skills
Green: open source; black: proprietary.
From left to right: Figma, Gitlab, Github, Whimsical, Notion, Weglot, Kdrive, Squarespace, Infomaniak suite, Rails, Grafana, Matomo, Traefik, Opencollective, Odoo, Docusaurus, Crowdin, Prisma, tRPC, Zod, AuthJS, Mailcatcher, Fider, UptimeKuma, Metabase.
Though similar to the tools used by other teams in the sector, it's interesting to note that the whole stack adapts to the tool that'sat the heart of our business: Gitlab allows us to coordinate product releases and involve all the productive roles in the team: Product Owner, UX, Dev, Sysadmin, etc.
In terms of "organizational architecture", we can't help but think of Steward Brand's diagram "How Buildings Learn", describing the life cycle of buildings as conditioned by what is most often reproduced within them: patterns of use, then interior layouts, room functions, and ultimately the architecture and foundations.
How Buildings Learn, Steward Brand, 1994.
It would be simplistic, however, to see this as the same situation: just as a building comes with its own constraints, such as materials, zoning, neighbors, and so on, so do we. Octree's main constraints are financial viability and ethical commitments. We therefore strive to maintain a constant balance between these different factors:
Productivity –VS– cognitive load
Technical autonomy –VS– profitability
Quality of service –VS– openness to change
Interoperability –VS– maintenance cost
Team size –VS– resillience –VS– agentivity
Today, we've replaced the following tools with these free alternatives:
X → Mastodon
Harvest → Odoo
Google → Infomaniak
Slack → Matrix
Github → Gitlab
Google Analytics → Matomo
Freshdesk → Odoo
It all adds up to this:
More granular tools such as plugins, libraries and programming languages have been deliberately left out to simplify the illustration.
Next on the list could well be: Figma by Penpot Squarespace or Notion. There's no shortage of alternatives, but we're waiting until we're ready to manage these changes.
Interestingly, we've added a new tool, Opencollective. Breaking free from classic liberal logic, Opencollective enables us to givefinancial transparency to our projects and to launch participative financing campaigns.
A workshop is not an office
Getting away from the Gafams is a big win. The usability of proprietary solutions is real, but goes hand in hand with the opacity of the systems used and interactions conditioned by profit logic. We have to make a profit at octree (or we're sunk), but it's useful to remember that apart from productivism, autonomy and cost optimization are a big help to our little team.
Put simply, the question of technical sovereignty arises quite naturally when one’s professional activity depends on digital systems: so, by using open source tools, we not only gain the ability to make them interoperable but also to contribute to their development. Where some might see a dispersion of effort, we see a productive investment: it helps us maintain and care for a technical stack oriented toward efficiency, while also allowing us to invest in the social reproduction inherent to our profession. By working on our stack, we meet others, nurture relationships, and develop new skills. These skills can then be shared as consulting and support for larger organizations that also seek to free themselves from the dominance of tech giants.
Tip: for each tool change, we open a test project. The purpose of this project is, for a given period, to test the tool change with real data, and then to identify any risks associated with this change for Octree as a whole. Once decided collectively, the change can be made one project at a time, to benefit from gradual feedback and to take risks measured on a group-wide scale.
Empowerment and freedom are forged through shared pleasure, as long as we stay organized and move forward, one change at a time. The African American poet Audre Lorde had already understood this in 1979 when speaking of feminism, and in the end, the same applies to breaking free from power dynamics and dependency in the workplace:
"The Master’s Tools Will Never Dismantle the Master’s House".
- Audre Lorde
— Lucien for Octree
Find out more:
