Loading...
 

History: Why Openfire

Preview of version: 24

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. Some solutions have variations. For example, Adobe has Adobe Connect Meetings, Adobe Connect Learning, Adobe Connect Webinars.

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 1 to 1, but can be transferred Share screen and remote control Easier to install software on their computer. 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
Remote Management 1 to no one or 1 to 1 Remote login and management, even unattended VNC / Guacamole



We picked Openfire for the following reasons:

  • XMPP support, and thus presence
  • WebRTC support (via inclusion of Jitsi Meet)
  • Great admin panel
  • Vast feature set
  • The community


We ultimately want WikiSuite to be awesome at covering all the use cases above, and we'll do so by mostly combining Openfire, with Jitsi Meet, Converse.js and inVerse.

Why not BigBlueButton

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
  • Still in 2017, the Flash version is the main one, and the HTML5 version is not ready for prime time

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

Why not Spreed


No XMPP

Why not Hubl.in

Hubl.in as part of http://open-paas.org/ is a newer option. Social networking + videoconferencing + realtime collaborative editor + others.
XMPP support?

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

Why not ejabberd?

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

ejabberd is written in Erlang (not a deal breaker, but less know than Java)

https://github.com/processone/ejabberd

Why not Prosody?

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


Prosody is written in Lua (not a deal breaker, but less know than Java)
Prosody is lacking a web admin panel
There is no WebRTC support or plugin

Why not Mattermost?

  • Not XMPP

Why not Matrix.org?

  • Interesting but not XMPP

Why not Rocket.chat?

  • not XMPP



https://rocket.chat/

Why not Let's Chat?

  • not XMPP


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

History

Advanced
Information Version
Marc Laporte 36
View
Marc Laporte 35
View
Marc Laporte 34
View
Marc Laporte 33
View
Marc Laporte 32
View
Marc Laporte 31
View
Marc Laporte 30
View
Marc Laporte 29
View
Marc Laporte 28
View
Marc Laporte 27
View
Marc Laporte 26
View
Marc Laporte 25
View
Marc Laporte 24
View
Marc Laporte 23
View
Marc Laporte 22
View
Marc Laporte 21
View
Marc Laporte 20
View
Marc Laporte 19
View
Marc Laporte 18
View
Marc Laporte 17
View
Marc Laporte 16
View
Marc Laporte 15
View
Marc Laporte 14
View
Marc Laporte 13
View
Marc Laporte 12
View
Marc Laporte 11
View
Marc Laporte 10
View
Marc Laporte 9
View
Marc Laporte 8
View
Marc Laporte 7
View
Marc Laporte 6
View
Marc Laporte 5
View
Marc Laporte 4
View
Marc Laporte 3
View
Marc Laporte 2
View
Marc Laporte 1
View
  • 1
  • 2 (current)
  • »