GLAMkit’s dirty secret

What is GLAMkit?

Glamkit is the base code we use for museums and arts organisations in need of a Content Management System (CMS). It’s particularly useful for museums as it includes features to handle events and exhibitions. We’ve recently used it to bootstrap projects such as:

• The National Gallery of Australia
• The Factory
• Bathurst Regional Art Gallery

Glamkit uses among other things, the web framework Django (which we love!) and the Content Management System (CMS) Wagtail. For more information about Glamkit, read our article "GLAMkit is dead. Long live Glamkit!"

In short, Glamkit is our internal CMS with prebuilt features that let visitors complete tasks such as “finding events happening in the next 7 days”.

The secret

Glamkit isn’t a library, it’s not “modular”, not extensible, not “micro”; also it’s definitely not “corporate-ready”... We – shame on us – copy-paste Glamkit and change the code at the start of a project! Yes, you’ve read it correctly, we do copy-paste code; a whole chunk of code. Basically, Glamkit contains code that is similar in most projects - but code which is never exactly the same.

Copy-pasting code, you must be insane

Apparently, at the IC, the owner is not the only person with a weird brain. We have decided together on the copy-paste approach. It is the least worst option we’ve found.

A possible alternative is to have one big library and reuse it in every project. This approach presents two major problems. Firstly, an update in this library would impact all our projects. More importantly, making it extensible (i.e. customisable) would take a lot of effort. We would have to define what are the core-common features, what’s extensible and how. For Django developers, picture lots of abstract models to extend correctly and various beloved mixins and configuration files.

Another possible solution is to make many external libraries. We would have one for each Glamkit feature: one for the EventPage with their scheduling, one for the Exhibition pages, one for our logo wall, and another 20ish. Now, what happens to the common CSS styles, do we split it into 20 libraries or is that library 21? What about small utilities common to these libraries? Multiplying dependencies and maintaining them wouldn’t be worth the effort. Furthermore, the exact same issue remains: making these libraries extensible would take a lot of work.

With a copy-paste, we don’t have extensibility issues. We can just change the pasted-code. With a copy-paste, we don’t have update issues, we can change what’s in Glamkit without having to worry about the current projects. The changes are only for future projects.

The only drawback with that approach is that our projects do not take advantage of GLAMKit updates. While this is true, in practice, it hasn’t been an issue so far.

We are not copy-pasting everything

Glamkit itself has a bunch of dependencies. These include the aforementioned libraries Django and Wagtail but also some of our own internal ones. These libraries are NOT copy-pasted.

We only copy-paste code that we know is 90% likely to change. For example, the event-pages, while they are always similar, always have slightly different fields. Their templates are always different. We offer an out of the box solution for scheduling event occurrences. That code is always changed to work with or be replaced by an external platform like Tessitura, Spektrix, etc.

We tend to update Glamkit after every large build. When we do, we focus more on things to remove from it than things to add in.

When appropriate, we will take parts out and make them external libraries.

To sum it up, Glamkit contains code which is better off being copy-pasted than externalised. That approach seems to defy best practices - and yet - we are very happy with it. Kudos to Mark and James who both put a lot of work at the start of the project.

Random thoughts on “best practices”

When you work in IT, it’s quite common to hear: “it’s best practice”. That “argument” cuts off any discussion. It shouldn’t; the most important part of any best practice isn’t the practice itself, it’s the reasons that lead to it. In other words, why is more important than how.

Circling back to the copy-paste topic. Copy-pasting is mostly considered bad practice because of code duplication (duplicating bugs and security issues) and potential licensing issues. The latter doesn’t apply in our case; the code we duplicate is our own (and we give it to our customers for their project). The code duplication doesn’t happen within a project; it happens in between projects. This is exactly why we only duplicate code that we are very-likely to customise.

In the particular case of using Glamkit as a bootstrap project, copy-pasting is not bad-practice after all.