21 September 2009
Recently, I released Lupo Manager and Lupo Translator, two license-based, commercial AIR applications designed to give developers and translators tools for helping them internationalize and localize Flex applications. My experience is certainly not representative of most commercial AIR applications: I was the only person involved in this project; the scope of my applications is pretty narrow; and my financial objectives are very modest. As a consequence, the goal of this article is not to be a recipe for success, but to give the reader some feedback on my humble experience with building and releasing a commercial application built on the Adobe AIR runtime, from the ground up.
I've been working as a Flash platform freelance developer and consultant for the past 6 years.
When Adobe AIR was released, I first saw this new technology through the eyes of a web developer: I could finally break free from the limits of the browser. Being able to leverage my web developer experience to build desktop applications, while still being able to reach virtually almost any user, was simply amazing. Of course, I also realized the business opportunities these features could represent for my clients, and, by extension for me, as a consultant.
Only later came the desire of making money not only through consulting but by selling applications directly to consumers. The trigger was the success of some AIR applications, in particular Balsamiq Mockups which brilliantly showed the way for actually generating revenue out of a one-man-made Adobe AIR software. Not only did it prove that people were actually willing to pay for an application that did its job right, but it also made clear that a license-based business model could still be relevant in the context of this new kind of platform.
As a Flex developer and consultant, learning how to build applications on AIR was really trivial. Building my very first AIR applications on top of existing Flex applications only took minutes. In all honesty, this has less to do with my own skills as a developer than with the fact that AIR development tools are quite easy to grasp if you have a decent experience in web development, whether with Flash Player or with plain HTML/Ajax.
The first AIR application I released publicly was FCG, a code generator for Flex developers built during the beta days of AIR (see Figure 1). It helped me learn a lot about the AIR file system API. In its firsts iterations, the application came through the form of a raw AIR file. It had no install badge, it wasn't signed using a certificate, and wasn't built with updates in mind. In other words, it didn't leverage many of the best features or AIR.
This experience helped me understand that developing an application for the desktop is pretty different from building an application for the Web. As I already had the opportunity to explain in a previous article, this difference in nature has many not-so-obvious consequences, especially regarding the fact that your application may create various dependencies on the user's computer. To this end, and for many other reasons, it is essential to adopt a strategy regarding future updates of the application from the very start, possibly before the first release. Most of the time, this will consist of using the update framework and managing its consequences on your workflow.
Likewise, I learned that there is a huge gap between developing an application for a client (or yourself) and making the application public. You need to have a deployment strategy which allows your users to easily find, download, and install your application. Of course, your goal is to reach as many users as possible, which probably involves distributing your application on the Web. In this case, I can't think of a better way than using the AIR install badge. An install badge is a standard way to let users download and install your application from a web page, via a small Flash animation, which has the great advantage of automatically installing the Adobe AIR runtime on the user's system if it's not there yet (see Figure 2).
Soon after FCG, I created an Application Descriptor Manager, a pretty straightforward tool for AIR developers which can be seen as a design view for AIR descriptor files. This time, it featured an install badge, auto updating capabilities, and was electronically signed using the publisher certificate I was offered when I submitted the application to the Adobe AIR marketplace. This signature really helps your users trust your application, which, in my opinion, is absolutely essential, especially if you're to ask users to pay for it.
My next AIR application, Lita (shown in Figure 3), was much more ambitious. Lita is a SQLite database administration tool, which, at the time of writing, has been downloaded and installed on some 10,000 systems. Although this is not that large of a number when compared to top AIR apps such as Adobe Media Player or twitter clients, it is enough to give a pretty good idea of what it means to maintain an application that is actually used by people.
For the first time for an application of my own, I had to use project management techniques I generally used with my clients development teams, such as a subversion repository, a bug tracking system, build automation, and so on. I also began to communicate more seriously about the software, using my blog and twitter. More recently, since the daily feedbacks from Lita users are becoming more important every day, I started looking at various online user feedback management services.
At this stage, I felt I had a decent enough experience with the platform to try to build an application people could actually buy.
All AIR applications I had publicly released so far were aimed at developers. The reason is simple: before making it public, these applications were tools I used for my own needs. So I guess making tools for Flex developers made sense for me, because Flex development is what I know best.
Among my personal (not publicly available) set of development tools, one helped me manage properties files for my Flex projects. It just parsed my source code to extract the localizable strings and create the corresponding Key/Value pairs in some properties files. I thought that this could be quite a good candidate for a commercial application, for many reasons.
First, localizing an application is a great way to naturally increase revenues simply by opening new markets. After all, what's the point of having a 98%+ player penetration rate, an über ubiquitous desktop/browser/mobile and devices presence, if half of the users can't use the application simply because they don't understand it?
Despite this significant argument, as a consultant, I had realized that software internationalization and localization are often perceived as complicated topics. The Flex framework does provide a basic API to deal with resource bundles, but actually supporting multiple languages still requires a lot of work. It implies a good organization, a solid architecture, and often takes a long list of repetitive, un-agile, tedious tasks to finally get the job done.
So I thought that there could be a market for a tool that would help developers do this job. Besides, as a former technical translator, I had a pretty good idea of the challenges that could be faced by the people who do the actual localization job. And from a marketing standpoint, I knew that I could use my free applications as a promotional platform for this new application, since all ADM and most Lita users are Flex developers.
I improved the application to create a more sophisticated set of tools, which I used for some client work (see Figure 4). Then I made a small video to promote the tool, which I could use as teaser of sorts, and blogged about it. The reaction was pretty good, enough to get me thinking that I'm on to something—that there is a need for a tool to help developers create internationalized Flex applications.
The main problem I had with the idea of selling this application was that developers in general, and web developers in particular, are pretty reluctant at paying for development tools, especially because you can find tons of free or open source applications out there. Nevertheless, to my surprise, I discovered quite a lot of pretty expensive commercial applications specialized in software localization.
Of course I had to make sure that there was a place for my product between those big commercial localization software products and the smaller, platform-dedicated, free ones. I spent a considerable amount of time trying each and every free tool I could find, especially from the Java world. I definitely found nice tools, but many of them were buggy, unusable, or didn't solve the problems I was looking to solve with Lupo. On the opposite side, commercial applications are very sophisticated solutions that do not target a particular platform or file type, and tend to feel over-engineered and don't look very well suited for the typical Flex application.
Another important issue I was facing was that I knew that creating a single tool for both developers and translators was simply unrealistic. Developers and translators have very different needs. So I had no choice but to create two separate applications.
This was definitely a problem for me, since it obviously required even more work, as I had to imagine what could be the best workflow between them. More importantly, this turned out to be pretty confusing from a marketing standpoint, as I had to promote two different, yet related, products.
Besides, I also created a new consulting activity, Lupo services, dedicated to software localization services, in order to help my clients deal with issues that cannot be solved with a tool, including things such as finding professional translators or organizing localization project management.
Contrary to some marketplaces such as the Apple app store, Adobe does not require you to ask for their permission before selling your software built on AIR. The AIR Marketplace is a showcase for applications—publishing applications there is not mandatory, but it's a good idea if you want to increase the visibility of your product.
This freedom has two important consequences. First, as long as you respect the AIR SDK license agreement and Adobe trademarks, you are completely free to build and sell AIR applications under any (legal) conditions, at any price, without having to pay any kind of fee to Adobe. However, this also means that, when it's time to find a business model or a monetization strategy, you're on your own. You cannot rely on a simple, form-based, ready-made mechanism. For a solo entrepreneur like me, this can be a bit intimidating.
Due to the rather specific scope of my applications, any advertisement-based model would have been pretty irrelevant. Subscription-based models can definitely be a good idea in some cases, especially when you provide extra services besides the core software, but again this was simply not relevant in my case. So I decided to go with the simplest thing possible: the Manufacturer Model (sometimes called "Direct Model") , which consists of having users pay once for using the software for as long as they want.
I then searched the Internet looking for a fair and simple commercial End User License Agreement. Surprisingly, finding such a license was much harder than I first thought. As I didn't have the time or the money to hire a lawyer for this work, I decided to mix up and adapt various licences derived from what seems to be the most significant effort to this date, Ed Foster's Fair EULA.
The question of pricing is definitely a tough one. As my first goal was, of course, not to lose money, I first had to determine what it actually cost me to build the software. Then, I tried to estimate a minimum number of potential buyers, which is a very difficult task. For a moment, I also considered non-fixed pricing models, in other words having users pay a different price according to the success of the applications, but I quickly gave up this idea since dynamic pricing is both commercially risky and technically challenging.
Strictly speaking, my development costs were extremely low. My IDE, Flex Builder 3 paid for itself a long time ago through my consultancy activities, and a one-year publisher certificate was offered to me when I published my first applications to the Adobe AIR Marketplace. So my development cost essentially consisted of the time spent building the software. So I simply multiplied the amount of days spent on this project by my normal daily rate for consultancy.
Of course, I also had to take into account marketing costs, which in that case consisted of Google AdWords, and time spent promoting the project in various ways. However, as Paypal fees are proportional to the incomes, I did not include them as costs but simply included them in the final price.
Once I had determined a rough figure for the development and marketing costs, I somehow had to come up with an estimate of the number of users who could potentially buy the products. I honestly had no idea about how to do that. All I knew was that 20 people signed up for the beta program within 24 hours. Of course, I knew there would be a huge gap between this and the number of potential users who would be ready to actually pay for it, but I really didn't know how large it would be, so I just had to take a guess.
As this guess was rather conservative, it lead to a relatively high retail price, compared to the price of existing AIR applications. But I also had to take into account the fact that my costumers are either companies or professional independent developers.
As you probably know, there is no such thing as a 100% efficient software protection system. Given enough time, skills, and motivation, a hacker will always be able to crack your application, eventually. In particular, you have to be aware of the fact that SWF files can be decompiled. For this reason, in most cases, what you need is a system that is strong enough to discourage most users to try to bypass your protection. Once you're aware of this, you can choose a protection system that best fits your needs.
Many strategies exist for implementing licensing logic and protection to your application. I know that some commercial solutions are available for Adobe AIR applications although I did not have the opportunity to try them. If you plan on releasing a commercial AIR application, I encourage you to check them before rolling out your own system.
I decided to run my own mechanism for two reasons. First, I had developed it before I heard about any of those products. Second, as a developer, I wanted to learn more about software protection, and I thought that building my own system would be the best way to improve my knowledge. However, it was not a question of saving money, since, given the time it took to build my own system, I'm really not sure it was more profitable than paying a reasonable fee for an existing solution.
The solution I put in place is very simple. I will not dive into each and every detail of the protection system here, for obvious reasons, but I can share the overall logic. After agreeing to the terms of the End User License Agreement, users can click a Paypal button which will lead them to the electronic payment process. Once the payment is confirmed, a server-side script is called in order to create the necessary entries in a database, including client data and a generated license key. The user is then automatically redirected to a web page featuring the install badge and the user's license key.
At startup, the application checks its EncryptedLocalStore to see whether or not the copy has already been registered. If it turns out the copy was registered, the application runs as expected. If it hasn't, which would typically happen on first run, it prompts the user for a license key.
When the user submits the license key, the AIR application does not perform any key validation logic. Instead, it sends this information to a server-side script, which validates the product and invalidates the given key at the same time to avoid using the same key for registering several copies. One advantage of this approach is that it is no use decompiling the application to find the key validation algorithm, or use brute force, since everything happens server side and a key can only be used once (for single-seat licenses).
However, this approach also has drawbacks. The first one is that the user has to be online to validate its copy, which in this case is not such a big issue since registration will typically occur on first run, right after the user sent his or her payment via the electronic payment which, by definition, requires the user to be online. The other is that the single seat license requires the user to unregister the key/product pair before installing it on another computer. This can be a problem when the user cannot have access to the computer the application was first installed on (which is the case, for example, when the computer was lost or broken). Under those circumstances, the user has no other choice but to contact me directly in order to recover the right to install another copy with its key, which, of course, is not very scalable. Lastly, I knew that it would be difficult to offer trial versions for Lupo applications, since my mechanism provides no way to perform a secure time validation on the client side, and a server-side validation would require an Internet connection at each and every application launch. This, of course, is a shame since trials are known to be a great way to boost sales.
Releasing an application to the public is a stressful experience, and releasing a commercial application puts you under even greater pressure. In my case, I guess the fact that the application in question is able to overwrite the user/developer source code, possibly ruining all its work, didn't help either.
There's only one way I found to limit this stress to an acceptable level: testing. By testing, I do not necessarily mean complex unit testing or automated functional testing. Lupo didn't use much of that, although I have since realized how helpful it can be. I'm talking about simple, human-powered, functional testing. The Lupo beta testing phase began very early, at a time when the software was still very rough around the edges, and it lasted twice as long as the main development phase, nine weeks.
I chose to put in place a private beta phase limited to 20 users, which is a rather small number. The main reason why I wanted to limit this number was because I wanted to have an individual relationship with each of them. As I knew that user feedback is absolutely essential to the success of an application, I thought the best approach in this case would be to choose quality over quantity.
This turned out to be a good choice. Of course, as expected, a huge amount of bugs were discovered and fixed based on user feedback. But beta testers were involved in a much more important way than bug hunting. Indeed, while being a typical end user for your own applications has many advantages, it may also have you mistakenly think that you represent all of your users. The illusion that your take on a feature is representative of all users can be very misleading. This, I think, is the very reason why going through a private beta test phase early in the development process was so essential.
As a result, many features suggested by the beta testers made it to the final release. For example, the first versions of Lupo Manager had a very limited support for pending extractions (instructions or strings that require a developer modification before being actually extracted). A beta tester suggested a “Mark as Todo” feature in this case, which was implemented in the next build. Likewise, Lupo Manager didn't provide an easy way to hide a key/value pair from the translator. Several beta testers suggested a flexible way to do just that by inserting a standardized comment before the related pair, which happened to be a simple but effective idea. And those are just some of the features which were built thanks to early user feedback.
The beta phase also helped me better manage my priorities. It was a very efficient way to forget the details and focus on getting things done. Besides, communicating with the beta testers forced me to write down and properly formulate what, until then, was just notes and vague ideas. Later, I used this material as a base for marketing and software documentation. For example, many testers had trouble with the overall workflow they should put in place when using Lupo. I spent a lot of time describing this workflow in detail by email, which eventually lead me to write the main Lupo studio overview including a workflow diagram.
If you've read this article, chances are that you too are considering selling your own AIR application. Well, that's a great idea! Adobe AIR is an excellent platform which provides many new business opportunities, and I'm convinced that the best applications are yet to be released.
However, if you're not familiar with it yet, note the following advice before jumping in: