Servers
ejabberd, Prosody, Openfire: how they differ
All three speak the same protocol. Choosing between them is a question of what you are willing to operate.
Ask three administrators why they run ejabberd, Prosody or Openfire and you will hear three answers built from things the protocol never mentions. That is where an honest comparison has to start. An XMPP server, by the definition the software index uses, provides basic messaging, presence and XML routing, and that triple job is the same for every implementation on the list. What separates the three names is therefore not the wire format. It is a set of properties, compliance in practice, usability, reliability and performance, that no neutral body has formally measured, and this article would rather point at that gap than paper over it.
One job description, written in the RFCs
The job description belongs to the RFCs, not to any of the three projects. XMPP is a way of keeping an XML stream open between two parties and pushing small, well formed pieces of XML down it, and the server is the party that holds the accounts, routes those pieces and distributes presence. The core of the protocol is frozen; everything added since arrives as a numbered extension carrying a published status. The baseline is therefore public, fixed and identical for ejabberd, Prosody and Openfire alike, and a comparison that starts anywhere else compares extras before it has compared the contract.
Can the wire tell you which one is running?
In principle it cannot. A client opens its stream, authenticates, then exchanges the same three stanza types whichever implementation sits at the other end, and addressing behaves the same everywhere: a JID names a person, the server that holds their account and the particular device in use, with no room in the format for a vendor dialect. The software entries on xmpp.org take the same view. They describe each program through categories, core compliance, instant messaging, mobile, web, audio and video calling, and they can be filtered by platform. Conformance, where it is claimed, is a category an entry carries, not a prize one of the three wins.
What nobody has formally tested
The index carries a note that deserves a slower read. The projects listed there were not developed by the XMPP Standards Foundation and have not been formally tested for standards compliance, usability, reliability or performance. Set that note against a comparison of three servers and something useful falls out: the four things you most want to know before choosing are exactly the four things the reference site declines to certify. An article that ranks the three from memory is filling a silence. This one prefers to say that the silence exists, and to show you where the sound evidence lives instead.
Why does every list go stale?
The XMPP software list answers that question itself: any list of servers, clients or libraries will, given the dynamic and evolving nature of the market, be out of date almost as soon as it is published, which is why anyone tied to a project is invited to submit a pull request over mistakes, errors or omissions. A comparison article ages on the same clock and runs faster, because it freezes judgements as well as names. The relative merits of the three servers move with every release; the RFCs beneath them do not move at all. Trust the half of any comparison that cannot change, and treat the other half as dated the moment you read it.
The decisions that come before the choice
Federation has no centre, which puts the interesting decisions in the hands of whoever runs the server, and several of them are identical whichever of the three you install. You still publish the DNS material that lets other servers find yours. You still decide what is actually encrypted on the two hops a message takes, the hop from a client to its server and the hop between servers. These are configuration questions, not software questions, and not one of them disappears when you swap implementations. The brand choice tends to feel smaller on the day you have actually settled them.
Internet or local network: the first real fork
The listings define the task plainly: server software you can use to run your own XMPP service, either over the Internet or on a local area network. That distinction does more work than any brand loyalty. On a local network, the same three jobs, messaging, presence and routing, get done with federation quietly out of scope, because no outside server ever needs to find yours and the DNS question shrinks accordingly. On the public Internet, every decision from the previous section applies in full. Whether you need federation at all is the first question to answer, and it can be answered without knowing anything about the three implementations.
How to run the comparison yourself
Since no neutral verdict exists, make the comparison a procedure. Open the software section, filter it to servers and to the platforms you actually run, then look the three names up in the software comparison the site keeps for exactly that purpose. Read what each entry claims, core compliance first, then the extras you care about, and step outside the index for the rest: modules, requirements and release habits are documented by each project itself, and that documentation, not a paragraph in a magazine, is where the differences between the three actually live. If you find a mistake or a missing name along the way, the list takes a pull request, which is how an index like this stays honest.
xmpp.org is the reference site for the standard: one address that maps what XMPP software exists, from apps and clients to libraries, servers, components, tools and integrated platforms, with entries you can filter by platform and compare feature by feature. The site develops none of the software it lists and formally tests none of it, and it corrects mistakes and omissions through pull requests.