5 ms·

Thanks! Yeah, I've looked at warp.dev. Funny story: I heard about them from Daniel Martí, aka mvdan, the author of the shell library I'm using. It looks reall

Thanks! Yeah, I've looked at warp.dev. Funny story: I heard about them from Daniel Martí, aka mvdan, the author of the shell library I'm using. It looks really neat, though I confess I haven't explored it much; dogfooding, don't'cha know. :) I felt a little threatened by them but also weirdly encouraged, since they got $50M in funding. It made me think that hey, somebody thinks a new experimental shell/terminal is a viable commercial product; why not mine? Also, Warp is pretty expensive by comparison (for teams of 6 or more, anyway; granted it's free for 5 or less). Yeah, getting people to switch will be difficult, especially since most terminals are pretty rock-solid as far as their actual ncurses emulation, and mine still has some rough edges. I'm hoping that I can at least get a few happy users and go from there. Thanks again for the kind words!

pvg 3y ago
somebody thinks a new experimental shell/terminal is a viable commercial product; why not mine? I'm glad people are working on these although as you say yourself, commercial viability is tricky. I like the non-SaaSyness of this but then I'm still left with having to: 1. change my shell 2. change my terminal 3. but not on Windows 4. rely on a single person for bugfixes, security issues, features 5. pay $40/yr for the privilege None of these things are individually an insurmountable hurdle but they add up to a pile of friction. In the words of sales theorist J. Winnfield, "Well we'd have to be talkin' about one charming motherfuckin' pig".
- gabrielsroka 3y ago
  Say "what" again! I dare you! I double dare you!!
- LarryClapp 3y ago
  All of that is fair and I appreciate the comment. Hmm. #1 - I could fork an instance of bash for every command instead of using an internal interpreter. I've shied away from that because it adds an extra layer of complexity, and also on the theory that if you're trying something that hucksh can't run by itself, then you should probably write a stand-alone script anyway. But perhaps as an option it'd help ease the transition or make people more willing to try it. #3 - A Windows version is possible. Hucksh has worked there in the past. I think my hurdle there is a build error on Windows in one of the libraries I use. It's probably one of those things that when I actually look closely at it, it'll take an hour to fix, but so far I haven't. More fool I, perhaps. I also shy away from Windows a tiny bit because it's not my primary platform (macOS), or even my secondary platform (Linux), and the Windows file system structure (with drive letters and so on) requires different code. On the other hand, a Windows client talking to a Linux server would cover a big use-case. #4 - If enough people buy it, I could hire other people! ;) I realize that doesn't make it any easier to be an early adopter. #5 - Would you care to speculate on what you think is a fair price? Also, based on your other comment, I've added a discount code for 90% off (HN-1223).
  - pvg 3y ago
    I don't think there's anything 'unfair' about your price, it's just something I don't want to have to think about yearly for a shell/terminal. One possible workaround is longer term licenses (especially promotionally to early adopters) or a different paid upgrade cadence. I think the fundamental problem to me is similar to that expressed by some of the other commenters - a vague sense of unease with using a closed source shell/terminal combo. That's much harder to overcome than paying for a shell/terminal combo. Of course, getting reasonably compensated for open source work is an even trickier problem.
    - abeyer 3y ago
      > a vague sense of unease with using a closed source shell/terminal combo. That's much harder to overcome than paying for a shell/terminal combo. Of course, getting reasonably compensated for open source work is an even trickier problem. I actually see them compounding... either one alone isn't great, but combine them and you're left with a tool that can be rug-pulled out from under you at any time for any reason. OSS with some monetization gives you a fallback of maintaining it yourself, while commercial non-OSS with a perpetual license at least means you can keep using an old version as long as you can manage. Commercial subscription software is at best ephemeral, and not something I'd invest (time, money, transition effort, etc...) in without a strong fallback option, and even then the benefit offered has to be pretty impressive to overcome those switching costs.
      - LarryClapp 3y ago
        > commercial non-OSS with a perpetual license at least means you can keep using an old version as long as you can manage That's what hucksh has. Today's license will work with today's code (and code released in the next year) forever. Sorry if that was unclear.
        abeyer 3y ago
        Oh, ok, that's at least more reasonable. Thanks for clarifying. (and for using such a license) Not really unclear, now that I look closer, I just saw the annual rate and hadn't actually clicked through to the license/pricing details and assumed that to mean a typical SaaS subscription model. (it's cool and all, but not a fit for me based on the direction you're going.)

