Freemium Is The New Piracy In The SaaS World

It is estimated that approximately 41% of revenue, close to $53 billion, is "lost" in software piracy. This number is totally misleading since it assumes that all the people who knowingly or unknowingly pirated software would have bought the software at the published price had they not pirated it. RIAA also applies the same nonsense logic to blow the music piracy number way out of proportion. The most people who pirate software are similar to the people who pirate music. They may not necessarily buy software at all. If they can't pirate your software, they will pirate something else. If they can't do that, they will find some other alternative to get the job done.

Fortunately, some software companies understand this very well and they have a two-pronged approach to deal with this situation: prevent large scale piracy and leverage piracy when you can't prevent it. If an individual has access to free (pirated) software, as a vendor, you're essentially encouraging an organic ecosystem. The person who pirated your software is more likely to make a recommendation to continue using it when he/she is employed by a company that cannot and will not pirate. This model has worked extremely well. What has not been working so well and what the most on-premise vendors struggle with is the unintentional license usage or revenue leakage. Customers buy on-premise software through channels and deploy to large number of users. Most on-premise software are not instrumented to prevent unintentional license usage. The license activation, monitoring, and compliance systems are antiquated in most cases and cannot deal with this problem. This is very different than piracy because the most corporations, at least in the western world, that deploy the on-premise software want to be honest but they have no easy way to figure out how many licenses have beed used.

In the SaaS world, this problem goes away. The cloud becomes the platform to ensure that the subscriptions are paid for and monitored for continuous compliance. You could argue that there is no license leakage since there are no licenses to deal with. But, what about piracy? Well, there's no piracy either. This is a bad thing. Even though a try before buy exists, there's no organic grass-roots adoption of your software (as a service) since people can't pirate. In many countries where software piracy is rampant, the internet access is not ubiquitous and bandwidth is still limited. This creates one more hurdle for the people to use your software.

So, what does this mean to you?

SaaS ISV: It is very important for you to have a freemium model that is country-specific and not just a vanilla try-before-buy. You need to get users start using your service for free early on and make it difficult for them to move away when they work for someone who can pay you. Even though you're a SaaS company, consider a free on-premise version that provides significant value. Evernote is a great example of this strategy. It shouldn't surprise you that people still download software, pirated or otherwise. Don't try to change their behavior, instead make your business model fit to their needs. As these users become more connected and the economics work in their favor, they will buy your service. It's also important to understand that the countries where piracy is rampant, people are extremely value conscious.

On-premise ISV: Don't lose your sleep over piracy. It's not an easy problem to solve but do make sure that you're doing all you can to prevent it. Consider a freemium business model where you're providing a clean and free version to your users. If the users can get enough basic value from a free version, they are less likely to pirate a paid version. What you absolutely must do is to fix your license management systems to prevent unintentional license usage. Help yourself by helping your customers who want to be honest. The cloud is a great platform to collect, clean, and match all the license usage data. You have a little or no control over customers' landscapes but you do have control over your own system in the cloud as long as there's a little instrumentation embedded in your on-premise software and a hybrid architecture that connects your on-premise software to the cloud. In nutshell you should be able to manage your licenses the way SaaS companies manage their subscriptions. There are plenty of other benefits of this approach including the most important benefit being a SaaS repository of your customers and their landscapes. This would help you better integrate your future SaaS offerings and acquisitions as well as third-part tools that you might use to run your business.

Life Is Too Short To Remove A USB Stick Safely

Today, Steve Jobs resigned as a CEO of Apple. I think I will remember this day and so will others.

“Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don’t settle.” — Steve Jobs

For me, Apple is not just a personal choice that is better than other alternatives, but it's also an ongoing proof of what's possible if you believe in what you think is the right thing to do. It's also about the elements of design and endless perseverance that I can thrive for. Thanks Steve for showing what's possible and wish you all the best with your health and a speedy recovery. I hope you can stay on and mentor others at Apple for what's going to be a great future of computing.

Parallelism On The Cloud And Polygot Programmers

I am very passionate about the idea of giving developers the control over parallelism without them having to deal with the underlying execution semantics of their code.

The programming languages and the constructs, today, are designed to provide abstraction, but they are not designed to estimate the computational complexity and dependencies. The frameworks such as MapReduce is designed not to have any dependencies between the computing units, but that's not true for the majority of the code. It is also not trivial to rewrite existing code to leverage parallelism. As, with the cloud, when the parallel computing continues to be a norm rather than an exception, the current programs are not going to run any faster. In fact, they will be relatively slower compared to other programs that would leverage parallel computation. Robert Harper, a Professor of Computer Science at Carnegie Mellon University recently wrote an excellent blog post - parallelism is not concurrency. I would encourage you to spend a few minutes to read that. I have quoted a couple of excerpts from that post.

