Skip navigation
All Places > Ignite Realtime Blog > 2007 > February
Matt Tucker

A new name: Openfire

Posted by Matt Tucker Champion Feb 28, 2007

I'm pleased to announce that we've chosen a new name for the Wildfire server: Openfire. There's several things I really like about the new name:

  • We preserve the fire theme, which makes for an easier transitition. In fact, we're working on some snazzy updated logo ideas right now.

  • The new name better communicates two of the strongest aspects of the project: open protocol and Open Source.

  • The suggestion originally came from a community member.

  • Things look good on the trademark front.

For those looking for more context about the name change, see my original blog entry and Greg's update. Making the full transition to the new name is going to be a long and painful process. First we'll tag everything as "Openfire, formerly Wildfire" and then will gradually transition to just using the Openfire name. We truly appreciate everyone's help, especially with the huge list of name ideas.  I'm eager to hear what you all think of the name name!


ETel 2007

Posted by greg Feb 28, 2007

Dave and I are at ETel 2007, the Emerging Telephony Conference put on by O'Reilly, talking about the new voice features in Openfire and Spark. It has been great to meet many of the people who are working to change the voice and telephony landscape. There has been lots of buzz about Adhearsion, a Ruby library for use with Asterisk, and some very interesting demos at Launch Pad last night.



Like Matt discovered at the Internet Telephony Conference, the focus on telephony means that the discussions going on are very different than what we generally see in the IM community. I ran into this head on during my talk on XMPP and Jingle. The juxtaposition of Jingle and SIP came up front and center which lead to a great (if painful) discussion of both protocols. It struck me that it is easy to become myopic and that an open dialog going between protocol communities is very important. Reading Peter's report on the great meetings that happened in Brussels further drove home the point that we have a great community with XMPP, but that as we move into other areas, like voice with Jingle, we need to make sure we clearly articulate the problems that we're trying to solve, and the problems we are not trying to solve.


ETel will continue through Thursday afternoon and I'm looking forward to gaining a deeper appreciation for the problems faced in the telephony world. If you happen to be at the conference make sure to stop by and say hi.


Smack uses an XML Pull Parser (XPP) to parse XMPP stanzas and build custom Packet objects. Wildfire represents XMPP stanzas as DOM objects wrapped by Packet objects. Each approach has its own pros and cons. Moreover, in Wildfire we can use different parsers to generate DOM objects.


For Wildfire 3.2 we needed to change the way we were parsing XML to work with the new, more scalable, networking layer built using MINA. We wanted to keep building DOM objects wrapped by Packet objects so our parsers were still useful. However, we needed a way to parse stanzas received in an asynchronous way. We ended up reusing a contribution made by a community member. We know that it is a custom solution that we might need to replace at some point since the parsing is not 100% efficient and some cases may potentially break the parser as was seen in Wildfire 3.2.1.


Anyway, while doing some heavy load testing on Wildfire and measuring performance we noticed that the parser we were using to generate DOM objects was becoming a serious bottleneck. At that point we were using a SAX parser (SAXReader) so we decided to try with other parsers and compare results. The other parser that we had in Wildfire was XMPPPacketReader that uses an XML Pull Parser (XPP).  To my surprise the performance improvement was substantial with the new parser: around 30% faster with the XPP parser compared to the SAX parser.


Architecturally it is obvious that an XPP parser will be much faster than a SAX parser, but since both parsers were being used to create DOM objects I initially thought  it wouldn't make much of a difference which one was used since building DOM objects was the expensive operation. Well, I was simply flat wrong and I learned it the hard way. I'm happy, though, that we found this bottleneck during our performance tests prior to release. It is yet another proof of how important it is to include QA as part of your development cycle.


More on the Renaming of Wildfire

Posted by greg Feb 27, 2007

Thanks to everyone for the feedback on our need to move to a new name for Wildfire. We are still working on a new name to take the place of Wildfire. Also, based on the blog posts we received, we realized that we should provide more clarification on how the trademark issue arose, and our need to move to a new name. Here's the story -


It started in December 2005, when we adopted the Wildfire name, believing it to be available for use with our IM server. In 2006, a company by the name of HBN, Inc. became aware of our usage, and HBN noted that there was possible overlap with their usage of the Wildfire name.  They pointed out that they were first to use the Wildfire name and requested that we rename our product to avoid any potential confusion in the future.  We agreed on it after some discussions around the issue.  When we first announced this situation, we did not mention HBN but that is part of the story and our reason for changing names.


We'll be moving forward with the new name shortly....


Matt Tucker

XMPP + SIP: Fate?

Posted by Matt Tucker Champion Feb 23, 2007

