I can definitely relate; I was somewhat discouraged that it wasn't open source, and was somewhat resistant at first. It would have more value to me that way.

I can definitely relate; I was somewhat discouraged that it wasn't open source, and was somewhat resistant at first. It would have more value to me that way. I paid my $60 and I would easily pay another $60 if he'd open it up :). So I understand that its proprietary nature is a cost and a risk, but it's important to keep that cost and risk in context. For me, there are two mitigating factors. (1): It's actually really, really good. It is hard to overstate this. As I am writing this I realize that I am shilling pretty hard for this product, so I should say I have no financial interest in helping the author succeed :). I am giving you this sales pitch as someone interested in the well-being of my fellow developers. If you spend your days staring and typing into a text editor, you owe it to yourself to give Sublime a serious shot. After two decades of Emacs, Vim, and Eclipse, the level of quality and polish in Sublime, even in the "beta", is almost shocking. It's not perfect, but there are aspects of it which will make you wonder why you ever put up with the obviously broken behaviors and terrible performance of (your favorite editor here). In particular, I should note that you can really get exactly the key-mappings you want on every platform, so you don't have to change your habits too significantly; it doesn't have any strange reserved keys that are hard-coded to behave differently on different platforms (I'm looking at you, Eclipse). After a few months of using Sublime, Emacs's weird, chunky, jerky scrolling, slow plugin-loading at startup, and constant pauses for GC seem like pointless self-punishment. Eclipse's patina of UI widget detritus looks distracting and confusing. And Vim's slavish adherence to the character grid and grating scriptability limitations (no way to perform timed or background tasks, random segfaults when changing buffers from certain contexts) will look dated and pathetic. (2): Perhaps more importantly in terms of the amount of energy you might need to invest: although Sublime itself is proprietary, the API is actually reasonably narrow, and there is a ton of open-source Python that has grown up around it. So, if the Sublime Text core were to implode tomorrow, and you had a significant investment in a ton of plugins, you could bring the interesting bits over from your Sublime setup to Vim (via its Python bindings) or Emacs (via Pymacs) or Eclipse (via PyDev for Eclipse's Jython scripting bridge). Perhaps someone could even write a compatibility API that provided Sublime's Python API on those editors. In fact, I had made a conscious decision a couple of years ago to stop writing ELisp and VimScript and start doing as much of my personal editor customization in Python, and that really paid off when I moved over to Sublime; my custom habits and automation were mostly there already. Had I been going from Sublime rather than to it, wrapping the underlying API to do something sensible in Emacs or Vim would be a lot easier than trying to turn my ad-hoc eval()'d turds of elisp and vimscript into something same. I was pretty surprised that I like Sublime so much. I am pretty finicky about my editor; I spend tons of time customizing it and adding on to it and scripting it and automating things. Since my initial burst of making Sublime behave like the parts of Emacs I care about, though, I've had to tweak it far less than any of my previous experiments, and I really got to know all the editors I've used in the past pretty deeply. My suggestion would be to get it, use it, love it, and just send the author a friendly note saying that, as a paying customer (rather than a random Internet troll), you'd love it even more if the source were available under a friendly license.