How open source is losing the charity battle was posted today on ZDNet Australia. There’s a quote in there from my colleague, given during her presentation at the ConnectingUp conference. Here’s the paragraph:
Even organisations that have embraced open source urge restraint. Philanthropy Australia used the open source MediaWiki software platform built for Wikipedia to help centralise its knowledge resources in a wiki format. “Nearly all our software is open source which works really well for us, but I always caution people that there’s a cost in terms of the time and expertise needed,” said communications and knowledge manager Louise Arkles. “While it has saved us a bit of money up front, there are costs involved.”
I tend to agree with Louise - much as I love open source software, as with all use of tech, don’t forget to take into account the human resources needed to make it work - be that time or expertise. I’ll elaborate on the open source software we use here at the PB, and why:
Our file server is based on Debian
Debian is an open source operating system. Not being a sysadmin, I can’t say much about it myself; it’s managed by our IT firm. One of the good things about Debian is that (and apologies if my terminology/explanation is shaky here, to reiterate: I am no sysadmin) it can come bundled with other open source software including MediaWiki and Wordpress. The down side of this, in my experience, is that sometimes upgrading that additional software can be problematic - what version of Debian you are running will influence how you can stably run the additional software, or take the risks of doing a potentially unstable “backport” if you want the latest version of, say, Wordpress, which is not included in the version of Debian you’re running. Again: skill needed to administer an operating system, and more time/skill to build a backport to manage those upgrades, if you want to do them.
For email, we use Zimbra
Zimbra is browser-based email software that functions just as well as (and looks pretty similar to) Microsoft Outlook. One of the main reasons we took the advice of our IT firm in going with Zimbra was because we needed shared calendaring that would have required an expensive change on our network otherwise. It’s really handy for those staff who work out of the office frequently, and even those who work interstate - being browser-based means that for the technophobes, their email always looks and works the same no matter where they’re accessing it from: very handy! We’ve had few problems with it. Our install, and our email server, is again managed by the IT firm. The software is free, but we pay them to make sure it’s operating efficiently, upgraded, fixed, etc. That it’s browser-based is useful in itself in this case as well - more often than not our IT support can fix the problem remotely, and the problem is usually something to do with the server - i.e. we pretty much never have email problems due to an error on an individual machine. Again, especially handy when our org’s IT support is in Melbourne but we have an office in Sydney.
Our mailing lists are based on Sympa
Much like our email, most of the back-end stuff for Sympa is managed by our IT firm. We’ve been using Sympa for many years, and I must say that our recent Debian upgrade and subsequent Sympa upgrade has made it much easier to use. I am probably too spoilt by Google Groups (which, being web-based, we can’t really use - we need something that we can host on our own servers in order to properly control/maintain), but I find Sympa a bit clunky in terms of its interface. I am sure there are ways to make it less so, but I have not looked into it; we’re currently working with our IT firm to build Sympa into our communications database to make it easier to manage (and avoid some double-handling).
The PhilanthropyWiki is based on MediaWiki
Here’s where my big love for open source comes in. When I’m not at my day job, I’m hosted with DreamHost, who have very handy “one-click installs” - robots that set up MySQL databases and install open source software for you (they have a selection available, including MediaWiki, Wordpress, Joomla and more). Again I manage to avoid that pesky sysadmin stuff, but have managed to teach myself a fair bit about customising my install - enough that at the PB we came in considerably under what we’d budgeted to spend on that project (in terms of work done on it by our IT firm). Pretty much all we ended up paying for was for our IT firm to install the software on our server, give me SFTP access to the install folder so I could modify the LocalSettings.php file and add extensions myself, and make the occassional change to the database that I requested.
That said, it did require a lot of time and skill from me to get it to where it is now, and my time here does = money, so. That said, I am somewhat MediaWiki-mad, and run several wikis based on it, the PhilanthropyWiki being my only work-related one and probably the least modified and with the lowest traffic. So for a while there, my days were very much 24/7 developing and populating wikis (okay, maybe not 24/7, I did sleep occasionally - and dream about wikis). So basically what I’m saying is that yes, we did most of it ourselves, but I don’t think that I am a particularly common human resource for a nonprofit organisation to have. So again: free software, not-so-free skills and time to set up and manage it.
(Related: If you’re interested, a while ago I put together a MediaWiki Resources Post.)
The philanthropyOz Blog is based on Wordpress
As with MediaWiki, Wordpress is another piece of open source software that I have extra-curricular experience with, having used it as a platform for many blogs, podcasts and small websites over the years. So I am quite familiar with customising it - both in terms of tweaking code or adding extensions, and skinning it to make it suit a brand. I’m also familiar enough with the software that I know how to use it most effectively for our needs. The blog is currently the only bit of the PB that uses Wordpress, but in the pipeline I am working on two sub-sites that are also both based on WP. They are currently a bit stalled for the problem with Debian that I outlined above - I need to upgrade to a later version of WP in order to have all the features I require to make these sites work, but in order for that to happen we have to get our IT firm to either build a backport of a later version, or upgrade Debian entirely - which, though the software costs us nothing, does have a labour expense to it.
That’s it for our main open source software (of course we use other free online tools during the course of our work - like Google Reader, Google Analytics, del.icio.us, Feedburner and more). But I will include some honourable mentions as well:
We have Windows XP OS and Microsoft Office on all our machines thanks to DonorTec - The only glitch with the process of obtaining ‘free’ software (i.e. about $10 a piece) via DonorTec was that we had to do some negotiating because we don’t have DGR status. Otherwise, we saved thousands of dollars in the process of our software upgrade (done en masse to make sure we’re all on the same OS etc).
Philanthropy Australia’s main website is not built on a CMS - It’s built from scratch with XHTML and CSS, and managed with Dreamweaver. This is mainly because it’s the first thing that I did when I started doing the PB’s ICT, and that’s what I knew how to do - write websites from scratch. It works well for us, I think - the site, its look, feel and structure, is custom built for our needs, easily modifiable and expandable. There is no cost for our IT firm to manage software (open source or not) to run it, however, because it’s managed with Dreamweaver’s templates, it can generally only be managed with Dreamweaver - with which there is a cost associated.
Our Communications Database is custom built, not off-the-shelf - Our IT firm developed our communications database, and we’ve recently revamped it with much success, during which we worked closely with them to get it exactly how we want it. While this is not the cheapest way to go, it’s most definitely the best for our needs, as we have very specific relationships with our constituents that we need to keep track of and often facilitate through our database. So this solution definitely serves us better than to buy an off-the-shelf option, pay our IT firm to modify and administer the software for us, and the no doubt double-handling etc that would result in it not being able to serve our needs specifically.