After years in this industry, I still sometimes hesitate when adding a log statement. Should this be trace or debug? It feels like something that should be obvious by now, but in practice the line is blurrier than you’d think. I’ve seen experienced developers (myself included) mix them up or just default to one level out of habit.
So I decided to write down how I think about it – partly to clarify my own thinking, partly in case it helps someone else.
Released software or other open projects to the public? Then you know the pain: “It doesn’t work!” with zero context, scattered information across multiple messages, or bug reports describing a different problem.
I’ve filed my share of bad reports too, so I know what it’s like when you’re in a hurry. But if you consistently get bad bug reports (and I don’t mean AI slop — that’s a different problem), it’s often on you, not your users.
Another year, another FOSDEM. I think my first one was 2014, but I’m not sure. Just like myself, the hotel I usually stay at could use some renovation, and Brussels nowadays feels a tiny bit like another home. With that, let’s head into a summary of FOSDEM 2026.
The theme this year was policy, security and regulation. A lot of developers nowadays are very interested in these aspects, so much so that you had to line up early to have a chance of attending the crowded rooms. This is good — software engineering is about far more than just the code. The crowd was the usual mix of youngsters, graybeards, people from the EU departments, academia, companies, public sector, hobbyists. Despite the high interest in policy, there were still talks that dug into more obscure topics, so I don’t feel FOSDEM is losing its grassroots spirit, even though the talks are evolving.
Were there 10,000 visitors? I can only guess.
NOTE: This post is written from a private developer perspective, not that of my employer.
I’ve started migrating my active projects from GitHub to Codeberg. Codeberg is a European open-source alternative that looks a lot like GitHub—a code collaboration platform. I’d been considering it for a while, and now that it’s almost done, I wanted to share my thoughts.
Why? One thing I’ve increasingly felt about GitHub is that they ignore basic, important developer features while prioritizing features nobody asked for. What I miss: fast-forward merges for linear history, rebase-only repos, SHA256 support, and AsciiDoc rendering that’s still missing or broken. The whole markup rendering is a mess with uneven support for different formats. Full token security has been requested for a long time, yet we still have to use old, insecure Classic tokens for publishing packages (fine-grained tokens aren’t done). Many solutions end up 80% done and then seem to stall. Maybe it’s telling that the open source parts, like the GitHub markup repo, seem abandoned. Issues sit there for years, and the commit history shows no steady stewardship. Overall it feels like GitHub has, in some areas, stopped prioritizing developer community needs and technical excellence. Much of GitHub is historically good too, of course, but I expect more from such a widely used service — more technical drive, more listening to developers.
I recently started moving my maintained projects from GitHub to Codeberg.
Along the way, I collected a few notes on the problems I encountered feature-wise.
This is in no way meant to complain about Forgejo (or Codeberg), but maybe it will help get those remaining issues solved, and if so it serves a purpose. Please correct me if I’ve missed something. For most of these, there are existing issues though.
GitHub fine-grained tokens: