Atomic Energy

I read a fascinating article in today’s WSJ, available here, about how AOL was the first Facebook, that really understood the value of community. Unfortunately, as they became a public company, a “Taliban” of MBAs came in, focused on short term profit and their own reputations, and killed the real long term value of AOL.

In many ways, I can appreciate his perspective. Many companies have been killed by naive MBAs who think the formulae and theories they learned in business school can “save” any company, in fact all companies are just waiting to be so saved. At the same time, even when they do have value to add, they haven’t learned how to communicate with the critical producers in the company.

For those very reasons, I have always preferred MBAs with strong operating experience

before

going to B school, and schools that emphasize those with experience in their program along with a tight focus on what works in the real world and how to communicate with real people. That is one of the key reasons I went to Duke’s GEMBA program, where the minimum experience was a decade.

I believe Kornbluth’s discredit of MBAs on principle is wrong, for the very reasons that he unwittingly makes aware in the article. AOL definitely underemphasized community, a serious management mistake. But AOL also made three major mistakes, ones that creative content types would also have made, but experienced creative business types might have found.

1. Intense focus on dial up, completely missing broadband.
2. Short term revenue focus, confident that customers would continue to pay $23.95 per month for their service, when alternate revenue models were becoming available, notably the Google model of free supported by advertising, exactly the Facebook model.
3. Control. AOL loved their walled garden, but the Internet is much wider than that. People didn’t want to be walled in.

Business fail because they kill their creative people, creative edge, but also because they miss the creative business foresight to pivot with changes in the market.

So Zappos was breached. It happens every day, certainly far more often than we hear about in the news, and, I suspect, more often than is reported to the appropriate law enforcement agencies, primarily the FBI cyber crimes unit (whose exact name escapes me at the moment).

I have done a lot of work in the cyber security space, in financial and retail, internal corporate and external facing, including compliance with the card industry’s official standard for cyber security, the imaginatively-named PCI-DSS.

I do not know how Zappos has built their internal network. But I can reasonably infer that they did at least a decent job, based on the results of the breach. The most important point is that despite a serious breach, no credit card info was compromised. Not one single complete credit card number was exposed, no security codes (those printed codes on the front of an AmEx and back of all the others) was lost.

Cyber security, like physical security, is built in layers of defense. The goal is both to minimize the probability of breach and assume a breach will happen some time, and thus mitigate the damage. Clearly, Zappos did not store credit card data in the clear with general information, but separately, and, likely, encrypted. They did not store the security codes, as PCI-DSS bans it. This breach hurts, but the impact is more of an annoyance than a serious impact. Further, they properly implemented password changes. They don’t store your password, nor can they email it to you, but rather can enable you to change it.

Most importantly, though, they handled customer relations correctly. They came clean from the beginning, and thus risking public wrath instead won customer trust.

Kudos to Tony Hsieh and his team.

Open-source, as discussed in the previous posting on network equipment, is a fascinating world. Perhaps the best intellectual and business promotion ever written is Eric Raymond’s “The Cathedral and the Bazaar.” There is no question that open-source has led to an upheaval in the world of business technology, enabled entirely new industries, and benefitted the overwhelming majority of individuals and companies out there, with few tears shed for those commercial vendors that have lost business due to open-source competitors. For those who do shed such tears, I strongly recommend Joseph Schumpeter’s “Capitalism, Socialism and Democracy.”

In this article, we will explore the legal side of open-source. This article was inspired by a rather heated debate on open-source licensing with The Schlossnagle. Theo is probably one of the best system engineers and architects I have met. He is the author of a book on building scalable Internet applications, and founded and runs the consulting firm OmniTI.

Open-source creates an interesting and unique series of challenges for its creators.

• Copying: In the closed-source world, while someone else can potentially reverse-engineer your product, or duplicate its functionality, in the open-source world, the original source is available right there for anyone to take. Thus, the only protection you have as to how your code is used is legal in the form of copyright.
• Usage: In the closed-source world, you have the option of using code inside your software to restrict its usage and functionality, based on, for example, license keys, which you control. In the open-source world, such an option does not exist. Since the code is open-source, it is easy for anyone to see how the usage controls work and bypass them.

Unsurprisingly, most open-source products allow for unlimited usage. For example, anyone can download and run as many copies of Apache, Linux or OpenBSD that they want. It is almost a truism that open-source and unlimited usage are the same. Obviously, they are not, but they essentially go hand-in-hand.

Where it gets interesting is in redistribution or repackaging. To understand this, we need to delve a little bit into the arcana of copyright law.

In most modern developed countries, copyrights give the author of some creative work the exclusive right to decide how his or her work may be redistributed. This does not include an original, depending on the laws of a country in question and sometimes the particular sales agreement, but duplicates. Thus, if I create a painting, and you (for some unknown reason, given my artistic talents) purchase it, in most cases you may then resell that painting to whomever you want and for whatever price makes you happy. However, under copyright law, you do not have the right to duplicate or copy (hence rights to copy or “copy-right”) that exact painting and sell it off. In doing so, you are violating my copyright. I, and only I, have the right to decide how my work gets duplicated.

