Probably the most requested feature for Wildfire and Spark is the ability to chat with users on the public proprietary IM networks: AIM, ICQ, MSN, and Yahoo (Google Talk already works great with Wildfire and Spark since it can federate through the open XMPP protocol).

I'm happy to announce that we've been working with Daniel Henninger on a new Open Source gateway plugin for Wildfire. Daniel has brought his experience working on the Python gateway components to create a very easy to use gateway system. At the moment, there's support for AIM, ICQ, MSN, and Yahoo, with IRC support coming soon. The code is still in the very early stages, but there's already some things that make these gateways different than what's been done before:

• Installation and setup is trivial since it's a Wildfire plugin. Existing gateways for XMPP servers have to be installed as external components, which means installing dependencies, config file edits, etc. Also, working as a Wildfire plugin gives the gateways internal access to the server, which allows nice features like dynamic changes to users' rosters.

• Web-based administration of the plugin allows each network to be enabled or disabled along with features and permissions, and to view and edit gateway registrations.

• Tight integration with Spark: we're building extremely easy to use Gateway support into Spark. Of course, any other client with gateway support will work as well.

The current plan is to have beta releases available in the next several weeks. We'll also provide continued updates on development progress in the forums.

[forums|http://www.flickr.com/photos/50884898@N00/203286219/] [forums|http://www.flickr.com/photos/50884898@N00/203286220/]

With the release of the Enterprise Edition of Wildfire, I wanted to put forth our thoughts on why we do Open Source software, and how our OSS projects will co-exist with our commercial applications. We have posted this to the .org website as well.

Summary: Our goal is to create the de-facto standard for open, real-time communications. We aim to achieve this goal by providing an elegant, flexible, open solution, suitable for any implementation  security, scalability, reliability and performance, at little or no cost.

Why do we create Open Source software?

• We believe in the Open Source movement and its power to fundamentally improve the software landscape.

• We believe in the potential of XMPP and seek to increase its adoption.

• Open Source communities are a powerful mechanism for continuously improving applications through development, testing and feedback.

• We prefer to spend our money on activities that help our customers (development, QA) rather than activities that have no value for our customers (e.g. advertising).

Why do we create commercial applications?

• Our commercial applications provide the funds required to support the OSS project. We see it as the air that the OSS projects need to breathe, since it would not be sustainable on its own.

• There is a healthy, symbiotic relationship between the Open Source and commercial applications, and continuous communication between the company, customers and community keeps it healthy.

• Some organizations are wary of the open-source license requirements and need alternative licensing models.

• As a business, we need to grow to stay competitive  commercial applications allow us to achieve this goal.

How do we balance the Open Source and Commercial applications?

The OSS project will <ins>always</ins> represent a "complete solution", which means it will always have the key features required to fit its purpose (and beyond). This means we will not arbitrarily add what most would consider "core features" into commercial editions.

What features will go into commercial extensions?

• Features to support mission-critical rollouts, such as server clustering

• Embedded third-party applications (non-Open Source)

• High-end, luxury features, such as enhanced reporting

• Advanced security features, such as deeper archiving options

• Features for unique use cases, such as customer "click to chat" support

How do we make money?

• Services: Support services and professional services (consulting) to customize, integrate and implement the applications.

• Commercial applications: Sales of commercial applications that are based on, or extend, the Open Source offerings.

• OEM Licensing: License fees for embedding the Wildfire server into other 3rd party applications.

Our Commitment

• We will live out the values of the Open Source movement to the best of our abilities.

• We will act responsibly and in the best interests of our community.

• We will be responsive to the needs of the community and communicate proactively.

[http://www.flickr.com/photos/50884898@N00/162086950/]Today, Wildfire won a ServerWatch product award in the Real-Time Communication Server category while Jabber took top honors in the Open Source Community category; check out the article for full details. Two things about the Wildfire award get me excited.

First, it's typical for Open Source projects to do well in reader's choice awards. Large Open Source communities are willing to take the time to cast votes for their project (if they know about the contest); it's hard for proprietary vendors to inspire that same passion. But that's not what happened in this case. Although we knew Wildfire was nominated for the award, we didn't know the details of the voting process and didn't make any mobilization efforts. So, the voting came directly from ServerWatch readers. On behalf of the entire Wildfire community: thanks ServerWatch! Even better, not only did Wildfire win, but we "ran away with the real-time communication category, capturing more votes than Microsoft Live Communications Server 2005, IBM Lotus SameTime, and Antepo OPN XT combined."

Second...notice who came in second? We think Wildfire is emerging as a viable alternative to Microsoft's LCS. We're disrupting the market using Open Source, open standards, and innovative features. But while this award shows we're heading in the right direction, we have a lot of work left to do. LCS is a clear leader and most organizations choose Microsoft products because they're a  safe and familiar choice. We've only just started to get the word out about Wildfire and Spark. To the Wildfire community: thanks for your help so far and keep it up!

The Spark Skinning service has been officially launched. It's an easy way to customize the look and features of the Spark IM client (and have those customizations automatically applied upon new releases). While I hope that you'll check out and use the service, this entry is for those that are interested in the behind the scenes story.

As originally scoped, Spark Skinning was going to be a fairly simple two week project. So, how did it take us two months to launch?

1. Feature Creep. We're typically pretty good at spec'ing out and scheduling releases at Jive. We develop detailed overviews for each feature in our wiki (so that everybody can edit the documents) and create mockups of how the features will look and function. Since this was "only a two week project", we thought we could get away with a less formal process -- a couple of quick meetings around a whiteboard. You can probably guess the outcome. Because we hadn't made the right investment in planning, the first version we built was missing some basic features. For example, the service didn't have the ability to lock the client to a particular server or to specify connection proxy settings. The color schemes also only applied to the login screen instead of the whole client. Yes, sounds pretty dumb, but that's what happens without planning. Lesson learned: Even "small" projects should go through a proper planning process.

2. Platform Fun. Spark is a cross-platform client, so the build process has to create installers for Windows, Linux/Unix, and Mac OS X. It turns out that in order to build an OS X installer the way we want to, the installer has to be created on OS X (Windows and Linux/Unix installers are built using pure Java so can happen on any platform). This was our first OS X box in a production environment and we choose to use a Mac Mini (pictured in its rack below). After setting up and deploying, everything was working well except that the service crashed once every two hours. After two weeks of debugging, we finally ran across a blog entry that explained a workaround to the problem.Lesson learned: New and unfamiliar production environments will always account for unseen problems and delays.
   

3. Integration. Spark Skinning is the first product we've launched that's purchased online via a credit-card. Getting online purchases setup involved a lot of non-engineering work. We had to set up an account with an online card processing service (Verisign) and then hook that up to our merchant account. Our operations team needed the right transaction information to correlate purchases in our accounting system. We had to setup the server so that we could process the transactions securely. Etc, etc. etc. Lesson learned: Make sure that all stakeholders (from development through operations) are involved in the schedule development.

Of course, we can apply rose-colored glasses to these three problems. Ultimately, the Spark Skinning feature set is richer and more compelling than originally planned, we know a lot more about OSX server hosting, and we've done a lot of work on ecommerce that can be applied to our other products. I guess I'll take the lessons learned and be happy with the result.

A couple of weeks ago, we gave a clueabout a new partner. Today, the cat's out of the bag. We're excited about the partnership. Further details about how we'll be integrating are forthcoming.

In Wildfire2.6, we've introduced support for the Publish-Subscribe extension to XMPP (Jabber). A loose analogy is that it's like RSS on steroids, but for instant messaging. A slightly more technical take: it's a comprehensive system for publishing and consuming topic-based events.

Like RSS, pubsub offers a simple way to get notifications. But far beyond RSS, pubsub has rich publishing and permissions systems. As a more radical example than standard news syndication, a company could use pubsub to power a file sharing service; certain users would be allowed to publish files, while others could read them (with optional moderation). Users would be notified in real-time when files are added or modified, and could even filter notifications using keywords. Other IM twists to the pubsub protocol allow you to choose to only receive events when you're online, use your buddy list for permissions management, etc. The reason we're excited about pubsub is two-fold:

1. It's much more comprehensive than the existing mainstream event protocols like RSS and Atom, which means you can do much cooler stuff. Of course, RSS and Atom should be thought of as complementary rather than competing technologies since they're for a different medium.

2. If you believe like Jive and Google that an XMPP instant messaging client will be on every user's desktop, that means pubsub is a viable<span style="font-weight: bold"># platform</span># for building all sorts of services.

At this point, pubsub is just an interesting technology that remains to be proven. However, we'll be building some innovative services on top of it and I'm sure others will be too.

If you're interested in learning more about pubsub and how it can be applied, read our article on the topic.