I’ve never been so happy to unpack boxes. That’s just one of the memorable scenes happening at Jive’s brand new Bay Area home at 735 Emerson in downtown Palo Alto. We moved into this great space (which formerly housed Ning) after outgrowing our first Palo Alto space in only five months. Those of us in that first “Jive South” office quickly learned how to optimize space on a weekly basis as more and more employees joined. But now we feel like we have a great home that gives us plenty of room to grow as we expand our Silicon Valley team.

The other scene unfolding are the final touches for tonight’s Open House event to celebrate our new digs. If you are in the area, come join us tonight (November 19) from 4-7pm for some food and drinks. A good number of the Jive engineering team will be joining me to honor their efforts in launching Jive SBS 4.0 last month – the biggest bundle of innovation in our company’s history. Please RSVP to events@jivesoftware.com so we get you on the list.

Another major reason for the Open House -- Jive is aggressively hiring product management and engineering positions to help with our expansion efforts. It’s no secret that the Bay Area is a cradle of incredible tech talent, and we’d like to meet more of you and share the excitement of what it’s like to lead the Social Business Software revolution. The Open House is a great place to get familiar with the team and hear about what we’ve done and where we’re going.

At this point, even my dad has asked me what I think about Google Wave (sorry Dad for any tech-savvy intimations!). Since Wave is in the process of rolling out to a much larger audience of testers and developers, it seemed like an appropriate time to jot down some thoughts about it. But first, an announcement: as widely discussed around the web, Wave uses the XMPP protocol under the hood and in particular works with the Openfire XMPP server (see Wave Federation install docs). Openfire was developed by Jive and we continue to sponsor it as an Open Source project. Up to this point, Openfire has been available under the GPL license. We've moved Openfire to the more liberal Apache 2.0 Open Source license, which is the same license used for the Google Wave Federation project. This change is already reflected in the Openfire source tree and an official release will be made soon. We hope and believe that the more liberal Apache 2.0 license will help unleash a new wave of innovation around Openfire (bad pun gleefully intended).

So, Wave itself -- though the project is still in the early stages (and far from ready for prime-time, especially in an enterprise setting) it's generated an enormous amount of buzz. No doubt a large part of that excitement is due to it being from Google. But more importantly, Wave is pushing the boundaries of what's possible in a web browser with a super rich and real-time user experience. It serves as inspiration to all of us that develop collaboration software. While it's still a bit early for Jive to have an official position on Wave, we're definitely following it closely and the Wave concepts align well with our roadmap. So much has been written about Wave already that I won't attempt to duplicate any of the existing detailed overviews. But I do have my personal three favorite things about Wave:

1. Wave will help drive adoption of HTML 5 by serving as such a compelling example of what that technology makes possible.
2. Wave uses XMPP as the back-end protocol. Yes, I'm a nerd for loving a protocol.
3. Federation is baked-in. This was a visionary move by Google and big win for an open internet in the new world of monolithic web sites/services.

It will be fun to watch where all of this goes.

We've been participating in and sponsoring several great engineering events in both Portland and the Bay Area that I wanted to highlight:

Recent Events

Portland JavaScript Admirers, June 24 -- a group of smart Javascript hackers that meets monthly to discuss cutting-edge Javascript techniques. We provided beer and pizza and look forward to participating in the future meetups.

Portland Cloud Camp, June 30 -- Portland's own iteration of the popular CloudCamp unconference series, which Jive sponsored. There were lots of great discussions and it's super relevant content for Jive given our expanding investment in cloud computing and specifically Amazon AWS. I also enjoyed attending the San Francisco CloudCamp on June 24.

Upcoming Events

CHIFOO, July 8 -- the Computer-Human Interaction Forum Of Oregon hosts monthly meetings at Jive's offices to discuss user experience, usability and interaction design.

Refresh Portland, July 23 -- a monthly event for designers interested in refreshing the creative, technical, and professional culture in the Portland area that's hosted at the Jive office.

We're adding more events to our calendar and are always interested in helping technical organizations in either Portland or the Bay Area with location space (or beer sponsorship!)

Today we launched Jive Express, a cloud service that lets enterprise business users get up and running with social business software within minutes. The cost is $3 a user/month and we're making the first three months or 100 users free for qualified companies. Departments and cross-company teams have never had such easy access to a collaborative social software product this powerful. It's the same incredibly rich platform that underlies our Jive SBS product along with features specifically targeted for teams like the success dashboard pictured at right. (Want to know how Jive Express stacks up to our full-blown Jive SBS platform? See the quick matrix). Other than being jazzed about the product and the fact that I got to be on the team at Jive that built it, I'm also excited about our first foray into cloud computing and the strategy we're building around it.

How is Jive approaching the cloud? We believe large organizations will embrace the cloud but that it will be a multi-year process. We want to be there to help with the transition in a pragmatic, realistic way. In the short-term, that means making it easy to transistion on and off the cloud using our single tenant architecture (see my last blog for more on single tenant cloud apps). We've used virtualization to drive amazing levels of cost efficiency while providing maximum security and data isolation. We know that enterprise companies are still in the intial stages of cloud adoption, so we're making it very easy to start there but then move to on-premise or to our more traditional hosted environment as the implementation scales. This hybrid approach is unique and we believe it's the best approach for enterprise cloud adoption. To implement all of this, we chose Amazon's AWS service as the backend cloud provider. Working with them has been a fantastic experience so far and they seem to be well on their way to solving many of the enterprise cloud concerns around security and compliance.

I plan to blog a lot more details about how we built the Jive Express service as well as our ongoing cloud ventures in the future. Also check out my interview with whurley at Infoworld for more details. In the meantime, be sure to check out the Jive Express site and signup.

I'm pleased to announce that Jive Software has acquired Jotlet. Jotlet has built some amazing calendar technology that we'll be incorporating into Clearspace in a future release. The two super-talented guys behind Jotlet are joining our team in Portland from Texas.

One key way Jotlet has innovated is by building a super-rich API that allows calendars to be easily embedded into any webpage. That's a big improvement over the Google Calendar approach, which requires an iFrame and doesn't offer a customizable UI. Over time we'll be applying similar concepts to all of the collaborative tools in Clearspace so that it's easy to bring the right social and collaborative features to wherever they're needed. Visit the Jotlet website for more details about their technology and to see it in action.

  There's a new firestorm brewing in web services architectures. Cloud services are being talked up as a fundamental shift in web architecture that promises to move us from interconnected silos to a collaborative network of services whose sum is greater than its parts. The problem is that the protocols powering current cloud services; SOAP and a few other assorted HTTP-based protocols are all one way information exchanges. Therefore cloud services aren't real-time, won't scale, and often can't clear the firewall. So, it's time we blow up those barriers and come to Jesus about the protocol that will fuel the SaaS models of tomorrow--that solution is XMPP (also called Jabber) . Never heard of it? In just a couple of years Google, Apple, AOL, IBM, Livejournal and Jive have all jumped on board. Sounds good, right? So, what's the hold up? Why aren't we building out cloud services with XMPP now? And, if people are already providing cloud services without XMPP, what's the motivation to switch? The rest of this post will shed some light on the current landscape and provide some answers to those questions.

Polling isn't working anymore

Since the beginning of the Internet, if you wanted to sync services between two servers the most common solution was to have the client ping the host at regular intervals, which his known as polling. Polling is how most of us check our email. We ping our email server every few minutes to see if we got new mail. It's also how nearly all web services APIs work.

Take, for example, Twitter. High Scalability recently covered the load stats on Twitter reporting that they average 200-300 connections per second with spikes that climb to 800 connections per second. Their MySQL server handles 2,400 requests per second! Recently, the Macworld keynote became the most recent culprit for causing Twitter to cut off its API, which has 10x the load of their website. While Twitter is not a cloud service, nor the largest demand service on the internet (with a paltry 350,000ish users, which pales in comparison to a MySpace or Yahoo!), they do illustrate the kind of frustration a user experiences with polling based services. And, that's just Twitter! Imagine the impact on overall Internet traffic congestion polling creates worldwide.

Interestingly, the recent Twitter outage lead some influencers, like Dave Winer,  to suggest that Twitter move to XMPP which we've already begun experimenting with   

Some companies are trying to address the polling problem with existing protocols. I think that move is largely motivated by a significant investment in legacy systems that makes moving to another protocol difficult. Salesforce is a perfect example of a company attempting to address the polling problem with creative applications of the old one way protocols.

The latest version of Salesforce will send notifications back to your own webservice to avoid polling. But, that's a pain to setup for developers. Worse, its very difficult to wire up reverse webservices calls through a corporate firewall.

The hold up

XMPP's largest hurdle is that its not HTTP, and common wisdom states everything new that's built must be web-based. That means we won't see a widespread application of XMPP in cloud services until a few more brave pioneers clear the path for the rest of us.

I've been heavily involved in the XMPP world as a developer of Smack (client library) and Openfire (server) and have also helped craft the standard as a member of the XMPP Standards Foundation. XMPP was invented for instant messaging and presence, and is the dominant open protocol in that space. Instant messaging? Yep, it turns out that all of the problems that had to be solved for instant messaging make the protocol perfect for cloud computing:

• It allows for easy two-way communication, so bye bye polling. It even has rich pub-sub functionality built-in.

