Why I like being able to get my hands on it.

Curiosity needs an open door

The more I explore self-hosting, the more I understand what draws me to open source: I can read the documentation, study the code, understand a choice and try changing it. I may not do that for every tool, but knowing the door is open changes my relationship with what I use.

When I build something, I like thinking another person could start from there too. Licences set the conditions of that exchange; explaining choices and sharing what I learned makes it concrete. That is one reason I want to write about Nannix.

What I learn comes from other people’s work

My lab exists because someone made software, guides and ideas accessible. I naturally think of scientific research: being able to study and verify work lets us move forward. I wish that willingness to share became ever more natural in computing too.

Wikipedia and open projects remind me how much of that shared resource I use every day. I would like to give something back: code, a useful explanation, support for someone maintaining a tool. Even an honest account of an experiment can help the person who comes after me.

People who keep building

I also keep people whose ideas I enjoy in the library. I am interested in the thinking behind software: what they simplify, which trade-offs they accept and how they explain their work. These are some references I want to keep returning to.

Linus Torvalds and the Linux kernel are a reference for work on shared code. What interests me about Salvatore “antirez” Sanfilippo is the thinking behind the tools: building, explaining choices and looking for solutions a person can still understand. Fabrice Bellard, through projects such as QEMU and TinyCC, reminds me how much focused technical work can achieve.

In D. Richard Hipp and SQLite I find a reference for focused, reliable tools; in Daniel Stenberg and curl, for sustained care of an open source project. Simon Willison makes experiments and technical notes available to explore; Mitchell Hashimoto, including through Ghostty, interests me for the connection between autonomy and hands-on software work.

Rich Hickey, in “Simple Made Easy”, helps me think about complexity. Rob Pike connects tool design to the needs of people building and maintaining software. Pieter Hintjens, through the ZeroMQ guide, brings protocols, documentation and community into the same conversation. These are references for different aspects: I want useful questions from each, without assigning them all the same philosophy.

I want to see how shared things are built

That desire to understand follows me outside the lab too. I would like publicly funded software to be open, so we can study and reuse work we have already contributed to. IO, in the pagoPA ecosystem, is a reference I appreciate for making its code available.

For me, opening work also means taking care of what is exposed: code, personal data and credentials need different treatment. I care about transparency that helps people understand the system and protects the people using it.

I want to choose what I pay for

My dislike of subscriptions sits alongside respect for developers’ work. I am willing to pay for something useful and to support its maintenance. What bothers me most is an unclear exchange in which I give valuable information and also pay to remain in a service that is hard to leave. I want to pay knowingly and have a choice.

Donations, crowdfunding and services with clear costs are ways of supporting open tools that interest me. I also appreciate the efficiency and research of private companies. In my own small way I am working out which conveniences I want to buy and which I enjoy building, while remembering who makes all this work possible.

A small lab and bigger questions

Thinking about my technological dependencies also takes me beyond the server. I want more European investment in software and infrastructure, more room for new companies and more choice. I would like the expertise and quality of life I appreciate here to translate into technological independence too.

In the lab that question takes a very small form: which tools do I understand, where do I keep data, what happens if a service changes? Open formats and skills that stay with me feel like a good starting point.

I like understanding why a decision is made

When I talk about internal transparency, I mean that people working in a company can find documents, context and the reasons behind decisions. I want to understand why something is being done, contribute and revisit the reasoning months later. Writing these things down helps people share knowledge and work autonomously.

The GitLab handbook interests me for its approach to documentation; Oxide Computer Company’s RFDs, “Requests for Discussion”, for written technical discussions. These are different ways to make work understandable. A public document can help people outside the company too; for me, the starting point is that information circulates among those working there.

The way of working that appeals to me

I care about an engineering-first culture: builders need context and room to make decisions. With PostHog, I look at the small autonomous teams described in its handbook; with 37signals, at working in small teams and keeping the product simple. I want a few useful processes and time to build and maintain tools well.

Mozilla is a reference for an open web and participation; Automattic’s creed for continuous learning and communication. I care about these specific practices without turning different companies into one ideal model. The thread I am looking for is shared knowledge, technical autonomy and little bureaucracy.

These readings accompany what I try to do in the lab. I still use external services where their convenience makes sense to me and look for alternatives where I want more control. My choices can change: I want to explain them and leave a useful account of that change here too.