I'm in Brussels for the XMPP interop event and FOSDEM. Tonight I was at a FOSDEM gathering (beer drinking) with fellow XMPP fanatics Peter, Ian and Alex. Totally randomly, the other half of our table was filled with the developers behind SIP Communicator. We're big fans of what they're doing, given that we're working on SIP VoIP support in Spark. It turns out that they're fans of Wildfire and Spark as well. Is this some cosmic sign that SIP and Jingle have a bright future together? I'm not sure yet, but I'm looking forward to talking to the SIP Communicator team further over the next few days.



How does building software for an open source community compare to the commercial world? It has been three years since I started working on an open source project. Before this exciting work I spent ten years building commercial software and I can tell you that the differences are really big both on the final product and the way the product is being built.


Here at Jive we are very focused on solving business problems rather than building cool technical solutions just because they help increase our ego. A consequence of this philosophy is that the community feedback is key to building a successful solution. This is one of the reasons I would like to thank you all for helping us build Wildfire into the product that it is now: a successful product that is growing and becoming more popular with each new revision.


Now back to the initial question. Is it really that different to build open source software compared to commercial software? As I said the answer is yes and let me give you a concrete example:


There was a time when Wildfire didn't have support for SASL and I have to say that I had no idea about SASL. Fortunately, there was a community member that provided the first implementation and that was a great opportunity to review his work to ensure quality standards and at the same time learn about the subject. Moreover, a few month later we heard that other community members were adding Single-Sign-On and also GSSAPI as SASLextensions. I said: Wow, this is great. The community keeps providing some cool new features that are much needed and I'm not an expert on this area.


It was clear to me that having a big community was much more powerful than just having several developers and a few product users. Another way to understand the difference is to split the question in two areas: 1) product quality, and, 2) product development and support.


Product Quality


Wildfire has an incredibly large community behind it and we can safely assert that, due to statistics reasons, the more people use a product the more chances a product has for maturing and becoming a solid solution. The number of downloads we are registering is immense and the number of problems we are receiving is proportionally inverse. Of course, this was not the way things used to be. I think that the key to becoming a mature product, in our case, was being strict in running automated or manual test cases before delivery code to the community. In addition, the number of setups that are out there helps ensure that someone has to have already used the software the same way someone else is doing it. In summary, the bigger the community the more chances a product has for becoming a solid product. Let's leave the analysis of the reasons why our community grew out the way it has grown for another post.


Product Development


Supporting an open source community is radically different from supporting commercial companies. The first thing that an open source product has to build, besides the product itself, is a community. For that it is key to have a good site that allows community members to meet up, collaborate, share experiences, problems, etc.. The second challenge is to organize your time so that you can keep thinking and implementing new product features or bug reports and answer questions posted in the forums. While building commercial solutions there is naturally a bigger distance between developers and end users and usually customer support handles customer requests. In open source products, the developer is much closer to the end users so it is always a challenge to focus on work and the community at the same time. I can tell you that this is a very hard challenge but it pays off at the end.


Wildfire 3.2.2 is out now and  I guess that this long post is just a way to thank you all for building Wildfire the product that we are all proud of.


Matt Tucker

An XMPP Valentine

Posted by Matt Tucker Champion Feb 18, 2007

I love XMPP. So, it's only fitting that I got some special license plates for Valentine's Day:

The new look for my car definitely confirms my nerdiness to the world, but I'll wear that badge proudly. I know that Peter has "Jabber" plates on his car. Anyone else out there? Anyway, give me a friendly honk if you see me driving around Portland!


My Spark Update

Posted by ddman Feb 15, 2007

After coding night and day for a while,  I sometimes forget that people need some help getting setup with some of our new features.  It's always a balancing act between development, forums and writing up documentation for all this good stuff we've been coding up. Trust me, I have Matt and Greg always coming to me asking when I'm going to do my next blog post, and the answer is always, "It's coming soon." Code, code, code, code, code, code, code.  Anyhow, since I've just finished up the latest round of Spark 2.5.0 Beta releases , I thought it would be good idea to write up a Spark Phone How-To Guide.


