Beautiful product! Just be aware of the support nightmare that comes along with people trying to install your software in many different environments. I will never, ever create installable software ever again.
Same here. I was selling a PHP+MySQL script and about 20% of my customers couldn't install it despite my verbose instructions. I don't really blame them, I shouldn't have been making non-technical web masters navigate a cPanel account and mess with PHP in the first place. I couldn't possibly provide personal technical support to everyone in need so I granted a refund to anyone who didn't get it working.
As a side note, this is the reason I hate PayPal. They didn't like my refund percentage apparently and simply banned my account. It sucked being treated like some scammer by countless customer support reps just because I couldn't provide tech support to all customers and had a higher refund rate. It's all for the best now though :) Subscription model + Stripe is a godsend.
We have a vendor of some mailing list software that you install your save (basically a tarball of php code). If we have an issue with it, they basically refuse to help unless we give them ssh access to our server.
Stupidly we have this mailing list software running on our production web server (the same one our customers use to access our apps), so we can't do that. I mean I trust the guy to not go in an install a backdoor or delete all of our files (maybe I shouldn't trust him?) but I've always wondered what the liability is there.
Would we basically have to prove he did something malicious if our server crashed the next day or turned into a spam box?
> You don't trust him with ssh access to your server, yet you trust him to run arbitrary code there. That doesn't make any sense.
When people say "ssh access" they usually mean root. The software that's running there, if the server is properly set up, will be running on a restricted account with restricted privileges. Now, granted, even with that there can be quite a bit of damage, but not as much as giving somebody root access to your system.
That's indeed the core of the problem. If your server is properly set up, you probably have one unix user per app, with other home directories not traversable and you can simply add a temporary ssh key. But then again, if customer have difficulties to install your software being just a php / mysql app, chances are great his server is not properly set up.
I think that the proper solution to any paid, self hosted application would be ... to provide hosting for less tech savvy users. Granted, your main selling point is to be self hosted, but you should not alienate people who are interested just by the product itself. And having a less costy per month plan is a great mean to let users try your app before deciding they should takes time or money to educate or hire a sysadmin.
2 days ago I cancelled Basecamp. Why? Pricing.
Duet looks beautiful. I agree, hosting for less tech savvy users would be great. The pricing is great for self-hosted. Frankly, the SaaS adds up quickly, and my hurdle rate is 10x (I have to save 10x the comparable annual dollar cost for Saas it to be sustainable).
Indeed, I was not trying to evangelize SaaS/PaaS :) I'm quite bored of seeing clients wasting founding money on heroku stack, where they first pay incredible amount to have unix processes, then pay a service to have email sending, then one to host uploads, then one to have logging, then on to monitor their app, then they rent a dedicated server anyway because they have specific needs ...
My point is more that it's probably a good thing to provide both webservice and installable app (github, with its github enterprise is a very good example of that, even if way too expansive), to let user choose your product based on what it does instead of what are its requirements and implications.
Yeah ok, but then a) the software should probably not run under root. In fact it should probably not run at all, if you haven't done any kind of audit on it/the developer.
And b) assuming you have done your due diligence on the developer in the first place, why not trust him with access to your machine? And again - you shouldn't grant him root of course, but a shell account with privileges similar to the application would be fine.
But really - Purchasing a script from some back-alley developer you have no knowledge of and placing it on your production server? That's the reckless part.
That sounds like a sticky situation. I don't think it's a matter of trust, but just a matter of principle for me. He can be the most trustworthy guy ever, it still doesn't mean it's a good idea to give him ssh access to your business. That should be sacred. Because of the fact that they are requesting ssh access, I would try to migrate to another mailing list service, probably something hosted like Mandrill or SendGrid. I realize that is probably much easier said than done for you guys, but I think it's necessary in the long run.
In the meanwhile, I guess you can mitigate risk by making strict permissions for the user they ssh in with. Are they usually manipulating data on the production server, or changing code? If it's just code, you can give them access to a development server and push code to production by yourself after you've done a review.
I recommend using acct to monitor the server in addition to limiting the vendor's user. If something happened, you would have a very clear picture of all users' actions in addition to some statistics about system health.
As someone who's built software that others can install I can confirm that it's a lot of work. It doesn't mean you shouldn't do it though.
The most important thing is to separate the "self installed" users from the ones using the hosted version (which you might try to monetize at some point).
Point self hosted users to a "community" that can help them while users on your system can email you directly.
It's worked out pretty good for us. We have a much shorter response time for hosted users than self installed. We typically answer most questions on both but it helps separate what's most important (hosted users).
I've been thinking about this and I like the idea of building the software to run on Heroku (or similar). For those that want a self hosted plan you just tell them where to host it and if they want installation outside of that you charge them a decent hourly rate to make it worth it.
I've always liked the option of providing a virtual machine image. Then you get a predictable deployment environment, and the client can run it where they like.
That only half solves the problem. A lot of shops that want self-hosted literally want to host it themselves, to keep data in their datacenters. if you built something deployable to EC2, you could make sure it works on a local Eucalyptus/OpenStack deployment or something. Or you could try to build for OpenShift and tell clients them have to have their own OpenShift cloud. But there's no real easy solution.
I agree. Handling support for this type of product is definitely a challenge. Especially since many customers don't have any experience installing anything on their servers. I've tried to make the installation process as simple as possible (It only requires database credentials), but many customers still have issues.
A free-to-download "test my environment" script could be a good idea to mitigate some of the installation issues. Write a simple one-file PHP script that a prospective buyer can download for free, and run on their target environment. That script can give them a report showing them what works and what doesn't.
This could save you a lot of post-purchase support requests.
I can easily imagine what some of the dependency management issues could be, but I'd love to hear your thoughts on the following two options:
In the Java world there is a concept of a .war file which packages everything up so it's easy to deploy on app servers that handle it like: Tomcat or Jetty.
Also what's wrong with giving out a prebuilt virtual image for a single server install? Github enterprise does this.
I'm not a fan of app servers; I'd rather segment my running applications. I use maven-shade or sbt-assembly to create an executable .jar with an embedded web server. (Also makes it easier to just provide a runtime interface with jsvc.)
Also makes it a hell of a lot harder to scale horizontally. With an app layer you can just horizontally scale your app server stack and put a load balancer in front of it and you're done.
I don't know where you're getting your information, but your claims do not match my experience or, apparently, that of pretty much anyone else using Play (embedded Netty) or Dropwizard (embedded Jetty with a handler). Or anyone who is writing a Rails app or a Django app or anything else that lives as a standalone HTTP handler.
I have a Puppet script that sets up deployment on a new server. Puppet does not care how many machines the application is running on. Neither does the load balancer/reverse proxy in front of it; it takes a list of IPs and does its thing across them.
I have never seen an app server do anything that wasn't essentially this process, only with more XML and aggravation.
Not really the same because you can say "We don't support IE version x" and be done with it. There are much more variables at play in a server setup: PHP, MySQL, web server, OS etc.. Each of these can be running different versions and each instance (of PHP for example) can be configured completely differently from the next.
