3 ms·
Regarding the pricing model and server usage: A major design goal for Ship is to have everything you see be live. I love it when a colleague updates something
by TheTon 9y ago
Regarding the pricing model and server usage:
A major design goal for Ship is to have everything you see be live. I love it when a colleague updates something from the web, or the app, and I see it instantly on my screen. Receiving real time updates from GitHub requires us to have a server on the public internet listening for events from them.
I also personally care a lot about CPU use and battery life on my Mac, and being able to offload a lot of work to a server is a benefit. Ship needs to consume basically every bit of information that GitHub makes available, and just the overhead of doing the http requests to GitHub is noticeable if you run that locally.
I hear what you're saying about the benefits of a one time purchase app that doesn't require any third party server, and I've spent a good amount of time thinking about how to make that work, but I feel like I'm not able to offer the user experience I want with that model.
- Prefinem 9y agoI completely understand. Realtime is incredibly nice and offloading work does cost, which makes a subscription model required. That being said (and this might not even be feasible from a cost / benefit view of things) but my use case would mostly be opening the app once a day to check for new issues or see what I need to work on next and then past that would be posting comments on issues, etc etc. Realtime isn't really a concern and my response times are the speed of me getting an email and then responding. So, point being, a non realtime / standalone product has value to me personally. Just to give you another perspective. I probably wouldn't be saying this if my company used Github for managing things instead of just my personal projects, in which case, realtime would be very handy.