"what is needed is a language-based model of computation in which we assign costs to the steps of the program we actually write, not the one it (allegedly) compiles into. Moreover, in the parallel setting we wish to think in terms of dependencies among computations, rather than the exact order in which they are to be executed. This allows us to factor out the properties of the target platform, such as the number, p, of processing units available, and instead write the program in an intrinsically parallel manner, and let the compiler and run-time system (that is, the semantics of the language) sort out how to schedule it onto a parallel fabric."

The post argues that language-based optimization is far better than machine-based optimization. There's an argument that the machine knows better than a developer what runs faster and what the code depends upon. This is why, for relational databases, the SQL optimizers have moved from rule-based to cost-based. The developers used to write rules inside a SQL statement to instruct the optimizer, but now the developers focus on writing a good SQL query and an optimizer picks a plan to execute the query based on the cost of various alternatives. This machine-based optimization argument quickly falls apart when you want to introduce language-based parallelism that can be specified by a developer in a scale-out situations where it's not a good idea to depend on a machine-based optimization. The cloud is designed based on this very principle. It doesn't optimize things for you, but it has native support for you to introduce deterministic parallelism through functional programming.

"Just as abstract languages allow us to think in terms of data structures such as trees or lists as forms of value and not bother about how to “schedule” the data structure into a sequence of words in memory, so a parallel language should allow us to think in terms of the dependencies among the phases of a large computation and not bother about how to schedule the workload onto processors. Storage management is to abstract values as scheduling is to deterministic parallelism."

As far as the cloud computing goes, we're barely scratching the surface of what's possible. It's absolutely absurd to assume that the polygot programmers will stick to one programming model and learn to spot difference between parallelism and concurrency. The language constructs, annotations, and runtime need to evolve to help the programmers automate most of these tasks to write cloud-native code. These will also be the core tenants of any new programming languages and frameworks. There's also a significant opportunity to move the existing legacy code in the cloud if people can figure out a way to break it down for computational purposes without changing it i.e. using annotations, aspects etc. The next step would be to simplify the design-deploy-maintain life cycle on the cloud. If you're reading this, it's a multi-billion dollars opportunity. Imagine, if you could turn your implementation-specific concurrent access to resources into abstract deterministic parallelism, you can indeed leverage the scale-out properties of cloud fairly easily since that's the guiding principle behind the cloud.

There are other examples you would see where people are moving away from an implementation-centric approach to an abstraction that is closer to the developers and end users. The most important shift that I have seen is from files to documents. People want to work on documents; files are just an instantiation of how things are done. Google Docs and iPad are great examples that are document-centric and not file-centric.

Photo courtesy: bass_nroll on Flickr

Plotting for serendipity

I rarely eat lunch at my desk. Eating lunch in a cafeteria is such a precious opportunity to waste. I plot for serendipity. That's right. Some of the best conversations that I have had with people — on my way to a cafetaria or in the cafeteria — are purely serendipitous, but they're not purely accidental. I even pick a cafeteria that requires me to walk a little more. I believe you can always create opportunities for good things to happen to you. When people say "It's a small world", they are so wrong. The world isn't small but they're at the right place at the right time to think it's a coincidence. The coincidences do happen but there's a larger force behind orchestrating the possibilities for such coincidences to occur.

The same applies to creativity. You can design an epiphany.

I have heard people say that they had an epiphany while they were in shower. It's not the shower but it's illumination followed by a prolonged incubation, two phases of creativity. The other two phases are preparation and verification. Preparation is a phase where you decide that you want to solve a specific problem. When you continue to work on a problem over a period of time, your brain, the unconscious, never stops working on it even if consciously you're not spending any time on it. This is called incubation. This lasts for a while. The "shower moment" is the illumination phase where you finally figured out a solution, after your brain unconsciously kept solving it for the entire night, and hence the metaphor of glowing bulb for innovation. What remains is the verification phase to prove that the solution works. We all do this, but we don't spend enough time on the incubation phase and hence many ideas don't go beyond that. You can plot for this epiphany by not letting a problem go for a while even though you think that you don't have enough time to work on it. I tell my students to start working on their projects early on for better results for that purpose. It feels counterintuitive that you could solve a problem by spending less time on it as long as you keep solving it for a longer duration off and on.

