Why did Atlassian Acquire Jitsi? (Hint: WebRTC Multiparty Video)

April 22, 2015

Atlassian just became a WebRTC superpower. Sort of.

HipChat acquires Jitsi

The news is out. Yesterday, Atlassian announced through their HipChat blog that they acquired Blue Jimp:

We’ve acquired Blue Jimp, the mastermind team behind the Jitsi Community.

The title itself speaks volumes of Atlassian’s needs and intent: “HipChat acquires Blue Jimp & Jitsi.org”

TechCrunch did the usual coverage of this, while the rest of the tech media was silent.

To understand what Blue Jimp did along with an analysis of how this affects the WebRTC ecosystem, I’d recommend Chad Hart’s post.

I do like to reflect on a few issues with this acquisition though:

  • WebRTC isn’t that interesting of a subject
    • Media coverage of this acquisition was low
    • Not many out of the tight WebRTC community know or understand the topic and the nuances of the technology and the offerings on the market today, so the importance of this acquisition was not picked up by most news sites
    • Either Atlassian didn’t do a good job of briefing the media and analysts, or there just isn’t enough interest
    • You can see this also in the company valuations of those being acquired
  • Blue Jimp isn’t the important party here. Jitsi Video bridge is
    • You can read my interview of Jitsi from 2014
    • Blue Jimp is a small open source shop specializing in VoIP
    • They developed the Jitsi client, which was SIP based and understood in time that WebRTC will kill that business. This led them to develop the Jitsi Videobridge
    • The Videobridge component is what vendors are looking for
  • AddLive, acquired a year ago by SnapChat, was used by Atlassian (at least from what was indicated on AddLive’s website)
    • Since the acquisition, Atlassian had to switch its vendor
    • It probably decided to go it alone instead of being dependent again on a third party
    • SnapChat wasn’t the only bidder, and so the need for a multyparty video solution remained
  • Jitsi Videobridge became the default solution for many tinkerers who wanted to have a multiparty solution
  • The problem with getting the Jitsi Videobridge to larger corporations was its open source license
    • Jitsi uses LGPL. A non-permissive license that is somewhat challenging for commercial use. While it is suitable for SaaS, many lawyers prefer not to deal with it
    • This reduces the Jitsi Videobridge’s chance to get adopted by enterprise developers who can pour more resources into it
    • This may limit Jitsi from building the ecosystem Atlassian wants (i.e – outsourcing some of the development effort to an external developers community)
    • Using BSD, MIT or Apache licenses would have been a better alternative. Will Atlassian choose that route? I am not sure
    • Did Atlassian leave the open source offering due to legal issues or real intent in becoming an open source powerhouse?
  • It is the end of the line for the outsourcing/consulting/customization work that Blue Jimp is doing on Jitsi
    • Will another nimble open source shop take the mantle and offer such services on top of Jitsi? Maybe &yet, who have worked recently on incorporating the Jitsi Videobridge into its Talky assets?
    • Without support and the ability to buy an SLA, what are existing users of the Jitsi Videobridge expected to do?
  • Acquiring Jitsi Videobridge still leaves a lot of work for the HipChat developers – things they theoretically got by using AddLive WebRTC PaaS:
    • Plugins for Safari and IE, closing WebRTC gaps in web browsers
    • SDKs for iOS and Android, making real time communication available in mobile
    • Scaling, monitoring, managing and maintaining the service itself
  • HipChat acquired Jitsi. Not Atlassian directly
    • Atlassian, HipChat, Blue Jimp, Jitsi
    • Atlassian acquires Blue Jump or HipChat acquires Jitsi?
    • The main focus of Atlassian is getting real time communications into HipChat itself
    • Atlassian probably see less value in incorporating video chats into its others assets – Jira and Confluence
    • It will probably do that indirectly by the integration of HipChat to Jira and Confluence
    • This was an acquihire of developers and technology. Blue Jimp’s customers and business models are of no importance to either Atlassian or HipChat
  • While no price was mentioned, Jitsi should have been acquired at $30 million USD or less
    • SnapChat acquired AddLive for a total of $30 million USD
    • Jitsi should be worth less – it has only the SFU component of AddLive’s technology – lacking SDKs, plugins and a running service
    • That said, there aren’t many alternatives for the acquirers of such a technology, so Jitsi probably didn’t sell cheap
    • What will other potential suitors of Jitsi do now? There are no obvious alternatives to acquire in the market today
  • Enterprise messaging are serious about gobbling up unified communications
    • I made this clear in my recent presentation at Enterprise Connect
    • Enterprise Video Conferencing vendors are slow to adopt WebRTC technology, and when they do, they only fit it into their existing offering and business model – doing little to disrupt or innovate
    • Enterprise Messaging care less about how video conferencing should work and more about how real time communication fits into the user experiences that they offer

