powered by Jive Software

Looking for feedback: the good, the bad,the ugly

I’m hoping to gain insight on how others are using openfire, and on how we can improve it! I came up with a few questions of interest. Feel free to add or comment on anything even if it’s not listed. I’d love some constructive feedback and comments.

How are you using openfire? Personal or Work?
What challenges have you had?
Has anything not worked as expected and if so, what?
Have you considered moving away from Openfire? If so, why? What made you stay?
What does Openfire do well? Where does it fall short?
If you could change or add ONE thing to Openfire, what would it be?


Let me add some inputs

  1. Used by company at work
  2. Not able to share images in group chat, but i just installed 2.9.2 – this is solved (yay!)
  3. So far, 4.6 on sparks 2.9.2 have been working okay for me
  4. Yes – when using previous versions. We evaluated rocketchat, but it is so buggy in our limited experience’s opinion especially when connected to AD. The interface was nicer tho
  5. Once installed properly, it doesnt really bug us with much issues. A few things can be added as future features if not already there:
  • inline image/video sending on groupchat as opposed to http link
  • built-in video/audio meeting without the need to install plugins
  • features for room management i.e. disable users from leaving certain MUC
  • built-in theme / skinning features
  1. One thing to change ? I think the inline image/video management as we used them all the time by almost all users


  1. Used at work for internal secure messaging we could send passwords over on Windows Server 2016.
  • Switched to Teams for seamless all-in-one messaging and video calls
  1. Currently use at home and have for about five years.
  • Clients are Pidgin (Windows), Xabber (Android)


  • Simple to install and set up
  • Message turn-around time is fast
  • Runs on my micro PC “server”


  • Server loses messages for offline clients, this gets much worse if you have an Android client that is sort of online (app in background, etc.) - number one frustration
  • Have never gotten easy file and image sending to work reliably
  • Once bricked an existing install with a patch and lost all home users
  • Java - the application takes a lot of memory for a little server process

This primarily is a client issue, not a server issue. If you install Openfire with the HttpFileUpload plugin, you’ll see that some clients (like Conversations) will show inline (previews of) the data that’s sent, where appropriate. Ideally, support for that is added to Spark.

I don’t expect us to turn away from plugins, but what we have been considering is:

  • Move functionality that’s now provided by plugins into the core Openfire build
  • Ship Openfire with more default plugins
  • Update documentation, and perhaps provide tooling, that allows administrators to more easily configure Openfire in ways most compatible with modern clients

Both Spark and Openfire used to have theming/skinning functionality, but that proves to be hard to maintain. If your organisation is looking for customized builds of either, I suggest enlisting the help of any of the commercial service providers that are supporting our projects.


If at all possible, stop using Pidgin. It’s XMPP support is pretty poor. Alternatives apart from Spark and Pade might be web-based ones, like Converse and JXCS (both of which can be installed easily through Openfire plugins.

This feels like a pretty major bug, that I’d like to address in a separate thread. Would you mind creating one, and detail the way in which we can reproduce this?

Have you tried the HttpFileUpload plugin? That’s supported by most modern XMPP clients.

That’s very unfortunate. What kind of ‘patch’ was that? Typically, the Openfire upgrade is pretty reliable. However, every update guide starts with “create backup”, just in case…

This might be the result of a bit of a balancing act. Default memory usage (through caches, for example) is geared towards not running on a minimal system. There’s a trade-off in efficiency, and user experience, where we tend to err towards user experience. Computers nowadays typically have plenty of resources available to them - the type of computers that typically run server-sided software nowadays, or are relatively inexpensive to upgrade. That said, people are running Openfire on things like Raspberry Pi’s so things are not to bad, I’d say. There will always be outliers, but I don’t think we can, or even should attempt to, optimize for resource usage in micro-environments if that potentially hurts the experience of the more common use-cases.

1 Like