Wednesday May 07, 2008
Thursday Jun 14, 2007
By jtb on Jun 14, 2007
All software groups were given the task some time ago to go open
source. Sun can tell the direction the wind is blowing. Many interesting open source projects have resulted from this effort, including the Glassfish application server, the OpenDS directory server (a 100% pure-java LDAP implementation), and OpenSSO. No one (well,
that huddled masses at least) is sure Sun will be able to capitalize on
this, but they are plowing forward full steam nonetheless. It's not that there isn't a plan, but no one is sure if the work of building an open source community will be rewarded in sales of products based on the project's code --- rewarded enough to offset the cost of building the community. We will see.
For Sun's Portal Server product, the mechanism to go open source was not clear. It essentially came down to two options: 1) throw what is there over the fence, or 2) re-architect the product and release it into open source as smaller projects. The product team initially went in the direction of option 2. There are many reasons for this, but in a nutshell the existing code base is, for lack of a better word, monolithic in nature. We (the Portal Server product team) didn't feel that option 1 would be a good for community building, as the large, interdependent code base would not promote understanding and therefore contribution.
Now, (external) contribution and community are not requirements for open source. It is perfectly valid to open source code and not build a community around it. This is probably not what people think of when someone says open source, and it is distasteful to software developers, but it does count as open source. If nothing else, it allows existing product customers to look into the code to understand how the product works.
For some parts of product, option 2 went ahead as planned. The portlet container, WSRP, JSF-portlet bridge, and portlet repository projects were all spawned from the closed-source Portal Server code. But until recently, the bulk of the code still existed inside the firewall.
A few months ago we came to the realization that option 2 would not yield a complete open source portal for some time, as modularizing the product is quite a daunting engineering task. So, we entered into the option 1 fire drill. In early June, the Portal Server code base was committed to the OpenPortal project. OpenPortal is now buildable and installable outside the firewall, and will be the code base for Portal Server version 7.2 and beyond.
Mainly due to some legacy C code, there are some rather nasty restrictions on building. And, it still has a dependency on the Sun JES stack up to Access Manager.
We haven't given up on option 2, the complete
modularization of portal, but we will be undertaking it in bits and
pieces, working from the OpenPortal code base. It will happen in the
open. A side affect of modularization will be a lighter-weight portal with an easier, more flexible installation. I won't be happy until I can install on OSX.