I think I have mentioned Picok before on my blog. This is a system that lets users arrange and configure a number of portlets in order to be able to keep themselves up to date with what's going on in various web applications, similar to iGoogle and netvibes. The difference is of course that this system is entirely open source, so companies can install Picok in their intranet and give Picok direct access to all sorts of internal applications that they could not make available to iGoogle or netvibes. What makes this project all the more exciting is that this system was initially developed as a closed source application for the Raiffeisen bank in Switzerland. This was the first time for me, where I had the opportunity to be part of open sourcing such a large chunk of code.

One of the things we open source proponents mention as a plus point for open source is that developers do not easily get away with taking short cuts. All the internal ugliness is there for the world to see. Well I do take a lot of pride in all the code I develop and I am particularly thankful to Liip that they give me the opportunity and time necessary to write good code without the usual time constraints that come to later haunt customers. However you do take shortcuts, mainly because of various assumptions you can make about the setup. If you know and are able to closely define the server on which your app runs, you can of course safe a fair bit of time not coding for the general case. That is of course in the best interest of the client.

Now when I went to install Picok for the first time at a customer location, I realized just how many such assumptions existed in the code. I also began to realize how much knowledge is really stored in all the config files. How much our system relied on how Apache was setup in terms of file permissions and such. I also learned the hard way that before open sourcing, you should write a script that checks these assumptions. With the latest release of Picok we have a first step in this direction.

Another challenge that we had to meet was how to make it possible to support various client specific customizations. Raiffeisen is actually very forthcoming with letting us open source code. However there are several things in the system what we simply could not easily generalize. For example there are a number of features in Raiffeisen's version of Picok that are totally dependent on their corporate structure. Some of these we have stripped down and generalized. For example Picok can also work with a local user database instead of the external Lotus Notes user management system used at Raffeisen. They also have a few portlets that are based on internal closed source systems. In some cases they needed minor modifications to the Picok portlets. For example the currencyconverter portlet uses a free service to get the exchange rates. Raffeisen however wanted us to use their internal data source instead. All these customizations can have effects on the core logic, on the templates, on the CSS and/or the Javascript code.

The solution we came up with in the end uses numerous different approaches to make it as easy as possible to easily make Picok features available to the Raiffeisen version, while still making it possible for Raffeisen to pick and choose what they want and of course maintain their own look and feel according to their internal UI guidelines. At the core of this is the use of subversion externals. All the core classes are imported into the Raiffeisen this way. We then extend them in PHP. So while the base class that handles the frontend action methods is called api_command_portlet in Picok, we simply extend this class in the Raiffeisen version "class api_command_raiwebportlet extends api_command_portlet". Through some autoload magic we can automatically load the "api_command_portlet" class from a lib directory. We use a similar approach for the javascript code. With the CSS and translations files we have decided to always just merge by hand using a visual diff merging tool.

For the portlets we decided to go a different route. If we were to extend the portlets if would severely complicate things. Portlets would now have to be named "raiwebfeedreader" instead of just "feedreader". In the case of the command classes, all of this is fairly nicely hidden behind mod_rewrite magic, but the names of portlets are something people directly work with. Of course we could have tried to hide this somehow, but it would have added complexity we wanted to stay away from. So instead we are using "svn merge". Whenever want to add a portlet from Picok into the Raiffeisen version, we use svn copy to "import" the code. From then on, we can always just use svn merge to merge all changes. Of course its possible to just merge one revision at a time, but I usually just merge everything and then fix up any conflicts are changes we dont want to port over. This works very well indeed. One problem though was for "svn merge" to work, things need to be in the same repository and at Liip we usually have a separate repository for open source and closed source code. So we had to add a password protected section in the open source repository for Picok client projects.

For templates we just use the theming support I have added into the HTML extension for OkAPI. This basically works that whenever a template file is requested it first looks in the directory of the selected theme. If the file is missing, the template layer automatically falls back and checks the default directory. In theory the template could then be copied over automatically to prevent having to trigger the fallback a second time, but for now we did not have the need to do this performance optimization. The default directory contains the standard Picok templates. Via CSS we can handle most of the look and feel differences, so there are only a few templates that had to be copied and customized for Raiffeisen.

So overall, most new features automatically become available in the Raiffeisen version depending on what version of Picok I import via externals. I can customize any command since we extend the command classes. Similarly we can overload Javascript logic. I can change the look and feel via CSS or by copying and customizing standard templates. I can maintain totally customized portlets and merge any new features from Picok via svn merge and pick and choose what I want in and what out. So far its working quite well for us, we will soon deploy the first version at Raiffeisen that is based on the the separate Picok source code and with the setup described above it was possible for us to make most of the new features requested by Raiffeisen available in Picok without any extra overhead. Actually since Picok runs on MySQL, which does not require me running SQL Server in a virtual machine (Raiffeisen uses SQL Server), I can develop new features more quickly, since my laptop does not get bogged down as much.

Hi!

I just checked out the demo, and I think this looks great!

Good job!