48. On Planetary in 2020: curatorial activism and open sourcing in service of digital preservation

This was originally going to be posted on Medium but my frustration over whether it would be accidentally paywalled means I’m publishing it here instead as a public post. As a bonus, all you regular newsletter readers get to read it too. Think of it as a (as we might say down here in Australia in the 1980s) “a Clayton’s newsletter episode”. [The real #48, now #49, will be out soon!]

Perhaps the most experimental aspect of Planetary’s acquisition was the fact that the museum released the source code online with an open license, allowing anyone to copy the code and modify it and adapt their copy to suit their interests. The intention of open-sourcing the code was to open the door to passionate fans of Planetary so they could aid in its long-term preservation and maintenance.

As one of the two former Cooper Hewitt staff behind the original acquisition, I read last year’s preservation report from consultant conservator Ben Fino-Radin on Planetary with interest. Little did I know that 12 months later, now in 2020, Kemal Enver, an iOS developer in Sydney would resuscitate the software.

Bloom’s Planetary was an early iOS App made to take advantage of the specific affordances of the iPad in the early years of its release in 2010. It was a piece of consumer software downloaded by somewhere in the order of 7 million iPad owners. It differed significantly from other items in the Cooper Hewitt’s collection by the fact of its comparatively mass consumer use, and that it was contemporary consumer software. Ben Cerveny from Bloom LLC talks about this shortly after its acquisition as part of the curatorial documentation.

The rationale for open sourcing Planetary at the time of acquisition was indeed to ‘open the door’ but the assumption was not necessarily that those ‘fans’ would immediately appear. A handful of people with iOS programming experience did appear, examined the codebase, asked questions, and then got stuck — but this was not the sole reason for open sourcing.

The longer term value of open sourcing the code, rather than inheriting the default closed source model (which is the case with almost all software acquisitions into museum collections) also lies in clarity that it provides for future generations. Source code licensing is left alone in most acquisitions for many reasons — sometimes the creators are unable to see the longer term value of open sourcing; or licensing requires navigating a thicket of rights owned by third parties; others, especially artists are concerned about their code being seen as being too ‘scrappy’ and ‘unprofessional’; and at other times the acquiring curator is not able to conceive of possible future re-use or imagine changing future models of scholarship.

During the acquisition process of Planetary, substantial work was done with Smithsonian’s General Counsel and the developers formerly Bloom LLC, to enable the open sourcing which has overall benefits for future preservation activities. The generosity of the developers and their efforts to prepare the source for release cannot be underestimated. By defaulting to open source at the time of acquisition means that future presertvation or presentation activities, emulation or other efforts cannot be stymied in the future by more conservative legal counsel, curators, or conservators at the museum. 

This is especially important for commerical, consumer software. We have seen in recent years the public release of the source code of Adobe Photoshop and early versions of many other other consumer software packages by the Computer History Museum. But also we seen that other significant computer software packages kept alive only through hobbyist communities with little enthusiasm from collecting museums to intervene. The recent release of the source code of Infocom’s legendary text adventure games of the 1980s is an interesting case of a source code ‘abandonware’ — whilst Activision current owns the licenses for these games, they have stopped making them available to the public — and their source code cannot easily be compiled by contemporary computers (the release of that source code did result in ZILF, a set of tools for working with the Infocom source code).


The first I knew of Kemal Enver’s work on Planetary was an excited message from Aaron on a friend’s private Slack. And there it was, live on the AppStore — Planetary Remastered. I got in touch with Kemal, not aware that he was based in Sydney. I was really curious as to how he came across Planetary and what he had done to bring it back to life.

SC— How did you first become aware of Planetary, I know you said you used to use it on an old iPad back in the day?

KE - I first heard about Planetary about 10 years ago. At the time I didn’t have an iPad, but I remember seeing it on a friend’s. About one year ago, a new acquaintance found out that I was an iOS developer and asked me if I had heard about Planetary. He told me that it was his favourite app of all time and that he was really disappointed it didn’t work anymore. He still had an old iPad with it installed, and was so excited when he fired it up to show me. He told me the code had been open sourced (he had tried to run it himself) and asked if I had any idea how to fix it — and that’s when I decided to investigate further.

SC — How did you become aware of the Planetary Github repo?

KE - After my friend mentioned it was on GitHub I took a look at the repo. I cloned the repo, fired up Xcode and was greeted with a sea of red errors and yellow warnings!

SC — Did you know that the repo was part of the Smithsonian’s design museum in New York, the Cooper Hewitt? Did you have any idea of what Cooper Hewitt was or did?

KE - When I saw the repo, I noticed it was part of Cooper Hewitt, but didn’t really look into it much more. Because there were so many problems with it, I told my friend that it was probably irreparably broken and that he would need to find a new app. Over the next few months I opened the code every now and again, and also found a couple of mentions about how it had been donated to the museum, but I didn’t know the full story.

SC — How did you approach resuscitating Planetary? How useful was the source code and especially the versioned codebase?

KE - When I first opened the project and saw how broken it was, I didn’t have much hope. So much had moved on since it had last been touched that I thought it would be next to impossible to fix without rewriting large pieces of the app (if not all of it). The first approach I took was to attempt to get the app running in an older version of Xcode, but unfortunately the version of Xcode it was written in no longer opened on my Mac — so I gave up on that.

One of the main things to fix was setting the compiler to the correct C++ dialect and standard library, and ensuring that the code would work with the Apple Clang compiler. Since Planetary’s original release, Apple had changed the compiler from GCC to Clang.

Another big update was setting the correct architectures and moving to 64 bit rather than 32 bit.

After that, I experimented with the various versions of Cinder to find one that would work with the latest version of xcode. I ended up settling with 0.86 since the 0.9x versions had changed a lot of things and would require considerable reworking of the app. As well as updating Cinder, I also had to find a compatible version of Boost.

In general when it came to trying to find versions of dependencies, my approach was to look at the year of release and match it up to the repo’s last updated time. I’d then find the closest version of that library that was compiled for 64 bit architecture etc. I wanted to avoid having to compile and update old libraries. Planetary’s problems were considerable enough! The whole process of finding libraries and updating settings was trial and error, and it took ages to find the right combination. Though, once I achieved this, the number of errors in the project dropped drastically.

At this point there were a few compiler errors in the project code — mostly related to touch handling and texture loading. After I avoided those (by temporarily commenting out code) the project compiled with no errors and I finally felt like I was getting somewhere.

The first time I ran the app and saw the loading screen was a great feeling — until it crashed almost instantly. At that point I realised I was only a small way along the long road to fixing it.

The next steps involved finding what was causing the crashes. I resorted to a lot of break points and a detailed study of the threading to investigate what was happening. I then removed the background processing for texture loading. My rationale was that modern devices would do this quickly — so the need to offload it to another thread wasn’t necessary from a performance perspective, and would allow me to avoid a lengthy and time consuming fix. After I did that, and fixed several other crashes, the app continued past the loading screen.

At that point I could see the galaxy view, but gestures weren’t working due to the commented out code! I could control the app to some extent by changing songs in the Apple Music application. From this point I needed to get touch working again, and this wasn’t so simple. I think the version of Cinder I was using was different to the original one used, so I was resigned to having to redo touches completely. Version 0.9x of Cinder was vastly different, so I ruled it out. At that point I left the project for a few months because I didn’t have the time to continue working on it, and documentation about how touch handling works in Cinder was hard to come by.

Fast forward a few months and COVID-19 arrived. 

My hours at work were reduced and I decided to resume work on Planetary, and try to complete it. My instinct was to attempt to recreate everything elegantly, but after some attempts with that mindset, I thought ‘what can I do to just get this working in its original form?’ At that point I bypassed some of the nice abstractions the original team had built, and instead started to directly forward touches to where I thought they should go (in areas of the code that still worked). This took a couple of days, but touches started to work. At that point Planetary was pretty much back.

Over the next few weeks, I fixed any remaining crashes I found. I enabled iPhone support, and fixed problems relating to that platform. Some of the fixes weren’t pretty. For example, on modern iOS devices there is no home button, and instead the operating system shows a home bar over the screen. This really messed with the app’s aesthetic so I found a way to remove it. Ordinarily this is a simple matter of 1–2 lines of code, but because the app was built with a framework that abstracts a lot of the core iOS classes (i.e. view controllers), this was a tricky process. I would have had to make changes to the version of Cinder I was using and recompile it. I didn’t relish that task. So I decided that I could hook into some existing Objective C++ code (orientation node) and use that place to ‘swizzle’ an iOS View Controller function. The swizzled version called the line of code I needed to hide the home bar when the app first rotated. That was enough to hide the bar on launch.

Overall there were many small things to update and address, the combination of them was overwhelming at first. But chipping away over time, and small successes kept me going. Some things got let go in the process like the gyro controls and orientation handling. Some things didn’t seem necessary to fix, such as the flurry tracking library and code, but most of the original features were kept.

I didn’t really use the versioned code. The most up-to-date commit was already vastly out of date and I guessed that anything older would be even worse! I did investigate some of the older commits though to get a rough idea of what had been happening.

SC— When did you become aware that what you’d done was actually quite significant?

KE - When I posted my tweet in May 2020, and put a comment on GitHub with an app link, I started to see some activity. I had no idea anyone was still interested in it, and I’d posted it more in hope than expectation. It was great to see that the original developers, the museum, and people who used the original app, were excited it was working again.

SC — Now that you’re aware of some of the history of Planetary and how it came to be open sourced and preserved by the Smithsonian, did this change how you are thinking about the future licensing of the work you’ve done on it?

KE - The history of Planetary’s creation is fascinating and quite a dramatic story. I’m thrilled that I could be a part of that history. I’ve recently made a Pull Request back to the original repo, so hopefully that will be merged back soon and anyone else who is interested will be able to download and run it. Now that it’s in a working state, it may encourage others with the requisite skills to pick it up and improve it.


As Aaron Cope and I articulated in our original acquisition statement to the Cooper Hewitt’s Acquisition Committee, more used to being presented stable, physical objects that they could (carefull) touch, hold, and visually examine, 

The underlying source code would enable the future exhibition of the object as a work in stasis, but also the exhibition and demonstration of the underlying interaction and experience design principles and models upon which it is based 

The release of the source code was also implicitly about asserting that design history and the practice of software studies are intertwined. This was, at the time (2013), part of the new Cooper Hewitt brand and mission as it focussed on reopening a new museum. This was a focus on design process, more than than the decorative arts and the products of design.

Our quip at the time was that this acquisition bore more likeness to keeping a species alive in a zoo rather than as a lifeless object in a museum warehouse.

We liken this situation to that of a specimen in a zoo. In fact, given that the Smithsonian also runs the National Zoo, consider Planetary as akin to a panda. Planetary and other software like it are living objects. Their acquisition by the museum, does not and should not seal them in carbonite like Han Solo. Instead, their acquisition simply transfers them to a new home environment where they can be cared for out of the wild, and where their continued genetic preservation requires an active breeding program and community engagement and interest. Open sourcing the code is akin to a panda breeding program. If there is enough interest then we believe that Planetary’s DNA will live on in other skin on other platforms. Of course we will preserve the original, but it will be ‘experienced’ through its offspring.

If it was not obvious at the time of acquisition, Planetary’s entry into the Cooper Hewitt (and broader Smithsonian) collection was a purposeful act of curatorial activism, to force a broader re-evaluation of collecting practices that favour material objects over fluid, unstable, software.

Planetary Remastered is not Planetary. It is a new piece of software that isn’t so much ‘forked’ as reconstructed. There’s a discussion in the Github repo happening about how to preserve Kemal’s changes - which have, at their root, the question of whether Planetary Remastered is a new ‘object’ or not - and in some ways, Cooper Hewitt will be grappling with a Ship of Theseus conundrum. To take the metaphor of the panda, this is a new baby panda. Panda breeding is notoriously tough, and in ‘museum time’, 7 years to a viable offspring should feel like a win.

Planetary Remastered can be downloaded from the AppStore.


See also: 

Chan, S., Cope, A., 2014, "Collecting the present: digital code and collections." MW2014: Museums and the Web 2014. Published March 19, 2014. 

Cope, A., 2014, “Objects in the mirror are closer than they appear”.

Chan, S., 2013, “Planetary - Collecing and Preserving Code As A Living Object”, Cooper Hewitt, Published August 26, 2013.

Cooper Hewitt Labs blogpost with a 2013 press roundup of articles on the original Planetary acquisition.