Atlassian Acquires Jitsi: what it means
This morning Atlassian announced it was acquiring BlueJimp for an undisclosed amount. BlueJimp — aka Jitsi — is an 8–10 person, open source development team with offices in France and Bulgaria. Jitsi was founded by Emil Ivov out of the University of Strasbourg, France. Jitsi is not a start-up — they have been working on various projects for more than 10 years. The company’s initial product was VoIP client software but more recently, Jitsi has become extremely popular in the VoIP community because of its Jitsi Video Bridge (JVB). The big thing JVB enables is multi-party video calls for WebRTC.
How does JVB work?
Jitsi’s value is largely due to its unique approach to handling multi-party video.
Multi-point Control Unit (MCU)
Multi-party video calls are generally handled by what is known as a Multi-point Control Unit (MCU). The MCU takes in each users stream, mixes them together into a single stream, and then sends this stream back out. The process of mixing is very processor intensive, which is why these devices have historically relied on specialized processing chips for this tasks. General purpose processors in the cloud today can accomplish this task, but they generally have a hard time scaling, driving up costs. Intel is trying to address with this some of their projects, but it will take some time to make its way through the entire cloud ecosystem. Even then, the mixing process adds delay to the call, hurting the user experience.
Selective Forwarding Unit (SFU)
JVB uses a newer model known as a Selective Forwarding Unit (SFU). Instead of mixing streams, it simply forwards them on to the clients — our smartphones and laptops — to process. This does put more burden on client devices to receive more than one stream. However, the process of encoding a video stream is much more intensive than decoding it and today’s devices generally have enough horsepower to handle this model.
Other techniques, such as simulcast help to minimize the bandwidth and processing burden on our mobiles by sending a single high-bit rate stream for whoever you want to look at, like the active talker, and lower bitrate streams for everyone else. In fact, this is how the Google Hangouts service works today.
Beyond just multi-party, SFU’s are essentially WebRTC media routers that can help direct streams to recorders and video processing algorithms for computer vision and augmented reality applications. SFU’s can be used to help handle multiple camera streams from a single device
By shifting the processing burden to end user devices, the SFU can scale an order of magnitude or more streams beyond traditional MCU’s. You can see some of Jitsi’s own performance test results here. These results have not been independently verified, but Jitsi claims more than 1000 streams per server. A typical MCU might get dozens in a similar scenario.
See this presentation I did last week for Dialogic at the WebRTC Global Summit for an illustration of how the MCU and SFU models work:
Why would Atlassian want Jitsi?
This is all about the Jitsi Video Bridge. Atlassian acquired the HipChat back in 2012 to add messaging and collaboration to its software development portfolio. HipChat had one-to-one video calling capabilities, but it could not handle group video chats. Jitsi will give them this capability along with a seasoned WebRTC development team. Leveraging HipChat, WebRTC, and the SFU model should give Atlassian a big cost advantage over traditional collaboration vendors like Avaya, Cisco, and Microsoft.
In today’s increasingly distributed development environments, the ability to hold a real-time Scrum stand-up meetings via video with many remote participates is huge. Branching out beyond just development focused activities could easily come next.
What does this mean for the WebRTC Community?
Launching in 2013, JVB was the first open source SFU. It is also the most popular and most mature SFU. It was typically the first place WebRTC developers went when they needed to add SFU capabilities.
The Jitsi team has done a great job of making it easy to setup and get going, but doing more than cosmetic changes was not always so simple. That is where Jitsi’s business model was — helping developers customize, modify, and build it its code. Presumably those development services will be coming to an end as the Jitsi team focuses on integrating with HipChat and driving Atlassian’s collaboration business.
While it powers many major open source projects, Atlassian is not an open source company. Does that mean the Jitsi’s team’s open source contributions are coming to an end? Apparently not — Atlassian did made a strong statement that Jitsi will remain open source:
The best way to keep Jitsi innovative is keeping it open and in the hands of those who created it in the first place: the open source community.
This would indicate a big change of culture for Atlassian. Can Jitsi be the catalyst to get Atlassian to start open sourcing more of its offering? That would certainly get many of its customers excited even if they don’t care about real time communications.
Are there alternatives to Jitsi?
A few. WebRTC Platform-as-a-Service provider Tokbox (which was acquired by Telefonica) has their Mantis SFU, but you will need to pay by the minute for that. If you just want software to deploy in our own cloud, other open source projects like Kurento, Licode, and Janus are adding SFU capabilities. &yet is a WebRTC development shop that has been working closely with the JVB that I am sure would be happy to help take the Jitsi’s team place for development help.
So is this a good thing for WebRTC?
Seeing a small, web-respected open source company like Jitsi be acquired by a rocket like Atlassian is certainly good inspiration for other WebRTC companies. This helps to validate that WebRTC is a big deal and that having the right capabilities early in this market can lead to a big payout.
If you are using the JVB today, you probably should be a little paranoid. Time will tell how well Atlassian does taking on both the Jitsi team and a new open source initiative. If Atlassian does leverage Jitsi to figure out its open source strategy it could actually invests more in the open source project than what the former Jitsi team could — this would be a great thing.
Certainly the JVB’s future will now be more associated with the success of Atlassian than the success of WebRTC.
Chad Hart is an independent WebRTC and communications market consultant, Chief Editor at webrtcHacks, a blog for WebRTC developers, and frequent speaker on server-side media processing in WebRTC. Contact him via email — chad AT chadwallacehart.com or follow him @chadwallacehart.