I actually agree with you completely: at this point you'd just assume that text editors would be free.

That said, I work faster in ST2 than I did in Emacs and I can very quickly repay its purchase price in increased productivity. Should ST2's author get hit by a bus tomorrow and every copy of ST2 in the world instantly stop working, I could go back to Emacs and still have benefitted from having ST2 in the mean time.

Suppose someone offers you a golden goose that earns you $1 an hour but costs $100. If you get your $100 back out of it before the goose dies, you've broken even. If you get $101 out of it, you've turned a profit. If you get $500 out of it, you've made a good investment. I've already made my money back on ST2. If I lose the use of it, I've still come out ahead.

Let me be clear though that I wasn't talking about price. Rather I was genuinely surprised to learn that it wasn't open source, perhaps because so many of the top editors are, because of its persistent popularity in these circles and its dalliance with open solutions, and because I would expect someone starting a new high-end text editor today to want to put the project on solid long-term footing, which to me implies open and community involvement.

It's pretty interesting to see that I'm still getting down-voted for posts that I think, at this point, do a fairly reasonable job of communicating their point, do it in a civil manager and pose a legitimate question re: expectations of the use of the open source paradigm in certain kinds of software.

I wonder if it's really just because I'm saying something negative about a popular piece of software, and people exercise the downvote purely because they disagree rather than have quality objections?

I've just upvoted the downvoted entries to try to counteract this. The downvotes were not deserved in my view. Nevertheless, as I noted in a commend a couple of months ago, they still sting: http://news.ycombinator.com/item?id=3422539

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.