Skip navigation

Recently, a debate has erupted on the Lucene (Open Source search library) mailing list about whether to make the next version of the library require Java 1.5 instead of Java 1.4. Predictably, opinions fall into two camps. I've done my best to summarize the arguments on both sides:

  • Move forward: "Java 1.5 has been out for about two years and making the next version of Lucene require that release is a reasonable way to move forward. Backwards compatability can't be preserved forever, and there are some nifty features to use in the newer versions of Java."

  • Backwards compatability: "There are still a ton of users on Java 1.4. Switching to 1.5 provides only incremental engineering advantages and could leave existing users in a lurch. It would be better to wait at least another year until even more users are on Java 1.5."

I've watched the passionate emails on both sides with some interest, as we went through similar discussions in the not-too-distant past. Our Jive Forums product has been locked to Java 1.4 for a long time because we have a lot of large, important customers that just can't upgrade their infrastructures very quickly. So, not much of a debate on which version of Java to use for that product, unfortunately. However, when we were going through the process of making Wildfire Open Source nearly two years ago, there was a choice -- use Java 1.5 and get all the cool stuff, or appeal to more existing users and work on more platforms by supporting 1.4? Back then, it was a pretty tough choice since Java 1.5 had just been released.


Progress at the expense of backwards compatability is obviously one of the core issues in software development, and I can't hope to fully address the problem in this blog entry. However, I can say that we were very happy that we picked 1.5 for Wildfire. Generics and features like the new concurrency package certainly helped our development process. But, there was something else about moving to the new platform that I wasn't expecting. If I had to distill it down to one word, using Java 1.5 simply felt "fresh". It got our engineers fired up and the community of users that developed around the project seemed only too happy to be using the latest and greatest. We also embraced a lot of other cutting edge technologies at the same time like XMPP. I truly believe that if we had gone down the "safer" path with 1.4, Wildfire just wouldn't have developed the same level of energy that it has today.


Maybe this is the path that all software products take as they "cross the chasm" -- start with what's new and risky (which appeals to all of us that love technology) and then gradually slow down into being more mainstream and then eventually obsolescence.  I guess we'll see what happens with Wildfire when Java 1.6 comes out later this year and we're faced with the same choice all over again. Will things be entirely different now that the Wildfire project is so much more mature?


Finally, what will the Lucene maintainers decide? We'll find out in the near future, but I cast my vote for the move to Java 1.5.

Our Open Source Philosophy

Posted by djhersh Jun 21, 2006

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.

Two new beta releases of Wildfire 3.0 made their way to our site last night. In addition to a new release of our popular Open Source Edition we have added a commercial upgrade to an Enterprise Edition of Wildfire. Be sure to check them out.


There's always a lot of discussion internally about who does a good job with online "product tours." We've found many different ways to illustrate key product features as I'm sure you've experienced, too. Some have video clips, some are animated, others are a list supported by screenshots (sometimes they're text-only).


For Wildfire's new product tour we were inspired by Atlassian's approach. We think they do a good job of rolling features up to simple, easy to understand ideas and then do just enough explanation of each feature to be compelling without overkill.


We'll be evolving these more (next: Our upcoming Community product release) and would love to know who you think does a good job with product tours.


[ Atlassian's approach.||Wildfire's New Feature Tour][ Atlassian's approach.||Atlassian's Confluence Feature Tour]

[]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!

Spark Going Open Source

Posted by matt Jun 5, 2006

We're very pleased to announce that the Spark instant messaging client is being released as Open Source. The press release discusses some of the reasons for the license change, but I wanted to provide additional perspective.


In the almost two years since we made Wildfire (formerly called Jive Messenger) Open Source, we've seen tremendous excitement and growth around the server. There's a huge community of peers answering one another's questions, and an active pool of developers contributing integration code, plugins, and performance optimizations. The combination of Open Source with an open standard (XMPP) is powerfully different in the EIM space; we wanted Spark to be a part of that platform. Spark and Wildfire already work great together, and that will only improve now that they're on the same Open Source footing.


Obviously, Jive Software is a company and there's a business model behind our efforts. We believe that a strong Open Source platform with innovative commercial extensions is the best approach for our customers. In the next several weeks, we'll announce the counterpart to Spark going Open Source -- a commercial solution to address many of the features that enterprise customers tell us they need.


Finally, a note about the actual release process of the Spark source code: if possible, we'd release it all right now. Unfortunately, there's a long to-do list before that can happen such as removing commercial library dependencies, changing source code headers, etc. The whole process took us about six weeks when making Wildfire Open Source, but we're hoping Spark will go a bit faster. We'll keep everyone up to date on our progress in the Spark forum.

Filter Blog

By date: By tag: