Eagle-eyed readers from the development mailing list will notice a flaw in my title. The latest Elgg (the one you can now download from Subversion, which will be available to download as Elgg 0.6 at the end of the month) uses a standard database library and can switch to Postgres out of the box; other database engines are possible with a bit of tweaking.
Nevertheless, it’s true that for over a year the Elgg software has been rooted in Apache, PHP and MySQL, and it’s very valid to ask why. A lot of people are using Microsoft IIS, for example, and have solutions written in ASP.NET or Java – languages perceived to be more stable, or less “hacker-ish”, if you will. Java is considered by many to be an enterprise solution, while PHP is not.
Highly customisable and cost effective
Just as our ethos dictates that a user’s account is their personal space, an institution’s installation is their personal community – it needs to meet those exact needs, not the shrinkwrapped average of all users. Therefore, we needed to create something that was highly customisable and cost effective. Education isn’t a market flush with money, and what budget there is often comes from the taxpayer. In all honesty, we’d rather that went to actually educating people; although we envisioned that people would be able to hire a cost effective developer to install the software and make changes for them (which of course they now can as per the standard open source business model), we also wanted them to be able to do it themselves as easily as possible if they had the expertise.
Open source software is the best solution for public services, education included. The Open Source Definition is essentially a manifesto for free (as in speech) community-driven software that aims to benefit its users. Loosely speaking, it offers similar freedoms to projects like Wikipedia (as recently discussed by Chris Sessums):
- Freedom to copy
- Freedom to modify
- Freedom to reproduce
- Freedom to redistribute modified versions
If Elgg was open source, not only could it be modified, but people could share their modifications with other people who might find them useful. If users collaborated and shared information, costs would be cut and efficiency increased further, and the software would more closely fit the needs of its users over time. We planned – and implemented – a plugin-orientated software architecture to support this, and this is why we’re being very careful about what features we allow into the core Elgg. It’s much better to have a stable core and a selection of plugins that people can add on than to have a vast core, which becomes unmanageable and inevitably incorporates system overheads, or worse, seventeen different versions of Elgg. If there’s one small, core Elgg with a plugin gallery, updates and bugfixes can happen quickly and all users reap the benefits of the open source community, while allowing for different requirements and features between installations.
A web application doesn’t work by itself. You need the server machine, which will have its own operating system and web server software. You also need a language interpreter to handle the dynamic scripts that power the application. Finally, you need some kind of storage system to handle all the dynamic data that users produce, for which some kind of database server is the most suitable (although not the only solution; we could have written and read XML files, for example). While we were in favour of the open source model, we also wanted to ensure our technologies would work with existing IT infrastructures rather than idealistically advocating a fully open source environment.
There are many solutions for all of these problems. So why did we pick the ones we did?
The popular scripting language has inauspicious beginnings, having been created for the programmer’s personal resum