Aside from that, some new things in the latest beta.....

  1. MAC Fixes:  This has always been an issue with our Spark releases, largely for two reasons. The first one being that I do all my      development on Windows (I use the command prompt constantly though. It's a kind of throw back to my old DOS days).  The second one is that to really get that OSX experience, I needed an OSX guru to      hammer on Spark for hours on end. Fortunately, one of those two problems has been taking care of in the form of David Smith. The guy is a highly skilled developer already, and really is a pleasure to have here at Jive. And.... he really knows his OSX stuff.

  2. Vcard Caching: For a really sweet client, we feel it's important to      use the right information about each of your contacts, and the vCard is perfect for it. However, besides doing caching in memory during runtime, we would always be burdened with doing network calls on each startup anytime we wanted to know anything about the user.       Fortunately, we came upon a great way to do local caching of the vCard, and hopefully you will all notice a 'slight' performance improvement.

  3. Drag and Drop Support For Conference Invitations: So, I don't know how many      of you have had contact with my boss Matt, but one of the things you will notice about him is that he really doesn't stray from what he wants.  So because of his most amazing perseverance, I have finally found a little bit of time to add drag and drop of contact items into Conference rooms to invite them in. Give it a shot, it's a nice, smooth experience.


Well, Matt just IM'ed me to fix something, enjoy!

Word on the Street

Posted by greg Feb 14, 2007

I speak with Wildfire and Spark users on a regular basis to find out how they are using the software. I really enjoy this dialogue and believe it is one of the most important activities for improving both Wildfire and Spark. Not too surprisingly, several patterns have emerged and they are pretty interesting. Here are some of the quotes I've heard:

"It just works."

I hear this sentiment a lot. People find Wildfire and Spark extremely easy to set up with quoted setup times ranging from 5 minutes to an hour.

"How would we compare Microsoft's Live Communications Server to Jive's Wildfire platform? Like the difference between night and day; the difference between a company who cares only for profit, and a company who listens to the needs of customers."

"It would only take us half a year to realize Live Communications Server would be a mistake."

This quote came after a switch to Wildfire and Spark which was precipitated by a rough experience with LCS.

"We actually own LCS but have never deployed it. We knew it wasn't going to be the answer."

"Not only was the move into Jive's system easy, it gave us the management tools, met basic audit ability requirements and allowed us to connect clients across the World directly to our staff over Public Instant Messaging applications."

"It's handy having the presence status information."


People often find that presence and availability information in the roster is an unexpected benefit.

"End users are used to public IM systems and they feel like we are taking something away. Having the gateways helped a lot during the deployment."

People like to keep their public IM contacts active and the use of gateways provides that flexibility.

"The end-user community views Spark as an essential tool to work now instead of just a luxury item."

Wildfire and Spark quickly become mission-critical in many organizations.

"Definitely use the LDAP lookups for user & group management if available."

Using LDAP or Active Directory is a best practice cited frequently by administrators.

"One other key aspect of deploying internally is we needed the LDAP integration for the users to use their existing active directory credentials.  This proved successful and greatly help the roll out."

I am incredibly excited that so many organizations are seeing these and other benefits. I'd love to hear about your own experiences with Spark and Wildfire!

I'm excited to announce that my first article on Wildfire plugin development has been published. What originally started off as a blog post grew into something much larger (and longer), so at Matt's urging the content was reworked and a space for it on the Ignite Realtime site was carved out.


The article walks the reader throught the development of a "Message of the Day" plugin that will send users a greeting each time they sign-in to Wildfire. Over the course of the article a number of plugin specific API's are examined along with other, core Wildfire API's. The completed plugin is fully functional but leaves room for a number of additional features.


As always, any and all feedback is welcome.


See you on the forums,



Matt Tucker

Announcing Clearspace

Posted by Matt Tucker Champion Feb 12, 2007

Last week, Jive Software made what's probably our biggest product launch ever. Clearspace is a team collaboration tool that includes discussions, blogging, and wiki documents along with social features like tagging. Unlike Wildfire and Spark, Clearspace is commercial (developer source) software. That follows our pragmatic hybrid Open Source model. That said, Igniterealtime is an Open Source community, so why am I blogging about Clearspace here?


! ng!First, Clearspace demonstrates how we're approaching collaboration strategically. We want to make team collaboration fundamentally more efficient, easier to use, and more fun. Most of you are pretty familiar with how we're striving towards those goals on the real-time side with Wildfire and Spark. Clearspace is another piece of the puzzle. One example: instead of sending multiple versions of a document through email that get lost in the netherworld of email hell, why not track the document versions in a central place that also seamlessly manages real-time and non-real time discussion around that document? Many of the Open Source features we'll be building into Wildfire and Spark over the next year fit into solving that type of business problem. We'll also be integrating lots of real-time functionality directly into Clearspace.


Second, we've updated the pricing model for the Wildfire Enterprise plugin to better match  Clearspace pricing. Enterprise is now $15 per user/year, which includes support and all upgrades. It's much simpler than the old model, which included a server license cost and a separate support and maintenance fee. For full details on pricing and support terms, visit the Jive Software pricing page, which includes info on special bundled pricing of Clearspace and Wildfire Enterprise.


I'm really excited about everything we're building -- from wiki documents and blogging to presence and VoIP. We're sending a shot across the bow of mammoth companies like Microsoft. There's a better way to do collaboration that's lighter-weight and more user-friendly. Mix in open standards, open systems, and a liberal dose of Open Source and we think we have a compelling alternative. We hope to get as much feedback on Clearspace as possible, so we'd love to hear from you if you have a chance to check it out.

Matt Tucker

Releases: Second Wave

Posted by Matt Tucker Champion Feb 6, 2007

Just one week later, I'm pleased to announce the second wave of releases:


Wildfire 3.2.0


The production release of Wildfire 3.2 is now available, including updated versions of the Enterprise plugin and the connection manager module. The 3.2 release is a major milestone for the project. We've massively increased scalability and  started branching out beyond instant messaging by diving into VoIP support. View the changelog for details.


Spark 2.5.0 Beta 2


We've incorporated a number of bug fixes and minor improvements since the first beta. Grab the download from the new beta area of the site.


Smack 3.0.0 Beta 1


After a long wait, Smack 3.0.0 is now in beta. See the blog entry for full details.


Gateway Plugin 1.0.0 Beta 7


The gateway plugin, which provides connectivity to AOL, ICQ, Yahoo and MSN, gets a step closer to the final 1.0 release with the beta 7 version. View the changelog, or visit the download page.  Also check out Daniel's post for details on the release.


SparkWeb 1.0.0 Beta 1


The first downloadable release of SparkWeb is now ready. Over the last week, we fixed support for Safari, did many UI tweaks and added minor new features like emoticon support.


Matt Tucker

Smack 3.0 Beta

Posted by Matt Tucker Champion Feb 6, 2007

A new beta of Smack (3.0.0 Beta 1) was released today. It's been a long time since the last release, which is easy to tell by the length of the changelog. The beta represents major new functionality. Some highlights:

  • Much better control over connections, including the ability to re-connect after a dropped connection.

  • Many new XEP's supported and better XMPP RFC compliance.

  • Major re-factoring of how chats work.

All this is very good news. The bad news is that this new release isn't a drop-in replacement for the old version of Smack. We had to make API changes in order to support the features above and we decided to make the move to Java 5 at the same time (might as well break a lot if you're going to break a little). The switch to Java 5 in particular will be a deal-breaker for some. We'll likely continue making bug fixes in the 2.x branch as compensation.


