Loading...
 

History: Why Openfire

Preview of version: 80

Openfire has been selected as one of the Software Components for WikiSuite. Here are the general component criteria.

Why Openfire instead of the many options in this space? To properly explain this one, it's important to first distinguish the various "real time" use cases. All use cases need chat, most need audio and screensharing. However, there are some "key distinctive features" which make some tools great at one use case, but poor for another. Try it out now at http://wikisuite.chat/

If you are interested in helping develop the software, please see: Openfire Meeting and Jitsi Meet development.

Realtime collaboration use cases chart

Type Predominant mode Key distinctive features Typical app
Ongoing Team collaboration on projects 1 to 1, many to many or emergent Presence, and can escalate to audio / video / screensharing as needed Skype
Meetings / conference calls Many to many Meeting notes (meeting agenda, and live collaborative note taking for decisions) Etherpad + phone call, or Skype
Webinars / Scheduled Course 1 to many Presentation and whiteboard BigBlueButton
Community presence and support many to many web interface and desktop/mobile clients IRC
Help desk for team members (Remote Assist) 1 to 1, but can be transferred Share screen and remote control. Easier to install software on their computer. Team member must give permission to take control of computer (ex: for 30 minutes) TeamViewer
Help desk for customers 1 to 1, but can be transferred To route request to someone who is available. Canned responses. Difficult to install software on their computer. Openfire Fastpath. See also WebMeet
Remote Management 1 to no one or 1 to 1 Remote login and management, even unattended VNC / Guacamole / RDP / MeshCentral
Telepresence


We picked Openfire for the following reasons:


We ultimately want WikiSuite to be awesome at covering all the use cases above, and we do so by mostly combining:

Why XMPP is important

https://xmpp.org/about/technology-overview.html
https://xmpp.org/about/myths.html

Image

Why not BigBlueButton

Tiki Wiki CMS Groupware has built-in (but optional) integration with BigBlueButton since Tiki 5 (2010), and the two communities worked closely together for a tight integration and thus, for WikiSuite, this would have been the simple option.

