When we began the project to build a new Student Information System (SIS) one of the first questions we asked ourselves is whether to write something for internal use or whether to try and engage with other schools to see if there was scope for building something together as a collaborative effort.

The latter approach carried a number of burdens and risks. We chose the most widely available technology platforms (PHP and MySQL) in order to appeal to the widest possible pool of developers while trying to at least avoid the mess that many PHP projects can become by using the CodeIgniter MVC framework, I built a website here at nextsis.org and started an open source Github project, and spent a lot of time talking to people around the world about what we were setting out to do.

I strongly believe in the idea of schools coming together to create their own educational software solutions because we have had really poor experiences with software companies with their commercial agendas and design inflexibilities, and I know this is not uncommon with my counterparts within the school community. However, we do face an inherent disadvantage in such endeavours, namely that we have day jobs which only afford us so much time to engage in longer term projects such as this one.

At the beginning of this academic year we thought we were in a more fortunate position than most because we believed we had the time and resources to build the new system we envisaged, which is why we stepped up with our nextSIS proposal. Two things happened. We didn’t succeed in building the small network of developers we had hoped to despite our efforts, and I was called upon to write a complete grading and reporting solution for my school when the external vendor that we believed was going to provide this didn’t do so. This latter development is an extremely long and sorry story, which is not likely to be told in the foreseeable future for legal reasons.

The grading module within our existing open source SIS was not remotely suitable for our needs, so I replaced it with our own for first quarter reports in November. For this I integrated Twitter Bootstrap into the aforementioned SIS, and used FPDF to generate the reports. But it was the full Semester 1 reports which quickly became the focus once this was done, as it culminated in the production – visually at least – of 50 separate data entry screens and 8 PDF documents comprising a total of 53 pages in our Elementary School alone and an additional – but thankfully smaller effort for our Middle and High School. Once the grading exercise is complete, the student report PDFs are to be automatically emailed to parents – from a Windows server, which turns out to be much more difficult.

Having to work on our existing student information system at the expense of investing in the future by building its replacement has been frustrating, but it is not a wasted effort for nextSIS because it has provided valuable insights into user acceptance of new interface designs in addition to technology I am likely to integrate into it. However, it also carries with it some hard lessons about the fractured nature of student reporting – even within our school which now has three significantly different report formats. How can we rise to the challenge of providing something which can meet such diverse needs in one system?

We are certainly behind schedule because of these unforeseen circumstances, and going forward we will always find ourselves beholden to the difficulties of working within a school where sudden demands to solve more immediate problems can take our focus away from building a better software future. But while we are far behind where we wanted to be, and I would have to concede that our hopes of launching a first version in August appear increasingly remote, we have to get where we are going, so our goals are unchanged and we will continue to do the best that we can – both for ourselves and for the wider community who have expressed interest in this project.

We’ve now uploaded an initial framework to GitHub based on CodeIgniter with Twitter Bootstrap. The code displays a login screen and token homepage if the access to the system is granted, so it’s really for the interest of developers just to see where we are heading. Mostly it’s about the underlying structure of the PHP code rather than the HTML – so the interface design is simplistic and it hasn’t been tested across the various browsers yet.

CodeIgniter – and recruiting developers

We had some serious second thoughts about the choice of CodeIgniter after talking with interested parties about the nextSIS project, because during the course of these conversations it’s become apparent that it – or any framework for that matter – is a potential problem to to its higher initial learning curve. The project probably seems more accessible if developed in plain PHP, and this is probably more aligned with developer experiences in the education sector.

Despite this, we’re pressing ahead with using the CodeIgniter framework, because in the longer term we believe it will lead to a more structured and therefore maintainable system, and arguably it provides a more productive development environment.


The passwords in the database are salted and hashed based on SHA-256, but later the plan is to increase this to SHA-512 or Blowfish via bcrypt or scrypt with key lengthening.

Multiple language support

The default language for the application is English, but Korean language files have been added for testing purposes. Currently, the language can be set by changing the associated value in the config.php file. We’re actually storing these in text files as per CodeIgniter’s language class, which might seem like a throwback to older times given that we have a database at our disposal, but it helps avoid database thrashing which can otherwise occur when every text item on multiple network screens is being read from it.


