Koz Speaks

.NET and Java for Shareware Application Development

Joel Spolsky has ignited a bit of controversy with his recent complaint about .NET and windows forms in Please Sir, May I Have a Linker. Scoble responded saying it’ll be fixed in longhorn, and Ted Neward commented that hosting all the applications under ‘one virtual roof’ provides huge benefits and linking everything together goes against that.

Unfortunately the problem here is that, they’re all right. Java & .NET both provide huge productivity gains through their use of Managed code and a feature packed standard library. While .NET is Windows only, mono not withstanding, another benefit of this managed environment is cross platform compatibility, something which has seen Java take off for smart phones and servers.

Reading Joel’s article, I took his main argument as:

  1. The majority of his sales come from people who, like me, download the trial version. Have a look and decide to buy the full version.
  2. These people do not have the .NET runtime installed. (Joel has said in the past that he tracks percentages through User Agent strings and the like).
  3. To tell these people “Download this thing first, then reboot, then come back to me” would turn off a huge proportion of his triallers.
  4. In turn this would kill his sales pipeline and cost him money.

In recent months I’ve had a few ideas for some simple shareware utilities which I could code relatively quickly, and maybe sell for a few bucks, hopefully generating enough money to buy a book or CD every once in a while. Like FogCreek , I’ll be offering downloadable samples, and hoping that users will pay me some money for the full-featured version. I’ve been playing around with a variety of different options to do this. As much as I love Java, and as impressed as I am with .NET & Windows Forms. Neither of them are really an option for the reasons that Joel suggests.

The fact of the matter is the vast majority of potential ‘downloadware’ users, are not going to know what JRE-1.4.2 means, and whether they have it installed. Nor are they going to know if they have .NET framework 1.1 or 1.0 or nothing at all. And they shouldn’t need to. If they want to try my applications, I need to make it as easy as possible for them to do so. It’s all about lowering your barrier to entry.

At present .NET and Java don’t help me out there, as brilliant as they are for me as a developer, the barriers they present to my users are too high. I don’t think that all is lost though, I think the solution lies with the software’s installers.

What Java needs to be an option for ‘dowloadware’ is a completely automated JVM installation process. Here’s a quick sketch of what I have in mind, naturally all this applies to .NET too.

  1. The user, lets call her Jane, decides to try out CoolJavaShareWareAppv2.0. and downloads, CJSWA-2.0-setup.exe
  2. As she does with all the other apps, she double clicks on the installer and sees a familiar looking installer, an EULA, a blurb, some logos, etc.
  3. Jane clicks Next.
  4. Now, the installer checks her system and can’t find J2SE-1.4.2, so it tells Jane, in nice simple language “CoolJavaShareWareAppv2.0 uses the revolutionary Java environment, in order for the installation to proceed you will need to download Java”
  5. Jane is a little worried by this, but there’s a big friendly looking ‘Install Java’ button so she clicks it.
  6. The installer proceeds to download the JRE and copy the files into place, after checking she accepts the EULA of course.
  7. Then the installer takes over from where it left off and installs all CJSWAs files.
  8. if required, the option to reboot is presented.
  9. There’s a nice looking CoolJavaShareWareApp icon on Jane’s desktop.

I think the most important aspect of this installation process is that the JRE installer in step 6 must be part of CJSWA’s installer, at the very least it must look the same. The idea being that from Jane’s point of view, she downloaded CJSWA and it runs. There was no clicking around on another webpage, no deciding whether she needed the J2EE-SDK or the J2ME-RI. It all just worked.

Of course the big benefit of java here is that this installer could equally be built for MacOS too (we linux users can install it ourselves). The result would be that ‘downloadware’ developers can make use of Java to target multiple platforms and become more productive, without sacrificing their sales pipeline.

Are there any options available that behave like this? Will this create more problems than it solves?