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.

Sounds great, and I will definitely look into the developer stuff when I get used to this Mac stuff… until then, and speaking of which, does this mean that an ‘official’ downloadable version of Enso for OSX is imminent?

I wouldn’t say “imminent” exactly, but certainly sooner rather than later. I predict it will probably be the next big thing we announce.

Congrats for this awesome move, Enso rocks and will rock more than ever now :)

Yay! Free beers for you next time you come to Gothenburg! (or wherever we happen to meet).

Congratulations. But, what is now your business model?

Now this is something amazing. I can only say one thing: thank you. I’m sure this is for the best of the project and the future of computer user interfaces. Can’t wait to hack on the Linux version.

I applaud this move wholeheartedly! I like Enso better than Quicksilver and was having Enso Envy on my Mac.

Will the Humanized folks still be leading the charge on Enso? I think what makes Enso great is its attention to user experience, something that open source projects aren’t particularly noted for in general.

Cheers, y’all!

I don’t think people should have to create a user name to be able to post in the forum. I like the way it works here in the weblog.

In response to Sp, who asked
“What is now your business model?”

This news story should answer your question.

Thank you for the answer. I wish you the best of lucks.

But, like Mike asked: Will the Humanized folks still be leading the charge on Enso? or are leaving it adrift?

The news story doesn’t say what will happen with Humanized, and what is the business model of Humanized and Enso, independently of the executive team.

Sincerely,

Spencer

haha! BSD FTW!!

Enso Rocks! :)

A little bit bored this blog. I am disappointed.
Enso can be a great product. One that truly changes the way we interact with computers, even more than sophisticated surfaces and/or multitouch technologies (without taking their obvious merits and great expected future).

Lets continue with great ideas, investigating, benchmarking competing products.

Humanized, please don’t leave Enso adrift.

I think Enzo will be the most be used in the desktop and in the Web, too.. Go Humanized .. the net will eb one day humanized ;)

Enso on OS X? Yes!!!
Quicksilver just aint my thing - you guys are the only ones who understand (:

Just tried Enso, but decided that it’s not there yet and went back to Launchy. Figured you would like to know why. For reference, i am using windows xp.

First off, using the capslock key is a brilliant idea, mainly because i just plain can’t remember using it at all in any context. However, i’m also using Synergy, to control my laptop via my desktop’s keyboard and mouse, which is where the problems start:
1. Enso doesn’t recognize the caps lock key over the synergy connection.
2. I can use the ctrl key, but as that triggers on [key-down] and no on [key-up without any other key pressed since key-down], it is impossible to perform essential tasks like ctrl+a and using alt, will probably block alt-tab.
3. I also cannot define any combination, like ctrl+space to circumvent that.
4. I just plain don’t like quasimodal mode as it slows down my typing too much, tried sticky mode. That doesn’t work well however, as leaving sticky mode without performing an action requires me to press esc. A more natural behavior would be to toggle off via the call-up short-cut.

Visual:
Not bad, stylish, fast. However I’m missing customizability here as well.
1. Switching off opacity would be neat.
2. Same for rounded corners.
3. Same for animations.
4. the hattrick would be if switching those off would actually result in less CPU/RAM being used.

Uninstalling it leaves config files behind. Combined with an extremely odd and for me, straight-out disgusting, install location, this is not very nice behavior.

Hope this provides you with some useful input.

P.S.: Dropping this here, since your Contact us form is broken.

Thank you!

I contacted Humanized some months ago requesting a Linux version. I am happy you have finally decided to make one! Any hints on a time schedule for the first release?

I hope that ENSO Launcher will integrate nicely with both KDE and Gnome. ☺

Amazing move. I’m looking forward to parting my developer prototype extensions to the BSD version!