Skip navigation
All Places > Ignite Realtime Blog > Author: Matt Tucker
Matt Tucker

Openfire Powering Web 2.0

Posted by Matt Tucker Champion Apr 30, 2007

I've recently run into a number of innovative sites and products that use Openfire.

 

!http://www.igniterealtime.org/blog/wp-content/uploads/2007/04/imified.gif![IMifi ed|http://www.imified.com/] provides tools like task management, reminders and todo's through IM bots on AIM, MSN, and XMPP/GTalk. They've just released an API that will make it easy to write bots that work across all major IM networks. Openfire powers their XMPP back-end.

!http://www.igniterealtime.org/blog/wp-content/uploads/2007/04/mosoto.gif![Mosoto |http://www.mosoto.com/] is a real-time collaboration application for Facebook that includes chat along with file and music sharing. They're one of the premier implementors of the Facebook API and have a slick Flash client UI. The service is now in Alpha, but should mature and grow quickly (especially given the size of the Facebook userbase). They use both Openfire and the XIFF Flash API.

 

!http://www.igniterealtime.org/blog/wp-content/uploads/2007/04/justintv.gif!Final ly, we were told at the Web 2.0 conference that the chat feature on Justin.tv is powered by Openfire. I haven't had a chance to to verify that yet, but if true, it's cool that we're part of such an interesting social experiment. If you haven't seen the site yet, Justin wears a portable camera 24x7 that streams a live video feed to the website. I personally can't imagine broadcasting my life, but I have to respect the social commentary. In a world where we're always connected and available through cellphones and IM, this guy is really always connected and available... to the entire world.

 

These three examples are part of a broader trend: I think that XMPP will become a critical piece of infrastructure for a large number of next-generation web efforts, including Google. Recent protocol advances like BOSH (XMPP for web pages), Jingle (voice and video) and PEP (advanced presence features) will only further help drive adoption.

Matt Tucker

On the Release Train

Posted by Matt Tucker Champion Apr 22, 2007

