4 ms·
I concur. However storage is how they plan to make money, so there will need to be a different monetization strategy for BYO storage. As yet I can't imagine any
by DenisM 5y ago
I concur. However storage is how they plan to make money, so there will need to be a different monetization strategy for BYO storage. As yet I can't imagine any.
EDIT:
I think have an idea! Add the S3/OneDrive/Etc support but comment it out. To make use of it one would have to download the source, XCode, compile it, and deploy it. This puts a cap on the number of people who can do that, so you won't end up with everyone getting a free copy. Those people who are able to do it are likely to be asked for advice by their less techy friend, so this is basically free software to key influencers.... Ok, so this does not sound as exciting as it did before I started typing, but maybe this will lead to something...
- vishnumohandas 5y agoSo it's a little more complicated than that. Our API server runs the following - authentication - replication - differential sync - and a few more errands that are necessary for the apps to function The solution to this would be to offer a self-hosted variant where you can plug in your S3 credentials. But like I mentioned else where in this thread, maintaining such a project comes with an overhead we cannot afford right now. Hopefully sometime in the future we will be able to afford the necessary engineering bandwidth.
- barbazoo 5y agoI like how Joplin does it for notes. You authorize them as an application in Dropbox or give them credentials to a S3 bucket. Don't get me wrong. I want to pay for your service. I just have to be able to access and decrypt my files if you had to shut down your service all of a sudden.
- vishnumohandas 5y agoOur pricing model is such that the product can self sustain itself. Also, we have a desktop app[1] that syncs your uploaded data to a local drive, so you don't have to worry about a lock-in. But even if we do have to sunset the service due to unforeseeable reasons, our cold storage is relatively inexpensive and we will give our customers ample time to migrate out. Also, in such a scenario we would want to publish our entire system in an easily deployable way so that all our efforts would not be in vain. [1]: https://github.com/ente-io/bhari-frame/releases/latest https://github.com/ente-io/bhari-frame/releases/latest
- barbazoo 5y agoI see where you're coming from and I really appreciate that you're taking the time to respond. I know it's unlikely for a service like this to shut down from one day to the next but it's not impossible, plus the whole thing about a service having the ability to shut me out of my own data, that's just scary. And many of us are already paying for storage on Dropbox and have secondary backups set up for instance. I'm just saying that this would probably convince more people to switch, leveraging a service they're already paying for plus whatever you're charging to facilitate - less than the full service with storage would cost but enough to make you some money as well. Again, offering privacy in a field that was previously devoid of it is a great step in the right direction.
- toredash 5y agoI would pay for a self hosted solution, or for a solution where I can plug into a backend you support. I would also pay upfront, e.g. kickstarter
- fy20 5y agoThe problem with that is that some kind fellow on GitHub will clone the project, uncomment the code to enable the premium features for free, and change its name. If it's released under a FOSS license, the original authors have little recourse. This is what happened with Emby (a media server like Plex). The backend was open source and there was a license to activate premium features. Somebody cloned it, and then released the premium features to everyone for free.