What I've learn by self-hosting Openfire

When reproducing, using, or extracting this text, always reference the source and the author : Ignacio Rondini

Imagine using a messaging application, where messages can be encrypted end to end, that you can self-host and it is decentralised. Welcome to XMPP, a series of protocols describing standards about messaging. I got the opportunity to discuss with some of the ecosystem during the last FOSDEM 2026 and I thought it would be an interesting idea to try to self-host one of the opensource servers.

So I did. I took the time to install Openfire on a server and play around with it. It was a great reminder about many things that I am not usually confronted with on my day-to-day work:

  1. Operating a system is a completely different story than building it. Although I know that we should be aiming to a devops mindset, when you have to administer the server, is completely different from what you have to do when you develop it : Log management and alert handling, database administration, DNS, certificates, and trying to figure it out if something is a bug, an error from your side, an error from another component, from the user, or a combination of everything.

  2. Following the first point, it is not because you have a built software (here, an opensource solution, but we could think also about a “quicker vibe coded” solution) that you have a usable, production ready software that will resist the long term. Openfire is robust and tested by many people, but that doesn’t mean that you can just launch it and ready to go. Regarding vibe-coded solutions, I think it is too early to say if they will be able to resist a real production environment in the long term, but there will be the same difficulties as with other solutions.

  3. Opensource community is real. Documentation, support, sharing tips and inspecting the code, it is real. You can get help from the community. Of course, you should always try to give back, specially if you’re an entreprise.

  4. You don’t know how people will use your software. Yes, this is even clear with XMPP. Because it is a protocol, you can have many software clients that may use your server. Each of them having a different subset of features of the protocol implemented. So it is not easy to pinpoint an issue. Is it the server? is it a specific client? is it the user’s expecting something that’s not possible? The landscape complexity increases, which make appealing to regain control by centralising everything and simplify. But I think that we should promote this diversity, as it makes the system more robust and users can try to find software that suits them better. Of course, open standards do help in this. And XMPP allows a great degree of interoperability.

  5. Some issues are hard to pinpoint, specially if you’re not an expert on the solution. Yes, there’s a huge difference between knowing a software, and getting a deep grasp.

  6. Follow the documentation. It is tempting to try to go faster and not looking at it too much, or to ask an LLM, but nothing beats a well written documentation, that’s actually been tested by real people having your same issues.

  7. Free software is a privilege we can all enjoy. Is it incredible that I could just install a software, learn about it and use it. When you really think about it, it is not something you can do with many other things. And we should not take it for granted. We need to support and make sustainable communities.

In other words, there is a huge difference between writing code, and making a product ready for production and operating it. And not because something is libre, that has zero cost. It may take time, money and other resources. And we should defend our open source communities.

References