The engineering team at Jive Software is growing fast (btw, we're hiring!). I thought it might be interesting to talk about some of the engineering process changes we're making to cope with that growth, especially since they directly affect product releases. First, a bit of history. We've always had a fairly agile development process -- lots of iterations, tools like unit tests and continuous integration, etc. But, we've consistently had a lot of pain around our current process:

* Not enough time for QA* . It's always scheduled, but gets squeezed due to lack of time. For example, the "official" QA time period for the Spark 2.5.0 release got crunched down to almost nothing.
* Stress when we don't need it* . The stress is caused by having to cram a ton of work into a short period of time to make internally set product release dates. It's also caused by scheduling extra features into releases at the last minute and by having to do emergency patch releases due to bugs we missed. We like working really hard, but there should be a way to do that without excessive stress.
* Unpredictable release dates* . The bigger a release is, the harder it is to make accurate work effort estimates. That means that dates slip and that it's hard to communicate to the outside world exactly when a release will ship.

So, there are some clear problems that we want to fix. The trick for us was to come up with a process that fixes those problems but that's still light-weight enough to avoid a huge administrative burden. We're now experimenting with a strict release train model for Spark and Smack. Assuming it goes well, the same model will be applied across all our products, including Clearspace. A visual summary of the model is below (click the image for a larger version):

[Clearspace|http://www.igniterealtime.org/blog/wp-content/uploads/2007/04/train.png|train_sm all.png]

 

The key points to this model:

  • We put out a new release every three weeks (although each release will have gone through a nine week process total).

  • Three weeks before each development cycle is reserved for product management; three weeks after each development cycle is reserved for QA. But notice that all three processes are all happening at the same time.

There are all sorts of subtleties to the system like how to deal with new features that take more than three weeks of engineering time, but so far everything is going quite well.

 

The start of the three week cycle is always on a Monday, and we have a big meeting to determine exactly which features will go into the release. Product management has already done the work of prioritizing the features so we just need to choose exactly what we're going to work on and come up with the plan about how to get it done over the next three weeks. On the second and third Mondays during each cycle we go through more detailed updates than in our SCRUM meetings to see what's on track and what's not.

 

At the end of the cycle, we:

  • Do the product release coming out of QA on Thursday.

  • On Friday, finish all development and create a branch ("spark_2_5_2_branch" for example).

  • Switch the builds in our continuous integration environment, TeamCity. The new branch becomes the "stable" release of the product and trunk becomes "development".

  • Release a beta version out of the new branch. In other words, the world generally always sees a stable official product release and a beta release that will become official in three weeks.

There's way more that I could talk about with this process (including some of the potential drawbacks), but I'll save that for future blog entries. Things we're jazzed about so far include solid release dates, having a better process in place to deal with new feature requests and bug reports, more stable quality in each release, and always having a place to check in new feature development (trunk). We're still early on in the new system, but we'll all know how exactly how well this works in the next two months. Of course, we'd love your feedback as time goes on about how well you think we're doing.

 

Matt Tucker

Props to LG

Posted by Matt Tucker Champion Apr 9, 2007

!http://www.igniterealtime.org/blog/wp-content/uploads/2007/04/props.png!Earlier today, LG (IT2000) passed Gato to become the top point earner in the ignite community forums. It's the first time ever that an outside community member has jumped ahead of Jive Software engineers, which is a pretty impressive feat. With a current score of 3475 and 5 to 10 points per question answer, that's a lot of people he's helped out -- especially considering that not everyone remembers to award points.

 

So in the spirit of Ali G, all of us at Jive Software want to offer mad props to LG.

Matt Tucker

Happy St. Patrick's Day

Posted by Matt Tucker Champion Mar 16, 2007

!http://www.igniterealtime.org/blog/wp-content/uploads/2007/03/guinness-pour.jpg! Pouring a pint of Guinness is a sacred art -- get it wrong and the creamy goodness just won't be the same. So in honor of St. Patrick's Day, our resident design expert Ryan created a guide (below) to creating the perfect Guiness pint.

 

One thing we never realized is that actually getting a Guinness keg hooked up can be a huge PITA. However, after four store visits (parts), an overnight package delivery (tap handle), and courier service (correct nitro gauge), the Jive office is very happy.

 

Matt Tucker

Openfire Name Launched

Posted by Matt Tucker Champion Mar 15, 2007

  Today we re-launched Wildfire using the Openfire name. Along with the name change, we also have a great new logo. I wanted to provide some details about how the name change is being implemented to decrease confusion.

 

First, you'll notice that all website content has been updated to Openfire. There may be a few broken links still, so if you notice anything please let us know. We're also reaching out to external sites that still use the old Wildfire name and asking them  to make updates.

 

The product releases will work as follows:

  • 3.2.x series: these releases will continue to use the Wildfire name so that critical bug fixes can be delivered with minimal hassle to existing users. In fact, we're releasing 3.2.3 today.

  • 3.3.x series: starting with 3.3.0, the server is called Openfire. There will be a small amount of upgrade pain associated with this release since configuration files like wildfire.xml will now be openfire.xml, etc. We'll be releasing 3.3.0 beta early next week, with a final release following as soon as we can ensure the upgrade process is as smooth as possible.

Again, my deep thanks to everyone for all the support you've given us during the name change process. A lot of the hard work is already out of the way at this point, so now it's time to spread the word as much as possible!

 

Matt Tucker

Ring Ring!

Posted by Matt Tucker Champion Mar 13, 2007

With today's releases of Spark 2.5.0 Beta 4 and Smack 3.0.0 Beta 3, support for Jingle VoIP has officially landed. We're pretty excited about the progress so far (and perhaps Thiago can start to get more sleep after numerous all-nighters). Some highlights:

  • We've tested NAT traversal in a wide variety of environments, in one case punching through three layers of NATs.

  • Voice quality is sounding great on Windows and Mac. Note that we haven't had a chance to test on Linux testing yet, so support there is probably broken at the moment.

Of course, there's a ton of work still: more NAT traversal and media proxy tests, UI refinements, entity capabilities detection (so we know when to show the call button), Linux testing, options to use more than just the GSM codec, etc. We're working towards a final 2.5.0 release of Spark in the next several weeks, with a final Smack 3.0 release at roughly the same time.

 

NAT traversal isn't an easy problem to solve, but we've come up with some innovative twists to standard ICE techniques that we believe are superior. In essence, we've found a way to bypass the limitations of SIP (which doesn't have reliable signaling like XMPP) and therefore don't require STUN and TURN support. For those of you that don't read pages and pages of VoIP RFC's in your spare time, this probably all sounds like gobbledygook -- my apologies. Some specifics of our proposal are already being discussed in the XMPP standards list. We're now hard at work fully documenting the protocol and then will submit it for review (which will be a controversial process). Will we as the XMPP community have the courage to break from the SIP mold and standardize better and simpler techniques for NAT traversal?

 

Jingle: Too late or Perfect Timing?

 

All this Jingle work has made me reflect on the market realities of VoIP in XMPP. After a lot of hype last year, discussion of Jingle had quieted down a lot. Jingle excitement seems to be building again recently, but can we truly make an impact against SIP? Two things make me hopeful:

  • NAT traversal through open standards is not a solved problem yet. ICE, STUN and TURN are still draft standards and not many SIP stacks have deployed all these new protocols yet. That makes me believe that we have a window of opportunity to establish mindshare for Jingle as the best NAT traversal VoIP protocol.

  • SIP federation just doesn't exist in any useful way yet. Instead, SIP is generally deployed in isolated islands. On the other hand, XMPP federation is vibrant and growing at a huge rate. That may give Jingle a leg up.

Greg and I are heading to the VON conference next week. We're printing a huge sign to put up in the booth:

It will be interesting to see how people react. If you're going to be at the conference, be sure to stop by the booth and say hi!

 

The voice conferences we've attended this year have been a mixed bag for Jingle. We saw good interest in the protocol at E-Tel, although many bristled at the notion that XMPP could solve any problems better than SIP/SIMPLE. On the other hand,  those I talked to at the Internet Telephony  conference generally hadn't even heard of XMPP, much less Jingle.

 

For Jingle to succeed, a few things need to happen:

  1. We need to clearly articulate where Jingle fits into the VoIP puzzle and make sure we offer some clear advantages over SIP for those puzzle pieces (note that it's never been a goal of Jingle to replace SIP in all cases).

  2. Interoperable Jingle implementations need to start appearing as soon as possible.

I find it all to be an exciting challenge and I can't wait to see where Jingle is a year from now.

 

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!

 

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.

 

 

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!

 

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?

 

!http://www.igniterealtime.org/blog/wp-content/uploads/2007/02/clearspace_small.p 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

 

!http://www.igniterealtime.org/blog/wp-content/uploads/2007/01/sparkweb_mini.png! 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 igniterealtime.org (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!

!http://www.igniterealtime.org/blog/wp-content/uploads/2007/01/2007_finalist_bw.g if! Wildfire has been selected as a finalist for this year's CODiE awards in the Best Communications Solution category. We'll find out on April 17 just how much the judges like the most cutting-edge Open Source communications server on the market. Going through the judging process for awards can be time consuming, but they're a great validation for the project. Of course, don't forget about the  Open Source Reader's Choice voting -- we're just nine votes away from first place!

!http://www.igniterealtime.org/blog/wp-content/uploads/2007/01/sparkphone.png!Ear lier this week, I gave a talk at the Internet Telephony conference about next generation unified communication. You can check out the slides. A few caveats:

  • I didn't pick the title of the talk and the ugly slide template was required.

  • There's a lot of context missing without me talking, but at least you'll get the gist.

The telcom industry seems to be moving full speed ahead towards unified communications (I see it as the convergence of voice with other communication channels). Most of the vendors talked about presence as an important concept and were doing some amount of text messaging, chiefly through Microsoft LCS integration.

 

As many of you already know from our roadmap, we've been doing a ton of work on voice, which will land in the next releases. So, it was great for me to get the telcom perspective and imagine how we'll all meet in the middle with feature sets. Personally, I'm pretty excited about all the possibilities.

Filter Blog

By date: By tag: