Skip navigation
All Places > Ignite Realtime Blog > Authors greg

Ignite Realtime Blog

10 Posts authored by: greg

Spark Skinning Update

Posted by greg Apr 13, 2007

!http://www.jivesoftware.com/skin/images/spark-skin-sshot.gif!The Spark Skinning Service has been a hot topic here at Jive for the past couple of weeks. The service is not yet ready to serve up customized builds of Spark 2.5 (it will be ready late May) and it turns out that one small change to the service will make it much easier to keep the Skinning Service up to date with the latest Spark release. What's the change? Removing the ability to change the color of Spark. So in the interest of staying in sync with Spark releases, we'll be removing this functionality.

 

We have also decided to stop selling Spark Skinning as a stand-alone service. Instead, it will only be available as part of Openfire Enterprise Edition. Current customers of Spark Skinning will not be affected. If you have a subscription to the service already it will continue to work until the current subscription runs out, and there is an upgrade path to Openfire Enterprise to keep the functionality after that time.

 

Spark Skinning is being phased out as a stand-alone service for a couple of reasons. First and foremost, the changes to Openfire Enterprise pricing substantially lower the barrier for small deployments while maintaining value-based prices for larger deployments. The second reason is that the amount of administration required to keep two sets of Spark Skinning accounts functioning smoothly became too onerous. Simplifying to a single account type will help considerably.

 

As always, let me know if you have any thoughts about Spark Skinning or these changes.

Asterisk-IM: It's Alive!

Posted by greg Mar 30, 2007

!http://www.asterisk.org/themes/asterisk/images/logo.png!There have been a lot of questions about Asterisk-IM since the new voice features were added to Spark and Openfire. I'm happy to report that there are now four interested developers who are going to be stabilizing Asterisk-IM, adding new features and making sure those features work well with the other voice-related functionality in Spark and Openfire. There is plenty to do at the moment, but I wanted to find out what everyone wants to see from the plugin.

 

What would you like to see from the Asterisk-IM plugin once the existing features have been stabilized?

Google Summer of Code 2007

Posted by greg Mar 21, 2007

!http://code.google.com/images/code_sm.png!We're excited to be participating again this year as one of the mentor organizations under the XSF for Google's Summer of Code 2007. We have several project ideas and mentors ready to offer advice on getting the projects done. The ideas we've created:

 

  • Asterisk-IM: Asterisk and Openfire Integration

  • Link-Local Messaging ( XEP-0174) support

  • File transfers for gateways

  • Jingle Voicemail

  • Group Chat for Gateways

  • G722 Codec for JMF

 

If you are interested in one of these projects or in proposing your own, we suggest sending an email to "greg at jivesoftware.com". The more we can get to know about you and your expertise before the official application process through Google's site, the more that will help during the selection process.

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.

 

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....

 

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!

Parking Lot Presence

Posted by greg Jan 12, 2007

!http://www.igniterealtime.org/blog/wp-content/uploads/2007/01/sensor2.png!About a month ago Thiago flew from his home in Brazil to Portland for an in-person visit with the rest of the team here at Jive. When Matt and I went out to the airport to pick him up we noticed long lines of fancy new vehicle presence sensors on the ceiling, one for each short-term parking slot.

 

Beyond simply sensing the car's presence the device includes bright LEDs that display blue when vacant and red when occupied. Since the device is mounted on the ceiling it is visible from several aisles away and can help guide drivers to available parking slots. After a little searching I came across a presentation by Dan Brame that provides an overview of the PDX parking technology. It turns out that the sensors and lights are just the beginning of a system that is designed to direct drivers to available parking slots efficiently without the need to drive up and down aisles looking for that elusive open spot. Apparently, innovation in the parking lot is happening all over. One of the Clearspace engineers, Aaron, recently came across a blog post about Santa Monica's real-time parking availability maps as well.

 

!http://www.igniterealtime.org/blog/wp-content/uploads/2007/01/arrow.png!Presence is a powerful concept, and it isn't limited to people. Network devices, parking lot sensors, computers, etc., can all have presence that can be used to make systems more effective. But, as the example above shows, a physical representation of presence, such as a desktop signal light, can be very helpful in some situations. The world is just scratching the surface of this powerful concept. From something as straight-forward as rich presence based on your calendar to advanced sensor networks adapting to topological changes we'll continue to see new value created by new presence detection and inference mechanisms as well as innovative uses of the presence data.

$588 billion? Are you serious?

Posted by greg Jan 2, 2007

At Jive there are quite a few "Battlestar Galactica" fans, but I had not watched the show before this weekend. When my wife received the season one DVD set over the holidays, it was a chance to find out what all the buzz was about. The show is awesome so far, but one scene in particular caught my attention. During the first episode the commander of the ship rehearses a speech as he wanders the corridors. He keeps repeating the first couple of sentences of his monologue, but is consistently interrupted before getting any further. As he settles into giving his speech it becomes clear that all of those interruptions distracted him from his plans and he ends up giving a completely different speech. In our own daily work lives, interruptions can be very costly. CNET recently reported on research by Basex that found that interruptions could be costing U.S. businesses up to $588 billion per year.

 

What does this have to do with real-time collaboration? Instantaneous human interaction, whether in person or through a medium such as IM, has the potential for interruptions which lower productivity. At the same time, some interruptions are critical to collaboration and creativity. Coming up with tactics for managing these interruptions in a way that balances the good and and bad aspects can greatly improve all of our effectiveness. Matt provided some tips last year, including some of the ideas below.

 

!http://www.igniterealtime.org/blog/wp-content/uploads/2007/01/lightred.png!One way to manage interruptions is through the active management of one's presence. At Jive, if you set your presence to "Do Not Disturb", most people will avoid messaging you unless it is critical. When you really need focused time, "Do Not Disturb" can be invaluable. However, there are still in-person interruptions that can occur since your presence cannot be seen as people walk up to your desk. We recognized this problem internally and have added USB LED signal lights to some workstations (the lights are expensive). A Sparkplug then changes the color of the light based on the user's presence. For example, when the presence is set to "Do Not Disturb" the light automatically changes to red as a signal to others. This system works well for people who actively manage their presence, but not for those of us who routinely forget to change our presence.

 

 

!http://www.igniterealtime.org/blog/wp-content/uploads/2007/01/lights.png!Automat ic presence information synchronization is a great way to help solve the pain of manually changing presence. Wildfire and Spark can be integrated with Asterisk so that when someone is on the phone, their presence is automatically updated to "On the phone" -- this works great with the presence lights. A future source of presence information will be Outlook calendars. Automatically changing presence to "In a meeting" will help others see whether you're available and save them time tracking you down. The (somewhat blurry) picture at right shows two presence lights in action -- the one in the foreground is green, while the one in the distance is red. Next week I'll package up the Spark plugin that powers the lights and release it in the forums for anyone that's interested.

 

Achieving greater productivity through the reduction of interruptions is beneficial for all of us. We can experience less frustration and be more effective without giving anything up. All it takes is more consistent use of presence to indicate availability -- that requires both accurate (and automatic) presence information as well as a culture of respect for presence status so that "Do Not Disturb" has teeth. Let's work together to shave a few billion dollars off of the waste that unnecessary interruptions generate.

Open Standards and Open Source

Posted by greg Dec 4, 2006

As we worked on Ignite we wanted to come up with a powerful core message for the community. We knew it was going to have something to do with both open standards and Open Source, but the real excitement came when we realized that it was the relationship of both of these forms of openness that we really wanted to focus on.

 

Open standards are an important part of any technology. From standard outlet sizes for electricity in homes to standard protocols on the Internet, open standards allow technology to reach more people and add more economic value than closed or proprietary standards. Open Source and open standards complement each other by increasing an open standard's relevance and by fostering interoperability between software projects. The XMPP community is a great example of this relationship and the benefits are visible in the wide range of areas that XMPP is used. Another favorite example is email -- once open standards took hold, email usage in businesses skyrocketed. Will the same happen with IM?!http://www.igniterealtime.org/images/ignite_home-circlegraph.gif!

 

Open Source is a primary driver of open standards. Wide adoption is fostered by free and no cost implementations and APIs for open standards. Take the Smack API for example. It provides a simple API for Java developers to add XMPP functionality to their applications. Smack is used for everything from low-level application integration, event notifications from hardware devices, and desktop RTC clients like Spark. And because it is based on an open standard, integration with other platforms becomes easier since XMPP APIs are available in many programming languages.

 

Besides fostering wide adoption of open standards, Open Source also feeds back into the standards specification process. Open Source standards implementers contribute back to the standards process by recommending improvements, discovering ambiguities, and providing an implementer's perspective on the standard. The standard becomes stronger and easier to implement and everyone wins.

 

With all of this positive feedback streaming between Open Source and open standards it was only natural that the core message of Ignite Realtime be the promotion of the relationship between the two. Of course, we're a commercial company and not just about Open Source. We sell Wildfire Enterprise as a commercial extension to Wildfire and count on the fact that a good percentage of the community will find the Enterprise feature set compelling enough to make a purchase. We strongly believe that commercial software fits well into the Open Source/open standards relationship -- we think of it as the crank that keeps the wheel going (see Dave's blog entries for more on this). How do we visualize all of this? You can see our attempt as the image in this blog post, which can also be found on the Ignite Realtime home page.

 

Simplicity Accelerates Adoption

Posted by greg Dec 4, 2006

The fact that simplicity accelerates adoption may seem obvious, but it is worth pointing out. All of the projects on IgniteRealtime have simplicity and ease-of-use as one of their core goals. Igniting real-time collaboration is all about spreading the word about the productivity improvements and collaboration opportunities presented by real-time modes of communication. This principle doesn't just apply to the end-user experience either. Simplicity in administration and API usage allows administrators and developers to focus on solving their technical and business problems without spending unnecessary time on technical issues or awkward interfaces.

 

Why is accelerating adoption of real-time an important goal? I am looking forward to the day when RTC is as open and ubiquitous as email. This doesn't just mean having a federated set of IM addresses that everyone recognizes, though. That would be email parity. RTC ubiquity extends to seeing a colleague or partner's presence and being able to initiate the ideal method of contact, or combined methods of contact, simply and immediately. And making it easy to capture the output of the collaboration at the end of the interaction is just as important as starting the conversation in the first place.

 

Filter Blog

By date: By tag: