I've been involved in the organisation of a number of scientific conferences over the past few years. For example 4m/ICOMM 2009 (submissions), I*PROMS 2009 (submissions). The conference sites are usually powered by drupal, the submissions using OpenConf. Managing the submission and peer review of papers is a chore, unfortunately, as is often the case, software gets in your way. So here I try to skim over some of the experiences I had with OpenConf - the good and the bad.
I've tested indico, which looks like a very good system, but it is heavy and over-engineered, especially if you want to run a couple of events, and not hundreds or thousands. It might be good for organisations managing a big number of events, but not for us.
After going through a number of trials I've settled on openconf. It was simple. It fitted the current web infrastructure - LAMP. I reckoned, I could eventually integrate it, or simply transfer some of the data into drupal, and maybe even benefit from code reuse. Surprisingly, I ended being both pleasantly surprised and not so.
It was an interesting experience. Openconf is a strangely written software. It is quite hackish, in a bad way. Inside it uses quite a lot of cryptic names, virtually no code documentation or useful comments, etc... A lot of 'bad style' code. The system won't win a beauty or security contest - that's for sure.
What won me over, and I will probably use it again, is that it is trivially moldable to my requirements. Let's give a few examples.
Well, it has very little significant markup present. Minimal, considering some of the monstrosities I've seen over the years. To personalise the look of the submission pages I had to modify three nearly empty files - the header and footer php scripts for some limited wrapping markup and the openconf css file. That's all. Ok, that was sufficient to modify the overall styling, so that it is consistent with the conference 'mother sites'.
Conference systems are not automatically adaptable to your workflow. You usually adapt your workflow to your system. They are not unique in this respect. A lot of enterprise CRM, workflow whatnot systems force you to adopt what they consider good practices, but that is a rant for antoher time - it makes good business for a lot of people. In this respect openconf is not unique - it presumes a workflow, and it even uses terminology which was alien to us.
The first thing to change was the terminology. An afternoon of reading code and testing resulted in a handful of scripts to replace advocates for theme chairs and some such. Annoying, sure, but not that hard.
A sequence of happy coincidences, helped with other problems, for example how do you check if authors revised their papers after review and if not send them a reminder email. I was prepared to check the file modification times and filter by date. Doable, but would result in some strange looking sql queries. Instead, due to publisher requirements, I ended checking for file types, and getting the list of forgetful paper authors that way. Funnily enough, the email.php file is contains both the best and worst of the code in openconf. The emails and recipient kinds declaration is fairly declarative. Just an array of definitions with stuff like titles, and sql queries in there. And based on your choice and php name magic you get the appropriate template, for which the appropriate list of recipients is pulled from the db. Nice. To make matters even better, it is a long flat file of if .. else .. statements with a few function declarations in the middle. It took me a while to get used to that. But for all its ugly insides, there is something good - it is easy to add modify the markup. No over-engineered templates - the system doesn't really need that. These cosmetic changes are surprisingly important, since it helped me improve the interface, to differentiate between emails for positive, negative and other causes - no wrong emails afterwards.
For one of the last conferences I had to add scripts to make all paper authors reviewers, do custom reports etc.... It was a couple of days of work, mostly testing and reading code. And only one file to modify - the one where I had to add a link to the new functionality. All that required very little modification. Just add the new functionality.
The end is nigh
To wrap it up. Even badly written software could end up being more useful in practice than a number of well written, carefully designed systems. I have a feeling that this is the story of a lot of php projects, and the language itself. Could it be that the beauty is in the eye of the beholder? Or maybe the authors guys know something I miss - because the software does do the job, maybe not brilliantly, but good enough to be re-used again and again.
What makes openconf so moldable? Probably the php "component" architecture, that is each different kind of page has a different entry point php script, with shared includes for code reuse. This meant I wouldn't break more than one page at a time. Which in turn can lead to task based modifications, which in turn made my life easier, despite occasional the surprises.