A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.
We're closed, folks!
Doug Nebeker ("Doug")
I will soon launch the Android version of an app I already released for iPhone, Pilot SSH ( http://pilotssh.com ), and I would really appreciate your advice on how to do it successfully.
I got a few hundred sales for the iPhone version, mostly following articles on news websites, but they did not continue steadily. I discussed with some users, and it seems that my target market is more on the Android side, so I rewrote it. A key part of the success would be the creation of a community of users around the app, but that is not easy.
I have tested it extensively (and made people test), I have built a small network of people to make some noise at launch time, even contacted some journalists and bloggers. So, it looks like I am all set for the launch, but it feels like I am missing something. This is the first product I have ever launched, so I may not see the obvious problems. Is there anything I should fix?
Sunday, May 12, 2013
+1 to increase the price. I will buy it for $15 if it works. I have a SSH client Android app, and it is... well, insufficient. I do not use it for that reason.
Now, as a former system administrator (I still use Unixes heavily), your copy has confused or put me off on the following items:
1. Shell. Please tell me directly and clear that I can just use the shell if the appropriate script is not yet written. Unix is all about flexibility, and I want a tool that allows me to do ANY task, not just scripted ones. It is not clear from your copy.
2. Stored passwords. Please tell me that I do not need to enter passwords every time I log in. It may be considered insecure by some, but I do not want to remember passwords to dozens of servers. Let me decide what is secure in my network, and what's not. Again, should be told clear.
3. Public Keys authentication. Tell me it is supported. Loud and clear. This is must have. Tell what format of the key is supported (OpenSSH format is my first choice).
4. Scary: "tap and kill the process". You copy seems to read that I would kill a process by (accidental?) tapping on it. It breeds a feeling of fragility. Make it clear (screenshot?) that a dangerous action requires a confirmation.
5. Show the process of creating the scripts. How complicated it is? How flexible? Can a script take a parameters (e.g. shutdown with a message to all users, where the message is entered on the phone).
6. Portable SSH? Heck, yes! $15! (well, already said that, but why not reinforce it?).
BTW... IMHO you should SELL your script packages, not offer them for free download.
Basic one is free and comes with the software.
Specialized ones (for Apache httpd, nginx, Tomcat, Weblogic, Websphere, Oracle DB, you named it) you order on a side and sell as a package.
And my last comment. (I feel myself like Scott, who often posts a few comments in a row -- I hope mine are equally useful :) )
I feel your copy (or lack thereof) should be screaming about benefits to the sysadmin. How they can easily carry the shell access to any remote part of the building (instead of laptop). How they can speed up common tasks by scripting. How the access point is always with them, be it while driving or in washroom.
You should make some long copy, man!
Right now, if you allow me some analogy, you're just extending your hand with something shiny in it towards the prospect and smile shyly. Silently. This is not gonna sell well!
Make some sales copy.
And good luck!
(Just cannot stop)
6. Do I need to install anything (script, binary) on the server? If yes, then it sucks. Some of the servers have _draconian_ policy on what can be installed there. I hope the scripts can be stored on the phone and "assigned" to the connection. Again, not clear from the copy.
Thanks for the answers :)
To sum it up: raise the price, and review the copy.
About some specific points:
* Shell: there is no shell in the app (yet). The whole point of the app was to avoid using a shell on a phone, because they're not really adapted to touchscreens. That should not be too hard to implement, though.
* Authentication: it supports stored passwords (in an encrypted database), public key authentication and sudo. I should really make it clear how to do pub key auth.
* Selling scripts: that was not really my plan, but I could do it for really complex ones. What I relly want is for people to write their own ones.
* Script installation: they are stored in ~/.pilotssh and the app can upload some if they're not present. Again, the goal was that people manage their own scripts, write them in the language they want, etc.
Maybe I should review some of those goals...
If you want iother people to write scripts, then you can jump on the marketplace bandwagon.
This will make extra hype and you will collect your 30% by just administering the marketplace (doesn't this sound familiar:)
Monday, May 13, 2013
> The whole point of the app was to avoid using a shell on a phone, because they're not really adapted to touchscreens.
There are (largely) two groups of Unix users:
1. Administrators. Those folks MUST have the shell. The diversity of their tasks is so large that no way one can script every task that pops up during the day.
2. Deployment teams, support, DBAs (especially junior ones), ... They are not Unix gurus, and it is often a time-saver (and safer) to create scripts for most common tasks.
I believe you can cater to both categories.
Administrators need flexibility, but there are enough standard tasks like "on server X, who are three users consuming most of disk space?". Note that uploading the same script to 20-30-50 servers manually defeats the purpose. The script should be kept on the phone and uploaded when you use it (and possibly get removed right away).
Non-administrators would want ready-to-use script. You may expect administrators to create the scripts for them, but admins are often too busy and often do not clear understand the set of tasks supports does and also there is sometimes a little bit of estrangement between those groups. The non-admins themselves are not good enough at Unix to create good scripts. At the very least, they need many examples. At the best, they need ready to use libraries of scripts. They do NOT want to write their own scripts. They have work at hand that needs to be done faster and with more quality. Help them to do it and they will pay you.
And that's is why you should consider selling the libraries.
I suggest you to do the following:
- List all most common admin tasks for, say, nginx
- Implement the script yourself or pay a skilled nginx admin to do it (oDesk may help)
- Package the scripts as a bundle
- Sell the bundle (on a separate page with a detailed description what it does)
I just do not see why would you skip this extra money-making opportunity. This is upsell! Selling app alone wouldn't make much money. Selling a solution (ready-to-use script) may.
> then you can jump on the marketplace bandwagon
Interesting idea, but the size of the "market" is too small to justify it. The administration and development costs of developing the market would probably be way larger than the cut.
Besides, why take 30% when one can take 100% and plus remain in full control of the quality.
What about selling the scripts through in-app payments? The upsell would be quite easy.
In addition, I added push support for the Android app. I will mostly use it to send messages from long running scripts or monitoring services, but it looks like a great way to tell users about new scripts they can use.
+1 for eventual in app payments for common scripts if you can find a need for them. Not sure if there is even a basic common set of scripts you can devise, but perhaps you can. I'd say keep it free for now so you can gather information on what scripts people want *or* allow them to configure a central repository for their company where they can download the scripts from themselves. In a company, this would make the most sense since they will develop common scripts on their own, particular to their situation.
As for the shell access/editing scripts, I would say the way it "should" work is I write the script on my desktop, sync it to my phone and click a button to execute it whenever I want on server X,Y,Z. I would not expect to upload it to the server before running as that is a non-starter for me. Too much work. It is reasonable, however, to expect me to somehow get the script onto my phone/tablet first.
Of course, it would be nice to edit it on the tablet interface as well since tablets are slightly more suited to small text editing than phones.
I think you've got to figure out the pitch that results in the "take my money" response.
as a linux sysadmin i use connectbot and hackers keyboard, installed on the tablet i'm writing this message with.
this saved me a couple of times.
i will not allow any scripts from untrusted source to run on my systems, expecially since they are heavily customized.
on the contrary i will favor some publicy available scripts that can be customized... but i like CLI too much :-)
That's a concept I often encounter when talking about my app. People would not accept those scripts, even though they already trust their SSH client not to send hidden commands. That is unfortunately very easy :p
All the scripts that are uploaded by the app are already available at https://github.com/Geal/PilotSSH-scripts , along with the instructions to make new ones, is that acceptable?
> i will not allow any scripts from untrusted source to run on my systems, expecially since they are heavily customized.
They don't need to be closed-source. Just paid for.
You'd get a script package with the complete source, which you may customize for your environment. You paid for someone to prepare those script for you, saving you perhaps hours of unproductive work.
This is 10x true for non-admins. A wslt script that does a rolling recycling of a Weblogic domain took our shared services team not less than a week, even with my help when I had time. Now imagine this script comes to them as a package with "collect domain stats, print stuck threads, ... ". That alone would worth 100s of dollars.
> Stuff with 5 or 6 worldwide customers
5 or 6? There are quite a bit more installations of Oracle Weblogic is out there.
Re: hundreds of dollars. I was just pointing at value. It could be that high. It could be way lower. To tell nginx to reload its configuration would be a one-liner script ... and still, giving proper configuration options (saved host & path) it still saves time = provides value.
The problem with selling sysadmin scripts is that there are no economies of scale. How many installations do you have to go through to find a dozen that have a dire need for your specific script but don't have the capability of either fixing the problem themselves or contracting with someone to fix it for them? How many to find a thousand customers? Close isn't good enough, if the client has to do customization themselves, why wouldn't they do the whole thing themselves (or contract the whole thing out)?
The solution is to sell consulting services. You might throw in a free license to your mobile app to help sell your services. Tell your clients how much they are saving by not having to pay you to develop a mobile app so they can do remote administration from their phone. That's where there is a potential for economies of scale. Keep your scripts to yourself, and take advantage of time savings when you customize them for your clients. At $250/hour you make the equivalent of 50 sales of your mobile app.
BTW, am I the only one uncomfortable with sysadmins rebooting servers, killing processes and problem solving without opening a laptop? Trying to get my flights changed with a mobile app is a sure path to insanity, I certainly don't want a million dollar web site monkeyed around with by someone fighting with a miniature virtual keyboard that just came out of his pants.
I had not considered the consulting idea, that's something I should try.
Funnily, solving a sysadmin problem with Pilot SSH is safer than with a shell: the script cannot do anything outside of what you designed it to do (and you can add logging, etc).
The idea for this app came to me because some friends of mine were on call for their companies, and had to open a laptop, plug the 3G key, or find some WiFi, and then fix the problem, while they were in a pub or a family event. The biggest concern is not fixing stuff on a mobile phone, but doing it while drunk in a pub :P
Tuesday, May 14, 2013
>To tell nginx to reload its configuration would be a one-liner script ...
am i the only one that found the conf file of a server process cluttered by some nonsense data casually inserted by some other admin?
you can for sure have a oneliner for a reconfigure but why do you need to reload conf if you haven't changed conf? how will you test the conf is in place, live in production, if you don't check log files first and then test?
as i said i used a tablet (10") with a special software keyboard for this kind of extremely urgent remote access and not a mobile (4") since the screen is too small and dangerous to mistype.
and if i'm drunk at the bar i will think twice before logging into a live system :-)
> Alright, do the math for me and tell me how many customers he could land for that script.
$20000, and 350 pages report will be on your desk, sir.
> really sure?
Those are all good points.
Yes, there are complicated cases when one need a console. In particular environment most of the cases are complicated. But that just means that those environments are not the target market.
And yes, there are cases where a script can just save typing and protect from occasional mistakes.
And not every Unix user is a sysadmin. Support and what not are using Unix too, but surprisingly many of them are not even skilled at grep, forget about find or awk.
P.S. Re: why reload the server config without changes. I do it with Jenkins-CI regularely. The thing just gets stuck in its thread pool from time to time, and the fastest way to normalize it is to tell to reload the config from the disk. Essentially, re-init itself.
> and if i'm drunk at the bar i will think twice before logging into a live system :-)
Respect. I though know a sysadmin of a relatively large company who spends quite a lot of time in bars being drunk, and doesn't shy to rule his servers from there... an extra level of safety wouldn't hurt him, methinks.
P.S. No, I'm not going to preach him to stop. None of my business.
> $20000, and 350 pages report will be on your desk, sir.
Passive-aggressive much? Work through it with me.
Script you want to sell: Oracle whizzbang database migrator, domain setter upper (I have absolutely zero knowledge about this.)
Customer: Oracle user who wants to migrate databases and set up domains.
How many Oracle customers are there? 370K
How many of those require a whizzbang database migrator AND domain setter upper? Let's say 50% So you have a total market of 185000 companies.
Now you want to sell companies that employ nerds, a script. Companies that pay out of their butts to employ said nerds will spend $500 looking for your script?
Just like the OP would save his time by not writing your suggested script, I think I just saved $20K. I'm going to go buy a car now.
Thanks for all the suggestions!
I modified the website a bit, there are more changes coming soon.
I was at the Web2Day conference in Nantes last week, and did a lot of demos. The results were encouraging: using the app was evident for everyone, very few people said they preferred using a shell on their phone, and among those, most of them said they could use it as a quick diagnostic tool.
Monday, May 20, 2013
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz