Groupware (part 2)
Dec 3rd, 2004 by Aaron Louie
Like any good systems librarian, I should probably figure out a few things before suggesting a groupware system. You know, little stuff like…
- Why do we need groupware anyway?
- Who are the stakeholders?
- Who are the end users?
- What do those users need?
- How are they meeting those needs now?
- What constraints (technological, budgetary, etc.) are we working with?
I should also know the who, what, where, when, and how of this project and its possible implementation. In a large library with tens of thousands of users, all this should be figured out by a task force. The committee should ideally be made up of:
- representatives of the end users (staff)
- someone from Administration
- someone who does computer training/support in the library
- someone who’s studied the organizational problems in our library
- someone from Systems (like me)
This process should be typical in any major IT project in a library. At this point in our process, it’s not clear whether we’re really going to commit to a groupware solution. To gauge need and interest, we’ll set up a prototype system as a “straw man” and present it to the administration. If they feel it’s worth spending time and money on, we may form a groupware task force to figure out which vendor meets our needs. The task force would need to write up an RFP, schedule demos by the vendors, collect proposals, evaluate proposals, etc. etc.
But first, let’s just focus on selecting our “straw man” prototype. Like I said back in my first post on this subject, I’d like to create a feature comparison table to track which system does what. Unfortunately, most commercial groupware vendors are less than forthcoming about the specs of their systems in order to protect their intellectual property. Thus, we’ve decided to evaluate open source packages only. An added benefit is that we can really get into the guts of open source systems and figure out how they’re built.
Our development server is running Linux and PostgreSQL, and our university’s authentication service is LDAP-compatible. We also need a system that is being actively developed (i.e. updated in the last year). Any system that does not meet these minimum requirements is ignored.
So, without further ado, here’s the resulting groupware comparison matrix (Excel spreadsheet). You’ll notice that the vendors are sorted according to the number of results in a Google search. It’s a rather arbitrary metric, but it’s useful for seeing how popular (or controversial) a system is [Credit goes to Bill for this idea]. Although there was no clear winner, the system we will probably go with is phpGroupWare. It’s lightweight, supports a good number of critical features (PDA syncing being the most critical) and has the added bonus of running under Apache, so we don’t have to run another server environment.
[Update 12/21/2004]
Well, after playing with phpGroupWare, I’ve decided it’s too unstable and disorganized to implement. Plus, recently discovered security vulnerabilities make me wary of considering it as an option. I’ve decided to play with PHProjekt instead. There’s a possibility the PDA syncing could be made to work with it. Maybe…