I have blogged about cloud being a natural platform to design tools that could create network effects. The tools that create network effects also offer an opportunity for digital serendipity. I have discovered many people through Twitter and learned quite a few things that I would have never explicitly made an attempt to learn. And, I'm not the only one who has had such an experience. I'm a big fan of social tools and platforms that enable opportunities for such serendipity to occur. There're only so many cafes and water fountains in the physical world; the digital world is far bigger in that sense.

Design your routine to plot for serendipity and epiphany and credit yourself instead of the shower. Creativity can be tricked. You will be positively surprised.

Cross-posted on my personal blog

Designing Terms Of Service Is As Important As Designing A Product

Dropbox revised their Terms of Service (TOS) over the long weekend. That triggered a flurry of activities on Twitter. Dave Winer even deleted his Dropbox account saying that he would revisit it once the dust settles. A lot of people concluded that there's nothing wrong in the new TOS and that people are simply overreacting. And then Dropbox updated their blog post, twice, explaining that there is nothing wrong with new TOS and cleared some confusion. I would let you be the judge of the situation and the new TOS. This post is not about analyzing the new TOS of Dropbox, but it's about looking at more basic issue in product design. What we witnessed was just a symptom.

Let me be very clear - your product design includes getting the TOS and End User License Agreement (EULA) right before you open up the service. The way the most TOS and EULA are worded, an average user can't even fathom what the service actually does, what information it collects, what it shares, and most importantly what's that it absolutely won't do. It's ironic that the simplicity element of Dropbox's design — there will be a folder and that will sync — made it extremely popular and when they designed the TOS, they had to publish a blog post with two updates and 3000+ comments to explain and clarify the new TOS to the very same users. There's something wrong here.

For a product or a service to have a great experiential design, it's absolutely important to get the TOS and EULA right upfront and even validated by end users. People release their product in beta and go to a great length to conduct usability study to improve the product design. Why exclude TOS?

I have worked with some great lawyers, but they don't make a good product designer. I'm a big fan of constraints-based design. Lawyers are great at giving you constraints - the things that you can and cannot do. Start there. Get a clear understanding of legal ramifications, ask someone other than a lawyer to write a TOS, get it signed off by a lawyer, and most importantly validate by end users. Then, start the product design using those constraints. If you feel too constrained, go back and iterate on TOS. Drafting a TOS is not different than prototyping a product.

I would rather have bloggers, thought leaders, and end users critique the product design on my blog instead of TOS. I would love to work on that feedback as against getting into a reactive mode to stop the bad PR and legal consequences. Thomas Otter says "law exists for a reason." Don't exclude lawyers but please don't let lawyers drive your business. Educate them on technology and end users and most importantly, involve them early on. The lawyers are paid to be risk-averse. As an entrepreneur, you need to do the right thing and challenge the status quo to innovate without jeopardizing the end users. It's a tough job, but it can be accomplished.

I don't want to single out Dropbox. There are other companies who have gone through the same cycle and yet I don't see entrepreneurs doing things differently. In this process, the cloud gets a bad rep. What happened to Dropbox has got nothing to do with what people should and should not do in the cloud. That would be a knee-jerk response. The fundamental issue is a different one. Treating symptoms won't fix the underlying chronic issue.

5 Techniques To Deal With Spam: Open Letter To Twitter

I love Twitter, but lately, I am getting annoyed by Twitter spam and I'm not the only one. I don't want Twitter spam to become email spam. I don't want to whine about that either, so I spent some time thinking about what Twitter could do to deal with spam. Consider this an open letter to Twitter.

Facebook's privacy settings are the new programming a VCR. Google has been criticized a lot about profiting from content farms. I believe that all the major players are playing a catch-up game. A lot of people have stared to complain about LinkedIn spam as well. Quora went into different direction — where they started out with a strict upfront policy regarding who can join Quora, ask questions, answer questions etc. — to maintain the quality of their service. Strict upfront policy hampers new user acquisition and adoption but could ensure better quality where as liberal policy accelerates the user acquisition with a risk of service being abused. I do believe that there's a middle ground that these services could thrive for by implementing clever policies.

Here are five techniques that Twitter could use to deal with spam:

1. Rely on weighted rank based on past performance: I ran a highly unscientific experiment. I kept a record of all the accounts that I reported as spammers on Twitter in the last few days. I went back every few minutes, after reporting an account, to see whether that account was suspended. It took Twitter some time before that happened. Every single account that I have reported so far has been suspended. I don't think Twitter is using that knowledge. If it did, my subsequent actions would have resulted into quicker suspension. Learn from Craigslist. Craig Newmark will tell you all about community-based flagging. Instrument the system to rely on reputation of power users — who are savvy enough to detect spam — to suspend a spammer's account. If it turns out that it's not a spam, give an opportunity to the account owner to appeal. Spammers don't waste time arguing; they simply move on.

2. Expand categories to match how people consume: Create a separate "unsolicited" category to receive mentions and replies from people whom you don't follow. This could be a separate window in a Twitter client that replaces the current "replies and mentions" window. Require Captcha for direct replies (and not mentions) for the conversations where both the accounts don't follow each other to stop automated spam. Everything else, including real spam, goes into "mentions", which is now a new category, that can be consumed in a separate window leaving the "replies" window clean.

3. Remove spam tweets from the stream: Many users don't consume their mentions or replies in real-time or even in near real-time. Mark the tweets spam once you suspend the account and require the Twitter clients to remove them from users' stream in real time. No API restrictions and no throttling. If you do it right and spam gets detected within a few seconds, the account can be suspended in no time, and the tweets are removed even before the most users would even see them. Emails can't be recalled, the tweets can be, if Twitter wants it to. Let's do it.

4. Focus on new accounts: Set a reasonably low limit on number of tweets per hour on a new account. A first-time genuine Twitter user doesn't go from 0-100 in a day, but a new spammer certainly would. Focus energy on new accounts; spammers don't wait for a few weeks or months to start spamming. The current "verified" account feature is a black magic. Open it up to all the people and use standard means such as cell phone, credit cards, and other identities to verify their Twitter accounts. These accounts enjoy the benefit of doubt - an upfront requirement of multiple signals before their accounts are suspended. Spammers don't want to verify themselves.

5. Find and fight bots with bots: There are a bunch of bots out there that look for the words such as iPad, iPhone, and XBOX in your tweets and then they spam you. Twitter can crate their own bots to tweet these words to catch these spam bots and more importantly harvest the links that they are tweeting to detect other spammers. Twitter's own bots would obviously be far more intelligent than the spam bots since they would have access to a lot more information that the spam bots don't.

The spammers do catch up, but if Twitter spends a little time and energy, they can stay ahead in this game. They can even lead the pact of social media companies on how to deal with spam.

Update: As soon as I published this post, I tweeted it and copied Del Harvey on it. She immediately responded to the post. You can read her response here. I really appreciate Twitter responding to this. My take on the response is that they seem to understand what the issues are and how they might solve them, but they haven't fully managed to execute on it, so far. I don't agree with their feedback on issue #2 calling it non-safety. Users see Twitter as one integral product where spam is very much part of it. Personally, I don't think of spam as a security issue for me. It's just plain annoyance. Executing on these ideas will matter the most. Let's hope Twitter gets behind this with full momentum and it doesn't become a "project".

Social Shaming

An interaction designer, Joshua Kaufman, had his MacBook stolen a few days back. He is a smart dude. He had installed an app called Hidden on his MacBook before it was stolen. He tracked down the thief and asked the Oakland PD to catch him. They said no. He was frustrated, obviously. He published all the details regarding the theft including the picture of the guy who stole his MacBook on his blog. This story went viral on Twitter and Facebook and made it almost impossible for the cops to ignore it. Oakland PD found the guy and arrested him. Since then the story has been picked up by many major media outlets and became sort of a sensation.

Social shaming works.

There's a fine line between peer pressure and social shaming. Many car dealerships in the US have a whiteboard that tracks which sales reps sold how many cars. They also ring a bell every time someone sells a car. It's a cheesy thing to do, but it sends a clear message to other people to be more aggressive; it's indeed a form of peer pressure. It's also an efficient technique to motivate the kids.

In fact, it's one of the most important gamification elements.

Public shaming has been used in many different ways e.g. send an email out to all the sales people with a list of people highlighted in red that haven't updated the CRM system. I know of a company that had a practice in place to publicly give a "D'oh! award" to a developer who broke the nightly build. Social shaming is essentially public shaming using social media. During my discussion with many enterprise social software vendors, analysts, and thought leaders I have repeatedly argued that changing end users' behavior is less likely to succeed unless there's a significant upside for the end users. What is more likely to work is codifying the real life end user behavior in the software that they use. Social shaming is one of those. One of the ways to achieve this could be by designing software that promotes radical transparency, signals one's successes to the other, and nudges them to excel without embarrassing them.