I don’t usually get annoyed by other blog entries in the XMPP blogosphere, but this one got my goat a bit: the claim that ejabberd is the most popular XMPP server (according to ohloh). Not only that, but their previous blog entry crowed about passing the 120,000 download mark. So, I thought it was time to set the record straight:
Openfire is now the most popular XMPP server according to ohloh. Why the sudden change? Easy; I read the ohloh FAQ, which states that popularity is based on Yahoo page ranking. The Openfire project page on ohloh linked to a deep page in the ignite site (something that people would never link to). I simply copied ejabberd and made the page link be the main website. Sure enough, we’re now the top server listing.
Openfire just passed 827,753 downloads.
The igniterealtime.org discussion forums have 53,348 messages, compared to 4025 on the ejabberd site.
Anyway, my apologies for the pissing match, but we have to be willing to step up when directly called out. I do think it’s a great thing that there seems to be such vitality in the XMPP world.
I fixed the URLs of all Jive projects on Ohloh to the specific product pages. It makes no sense to point to a site that lists several projects…it would be similar as using http://sourceforge.net/ as the website of Coccinella because the sourcecode is hosted by them. I’m pretty sure that will also increase that project’s ranking. That Jive Software does not has easy URLs to the direct projects and prefers to only have a link the site that lists all their projects is there choice. Nobody said it is impossible to do something like: http://project.igniterealtime.org/
And this is one that got my goat a bit. You forgot to tell that the igniterealtime forums includes a lot messages from customers from before Jive Messenger was open-sourced, that the igniterealtime forums also includes messages of Jive’s other open-source projects, that ejabberd has more documentation which lowers the needs to ask questions already answered in this documentation, that ejabberd has more decentralised support channels (e.g. mailing list, other websites with support).
PS: at least ejabberd has a more independent community than Openfire, in the sense of control by one instance. E.g. to contribute to ejabberd you don’t have to sign documents like you have to do with Openfire as Jive wants to release your code also as closed source in order to have a competititve advantage over other competitors that want to fork Openfire. Of course that doesn’t means the ejabberd community has no troubles regarding independency, but at least it is still a lot better. Note that I plan to blog about these troubles in the future. Let’s hope things improve then. So, what I want to say with this is that I’m pretty sure ejabberd contains (relatively) more code from independent contributors than Openfire.
I know you’re a huge fan of ejabberd, so can I make a humble suggestion that you apply your energies in a positive way towards that project rather than keeping up your continued attacks in our forums/blog?
Conor – the professional open source model we’ve chosen depends on being able to monetize part of our Open Source efforts. There are other possible models, but they’re certainly not proven and are less than ideal in many ways. Of course everyone wants everything for free, who doesn’t? But I’m proud of our model and record. Check out our philosophy if you’re interested: http://www.igniterealtime.org/about/index.jsp
Personally, I like the Jive model. OF alone has more features and is easier to use than a number of other servers. I generally use it for my home server, but its flexibility has awed me so much so that we’re considering a deployment here at work. Since I work for a regulated company, we’re investigating the compliance requirements and features of OF enteprise.
The professional touch on the software is much appreciated and I believe its value is that much higher as a result.
I think Openfire sets the standard on how an open source project should work. The quality of the code is excellent and it is easy to pitch in and contribute. Great bug reporting system too!
The biggest problem with ejabberd is that its written in Erlang. I’m a professional developer myself, but I confess I have never seen Erlang code - ever. Just that makes ejabberd a non-starter. The number of people that can contribute quality Erlang code is likely 0.5% of the development community.
“The biggest problem with ejabberd is that its written in Erlang.” Irronically, it is also the base of ejabberd’s strategic advantages, the source of its distinguishing key features.
The key thing what I hate about Jive’s open-source model is that it is way too similar to the MySQL model (which I also hate). I prefer the Linux and the PostgreSQL models. The big difference between the first and the last 2 models is that in the first model you are still dependent on 1 company for your software, while in the second and third model you can rely on other companies and/or independent community members that have a stake in the software project.
So, do not understand me wrong, I’m not saying that Jive’s model results in bad quality software. I’m just saying that you can’t switch to another company (or hire independent community members) if you think Jive’s support does not fit anymore for our organization for whatever reason (user lock-in). So, then you have to switch to other software which means (high) switching costs.
btw: what happened with my other 2 comments to this blog post?
“The number of people that can contribute quality Erlang code is likely 0.5% of the development community.”
…but of these 0.5%, maybe 10% contribute to ejabberd, while for the more common languages known by 50% of the development community, a lot more attractive software projects are competing for contributions of these individuals. So, maybe 0.01% of this 50% choose to contribute to a specific Jive project. In the end, there is no difference in numbers. Regarding to Openfire and ejabberd, the difference is probably the part of code contributed by independent community members compared to payed code by the company supporting the project. I’m pretty sure that most of ejabberd’s code was not payed by Process-One, while for Openfire it is just the way around (logic: Openfire’s closed source software origin, restrictions to contribute to Openfire in the form of signing a document that allows Jive to closed-source your contributions).
“The key thing what I hate about Jive???s open-source model is that it is way too similar to the MySQL model (which I also hate). I prefer the Linux and the PostgreSQL models.”
MySQL’s model is meant to provide free software, but at the same time generate revenue from software through commercial licenses. Linux and PostgreSQL are not businesses, and don’t have to generate revenue.
“The big difference between the first and the last 2 models is that in the first model you are still dependent on 1 company for your software, while in the second and third model you can rely on other companies and/or independent community members that have a stake in the software project.”
This is not true. Anybody can provide MySQL support if they want, just as anyone can provide Linux and PostgreSQL support. Look at CentOS vs Red Hat. Red Hat sells a Linux distribution but, because it’s based on free software code, anyone can basically take everything they’ve done (that’s also free software) and build a competing product. CentOS happens to do it for free, but there’s nothing to say that they couldn’t base a commercial product off the same code.
As far as Jive requiring people to sign agreements, that’s standard practice among many businesses. It protects them from legal issues later, and if I’m not mistaken, a number of open source / free software projects do this even when business isn’t involved. It also allows the project to open up their code more in the future, rather than closing it up, and the license can never be revoked on code that’s already GPLed or whatever. So if OpenFire 3.3.0 is GPLed, it can never be un-GPLed. Though, it would be possible to un-GPL 3.3.1, anyone who desired could base a competing or new product off the original, GPLed code-base.
Personally, I prefer OpenFire over any other XMPP server implementation. ejabberd was a pain in the butt, and I got tired of the developers touting their own horn at every opportunity. I expect some of that from everyone, because obviously everyone wants to be happy about their accomplishments. But with the ejabberd community, the excessive self-congratulation got to be rather annoying. This whole post is a direct result of that silliness.
Having installed several XMPP servers, Openfire won my support because of its simple administration and setup. I could really care less about performance benchmark X or feature Z if I can’t install and maintain the software easily. I also like the open nature of the development team, issue tracking, and active community support.
Also, the argument about ejabberd and Jive having the same number of contributing developers isn’t the real issue. Both projects may or may not have a similar number of contributors, but that is irrelevant to me. I care about what I can do to customize the product, as I suspect many developers do as well. When a customer requests some new feature, I don’t have time to go learn a new programming language and technology to deliver it, I need to be able to jump in and add the feature via a plugin immediately. Seeing as there are many more Java developers available, Openfire makes a lot more sense in this case.
“MySQL???s model is meant to provide free software, but at the same time generate revenue from software through commercial licenses. Linux and PostgreSQL are not businesses, and don???t have to generate revenue.”
Well, these projects are indeed no businesses. Instead, there are several companies that contribute to Linux, PostgreSQL (look on their website for commercial support), amongst a lot other projects AND these companies make money from these projects. Recently, I read that most of the contributions to Linux were made by companies. Is this a problem? No, because it are a lot companies including competitors; none of them controls the project; the project is independent.
“This is not true. Anybody can provide MySQL support if they want, just as anyone can provide Linux and PostgreSQL support.”
Though, this is technically true, businesses that want to do that have several major disadvantages over MySQL (the same is true for Jive) that makes competition with MySQL difficult:
They cannot provide a closed source version as MySQL can do (from their website: “With that said, we recommend the commercial license to all commercial and government organizations. This frees you from the broad and strict requirements of the GPL license.”)
I agree about OpenFire being easy to set up. I don’t run it in a business, but I do provide a public server to the XMPP community. I wanted something that was reliable, powerful and easy to administer. I was using it back when it was still Jive Messenger, and before they had s2s working. It’s been a great piece of software, and I can’t be anything but enthusiastic about what the future holds.
I’m pretty sure there are several companies that have contributed to OpenFire as well, and many, many volunteers who have done so. If you don’t agree with the terms of contributing code, either don’t contribute it, or fork and make your own version where you can do what you like with your own code.
There’s also absolutely nothing stopping anyone from creating plugins that provide the features comparable to OpenFire’s Enterprise edition, but in such a way that they’re free for everyone to use. I doubt they’d get included in the official source, but that isn’t really a problem.
My opinion is that all of this worrying about licensing issues is just that. Worrying. I’d say it’s also completely beside the point for the majority of users who are simply going to use the software, rather than develop for it.
“If you don???t agree with the terms of contributing code, either don???t contribute it, or fork and make your own version where you can do what you like with your own code.”
Regarding the forking , that was actually in the second part of my message that was lost. I’ll try to restore the copy in my mind later today. In short: forking Jive’s projects a extremely hard compared to independent projects. Plus, forking in general is already hard.
“There???s also absolutely nothing stopping anyone from creating plugins that provide the features comparable to OpenFire???s Enterprise edition, but in such a way that they???re free for everyone to use.”
But that is limited to plugins, architucture changes e.g. are impossible with that. Jive keeps control over that.
“My opinion is that all of this worrying about licensing issues is just that. Worrying. I???d say it???s also completely beside the point for the majority of users who are simply going to use the software, rather than develop for it.”
Well, some months ago I read a message in the forums by the Tigase developer that his code got into Openfire without his permission. This would have been no problem when Jive did not dual-licensed Openfire because then they didn’t needed his permission.
???This is not true. Anybody can provide MySQL support if they want, just as anyone can provide Linux and PostgreSQL support.???
Though, this is technically true, businesses that want to do that have several major disadvantages over MySQL (the same is true for Jive) that makes competition with MySQL difficult:
They cannot provide a closed source version as MySQL can do (from their website: ???With that said, we recommend the commercial license to all commercial and government organizations. This frees you from the broad and strict requirements of the GPL license.???)
They cannot influence the roadmap without forking (which is made extremely costly, see further), so they have no control and cannot adapt to all their customers needs
There is a big threat for them when another company, which isn’t that friendly to them, acquires MySQL.
Another thing why I hate Jive Software, is because they practically destroyed one of the niciest Jabber projects, your Pytransports project. I would have had no problems if Jive Software sponsored development of Pytransports, paid you to integrate it better into Openfire, or employed you to work on some completely different part of Openfire. Instead, they chose to employ you to work on a competing component that only works with Openfire (the Py*transports are compatible with ALL Jabber servers). The perversive results of this action were:
You lost your interest in Py*transports (which is understandable, doing things twice can gets boring)
The Py*transports was not yet a mature project, so it lost their driving source.
The Py*transports project practically died
Jabber transports current status in the whole Jabber community is worse than it could have been when they did not employed you to work on this specific Openfire part
Fragmentation: It’s just a matter of time until Erlang-based transports will arrive. In fact I know some individuals that started with such transports. Fragmentation in transport projects is IMO a problem because it is a waste of developer resources in the community; these transport projects are temporary (until these networks become XMPP compatible, which already happened with Sametime, if I am right!)
These consequences were predictable, so I guess this was done by intention. That’s why I get so angry when Jive Software’s PR shouts about its care for the Jabber community :-s It also explains my passionate posts over here, because I DO CARE about the Jabber community.
“Regarding the forking , that was actually in the second part of my message that was lost. I???ll try to restore the copy in my mind later today. In short: forking Jive???s projects a extremely hard compared to independent projects. Plus, forking in general is already hard.”
Forking is always difficult, but if you want something in the project that the owner won’t do, it’s pretty much the only option. This is true for all free software projects, not just ones that do dual-licensing.
“But that is limited to plugins, architucture changes e.g. are impossible with that. Jive keeps control over that.”
Again, this is true for all free software. If you want something incorporated into Linux that the kernel developers don’t want, or you want to add a new feature to PostgreSQL that the developers don’t want to add, you have no choice but to either offer it as a third-party patch, or fork the code base. The same goes for ejabberd. But you can make architecture changes to OpenFire all you like, though Jive may or may not be interested in incorporating them into the final release.
“Well, some months ago I read a message in the forums by the Tigase developer that his code got into Openfire without his permission. This would have been no problem when Jive did not dual-licensed Openfire because then they didn???t needed his permission.”
I don’t know anything about this issue, but I’d imagine it was a mistake, though one that can happen with any project if the license isn’t the same or compatible with the license of the submitted code. This isn’t a problem with OpenFire being dual-licensed, but rather a problem with accepting code. It’s also not much different than somebody’s non-GPLed code being incorporated into a GPL project without their permission (and it happens).