Why was this so important for HipChat? Here’s a session Jonathan Nolen, HipChat’s Product Manager, gave at our Kranky Geek event on June 2014:

This is the 16th WebRTC acquisition, and the 3rd one this year. Interesting times.

Can’t decide which open source media server to use? Towards that goal, I created a Media Server Framework Selection Sheet. Use it when the need comes to select an open source WebRTC media server framework for your project.

You may also like

Two years of WebRTC Insights

Two years of WebRTC Insights

Your email address will not be published. Required fields are marked

  1. Why do you say LGPL is a non-permissive license? AFAIK, LGPL is a very permissive license, comparable to MIT, BSD and Apache ones.

    Very nice post, BTW!

    1. Alex,

      LGPL is not compatible with MIT, BSD and Apache. If you compile LGPL into your own code, modify its code, etc. – you must contribute everything back to the community – including all the parts you have unrelated to it. This may be a non-issue for SaaS providers, but those selling products need to get over the legal hurdle of selling something that has LGPL inside as it might require them to expose other parts of their solution as LGPL as well.

      I’ll do an open source licensing post next week to offer a longer answer.

      1. > you must contribute everything back to the community –
        > including all the parts you have unrelated to it.

        That’s actually GPL. LGPL differs from GPL on exactly that point: you only need to give back the modifications. Not the newly added modules.

        Also, to remove the doubt on whether Atlassian will be throwing all these efforts by obligation or because it believes in the future of the Jitsi community, you may want to check these two links:

        https://jitsi.org/faq/patch (last paragraph of the question)

        P.S. And yeah, nice post!

        1. Emil, Thanks – and congrats on the acquisition 🙂

          From my experience working in traded companies and dealing with due diligence processes through acquisition processes, I can say that LGPL is always regarded as a troublesome license. Not as much as GPL, but a lot more than BSD or MIT.

        2. If you want to be exact (which you have to with licensing) there is no such thing as ‘modules’ in these licenses.

          The LGPL (as does the GPL) talks about ‘derivative works’. Which means as it’s most basic form: a derivative work is when you take the code and then modify it.

          So if you have a LGPL C-library and you link to it then you are fine. You are just using the library. You can obviously change the library, but when you distribute the changed library you need to include the source of said library (you can charge for your product of course, but you have to include the code of the LGPL parts).

          In Java it’s a bit more complicated because how people are used to working with it. In the case of Java it means: you can only load and use a library. You can not use inheritance because that too is clearly a ‘derivative work’. So if you want to create a new interface for a LGPL library, you’ll need to include the source (or in this day and age you can also make it available for download) of that new interface when you distribute it.

          As Tsahi says, businesses might not like the LGPL as much as the BSD-license because of this.

          But the goal of the Free Software foundation is to give the receiver of the program more rights. Not the developer. Not a completely stupid idea or crazy idea, just a different philosophy.

          Even most businesses rely on more software developed by others than just by themselves. Every receiver of software prefers to have the source of the program they are using in case the interests of the original developers don’t align with their own any more.

          1. Your interpretation seems to contradict some of the mainstream ones: https://www.gnu.org/licenses/lgpl-java.html

            While inheritance does imply a derivative work, it alone does not trigger LGPL’s reciprocity clauses.

            That said, while I agree a debate on licensing is always fun to have, I suggest you read the second part of my comment above.

            I was just hoping I’d clear out the doubts on one of the questions Tsahi raised and that second part is potentially even more relevant.

          2. Sorry, you are right. I made a mistake in that part about inheritance they do consider it similar to linking in a library in C.

            Anyway, what I’ve seen from Jitsi it seems great product/project. I would think that is the best reason for Atlassian to be interested in it and the rest is just details. 🙂 I wish both companies and the open source community a lot of success.

      2. I have felt little need to modify the JVB source code. It just works and since its usual mode of operation is running in a standalone process the license is not a big concern.

  2. Nice post, as usual, with a single flawed sentence:
    “…There are no obvious alternatives to acquire in the market today”. Just keep you eyes wide open, Tsahi. Lots of interesting efforts are available out there…

    1. Simon,

      Thanks. At this point in time, there are no alternatives that are as complete. There are other frameworks that can be used, but they require more work. Unless I am missing some specific alternative you want to mention.

  3. We work with hipchat everyday and we’ve seen the Jitsi folks at ClueCon the last few years. I hope they come back this August and demonstrate how the 2 apps will complement each other.

    We just completed some fairly deep coding on WebRTC video ourselves and began hosting the video and broadcasting our weekly call right to youtube.


{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}