3 ms·

When we initially started development, the application directly synced with GitHub. Turns out, to accurately reflect the current state of Issues on GitHub, you

by kogir 9y ago

When we initially started development, the application directly synced with GitHub. Turns out, to accurately reflect the current state of Issues on GitHub, you need to poll multiple resources per repository every minute, in addition to subscribing to hooks (hooks alone don't cover everything). Even if those requests are all 304 Not Modified responses, they add up in size, number, and time. Furthermore, some views, like Issue details, actually require tens or even hundreds of requests to refresh completely. The server component can quickly make needed requests in parallel over a reliable, high bandwidth, low latency connection. Then, once the changes are known, the server streams them down to the app as deduplicated, compressed, incremental changes. This allows the application to sit idle, using essentially no CPU, network, or battery resources. It's unfortunately the only way to provide a good user experience.

TheTon 9y ago
Not to contradict what my partner, kogir, is saying here, but I think the benefit, as a Ship user, for subscription pricing goes even further than any discussion of the server. Imagine that a future GitHub API v5 is perfectly suited to the feature set and user experience that we want to offer with Ship. That's great, now we can happily delete our server. But, GitHub itself is a subscription service that is not a fixed target. They routinely introduce new features and APIs, in fact nearly weekly [1]. Our app is only valuable as long as we provide utility to you beyond what you get by just using github.com. When GitHub adds a new feature, and your collaborators start using it, if it isn't usable in Ship, then Ship now has negative utility compared to loading up github.com in your browser. This isn't just hypothetical either -- we do a lot of work to keep up with GitHub's pace of development. Imagine you sign up today and then 2 months from now GitHub makes a change that substantially reduces the utility you get out of Ship, or Nick and I go out of business. With the current subscription pricing, you will have spent $10 for 2 productive months with the app, and you can go back to using GitHub in a web browser with no downside, because Ship (intentionally) doesn't have any lock-in. Now contrast that with a model in which we ask for $70 up front for Ship. I think this is not unreasonable considering the pricing of standalone dev tools of similar utility (for example, consider fancy diff tools like Kaleidoscope [2] or Beyond Compare [3]). As I'm sure you know, most indie Mac software has a sales curve that starts off with a big spike over the first week or two after a release and then it trails off pretty sharply. That's fine for an offline app, but I hope you can now see how the subscription pricing model is a better fit for Ship, both for us and for our users, given the large surface area and fundamental nature of our integration with GitHub. [1] https://github.com/blog/category/ship https://github.com/blog/category/ship [2] https://www.kaleidoscopeapp.com https://www.kaleidoscopeapp.com [3] http://www.scootersoftware.com/shop.php http://www.scootersoftware.com/shop.php

by kogir 9y ago

TheTon 9y ago

Not to contradict what my partner, kogir, is saying here, but I think the benefit, as a Ship user, for subscription pricing goes even further than any discussion of the server. Imagine that a future GitHub API v5 is perfectly suited to the feature set and user experience that we want to offer with Ship. That's great, now we can happily delete our server. But, GitHub itself is a subscription service that is not a fixed target. They routinely introduce new features and APIs, in fact nearly weekly [1]. Our app is only valuable as long as we provide utility to you beyond what you get by just using github.com. When GitHub adds a new feature, and your collaborators start using it, if it isn't usable in Ship, then Ship now has negative utility compared to loading up github.com in your browser. This isn't just hypothetical either -- we do a lot of work to keep up with GitHub's pace of development. Imagine you sign up today and then 2 months from now GitHub makes a change that substantially reduces the utility you get out of Ship, or Nick and I go out of business. With the current subscription pricing, you will have spent $10 for 2 productive months with the app, and you can go back to using GitHub in a web browser with no downside, because Ship (intentionally) doesn't have any lock-in. Now contrast that with a model in which we ask for $70 up front for Ship. I think this is not unreasonable considering the pricing of standalone dev tools of similar utility (for example, consider fancy diff tools like Kaleidoscope [2] or Beyond Compare [3]). As I'm sure you know, most indie Mac software has a sales curve that starts off with a big spike over the first week or two after a release and then it trails off pretty sharply. That's fine for an offline app, but I hope you can now see how the subscription pricing model is a better fit for Ship, both for us and for our users, given the large surface area and fundamental nature of our integration with GitHub. [1] https://github.com/blog/category/ship https://github.com/blog/category/ship [2] https://www.kaleidoscopeapp.com https://www.kaleidoscopeapp.com [3] http://www.scootersoftware.com/shop.php http://www.scootersoftware.com/shop.php