Thursday
6 Mar 2008
Enso is Open Source!
Our Products Software Development
You can’t spell “opEN SOurce” without “ENSO”. An amusing coincidence, but appropriate, since from now on Enso is free-as-in-freedom as well as free-as-in-beer. This means anyone can download the source code that we use to build Enso. Anyone can read it, modify it, build Enso from it, and redistribute it to others. We’ve chosen the revised BSD license. This is among the least restrictive licenses, giving you the right to do basically whatever you want with the software; read the link to find out the details.
What does this mean for you?
The opening of the source isn’t going to have any immediate effect on the way Enso works for users. For now, the free Enso installers are remaining unchanged. Users should continue to download those. If your only interest in Enso is as a user, then you can say “Enso is open source now, that’s neat” and go on to the next thing in your reading list. Or check out our brand-new forum. But if you’re interested in how software is made, then keep reading…
Why are we doing this?
For Enso to have a chance of becoming the universal tool that we envisioned, it has to be compatible with an ever-expanding number of applications as well as providing an ever-expanding number of commands. For instance, there’s a program called GVim; Enso’s text-selection commands are currently incompatible with GVim because the latter has a unique way of handling text selections. A few users have complained to us about this, and while we’re sympathetic, we’ve had to pull a Spock and say “The needs of the many outweigh the needs of the few” as we focused the limited resources of our 4-person development team on getting the most popular commands to work with the most popular applications. The closed-source development model limits what we can do. It doesn’t scale well to the problem of an ever-expanding number of applications and an ever-expanding number of commands.
Now that Enso is free software, the needs of the many don’t have to outweigh the needs of the few, because “the few” now have the ability to help each other out. The frustrated GVim user no longer has to beg Humanized to fix Enso to work with GVim: he can edit the source code to make the fix himself. Not only does he solve his own problem, but by contributing his fix back to the Enso source code, he solves the problem of all GVim users. In this way, Enso will have a fighting chance of keeping up with the wild-and-wooly world of third-party application compatibility.
Similarly, Enso should be available on all platforms. Windows needs the most help, it’s true. Yet our most often requested feature is to have Enso run on the Mac, and we get quiet a few request for Linux as well. We couldn’t do it with only 4 people, but with your help, we as a community can.
And by opening the source code, we’ll make it much, much easier to write your own Enso commands and share them with others. We’ve read your complaints about the Enso Developer Prototype, and we agreee — it’s too hard to use. Its design was hampered because user commmands had to be separate from the closed-source Enso core, with the Developer Prototype acting as a bridge between the two. But now that the source code is open, there’s no more need for this bridge: you’ll be able to write your own commands using all the same tools and APIs that we Humanoids use.
I’m not a coder. What can I do?
In our push to be more open, we’ve started a a discussion forum. We’ve had some good discussion in the comment threads on our weblog so far, but as many of you have pointed out, the blog comments don’t give you any way to start a new discussion of your own. The forum does. What’s made our blog so valuable is the the community’s discussions. Now you guys can bring it to the next level!
I’d like to direct your attention to one discussion topic in particular. I’ve started a thread of common Enso problems and their solutions. Since we made Enso free, we’ve been getting so many tech support emails that we haven’t had the manpower to respond to them all. I hope this thread will help to close the gap by providing an additional place to get tech support. If you’re having problems with Enso, please check it out. You may find the answer you’re looking for already there. Even — and especially — if you can’t code, you can help out by answering other people’s questions and getting the those people new to Enso up to speed.
Where’s the code?
(The rest of this article is unavoidably technical. Read on if you think you might have an interest in working on Enso and/or developing your own Enso commands.)
We’re using Google Code to host the public infrastructure for this project. If you’re interested in helping us out with development or just in taking a look at the source code, that’s the place to start. You’ll need to have Subversion installed in order to check out the Enso code. To learn how to build and run Enso, consult this README document.
Additionally, we’ve set up an Enso Developers Google Group to use as our mailing list for development discussions. If you have an interest in discussions of core Enso development, please feel free to join. (The Developers Group is not a place to make feature requests or bug reports — you should take those to the forum instead.)
Where’s the rest of the code?
As you may notice, the code in the repository is far from complete. We decided that since we had to migrate the code from one repository to another, we’d take the opportunity for some much-needed refactoring and code clean-up. So we’re integrating one module at a time from the old codebase into the new codebase.
We could have done this in secret and then opened up the source only after the new repository was complete. But we’ve chosen transparency because we think there’s significant value in letting everyone watch and comment on the process.
In the process of re-assembling the codebase, we’re doing several things that will result in a stronger foundation for future development. We’re eliminating proprietary code that we don’t have a right to share. We’re eliminating some of the large, complex modules that made the old code hard to understand and modify. We’re re-thinking Enso’s concurrency model and memory management system to ensure that it’s even more stable and uses as few resources as possible. And we’re redesigning from the basement on up for portability between operating systems and for easy internationalization.
Mac, Windows, and Linux versions
Versions of Enso for all three major operating systems will have equal billing in the new repository structure.
However, at the moment we put up this weblog post, only one of the three actually has code in place in the repository. Which one? Surprise! It’s the Mac OS X version!
Over the next week or two, we’ll be putting the Windows version into place, based on our existing Windows codebase. And an amazingly helpful volunteer named Guillaume Seguin has already written the core of a Linux version, so we will very shortly have something usable there as well.
If you’re a programmer with an interest in Enso, this would be a great time for you to get involved in the project. It doesn’t matter on which operating system your talents lie: we need help with all three. The best place to start getting involved immediatly is on our mailing list.

COMMENTS
23 Voices Add yours below.