We’ve chosen GPL3 for the nextSIS license – and the selection was a major headache because the issues involved are emotive and raise a variety of both philosophical and practical questions about what is trying to be achieved. We wanted to ensure a company couldn’t take the code and incorporate it into closed-sourced systems which are sold on the market, which some open source licenses would allow. Our choice comes out of an unhappiness with education software vendors.

Recently we’ve been looking at SchoolTool and it raises a couple of interesting questions, namely (a) why can’t we use it, and (b) what can we learn from its design and data model? OK, maybe that’s three questions depending on your view of AND statements.

SchoolTool version 2 is very good, and all other things being equal we think you should probably be using it (version 1 is a whole other story but that’s history now). It lacks features we need, such as admissions functionality, and that’s a sticking point for us, but it is open source so in principle we could amend it – and this is the crux of our problem: viable extensibility.

SchoolTool is built on Python which is OK, it uses Zope which moves us a little off the reservation, and in turn for its database it uses ZODB, which is not really OK for us, because what these three things represent are a progressively steeper learning curve and consequently more dangerous subsequent production environment. Even if we went through the learning curve, given what some people think about ZODB, MySQL seems like a case of it being better the devil you know, than the devil you don’t.

What this highlights is the question of what is ‘normal’. The SchoolTool has gone down a route of tying their software into Ubuntu – which is not surprising because it’s developed by the Shuttleworth Foundation, as in Mark Shuttleworth, as in Ubuntu. And it really is ridiculously easy to install – if you have Ubuntu. You’re on your own with anything else though because it’s doubtful whether it can even run on a Windows server, and it’s certainly not supported. Running it remotely becomes a little more complicated as well because it uses its own server.

We really need something running at our school that another programmer and system administrator could seamlessly take over the development and maintenance of, and that’s not going to happen with ZODB, especially in South Korea. What that means for the nextSIS project is that we’ve made a conscious decision to ignore the tools the cool kids are using this year, and stick to PHP and MySQL, which are not sexy, but you can run it on basically anything, and you can find people with the skill set relatively easily. We’re aiming at the mainstream – and at normality – such as it currently is.

It pains me to not be able to just use SchoolTool because of its technology platform, especially as I’m writing this at home on my desktop running Ubuntu, but if I set up an Ubuntu server at my school and have all their data on it, and then something happens to me, they are potentially left with a server they can’t support (I’m the only Linux person there) – in a country where IT companies are considered adventurous if they know how to run a browser other than Internet Explorer on Windows. The choice of technologies is a real problem to us.

Database technology aside, SchoolTool’s data model is interesting in that at the interface level SchoolTool it appears to present a very transparent view of it. Essentially you have People, Groups, Courses, Sections (actual class periods), Terms and Timetables – and People are an entity. This differs from the preconceived idea that your entities in a student information system are actually Students, Teachers, Parents and so on, but it highlights the fact that database normalisation is an inexact science – sometimes you have to be a little pragmatic in trading off normal forms and efficiency, and sometimes it’s a matter of perspective in the first place.

The data model decisions made for nextSIS at this stage will likely define the system permanently and we’re having a serious rethink about our preconceived notions of what our entities are, because while SchoolTool uses an object rather than relational database, insofar as you can still model the former as the latter it does highlight an alternative approach which can carry significant implications.

For example, a number of our teachers have students at our school and are therefore also parents, but if teachers and parents are separate entities in the data model, at the design stage you’re left with one person being two very different things in the system – perhaps to the point of not being able to associate a student with a parent because they that parent in is your system as a teacher. In fact, this is how things are with namelessSIS, where the only solution appears to be for a teacher to have a separate user name as a parent in order to associate them with their children. Whereas, of course, if people were just people, then the logic is that one person (a student) can be designated as the child of another person (either a parent or teacher or anyone else), and a person has a one-to-many role, which can mean them being both a teacher and a parent.

The example where you have to create separate logins for teachers who are parents is actually easy enough to overcome in principle within the logic of a program, but it does perhaps set the program somewhat at odds with the data model, which is why the data model question is occupying a lot of time here at the moment.