All of this is particularly relevant in the world of open-source code. If I create an open-source product, when you download it, you have already created a copy. You are welcome to use it for your own use as you see fit. However, if you distribute it to someone else, especially for some form of compensation, and you have not received my permission to do so, you have violated my copyright.

Given all of the above, it is crucially important to decide exactly how the creator of open-source software will license that software. There are, essentially, two schools of thought in open-source licensing: GPL and BSD/Apache/MIT, which, for brevity, we will call BSD.

• GPL: The Gnu General Public License, based on the Gnu project by Richard Stallman, is a restrictive distribution license. While it has many details, its philosophy is, essentially, “I made this for free, you can use and distribute it for free. If you want to make money off of it, you cannot since I did not.” The GPL restricts distribution of the software to inclusion in any other software or product that is also GPL (or compatible). For many open-source developers, this makes a lot of sense. They are more than happy to contribute their work product to the good of the community, but do not want someone using that work product to make money unless they do. There really is one downside to the GPL: it restricts adoption. If what you have is unique, or used only in GPL-type products, then adoption will be high. But given the choice between a GPL product and an unrestricted one, a new product developer will always prefer to incorporate an unrestricted one.
• BSD: This is a class of license that says, essentially, do what you want with my product. There are variants on the BSD (not taking into account who was first) incorporated in the BSD, Apache, MIT and several other licenses, each of which contain legally important differences, such as limitations of liability, requirements of attribution, and other legalities, but essentially all of these licenses let someone use and redistribute the product largely at will. Thus, if I am building a commercial product, I am unable to use a GPL-licensed product in mine, but I can use a BSD one.

The battles between the BSD and the GPL camps can get fierce at times. The GPL was created by a “religious extremist,” the BSD is an “invitiation to legal piracy,” the list goes on. When a very powerful Web 2.0 rich client library, ExtJS, converted from a less restrictive version of the GPL (LGPL) to the full GPL, criticism by users was severe. In the end, both of these philosophies are valid, and are entirely subject to developer’s choice. If you created a product, you really do have three choices:

1. Keep it closed-source and sell it commercially. Microsoft and Oracle have built huge business on this, as have countless other companies. There is nothing wrong with reaping the financial benefits of your financial investment.
2. Open-source it and make it completely available, i.e. BSD. Again, there is nothing wrong with being fully community-focused, and either making no money on the product, or making money through ancillary services, such as consulting and support arrangements.
3. Open-source it and restrict it only to similar products, i.e. GPL. If there is nothing wrong with making money off of your labour and investment, and it is certainly commendable to contribute to the community, it is certainly acceptable to take a middle road that says, “I want to make money, but am willing to be altruistic towards others who are also altruistic.” Many products in the GPL world are dual-licensed, wherein the GPL applies to other GPL products, but if you want to embed it into a commercial product, you need to buy a typical commercial license.

Theo did raise one interesting objection to my middle-of-the-road argument in favour of GPL and/or dual licensing. He said that commercial and BSD-style are very clean and clear, black and white. One has a very clear picture where one stands. The GPL and dual-licensing, on the other hand, are much more in the middle, a shade of grey, and can be confusing. While I understand that objection, I am not convinced it holds for several reasons.

1. Life is grey. Very rarely is life, or business, black and white. Humans work quite well on the middle ground, codified as Maimonides’ “golden mean.”
2. If it works, use it. If the philosophy applies well to the situation at hand, then it should be used.

Which does this author prefer? None. Each license – commercial, BSD, GPL – has its time and place.

Over the last two days, a mailing list of which I am a member had an interesting – and sometimes sharp – exchange (pun intended) about whether or not the mass availability and advanced feature sets of Web-based, corporate-focused mail services, like Google Apps for Your Domain, are a threat to, and possibly the end of, internally managed collaboration products like Microsoft Exchange. This article will provide a short analysis of the arguments in both directions and a framework for analyzing when CaaS, or Collaboration-as-a-Service, makes sense .

Why CaaS?

Why is Google Apps (or Yahoo, for that matter) so appealing to an IT manager or CFO? Normally, it is portrayed as beneficial for two key reasons, one to suit the users, the other the CFO:

1. Everywhere: If you use browser-based email or collaboration, it is available everywhere – from your home, office, laptop, customer site, even Internet cafe in Thailand. While this does not usually allow you to “leave the laptop behind,” the inconvenience, which can lead to lost business, due to being tied to a particular piece of equipment to collaborate is a significant matter for most users.
2. Management costs: With a cost of $50/user/year for premium edition and $0 (a.k.a. free) for the basic edition, the financials are extremely appealing to the CFO. In addition to an often lower cost, the ability to turn a large amount of fixed infrastructure costs into variable costs that can increase and decrease precisely linearly with the number of employees is very valuable to any CFO. It is also valuable to any CIO who understands his or her role to be COO for information, rather than chief technology manager and implementor. Unfortunately, such CIOs are all-too-rare.

In direct response to the “everywhere” issue, most internal software providers, of which Exchange is the most well-known, have provided a browser-based interface to their products. In many corporations, Outlook Web Access, or OWA, is actually the primary method many employees use to retrieve their mail. Largely, this neutralizes the anywhere advantage. Thus, the primary argument in favour of CaaS in the form of Google Apps or any other such service is cost: it is cheaper, and it is variable.

Costs

Is it cheaper?

The answer, of course, is “it depends.” Let us analyze two extremes: a small 10-person business and a large 20,000-person multinational.

1. Our small 10-person business can get Google Apps for $50/person/year, for a total cost of $500/year. By contrast, Microsoft Exchange 2007 Standard Edition is $700, plus $67 per client access license, for a total of $1,370 before hardware. Of course, the business can use Microsoft’s Small Business Server 2008 with 10 client access licenses, for a total of $1,474, around the same amount. Add in hardware for $2,000 (it will actually cost a lot more), for a total of $3,500. Since a reasonable life expectation for this equipment is the standard 3 years, ignoring time value of money, the annual cost is over twice that of a CaaS solution. Add to that the ongoing costs of power, cooling, systems administration, problem-solving, and backups, and the CaaS solution’s appeal is very strong.
2. Our large 20,000-person multinational can get Google Apps for $50/person/year, for a total cost of $1MM/year. Unlike a small company, a large firm has to deal with significant issues relating to infrastructure redundancy, cost of routing, etc. Additionally, the bandwidth demands of 20,000 people accessing email over the company’s Internet connections can be quite high. On the other hand, the large company can gain significant economies of scale in utilizing its mail servers. Assume the company has 30 quad-core Exchange servers, with 1,000 mailboxes spread over each of 20 servers on average, 5 additional servers fronting Outlook Web Access, and 5 servers in failover mode for redundancy. Since the rule of thumb often used is 1,000 average users per core, this should be sufficient. 30 Enterprise Exchange 2007 server licenses is $4,000*30 = $120,000. Add in 20,000 client access licenses at $35/license for an additional $700,000, and software licensing totals $820,000. Each quad-core server is approximately $4,000, for a total of $120,000. Assuming each mailbox to be 2GB in size, total storage requirement per server is 2TB, or 40TB total. There are lots of routes to get this storage, but assuming the least efficient direct attached storage, the additional cost will be about $6,000 per server, for a a total cost of $120,000. Thus, the total upfront cost before any corporate discounts is $1,060,000. Since the expected life of the product is 3 years, and ignoring time value of money discount rate, the annual total is just over $350,000, or $17.50 per mailbox, one third of the CaaS cost. The maintenance and staffing costs can significantly increase the total internal cost to as much as triple or more.

Thus, the raw costs of the internal route for a company of scale are significantly below those of CaaS, while those of a small business are significantly higher. To answer the first question, “is it cheaper?”, the answer depends on company size. At some point in scale, it becomes cheaper to do it in-house than out of house. My own experience shows that the point at which the two cross is actually quite high, somewhere between the 5,000 and 10,000-person mark. The primary concern is, quite frankly, how efficiently the internal IT team operates. If they keep costs low and are highly automated, then raw hardware and software costs dominate, and internal costs are much lower; if they do not, then labour costs dominate and the internal costs can match or exceed external costs.

Thus, from a costs perspective, CaaS will almost always be cheaper for small business, whereas larger institutions can sometimes save money in-house depending on their internal labour and operating costs and efficiencies. The challenge is that often costs are mixed together. The IT mail maintenance team may also support file-sharing servers; Internet bandwidth costs may be a single line item on the IT infrastructure budget; and storage costs may be subject to odd forms of fixed-cost accounting. Only an unbiased internal analysis that quickly isolates all of the costs correctly, including current and ongoing costs in both scenarios, and fully understands technology usage patterns and benefits, can correctly determine the optimal cost path.

Non-Cost Considerations

For many enterprises, however, cost is not make or break. Other considerations unique to the business operating or regulatory requirements of a particular organization or industry may have a far greater impact. In this section, we will explore those considerations and how they impact the CaaS vs. internal choice.

Budgeting

Going back to our 20,000-person company, we determined that every three years or so, on average, the firm would need to spend about $1MM in software and hardware refreshes. In most companies, these expenses would (properly, although I am not an accountant) be considered capital expenses, an asset purchase with a three-year lifespan. However, within most businesses, the process of getting OpEx, or operating expenditures, is significantly different from the cost of CapEx, or capital expenditures. Whereas an IT manager can usually get operating expenditures, whether increased or decreased, as part of the normal budget cycle plus some special approvals process at the time of expenditure beyond some threshold, capital expenditures, especially those of $1MM or more, require many more hoops to jump through. For this reason alone, if the CapEx approval and justification process is particularly difficult, there are significant advantages to CaaS, which is essentially a service leasing model. I have one client who, after several years, switched from owning and maintaining their Enterprise Resource Planning (ERP) software and hardware infrastructure to leasing it as a service. The cost financials were largely the same. However, with the lease model, the ERP manager and the CIO have converted CapEx headaches into ongoing operating expenditures. The era of capital investment battles, at least for ERP, are over.

Operating Risk

When dealing with technology services, there are essentially three layers of risk: systems, software and network. Each one needs to be managed differently and separately from a technology risk reduction perspective. However, from a business perspective, our concerns are the risk of failure and the impact on the business. Systems and software risk are identical, from the company’s perspective, whether the service is internal or CaaS. Network risk, on the other hand, differs dramatically. In the case of CaaS, loss of or significant degradation in Internet connectivity means complete loss of email service, both employee-to-employee and employee-to-outsider. In the case of internal email service, only employee-to-outsider (and reversed) is affected; employee-to-employee continues to function. The impact of this differential depends on the nature of the organization’s email usage patterns.

In most small businesses, a large proportion of mail is sent between internal employees and external customers, vendors and partners. Thus, the risk with the greatest impact is loss of Internet connectivity. As soon as the Internet connection is no longer available, or performance is degraded beyond effective usage, email essentially ceases to exist, whether the mail service is internal or CaaS. The very nature of the smaller organization size also makes it easier to work around those failures. A 10-person shop can simply use the phone, as inefficient as it may be.

In larger organizations, a larger proportion of email is sent internally between various departments or regions. Thus, loss of Internet connectivity, while painful, is not equivalent to loss of email entirely. Thus, the larger organization will suffer much greater dislocation if connectivity to the CaaS provider is lost, even though internal services continue to function. Further, the sheer size of the organization makes replacing email with phone calls nearly impossible.

Regulatory & Litigation Risk

Many businesses operate in a regulatory environment that requires them to do one or more of the following. Some companies may wish to do these for legal protection reasons.

1. Retain and/or review all emails over some period of time.
2. Keep copies of emails for some period of time.
3. Remove all copies of emails after some period of time.

Essentially, regulators of various stripes insist the company exercise different types of control over email. For example, some European countries forbid companies from ever looking at employee email, under privacy laws, while others require companies to review email for inappropriate, illegal or offensive behaviour, such as harassment or insider trading. This author is perfectly aware that these requirements may be conflicting. I once worked with a large multinational bank that operated in Switzerland, Germany and the United States, among others. German regulators forbade the bank from reviewing email; American regulators required regulators to review the emails. It was literally impossible to comply with both simultaneously. The solution required re-routing email based on source and destination in ways that they would never become part of two conflicting jurisdictions simultaneously, an absurd and expensive situation but one required by the circumstances.

Some CaaS providers can meet some of the requirements; almost none can meet all. Additionally, lack of knowledge of location of the CaaS servers and storage can open a regulatory morass, a veritable Pandora’s Box. Thus, in circumstances where conflicting and changing regulatory and litigation regimes require fine-tuned control over email behaviour and routing, both during viewing and for a time period thereafter, CaaS is unlikely to provide a viable solution for a while yet, until some CaaS provider focused primarily on these issues arises.

Privacy

Privacy is an issue for many entities. Organizations are concerned that the CaaS providers, primarily Google, but also Yahoo and Microsoft, have too much knowledge of their personal and employee behaviour. Many are reluctant to place every email they send, inbound and outbound, through servers managed and controlled by these companies. Although these concerns are legitimate, it is important to note that they are not as severe as normally raised. This is not because the companies are unlikely to mine or use email content; quite the opposite, they are highly likely to do so. Rather, it is because email that goes outside the organization, unless encrypted, is already largely public. There are no “sealed envelopes” like in normal “snail mail”,  and regulations in many countries do not equate email theft with mail theft. Further, many organizations already use SaaS mail filtering services for spam and viruses, like MessageLabs (owned by Symantec) or Postini (owned by Google). The excellent consumer and small business security company Webroot also provides enterprise services, and is a flexible alternative without being bound to Symantec’s sales procedures or Google’s mining.

Is It a Threat?

As we have shown, internally managed email and collaboration services will exist for a very long time. CaaS is definitely a threat to Exchange at small organizations, where the cost far outweighs the benefits. However, many organizations, especially large ones with complex technology, legal, privacy, budgeting and cost requirements will perform this analysis and decide they need internal email infrastructure. Exchange and its competitors will continue to be a critical product for organizations with requirements that lead to internal deployment and management. An interest proof that even Web companies are of the same mind is Zimbra. Zimbra makes a fully open-source, Web-based Exchange competitor. On October 4, 2007, Yahoo acquired Zimbra for $303MM in mostly cash and some equity. Clearly, even Yahoo, a Web pure-play business, saw the need to continue to have a presence in the internally installed and managed email and collaboration software industry.

Making the Decision

In sum, to decide between CaaS and internal email, one needs to analyze the following major factors:

• Software and hardware costs, including timing of outlays and discount rates
• Ongoing maintenance costs, including power, cooling, administration and support
• CapEx budgeting, including relative difficulty of releasing CapEx funds versus OpEx funds, and the preferred accounting treatments of assets on balance sheet
• Operating risk tolerance for network failures, as driven by email usage patterns and available alternatives
• Regulatory and litigation risk, including requirements for multi-facted and often conflicting retention, review and privacy rules
• Privacy preferences, and concern for passing all mail, internal and external, through a third-party provider

An single analyst or consultant should be able to determine these requirements for a company of any size in no more than eight weeks at the outside. If your organization does not have the staff with the mix of technology, finance, operations, legal and political skills, consider an outsider, but make absolutely sure that (a) they have all the skills and (b) they can execute quickly.

Insource vs. outsource, CaaS vs. internal, is a major decision with significant ramifications. Doing it correctly can have a significant impact on the business; doing it wrong can cost millions. Make sure to do it right.

In dealing with e-commerce solutions over the last several weeks intensely (and the last several years in general), I have come to the conclusion that there are four different categories of e-commerce solution providers: gateways, processors, providers and promisers. 

In understanding these categories, as in all projects where you have a defined goal, it is important to understand what your e-commerce goal is. Most e-commerce occurs where the vendor wants to sell something to the customer. All is good and fine, until the vendor needs to take payment. That payment can occur in lots of ways (barter, cash, gold, diamonds), but online usually takes some form of electronic payment. This is usually a credit card payment or e-payment (like PayPal), but can also be e-checks, especially since the creation of Check21 and the wider acceptance of ACH in recent years.

So you, as a vendor, have a need, once you have decided to accept payment from a customer, to accept that payment from them. You have three choices:

1. Gateways: Gateways provide nothing more than a direct line to handle the nitty-gritty of credit card processing. Authorize.net is one of the more well-known, but others exist. When you use a gateway, you are saying, “I want to do everything myself, I even have the credit card merchant account, but someone has to process the payment.” Your costs are likely to be quite low, your technical requirements quite high. Unfortunately, most of the gateways are actually still quite primitive. For example, it is nearly impossible to get decent machine-readable (= automated) information about chargebacks, and when they do arrive, they often lack enough information to match them to an initial transaction that may have occurred months or longer ago. To make matters worse, they often include the original credit card number, which is unnecessary and complicated PCI-DSS compliance.
2. Processors: The processors provide you with some basic services on top of the gateways. First, they may use multiple gateways, providing some reliability and redundancy for you. Second, they may do a lot of the heavy lifting to automate some processes so that you can use Internet-age technology and tools to manage payment processing. Third, they may include direct access to some of the e-payment systems, which a gateway cannot. Fourth, the processor brand may provide some level of security and comfort for your customers. Fifth, they can alleviate the PCI-DSS compliance burden in some cases, by removing the need to handle credit card data at all. Sixth, they can provide some more rapid response, for example notifying your infrastructure of payment events (authorize, capture, reject, etc.). Notable entrants in this area are PayPal, Amazon and Google. 
3. Promisers: The promisers promise the world. They are all in one solutions that include a cart, coupons and discounts, cross-sells, up-sells, customer reporting, you name it. They may even have a complete licensing system. They handle everything for you. They are the easiest to implement and get started with. Some examples include Kagi, esellerate and others. Many have been bought up by Digital River, which, unfortunately, has let the engineering and investment side (and certainly the user experience side) slip into well below mediocrity. The downside of any of these? You are tied in tightly. If what you want doesn’t work with them, tough luck. You may have to change your business model (as one company I recently worked with did) to suit their infrastructure rather than change your systems to meet your business model. They also make it difficult to work part-and-part, e.g. licensing from one supplier, sales from another, cart from another. Finally, their costs tend to be fairly high.
4. Providers: The providers category is pretty new. They live somewhere between the Processors and Promoters. A great example is FastSpring. You manage the user experience on your site. However, when you are ready to actually sell or add to a cart, you do it on their site. They provide open URL access to the product, and many of the instant notification features of Processors, along with the price and promotion management features of the Promisers. Their costs tend to be somewhere between the Processors and Promisers. They are very quick to get up and running, especially the new Web 2.0 ones, but sometimes lack the catalog/product controls that you would get from managing it on your own (although then you would have to implement it).

Where do these rank for those looking for a commerce solution?

• If you have simple products to sell, with fairly straightforward up-sell, cross-sell and discount needs that you do not expect to grow or change – a.k.a this is either a hobby or a small business that will remain small – the Promisers will suffice. Be prepared, however, for high variable costs and great pain if you ever want to pull apart… you will likely need expert help to tease apart the components. On the upside, consultants like us love those. 
• If you are doing very complex transactions, recurring transactions, and need to store your own payment data, or if you have very high volumes, you are most likely to use the gateways. Your fixed cost in maintaining them will be high, but you will have the greatest control and direct access and lowest per-transaction costs.
• If you are prepared to maintain your own storefront, or desire to do so for control purposes, but want a decent system to handle reporting and ease of access, use the Providers. I have been very impressed by FastSpring thus far, although some level of control over what products are available under what conditions would be hugely useful. Just about everyone who sells any volume has specials that only apply to certain customers under certain conditions (time, past purchases, membership in a special club, etc.). The Providers make everything available if you know the URL, and in the age of the Internet, nothing remains hidden for long. Security by obscurity is a recipe for insecurity.
• If you just have a few products to sell, and you want the lowest-cost fastest implementation, go for the Processors. PayPal as the lead, followed by Google and Amazon, have made implementing payment processing extremely easy, although the easiest to use are also easy for anyone to fool, or even set up a pirate page on a Russian server that even non-technical users can use to fool your page. As soon as you add some security and controls, it gets more complex. Kudos to PayPal for their usage of encrypted buttons to allow you to still use their “easy” product (Website Payments Standard) but provide some protection.

So having gone through the above (see previous posts), there are basically two choices when it comes to implementing licensing schemes.

1. Sell the upgrade. Many sales systems, even fairly primitive ones, support this. You create a separate SKU for each major release, and possibly for each minor, and a separate license key scheme for each major release (but not minor). The licensing ensures that different minor releases within the major release will allow cross-upgrades (or downgrades). For the sales, you create a coupon that says, “if a return purchaser bought one of the following SKUs (all those in the previous major release), give them x% off for this SKU (all those in the latest major release). Note that some systems do have limitations with this. For example, esellerate can apply the coupon for everyone, one time, or one time by email. But what if a previous purchaser bought 3 copies? Well, then, you are out of luck.
2. Sell the plan. You need to manage your customer data set on your own. You then need to manage the customer interaction with the sales system, so that only appropriate users see the appropriate pages, either the regular SKU with an appropriate applied discount, or special discount SKUs. 

Inevitably, one will ask, can any sales system handle being so controlled from your Web store, such that it will only display appropriate pages to appropriate people? One does not want to have a new buyer get to the supposedly hidden pages and get the product for free! As the old saying goes, “security by obscurity is insecurity.” Here is a short summary of what I have found.

1. No open-source cart system manages this. Period. Zen-Cart, osCommerce, CubeCart, even the new Magento all fall short. Nor I have seen a commercial system that manages it.
2. The sales channel providers, like FastSpring, which combine sales management, reporting, up-sells/cross-sells and the like, but have the actual catalog per se on your page, are focused on letting you sell anything you want, provided the URL is correct. Needless to say, this is not something they offer. FastSpring is pretty impressive, but is not built for this. 
3. Surprisingly, the best solutions come from the least-featured providers. PayPal Website Payments Pro, Google Checkout XML API and Amazon FPS all are strong in this area because they allow your site to talk to their service, server-to-server, and will reject any transaction that your server has not approved. The downside to all of these is that accepting credit-card information means you must become PCI-DSS compliant, a not-insignificant effort. It is not very difficult, especially if you never store credit-card information, and almost all of the recommendations are good security practice, but a small ISV may simply not have the time to deal with it. I recently worked with a client on converting to PCI-DSS compliance. We did the analysis very quickly, but the conversion is taking time. 
4. The lower-end services of these Internet giants are less functional in this area, with one shining exception. Google Payments HTML API and Amazon Buy Now buttons both depend on data stored in the user’s browser to submit payment information. A user could easily change the information and get the cheaper or free prices, and even set up a Website to make it easier for others. The shining exception is PayPal, which is strong because of its weakness. Like the others, PayPal’s Payments Standard system is built around buttons that are configured and submitted from the user’s browser page. Because users can modify these and submit, thus cheating the ecommerce seller, there is an option to encrypt the buttons, thus allowing PayPal to authenticate that the values are valid. Put in other terms, PayPal’s need to resolve its weakness provides a strength in dealing with this issue. 

A number of providers also provide post-processing notification. FastSpring has Notification by POST to a Web site, PayPal has IPN. These can provide backstops, but they are not recommended for this purpose. Why? Because they only allow you to confirm or deny a sale after it is done, meaning the user thinks s/he is done and then gets told, sorry, no deal. This may even run afoul of consumer protection laws.

Conclusions:

1. For the short-run, if you need to boost sales by selling upgrades, sell upgrades to major versions, free updates to minor versions, and use whatever your sales channel will support.
2. For the long-run, get control of your customer data within your own databases, and provide authenticated Web API access. Wrap the data with a business logic layer, and then provide interfaces to your sales channel, so you can control how customer specials are managed.
3. If you need more complex structures, use PayPal or similar services until the mid-channels are mature enough to provide them.
4. Hopefully, at some point, the mid-channels like FastSpring will expand to provide these services.

In the previous post we discussed implementing Option A: Sell the Upgrade. Now we will address Sell the Plan. 

Sell the Plan has a lot of appeal for ISVs, especially when you start to sell to businesses, non-profits, or any group that budgets. The benefits are:

1. Predictable cash flow. The reality is that most individuals and organizations that have recurring charges simply keep on paying them. This creates more predictable cash flow for your ISV business.
2. Earlier revenue recognition: Let us assume that you release version 1.0 in Jan 2006 and 2.0 in Apr 2007. If you sell the upgrade, the purchaser of 1.0 will wait all the way until April to pay you. On the other hand, if you sell the plan, by Jan 2007 he is already paying you the plan fees for the coming year.
3. Easier recurring sales. Most organizations budget capital expenditures, especially for new purchases, separately from ongoing operating expenses. The $50 they will spend next year to buy the next version of your product must be approved and budgeted, and for the following version, and again. On the other hand, if buying the product the first time comes with an annual $50 charge for “maintenance,” it gets built right into the ongoing operating budget and is automatically approved.

It is important in this scenario to give new purchasers at full retail a “free” year (more or less, depending on your customers, but a years is fairly standard) of upgrade plan. The free helps you sell, but also avoids the sense from them that they are getting no support in terms of patches, upgrades, etc. 

So how do we go about implementing “Sell the Plan?” Again, we have multiple scenarios.

1. New purchaser: This purchaser simply buys the product outright at full retail price, in our case $100.
2. Return purchaser on plan: This person should be able to upgrade for free, whether it is because they are within their “free” year, or because they are within another year (or ten) of paid plan.
3. Return purchaser off plan: This person should be able to upgrade, but not for free. Instead of buying the new product, they buy another year (or more) of plan. This plan is normally sold at some discount off the current retail price of the product. In our scenario, we will assume it to be 50%.

How does implementation of each of these scenarios happen?

1. New purchaser: This is a standard sale. The purchaser buys it outright, gets a license key, installs, and goes.
2. On-plan purchaser: This is complex. This can be implemented either via the licensing system or the commerce system.
   • Licensing system: The licensing system needs to issue licenses that understand when upgrades are allowed and when they are not. It further needs to recognize when a version was released, compare that to the range of dates for which upgrades are allowed, and then allow or disallow the upgrade. I have not seen a single, solitary license system that can do this.
   • Commerce system via product SKUs: As in the “Sell the Upgrade” scenario, you can either have limited availability SKUs or the same SKU as new purchases, but with special coupons. In either case, the commerce system needs to  recognize that this is a returning user and precisely what rights they have. I have seen no commerce systems that do this correctly, either. The closest I have seen is that some systems will issue coupons based on previous purchases of a particular SKU by a returning user. However, these systems all treat the upgrade (for free) purchases as if they are new, and thus give them a whole new year for free.
   • Commerce system via plan SKUs: This is an approach that no commerce system has recommended, yet offers an intriguing new way. Each product has its own SKU, and each plan for free upgrades (12 month, 24 month, etc.) has its own SKU. When someone purchases a product outright, they receive the free upgrade SKU bundled with it. When they come to upgrade, the commerce system should recognize that they have a recent purchase (within time frame) of the plan SKU, and either give them access to the limited availability free upgrade SKU or the appropriate discount coupon for the regular SKU. Again, I have seen no commerce system do this outright, but some have shown flexibility in the right direction.
3. Off-plan purchaser: An off-plan purchaser is one who once was on-plan, and is now off. Essentially, they need the ability to subscribe to the plan again. This requires a separate SKU for plan, followed by a recognition of the ability to join the “free download” group. However, it is important that the commerce system only allow someone who once purchased to join the plan, else anyone will just buy the plan SKU at less than full retail and get free upgrades.

Conclusions:

1. Commerce system intelligence is a must. No system has shown the ability to do this, but some have shown promise. See my follow-up post on commerce systems.
2. Some of this can be handled in licensing, but some must be handled in commerce systems. As before, make commerce systems your focus.

As a follow-on to the previous post about licensing strategies for ISVs, I would like to discuss the nitty-gritty implementation details. It turns out that the open market has not been very kind to mISV firms, and have left with very few options, none of which provides the desired flexibilities. This post will discuss “Sell the Upgrade.” A follow-on will discuss “Sell the Plan.”

So you want to implement sell-the-upgrade. To do that, you need to have several scenarios, all working in concert. You have released one products with three versions: 1.0, 1.5 and 2.0. You are currently selling 1.5, but will soon start selling 2.0.

1. New purchaser: This is, of course, easy. You have a single product, call it SKU15, representing version 1.5. Everyone pays full price, say $100.
2. Return purchaser: This is someone who already bought 1.0 and now wants to upgrade to 1.5. The return purchaser should pay nothing for version 1.5, as it is a minor upgrade. You have a few choices: 

• Keep the same SKU for upgrade purchases and new purchases of all releases of the major version of the product. SKU10 covers version 1.0 and 1.5, whether new purchase or upgrade. Rely on your licensing system to recognize the allowed upgrade. This usually works if the same license set covers both version 1.0 and 1.5.
• Use the same SKU for upgrade purchases as for new purchases, but different between minor versions, and rely on your commerce system to recognize that this purchaser bought 1.0 already and is thus allowed a 100% discount off the purchase price of that SKU. 
• Use a different SKU for upgrade purchases than new purchases, say SKU15U (U for upgrade), and rely on your commerce system to recognize the allowed purchase. In other words, it is a limited availability SKU. 

In both of the commerce-system-dependent solutions, an upgrade means buying the new product, but having the commerce system recognize the purchaser as someone who purchased before, and thus give them the product at 100% off, either via discount of limited availability SKU. It is important that the commerce system recognize that the purchaser is a returning purchaser, and exactly how many copies they have the right to upgrade. For example, someone who bought 5 copies of 1.0 should have the right to purchase 5 copies of 1.5 for free, but not 50 copies. There are varying ways to do this, but very few, if any, commerce or cart systems seem to know how to manage this.

Now we move to major upgrades. People are buying version 2.0.

1. New purchaser: This is, again, easy. You have a single product, call it SKU20, representing version 2.0. Everyone pays full price, say $100.
2. Return purchaser: This is someone who already bought 1.0 or perhaps 1.5 and now wants to upgrade to 2.0. If you don’t give upgrade discounts, it is very easy: they are just like a new purchaser. However, most ISVs, especially mISVs, give upgrade discounts. For argument’s sake, let’s say our discount is 50%. The return purchaser should pay $50 for this upgrade. Managing this through the licensing system is nearly impossible, since they can only upgrade if they pay something, which means a new purchase, which means a new license key. Additionally, you are likely to have a separate SKU for this new version. Thus, your only choice is to manage it through the commerce system. Within the system, you have a few choices: 

• Use a different SKU for upgrade purchases than new purchases (SKU20 and SKU20U). Rely on your commerce system to recognize the allowed upgrade. Again, this is a limited availability SKU.
• Use the same SKU for upgrade purchases as new purchases (SKU20). Rely on your commerce system to recognize that this is an upgrade purchase, and thus provide the appropriate 50% discount.

In both of these cases, you depend on your commerce system for a lot of intelligence about returning purchasers. Once again, I have seen few, if any, commerce systems that can do this properly.

So, what is the solution to sell-the-upgrade?

1. Recognize that most of this is going to happen through the commerce system. Have a good cart of system that ties closely into your customer history database.
2. Make licensing as easy as possible, and have it trust your commerce system. Licensing may solve some of it, but major upgrades between SKUs will have to generate new license keys, so focus your energies on commerce systems.

esellerate, despite many other severe issues (not least of which is absurd pricing), does have the ability to do this decently using coupons. Their customer technical support is also excellent.

I have recently spent time with the various open-source cart solutions: magento, zen-cart, oscommerce and cubecart, as well as esellerate and a nice newcomer service, FastSpring. I will write a separate blog post on these services and carts soon. Unfortunately, none of these has the ability to do this cleanly. 

Next up: “Sell the Plan.”

For the last several months, I have been involved with a particular very small ISV, almost a micro-ISV (mISV), as it prepares for growth. One of the key elements we identified is that its pricing model – unlimited free upgrades – is not exactly conducive to good revenues and profitability. Although it seems obvious, it needs to be stated, and for several reasons.

1. Founders sometimes feel that to charge for upgrades would somehow offend existing customers. This was not at all the case with this customer. Nonetheless, many are afraid to do so. The opposite is true. Most customers not only understand that the service a vendor provides is ongoing, and requires compensation, but want to ensure the vendor will be around for a long time. Wisely, this founder had been saying from the beginning that as of now, upgrades are free, but he reserves the right to change it.
2. People equate value with price. Sure, everyone looks for a bargain, but if something seems too cheap, too good to be true, they subconsciously, and sometimes consciously, assume it to be, well, cheap and worthless. For a great reference, see Joel Spolsky’s article in the Inc magazine of July 2008.
3. Repeat customers are always lower cost to sell to than new customers, in every business.

It seems fairly simple, then, to charge for upgrades. But how to do it? We were left with two primary options:

1. Charge full price for a new customer, 40-50% off for upgrading customers at major revisions. This means buyers of 2.5 get 2.6 for free, but pay discounted price for 3.0. This is known as “sell the upgrade.”
2. Charge full price for a new customers, give them 12 months (or similar) free upgrades, whether minor or major versions. When the 12 months are up, they get no upgrades or updates. At that point, they can buy another 12 months (or similar) of free upgrades at 40-50% off the then-current retail price. This is known as “sell the plan.”

Sell the upgrade is cleaner to manage and implement, and is similar to what most large vendors do. When you buy Windows XP or Mac OS X Tiger, you get all the service packs for XP and updates for 10.4 for Tiger for free. You do, however, have to pay for Vista or Mac OS X Leopard.

Sell the plan has better revenue timing (it comes in earlier), and better cash flow. Further, it makes it much easier to sell to organizations that budget. Rather than a capital expenditure each year or two, it becomes a maintenance expense, built into the operating budget each year automatically.

For the above reasons, we went for sell the plan.