• It's XML-based and easily extensible, perfect for both new instant messaging features and custom cloud services.

• It's efficient and proven to scale to millions of concurrent users on a single service (such as Google's GTalk). It also has a built-in worldwide federation model.

I'm not the only one to notice that XMPP is a great fit for cloud computing. Tivo is switching to XMPP as a more efficient alternative to their old architecture:

<div class="jive-quote">Today each TiVo polls TiVo’s severs roughly every 15 minutes to check for new scheduled recordings, TiVoCast downloads, Unbox downloads, etc. That’s highly inefficient - nearly all of those polling calls are for nothing. There is nothing waiting to be done. And it introduces a lag when you want to start a download - up to 15 minutes. And it doesn’t scale well as TiVo’s user base keeps growing.

So what’s changed? The polling system is gone. TiVo is using XMPP now instead. (...) Yep, TiVo is basically using instant messaging for real- time communication. Now when the TiVo server has a new recording to schedule, it will IM the TiVo to tell it. Or if there is a download to pull, it will IM the TiVo to tell it to do so. This is a much more efficient system and it eliminates latency. It is really a clever idea.

</div>

Fixing the polling and scaling problems with XMPP as Tivo has done is compelling, but the built-in presence functionality also offers tantalizing possibilities. Presence includes basic availability information, but is extensible and can also include things like geo-location. Imagine cloud services taking different actions based on where the client is connecting from. 

More people, us included, will make the shift to XMPP, which will provide the missing evidence to create momentum toward a tipping point. In fact, I'm happy to announce that Clearspace 2.0 will include a feature that's powered by an XMPP-based cloud service. We'll be publishing a series of blog entries in the near future to discuss how we built it.

Resources for XMPP cloud service developers

There are a few places you can turn for help building cloud services around XMPP. Here is a list of a few:

• XMPP Standards Foundation -- where the standard gets defined

• Ignite Realtime -- Jive Software's Open Source XMPP projects

• Jabber Website -- lists XMPP servers, libraries and clients

Back in April, I blogged about how we were adopting a release train model for our Open Source projects. Since then, we've rolled out the same process to our commercial products Clearspace and Jive Forums. The release train is a fairly fundamental departure from how we've done releases in the past, so we wanted to provide more details about exactly how it works.

Why did we make a switch in how we build our software? There were many motivating factors, but the general theme is "move as fast as possible with high quality". For end users of our products, the key thing to know is that there will be a new release every three weeks. Each version contains bug fixes and new features and we're committed to maintaining high quality for every release (no more rushed bug fixes a week after a release). The graphic below illustrates how this process works:

Each release (from top to bottom of the graphic) takes a total of nine weeks: three weeks of planning, three weeks of development, and three weeks of QA. All three processes run in parallel, which leads to the three week release cycle.

Answers to common questions:

Q: Do we expect customers to upgrade every three weeks?

A: No, that's unreasonable in most environments. We've made it as easy to do upgrades as possible, and we hope you'll upgrade at least once per quarter to take advantage of all the great changes. When you do upgrade, the release train process will help ensure you're on high quality code.

Q: How will version numbers work?

A: Each release will get a minor version number: 1.5, 1.6., 1.7, etc. Major version numbers will change approximately once per year.

Q: How will you develop major new features that take more than three weeks?

A: Good question. No model is perfect and we're already working on new features that will take more than one train cycle to fully finish. In those cases, we're breaking the projects into milestones and using code branches as necessary.

Other Release Train Fun

The release  train has had a deeper cultural impact than just being a way that we engineer our software. The marketing team now times a lot of their work on the train, and even our major happy hours are now on the three week cycle. Late afternoon of every third Friday, we gather the company for a demo of the new features and then adjourn for partying.

Time will tell how well this new process works, but we're excited about it and the results so far are promising.

It's been pretty amazing to see how our own Clearspace deployment inside Jive Software has improved communication and helped us get work done faster. We're all Clearspace addicts, and as such, some of our fun has moved there. A few examples:

• Somehow, a mustache growing contest took off inside the company. Several blog entries with pictures made it into the "Water Cooler" space, including an embarrassing attempt by me. The clear winner was Todd (who will not be pleased about me posting his winning entry).

• There are lots of avid runners at Jive and group runs and races are all getting discussed through Clearspace.

• Erskine's personal blog entry about his nerd score (59) attracted a huge number of comments from all over the company.  Others' scores ranged from 6 to a perfect 100.

• Everyone controls their own avatars. The ability to inject a bit of personality into Clearspace has proven to be a major incentive to participate.
  !http://www.igniterealtime.org/blog/wp-content/uploads/2007/04/avatars.gif!

We even added a Youtube macro to Clearspace recently, which makes it easier to share the occasional fun video.