 |  |  |
« I See Markup, Part 2 - XML Industry Prone to Lack of Productivity | | Main | |
I See Markup, Part 3 - Transition To Commercial Product
This is the story of my C++ XML parser product CMarkup.
When Joel of Joel on Software began writing some five years ago about how he was going to run a successful startup, I found it inspiring to imagine that building a successful software company was just a matter of being smart about it. I am also inspired by the fact that my own uncle actually started selling fish tank lighting systems (of all things!) on the Internet at A H Supply as an offshoot of a hobby and created a successful full-time business.
It seems that people never know quite how they are going to get into business before they do. It doesn't matter how much planning you do, you have to be a bit of an opportunist as well.
Just as I'm sure my uncle didn't forsee selling fish tank lighting systems, one Micro ISV is doing horse show management software among other things while ramping up to tackle bigger ideas: we're going for simpler web-apps to get cash-flow to fund the larger projects wrote Matt of Metanotion Software. Another Micro ISV guy at brkstudio is asking his blog readers to vote please! on what direction he should take, and a lot of wannabe-ISV people are in the initial stages looking for an opportunity to do that thing in their field that they know will be hugely successful.
An Independent Software Vendor (ISV) does not include consulting -- consulting is that other activity that many Micro ISVs depend on to make a living while trying to get sellable products to market. In Set Your Priorities, Joel describes the spectrum from consulting to consultingware to shrinkwrap, the goal definitely being shrinkwrap:
Shrinkwrap is the take-it-or-leave it model of software development. You develop software, wrap it in plastic, and customers either buy it, or they don't... I'm gonna have to strongly recommend clinging as strongly as possible to the shrinkwrap side of the equation. That's because shrinkwrap has no marginal costs for each additional customer, so you can essentially sell the same thing over and over again and make a lot more profit.
Like many of my colleagues in this industry, I have been thinking constantly about it but I have never quite made the choice to jump both feet into the ISV business; I've always kept one foot in consulting. The very modest success of CMarkup is due to nothing more than making available a simple class that happened to demonstrate some reusability. The opportunity to sell CMarkup as a shrinkwrap product has been rewarding and fascinating.
There was originally no intention to sell CMarkup. It was developed on a subcontract that allowed my company First Objective Software, Inc. to retain the copyright and it was made available on the firstobject site beginning in May 1999. Then in February 2001 it was cleaned up and posted free on The Code Project and it became article of the week:
The idea of The Code Project is that source code posted there should be able to be used freely by everyone. But for some reason, certain users started asking if they could pay for CMarkup. I told them "no, it is on Code Project therefore it is free". Why did they offer to buy it? They wanted to be extra sure that they were not violating any copyright. Plus, paying for a product helps to obligate the seller to support it. After I rejected a third offer I decided to seize the opportunity and provide a commercial license as a way of supporting ongoing development of features and fixes. There is still a "Lite" version of CMarkup on The Code Project which is free (it is only asked that no one redistribute the source code).
At the time there were two of us in my company First Objective Software. Atal Patel and I were contracting full-time on multiple contracts. I spent evenings filling out the features of CMarkup and setting up the firstobject website to sell it. It may sound easy when someone offers you money for something that already exists, but it adds a lot of responsibilities like fixing, enhancing and documenting, and required me to set up a means to handle payments and figure out details like licensing.
The first CMarkup sale was on March 27, 2001; the price was $159. There was another sale in April, and none in May. It was evident the clientele would stay very very limited if a certain minimum of features were not included. I was also still figuring out how to define CMarkup as a product and how to attract users to make the purchase.
So how do you sell a source code product? It is not a program, it is just text files! The choices I made for how to sell CMarkup were based on what I would want as a customer myself in the industry of development tools.
Most source code products such as the Dundas Ultimate Toolbox give demos by way of sample applications. This lets you visualize what you might be able to do with the source code product but doesn't let you actually try it out. I was generally disappointed with this type of product because my imagination always exceeded the reality. For example, you see a great control in their demo, but when you try to integrate and customize the source code into your own product you discover problems and dependencies that make it less attractive. But anyway, even if this is a good model for selling source code, it is geared towards graphical user interface (GUI) products. CMarkup has no GUI, although it comes with a small GUI test harness.
I avoided the open source model because as a developer I had always looked for products for which you could purchase unlimited royalty free use without strings attached. Open source provides source code "free" with a set of strings attached called the GPL (GNU General Public License) or LGPL (Lesser). As a customer of open source, these strings can be more expensive and cumbersome than paying a price up front for a source code product. As a seller you have to be very creative in how you make money with an open source product because derivative works must be open source also and your revenue will have to stem from unique value you provide around your product.
I ended up creating evaluation and developer versions of CMarkup, allowing users to freely try it out, but giving them something extra when they purchased it. The freely downloaded evaluation version covers all the basic capabilities while the purchased developer version has all of the extra functionality. The customer is expected to purchase the developer version if they use CMarkup in a commercial application. Actually many customers can fully implement their solution with the evaluation version before purchasing the developer version: an arrangement that definitely puts the customer's needs first. This honor system is no doubt abused, but that is not necessarily bad for the product since it gains wider use and more opportunities to fall into the hands of those that will pay.
Though selling source code has its challenges, it also has benefits. First of all it is very valuable to the customer to have the source code so you can charge a lot more than you might for a black box binary component. Secondly, providing evaluation source code lets you avoid unhappy customers altogether. But I will talk more about these points later.
I scrambled to get more basic features into CMarkup. There were 3 sales in June, 4 in July; things were looking up. The chief differentiator of CMarkup was that it was one single class which could be very simply added to any C++ project. In 2001 there was simply no other XML solution that had this advantage and the next part of this series will dig more into the making of a product out of CMarkup.
« I See Markup, Part 2 - XML Industry Prone to Lack of Productivity | | Main | |