All these changes have been driven by work being done on Spark. In fact, Jingle support should officially land in Smack before the 3.0 beta period is up (you may have seen Jingle in the roadmap already). Let us know what you think of the beta. We'd also love your feedback on what we can do to make the transition smoother.


We've been heads-down for the past couple of months, hard at work on major new functionality for Wildfire and Spark. I'm happy to announce the first major wave of releases (in early access form):


Wildfire 3.2.0 Release Candidate 2


Highlights (or see full changelog and download):

  • Massive scalability enhancements. We've tested 30,000 concurrent connections on a single Wildfire box.

  • HTTP-Bind support.

  • All-new security certificate management.

  • Improved Mac OS X installer and management tools.

  • Numerous bug fixes.



Enterprise Plug-in 3.2.0 Release Candidate 2


Highlights (or see full changelog and download):

  • VoIP SIP client in Spark, with server-side client registration and management, including call reporting.

  • SparkWeb (see below).

  • Many Fastpath improvements.

VoIP support marks a major evolution in functionality as we move from instant messaging to real-time collaboration. SIP support is a commercial feature for integration with existing PBX systems, and in the near future we'll be ready to announce Jingle support as Open Source.


Announcing SparkWeb


!! The power and elegance of Spark, delivered through pure HTML and Ajax. SparkWeb is a Wildfire Enterprise (commercial) feature and today we're announcing the first public preview. Testing has primarily been done with Firefox up to this point, so support for IE, Opera and Safari is experimental.


In the near future, the Javascript library that SparkWeb is based on will be released as Open Source. The HTTP Bind implementation that powers the back-end is a standard component of Wildfire 3.2. You can view a live demo of SparkWeb on (you'll need to register an account on ignite with a different account to get in). In the near future, we'll have a plugin download available for testing on your own server.


Spark 2.5.0 Beta 1


Highlights (or see full changelog and download):

  • Enhanced look and feel.

  • Adium emoticon pack support

  • Improved notifications - know who's coming and going.

  • Improved Memory handling and speed.

  • Drag and drop of transferred files.

  • Buzz feature.

*Message Styles Specification


For the past several months, Adium engineer David Smith has been working as an intern here at Jive Software. He's helped make all our software more Mac friendly -- new builds for Wildfire and Spark so far, with many more Spark improvements coming soon. He's also been working on an open specification for message styles, a very cool feature that will be coming to Spark soon. The first version of the specification was published today.


Adium message styles allow the look of the message window to be totally customized, a feature that users love. By defining an open specification, multiple IM clients will be able to share message style implementations -- so, the same theme that works in Adium will also work in Spark and possibly other clients. All the Mac users here at Jive are big fans of Adium (especially given its support for XMPP),  so we're excited about this project as a way for the two products to work together. In related news, Adium 1.0 is about to be released, so check it out if you're a Mac user.


More Soon...


We're just getting warmed up with these beta releases, so look for more announcements soon!

Filter Blog

By date: By tag: