Sustainable software, part II: Proprietary, with a clue

Previously, on “Sustainable software”:

Only scarcity generates economic goods, that is goods that have economic value (we don’t pay for air and seawater). Digital goods such as software can be infinitely duplicated at zero cost, so they need a form of artificial scarcity, such as obfuscation and limited access, to justify a price tag. Artificial scarcity, in turn, needs a barrier to entry to resist the attack of competitors and alternatives: traditional barriers such as monopolies, complexity and lock-in are challenged by people scratching their own itches (Open Source) or by the intrinsic lack of complexity in building software (DYI).

At the end of the day it takes just Economics 101 and a pinch of common sense to realize how the software industry has an intrinsic problem. It is interesting to note how software has been digging his own grave by failing to provide enough value: the good news is that once you isolate the cause, you have a chance to find a cure. Which means there is hope for a license revenue model, after all, but it needs to be carefully thought out.

Let’s get rid of exceptions, first: there will always be the unprecedented case of a genius providing exactly what the market needs, at the very right moment. She will be able to charge loads of money, dictate her own conditions and get filthy rich in no time flat but, from a big picture perspective, we shouldn’t let exceptions distract us from business plans: chances for a software house to make billions overnight are as slim as the odds to be a professional sport player (as pointed out by the first commenter to this post). Sure enough, Tiger Woods is making millions by the minute out there, but would you let your child put all eggs in one basket to pursue a professional sporting career or would you rather suggest a plan B in terms of higher education and backup plans?

If we focus on the changes of average Joes out there willing to make a living out of software licenses alone, there is only one way to look at it: the business plan has to ensure barriers to entry are there to stay. If the barrier to entry is strong enough, very few will be motivated to build or market an alternative, and licensing money will keep on flowing. Now how do you do that? My personal recipe for a commercial/proprietary company looks like this:

  • Find a sweet pricing spot. Software has been plagued by questionable pricing tactics (predatory, supra competitive, or both). Pricing is your best friend if you play by market rules, and your worst enemy if you use it to gain a short term advantage. In a connected world, alternatives are one click away, but there is very little motivation in looking for (let alone building) an alternative if the price is just right, and even more if you err on the cheap side.
  • Link cost to value. What’s the deal with extorting money for non-production servers? What’s the point in counting CPUs or user seats when we are talking cloud computing and distributed environments? If your application is stupid enough to be clustered only as master-slave, don’t you feel ashamed when you require customers to pay an additional license for a node doing nothing but homework you should have done yourself? As a customer, I’m happy to pay (a fair value) for something that will cost you to provide, but the moment you cross the thin line between upselling and milking, I’ll be on the market.
  • Embrace openness. Your software will most likely have defects and bugs, and there is a good chance I will have to extend it to suit my needs. Don’t get in the way: give me extension points, and give me the ability to fix the problems I find (or pay someone to do it for me). Yes, I might screw up the system, and in that case you will be perfectly right in turning your back on me me, but aren’t successful relationships supposed to be based on trust? Protecting your source code from appropriation is fine, but you can easily accomplish that without obfuscating it and prohibiting me to work with it: if you obfuscate, I will start questioning what you might have to hide.
  • By all means, do not open source it. Give me a free alternative, and you can kiss your money bye-bye. Don’t let it be an excuse to ignore Open Source, though: chances are you will be using a number of Open Source components, and it will be very shortsighted not to have a stake in the commons. You want to contribute to those components, and you might even consider Open Sourcing the most general bits of your application, but you should never, ever have the full enchilada up for grabs. You still want to foster usage, of course, but there is a number of ways to do that, such as free licenses for non-commercial endeavors or individuals. Your licensing scheme needs to be liberal, but your revenue stream has to be protected.

Once again, please note that the following rules apply to a commercial and proprietary software house looking for a license based revenue model, and they are based on the general assumption of a cool software product (which is very hard to find these days). Future posts will analyze scenarios for a number of Open Source models, starting from what I believe is the biggest anomaly to date: Commercial Open Source.

Leave a Reply