Since moving to Mozilla, I haven’t had a ton of time to work on Enso, the commercial product turned open-source project that I worked on at Humanized.
One of the things I’ve been learning about at Mozilla, though, has been getting into the habit of writing about what I’m working on. We didn’t do this much at Humanized, at least not until the first few months of 2008 when we started designing openly. I’ve found that this openness is really helpful; just taking a little while to reflect and write out my thoughts forces me to really think through what I’ve been working on, which in and of itself can help untangle myself from the challenges I’m facing and give me a fresh perspective. And the feedback one receives from the community can be even more helpful (as long as one knows how to deal with poisonous people—which, fortunately, I haven’t seen any of yet).
One of the things I’ve been neglecting to talk openly about for the past few months, however, has been Enso. There’s a lot that I’d like to write about, because there’s been a lot going on with Enso. I’m going to focus this post on a basic status report, though, so as to lay out a road map for what I’ll write about in the coming weeks.
A Brief History of Open-Source Enso
Back in December of 2007, I bought a new MacBook Pro, and over the holidays I learned some Objective-C, read about OS X internals and hacked the commercial version of Enso to work on my new computer. This was a lot of fun: Apple’s developer documentation was a pleasure to read, and I found that I really enjoyed programming in the Cocoa framework. And because Enso was built with open-source technologies in mind, getting it to work on the Mac wasn’t that hard; aside from Python, we used Cairo for all our graphics work, so most of our underlying libraries were already cross-platform.
The thing was, in order to get the basics working on OS X, I really had to cut off a lot of Enso’s limbs—in particular, a lot of fault tolerance mechanisms that made Enso such a hassle-free experience on Windows. We spent an enormous amount of time on these mechanisms, which in some sense is part of why Enso didn’t appear to gain many features since its initial launch: much of our time was spent doing things like fixing bugs that occurred on certain system configurations; adding support for Vista and other families of Windows; allowing Enso to be installed and used by a user who didn’t have administrative privileges; supporting better internationalization; fixing issues with the licensing system and our fully transparent auto-update system (prompting the user to update Enso was too inhumane for us, as were existing licensing frameworks); and building a very basic extensibility mechanism. Such things sometimes made us feel like we were really building a whole new platform for software delivery rather than the actual software that we wanted to build.
In other words, we ended up re-inventing slightly more user-friendly versions of the wheel for a lot of things, and that ultimately cost us a lot of time. The end result was what I still believe was a pretty solid and unusually humane product for the Windows platform, but by the time we’d finished doing everything, a lot of the parts of our software that handled the edge cases were quite coupled to Windows—which is to be expected with any software that breaks out of the traditional application paradigm as much as Enso does. While the original architecture of the software was designed with platform independence in mind, the final production version had a number of components that were highly specialized for Windows, and even a few that were only applicable to Windows.
Getting the OS X version to the point that the Windows version was at would’ve taken a very long time. On top of that, Enso’s extensibility mechanism was really basic—because it was only really intended for in-house use, there wasn’t any suppport for features like dependencies or C Python extensions, and packaging extensions was a relatively lengthy and cumbersome process. Power users and Python programmers, our target audience for a young open-source Enso, wouldn’t be very pleased with any of this. The commercial version of Enso behaved much like an application that happened to use a fairly limited embedded Python interpreter; we wanted the open-source version to be more like a Python package that behaved like any other Python package, and worry about the details of packaging things up for grandma later.
So when we open-sourced Enso, we decided to start fresh. This didn’t mean writing everything from scratch, but it meant constructing a new fully cross-platform Enso in the open, moving in code from our old codebase as necessary, and opting for using—and potentially improving upon—existing open-source solutions rather than reinventing wheels when the community decided it was appropriate.
Where We Are Now
The early progress on Enso, which occurred shortly after we open-sourced it, was quite impressive. Guillaume Seguin jumped in and ported Enso extremely quickly—I believe it took only a day or two of back-and-forth emails between us—while Jono DiCarlo got things up and running on Windows and I got the OS X port working. It’s now possible to check out the project, follow the README, and get Enso running on any of the platforms.
Depending on your platform and experience with C compilers, however, that may or may not mean a whole lot. Linux is by far the nicest in this regard: if you’re on Ubuntu or another distro with apt-get, you can just fetch python-cairo, python-gobject, python-gtk2, and python-xlib and you’re done. You don’t even need a compiler.
OS X is the second easiest; in early May, I committed a change that made it so that only SCons and Apple XCode Tools are needed to build Enso. (Previously, the developer was left to their own devices to build a quartz-enabled version of Cairo, which usually involved MacPorts or Fink.)
Windows, as usual, is terrifying. As is the case with creating any Python C Extension in Windows, you have to compile Enso using the exact version of Microsoft Visual Studio that was used to build your version of Python. For Python 2.3, 2.4, and (I think) 2.5, this means using MSVC 2003, which Microsoft doesn’t even sell anymore.
Where We’re Going
Right now we just want it to be possible for people to get, use, and make commands for Enso easily—that is, without having to install a C compiler toolchain.
The first step is to get Enso to a point where we have downloadable, pre-built binaries for all platforms that need it (i.e., OS X and Windows). I’ve already done this for OS X, and will blog about it later. Windows is the place that needs the most help here, though; since all the original core developers of Enso are now on Macs, there’s ironically no one left to dogfood Enso on Windows and make sure that it works there. Any volunteers for working on this would be hugely appreciated.
The next step after that is to create and document a simple framework for writing and distributing cross-platform Enso commands. I’ve written something called scriptotron, currently in the Enso tree at enso/contrib/scriptotron, that I still need to document and blog about, but it’s not perfect. I’ve also got all of the scriptotron commands I’m using from day to day in my HG repository, but I need to document those, too.
Once these tasks are done, we should be able to introduce Enso to the Python community.