7 ms·

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 n

by rsobers 13y ago

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.

speg 13y ago
The same could be said about people trying to use old web browsers.
- davej 13y ago
  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.
zimbatm 13y ago
We really need a way to easily distribute web-apps on a single-server scale for start at least. If someone is interested to build something with docker.io please contact me :)
todd3834 13y ago
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.
- cacois 13y ago
  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.
  - lallysingh 13y ago
    http://aws.amazon.com/ec2/vmimport/ http://aws.amazon.com/ec2/vmimport/ You can export the VM from EC2.
- mbreese 13y ago
  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.
23andwalnut 13y ago
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.
- sbarre 13y ago
  I've seen this solution before: 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.
tonyedgecombe 13y ago
I've been doing it for ten years, it isn't that difficult.
- porker 13y ago
  I'd like to know your secret! I maintained an open source script being installed by fairly computer illiterate users, and I found it a nightmare.
ikhare 13y ago
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.
- eropple 13y ago
  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.)
  - aioprisan 13y ago
    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.
    - eropple 13y ago
      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.
jmathai 13y ago
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).
lopatin 13y ago
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.
- bluedino 13y ago
  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?
  - lopatin 13y ago
    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.

by rsobers 13y ago

speg 13y ago

The same could be said about people trying to use old web browsers.

davej 13y ago
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.

zimbatm 13y ago

We really need a way to easily distribute web-apps on a single-server scale for start at least. If someone is interested to build something with docker.io please contact me :)

todd3834 13y ago

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.

cacois 13y ago
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.
- lallysingh 13y ago
  http://aws.amazon.com/ec2/vmimport/ http://aws.amazon.com/ec2/vmimport/ You can export the VM from EC2.
mbreese 13y ago
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.

23andwalnut 13y ago

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.

sbarre 13y ago
I've seen this solution before: 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.

tonyedgecombe 13y ago

I've been doing it for ten years, it isn't that difficult.

porker 13y ago
I'd like to know your secret! I maintained an open source script being installed by fairly computer illiterate users, and I found it a nightmare.

ikhare 13y ago

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.

eropple 13y ago
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.)
- aioprisan 13y ago
  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.
  - eropple 13y ago
    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.

jmathai 13y ago

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).

lopatin 13y ago

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.

bluedino 13y ago
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?
- lopatin 13y ago
  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.