While Openfire Meetings and BigBlueButton broadly share the same feature set (videoconferencing, screensharing, etc), there are fundamental difference. BigBlueButton is a distance education tool.

  • So the focus is one to many.
  • No presence feature (it's for a scheduled class, and not ad hoc collaboration)
  • No XMPP support (ex.: Federation)
  • Still in 2017, the Flash version is the main one, and the HTML5 version is not ready for prime time Now OK, and developed


For WikiSuite, it's critical to also cover all the other use cases above.

The leaders of both projects (Fred Dixon and Marc Laporte) met 2 or 3 times over a few years to try to find a way to make it work. But ultimately, the basic DNA / drive / philosophy / focus which made BigBlueButton successful for distance education lead to some design choices (ex.: no XMPP) which are hard to change afterwards.


Why not Etherpad or Hackpad

  • Too few features
  • No XMPP support


https://github.com/dropbox/hackpad

Why not Jitsi Meet (standalone)

  • Jitsi Meet is part of the solution (WebRTC), but alone is not sufficient to cover the desired use cases, which is why WikiSuite uses Jitsi Meet as part of Openfire. This is similar to how Jitsi Meet is part of Atlassian HipChat

Why not Apache OpenMeetings

Apache OpenMeetings is an interesting option with a diversity of paid support options and quite a few features, however, the focus is more about scheduled meetings or classes than ongoing collaboration. For example, XMPP is not supported.


Why not WebHuddle

WebHuddle is inactive: https://sourceforge.net/projects/webhuddle/ and requires Java applets which are restricted by browers nowadays: WebHuddle "works in most web browsers enabled with Java."

Why not Spreed

This was the situation:


But then NextCloud reactivated the project: https://github.com/nextcloud/spreed/ (well done!)
There is discussion on XMPP: https://github.com/nextcloud/spreed/issues/826 and link to a client: https://github.com/nextcloud/jsxc.nextcloud but where is the XMPP server?


Why not Hubl.in

Hubl.in is part of OpenPaaS, and is a newer option. Social networking + videoconferencing + realtime collaborative editor + others.
This is WebRTC (which is great) but it doesn't handle XMPP.

https://github.com/linagora/hublin

Why not Tox

Tox is interesting

  • But no XMPP
  • Serverless aspect of Tox doesn't have huge value for us because WikiSuite is a server, and we have Syncthing for P2P file sync.

Why not Retroshare

Retroshare is very interesting

  • But no XMPP
  • Serverless aspect of Retroshare doesn't have huge value for us because WikiSuite is a server, and we have Syncthing for P2P file sync.
  • Retroshare is more focused on disseminating files, than on collaborating on files

http://retroshare.net/

Why not Zulip

Not based on XMPP
Lots of chat features but what about videoconference?

Why not Otalk

So—tl;dr: The only pieces we are not open-sourcing are the UI, glue code, and operationalized infrastructure—but that’s it!

Why not Tigase

Tigase is an XMPP server and it could have been the base

Tigase and Openfire are both written in Java.
License: Tigase is AGPL, Openfire is Apache

Openfire has more users and contributors

Why not ejabberd

ejabberd is an XMPP server and it could have been the base.

ejabberd has two editions:

  • Community Server (eCS) (Free/Libre/Open Source)
  • Business Edition (eBE) (not Free/Libre/Open Source)


As of 2018-10, many features you'd expect for a typical project are only available in the Business Edition (eBE) (not Free/Libre/Open Source). This open core model is a disincentive for community contributions. In contrast, these features are Free/Libre/Open Source in Openfire. And if anything is missing in Openfire, we can contribute and everyone in the community will react favourably.

See also:


ejabberd is written in Erlang: not a deal breaker, but less known than Java, used by Openfire.

Why not Prosody

  • Prosody is an XMPP server. This could have served as the foundation.


Prosody is very good for a multi-tenant use case.
Prosody is written in Lua (not a deal breaker, but less known than Java)
Prosody is lacking a web admin panel
There is no WebRTC support or plugin

Why not Mattermost

Why not Matrix.org

Why not Rocket.chat

  • not XMPP

https://rocket.chat/

Why not Let's Chat

  • not XMPP


http://sdelements.github.io/lets-chat/

Why not CandyJS

CandyJS is interesting. And we experimented with it to be the XMPP client and contributed the conversion to Bootstrap for responsive design.

But:


https://candy-chat.github.io/candy/

Why not Signal

Both the server and the clients are Open Source.
It's backed by a Foundation
https://en.wikipedia.org/wiki/Signal_(software)

Signal is a very interesting option, but we preferred XMPP

Why not Telegram

The server part is not Open Source, but the clients are: https://telegram.org/faq#q-why-not-open-source-everything

Telegram is an interesting option, but we preferred XMPP

Why not proprietary software or Software as a Service (SaaS) like Skype, Google Hangout, etc.

Why Free Libre Open Source software

See also


History

Advanced
Information Version
Marc Laporte 86
View
Marc Laporte Move to own page 85
View
Marc Laporte Now offline 84
View
Marc Laporte 83
View
Marc Laporte 82
View
Marc Laporte 81
View
Marc Laporte 80
View
Marc Laporte 79
View
Marc Laporte 78
View
Marc Laporte A semantic alias (301 Redirect) to this page was created when page ClearOS Voip Server was deleted 77
View
Marc Laporte MeshCentral is pretty awesome 76
View
Marc Laporte 75
View
Marc Laporte 74
View
Marc Laporte 73
View
Marc Laporte 72
View
Marc Laporte 71
View
Marc Laporte Telegram and Signal 70
View
Marc Laporte 69
View
Marc Laporte 68
View
Marc Laporte 67
View
Marc Laporte 66
View
Marc Laporte About the challenges of multiple use cases 65
View
Marc Laporte 64
View
Marc Laporte 63
View
Marc Laporte 62
View
Marc Laporte 61
View
Marc Laporte The page is strong enough now, so it doesn't need this. 60
View
Marc Laporte 59
View
Marc Laporte 58
View
Marc Laporte Well done NextCloud! 57
View
Marc Laporte img Plugin modified by editor. 56
View
Marc Laporte 55
View
Marc Laporte 54
View
Marc Laporte 53
View
Marc Laporte 52
View
Marc Laporte 51
View
Marc Laporte 50
View
Marc Laporte 49
View
Marc Laporte 48
View
Marc Laporte 47
View
Marc Laporte 46
View
Marc Laporte 45
View
Marc Laporte 44
View
Marc Laporte More background on discussions between Fred and I 43
View
Marc Laporte 42
View
Marc Laporte 41
View
Marc Laporte 40
View
Marc Laporte 39
View
Marc Laporte 38
View
Marc Laporte 37
View
  • «
  • 1 (current)
  • 2