pvg 3y ago

somebody thinks a new experimental shell/terminal is a viable commercial product; why not mine? I'm glad people are working on these although as you say yourself, commercial viability is tricky. I like the non-SaaSyness of this but then I'm still left with having to: 1. change my shell 2. change my terminal 3. but not on Windows 4. rely on a single person for bugfixes, security issues, features 5. pay $40/yr for the privilege None of these things are individually an insurmountable hurdle but they add up to a pile of friction. In the words of sales theorist J. Winnfield, "Well we'd have to be talkin' about one charming motherfuckin' pig".

gabrielsroka 3y ago
Say "what" again! I dare you! I double dare you!!
LarryClapp 3y ago
All of that is fair and I appreciate the comment. Hmm. #1 - I could fork an instance of bash for every command instead of using an internal interpreter. I've shied away from that because it adds an extra layer of complexity, and also on the theory that if you're trying something that hucksh can't run by itself, then you should probably write a stand-alone script anyway. But perhaps as an option it'd help ease the transition or make people more willing to try it. #3 - A Windows version is possible. Hucksh has worked there in the past. I think my hurdle there is a build error on Windows in one of the libraries I use. It's probably one of those things that when I actually look closely at it, it'll take an hour to fix, but so far I haven't. More fool I, perhaps. I also shy away from Windows a tiny bit because it's not my primary platform (macOS), or even my secondary platform (Linux), and the Windows file system structure (with drive letters and so on) requires different code. On the other hand, a Windows client talking to a Linux server would cover a big use-case. #4 - If enough people buy it, I could hire other people! ;) I realize that doesn't make it any easier to be an early adopter. #5 - Would you care to speculate on what you think is a fair price? Also, based on your other comment, I've added a discount code for 90% off (HN-1223).
- pvg 3y ago
  I don't think there's anything 'unfair' about your price, it's just something I don't want to have to think about yearly for a shell/terminal. One possible workaround is longer term licenses (especially promotionally to early adopters) or a different paid upgrade cadence. I think the fundamental problem to me is similar to that expressed by some of the other commenters - a vague sense of unease with using a closed source shell/terminal combo. That's much harder to overcome than paying for a shell/terminal combo. Of course, getting reasonably compensated for open source work is an even trickier problem.
  - abeyer 3y ago
    > a vague sense of unease with using a closed source shell/terminal combo. That's much harder to overcome than paying for a shell/terminal combo. Of course, getting reasonably compensated for open source work is an even trickier problem. I actually see them compounding... either one alone isn't great, but combine them and you're left with a tool that can be rug-pulled out from under you at any time for any reason. OSS with some monetization gives you a fallback of maintaining it yourself, while commercial non-OSS with a perpetual license at least means you can keep using an old version as long as you can manage. Commercial subscription software is at best ephemeral, and not something I'd invest (time, money, transition effort, etc...) in without a strong fallback option, and even then the benefit offered has to be pretty impressive to overcome those switching costs.
    - LarryClapp 3y ago
      > commercial non-OSS with a perpetual license at least means you can keep using an old version as long as you can manage That's what hucksh has. Today's license will work with today's code (and code released in the next year) forever. Sorry if that was unclear.
      - abeyer 3y ago
        Oh, ok, that's at least more reasonable. Thanks for clarifying. (and for using such a license) Not really unclear, now that I look closer, I just saw the annual rate and hadn't actually clicked through to the license/pricing details and assumed that to mean a typical SaaS subscription model. (it's cool and all, but not a fit for me based on the direction you're going.)