Lately there has been a healthy amount of press surrounding Novell's support and expanded resource contributions to JEMS (JBoss Enterprise Middleware System). There are several links I have archived in our Wiki regarding this. I won't go in to the finer details of how this affects JBoss or Novell as entities, or what the nature of the partnership brings to the OS community as a whole. I feel it is obvious to everyone that this is great news for both participants and the community as a whole.

The JBoss Portal community's, and my, specific concerns with the partnership, and one I will address here, is Novell's contributions and support of the project I work on, JBoss Portal. I believe the concerns are warranted. The OS community has always been skeptical of large corporations having a role in the development of OS projects. Religious philosophies and corporate paranoia over the hijacking of a project are probably at the root of these concerns. The questions that are voiced in private emails to me and forum posts, universally have the same underlying concerns, and I will address them all here.

Before I address these questions/concerns, a short background on the JBoss Portal project. Trust me, it'll help put things in perspective.

Background

When speaking about the JBoss Portal project, I am often forced to go even farther back and address our former JBoss Nukes CMS project. This is where it all began for us. Frankly, I see more and more CMS's converting over to the portal space and implementing the JSR-168 spec, as we did. This project was started by Julien Viet several years ago. It is what currently powers the JBoss.com website, and is a port of the popular OS Post-Nuke PHP project. Under the hood, it is essentially a CMS with an assortment of modules plugged in to it (forums, downloads, FAQ, etc..). Once the portlet spec was final, we made the decision to implement it. We then approached the ubiquitous CMS "fork in the road" where one has to decide whether to implement the JSR-168 Specification inside our existing Nukes CMS or start from scratch. For licensing and various other architectural reasons, we (ok, mostly Julien - Portal project lead) decided to begin anew. In hindsight, this was a wise decision that ended up saving us hours of development work and screaming bouts of frustration.

Over the past ~8 months, the project team along with community contributors, have worked hard on a scalable, flexible, and feature-rich JSR-168 compliant framework. Practically nothing of the old Nukes-CMS remains, with the exception of our Forums. We loved our message boards so much, we just had to "portletize" them and plug them in. ;-) We have made great strides in this time, with a Beta release announced recently at JBoss World, an RC planned for early May, and a Final Release in early June. (w00t!)

The portal team, employed by JBoss Inc., is made up of three developers... ok, now two. One of us ran off recently with the jBPM crowd and Sir Gavin King to work on other things that will later materialize in to a stronger Portal. Where there were 3, now there are 2. Luckily we have a vibrant and growing community willing to poke, prod, and extend the portal framework. Heck, they go as far as making it do things we never envisioned it doing... the wonders of OS software. ;-)

Enter Novell

So at this moment in time, we were faced with only 2 full-time developers working on the portal project. Considering the highly competitive nature of the portal space, I had some reservations. Before I could open my, rather large and un metered, mouth I was approached by someone with "Vice" in their title within JBoss, Inc. as to the prospect of having Novell work on JBoss Portal alongside the existing team. I knew Novell had their own portal software for years in development/production and was curious to see what it is they wanted with our, at the time, Alpha Release of Portal. After all, they were farther along than us. Perhaps it was my OS-corporate-religious-paranoia talking, but I brushed it all aside and opened my eyes/ears to what the Novell team had in mind.

We had a conference call with their portal team several months ago. They walked us thru their own portal software and we got to meet the brains behind it. I got a good sense at the time they had thoroughly evaluated JBoss Portal's architecture and played around with it enough to feel confident in merging teams, skills, and disciplines. They sounded like they were ready to jump in to the fire with us immediately.

I was still skeptical. The initial meeting left me with more questions than answers. One of them and the one asked most frequently to me,

"Why doesn't Novell just keep developing their own existing portal software?" The answer is simple, and unabashed, I asked the same question to one of their developers at JBoss World. The short of it is that Novell wants to focus on their core competency.. application software development. Its a wise move on their part. They stick to developing application software that plugs in to a portal framework, and they don't have to worry about the tedious and developer-expensive tasks of maintaining the framework. So they come to the table with some extremely bright and experienced portal developers, aid us in building out the core, and the rest of their team works on portlets that fuel their own business. It is a great use of resources and a great coupling of disciplines.

So once satisfied with Novell's reasoning behind the partnership, the next obvious question is, "What specifically will Novell do for JBoss Portal?" The short answer is that they will bring several key components that were already on our existing roadmap to fruition long before we envisioned them being implemented. These are:

• WSRP
• Theme API
• Installer
• Additional Portlets

So they are essentially accelerating our time-to-market for important features on the existing roadmap. The additional portlets they are bringing along with them are going to be open-sourced under the LGPL license. They will probably not be bundled with the main distribution, but offered as downloadable and categorized portlet packs. How/when they will be offered is still being discussed. We are targeting the Theme API and Installer for our Final release. They will likely be in our RC due out in early May and undergo extensive QA testing along with everything else. WSRP will not be available until post-Final-Release of JBoss Portal 2.0.

The above, outlines their contributions to the 2.0 release. Future enhancements, aside from WSRP, are still in planning and will be addressed on our public roadmap.

I've been asked a few times by JBoss Portal community members if we fear a large company, namely Novell, hijacking the development process for their own financial gains. This is a purely symbiotic relationship. I have found that all of us in the portal team have the same goal in mind... to offer the best, scalable, flexible, OS Portal framework to the public. Frankly, any paranoid delusions I had in mind have been quelled since I've begun working with the Novell team. On a personal level, they are great to work with. On a professional level, they are extremely bright and eager participants willing to pick up any and all tasks put before them on our roadmap. Corporate press releases tend to leave these sorts of details out, and that is why I embarked on this blog article.

So where do we go from here?

I only see great things coming from this partnership. The Novell portal developers are bringing years of experience in developing their own portal software and lending a hand with JBoss Portal. I feel grateful to be part of this project. After months of hard work, I see a quickly exploding community, wide acceptance and adoption, and a feature-rich and stable product that's fit to have the JBoss brand attached to it. In the end, the Novell contributions will only help to accelerate our growth-path and solidify the JBoss Portal product.

Stay Metal!

-Roy-