Dave Hornik spoke at the last FooCamp about viral marketing and lessons you could learn from an actual virus. I was there but I didn’t go. Thankfully, Christine Herron summarised his talk in the form of bullet points on her blog.
Since then, off and on, I have been thinking more about the opposite.
What blocks a potentially viral product from actually achieving critical mass. I haven’t seen much discussion of that.
So here goes.
Continuing the biological analogy, if you considered that the most unhealthy place was the one with the highest germ density then the Center for Disease Control in Atlanta would be right up there. But it’s not the most unhealthy place, because every infectious agent is enclosed in an impenetrable barrier. In a lab, that’s often a petri dish.
What then, is the software equivalent of a petri dish?
Something that is transparent, almost invisible, but an impenetrable barrier to proliferation. I call it transparent because the people who create the barrier don’t see it, impenetrable because the virus – the app does not overcome it and spread rapidly. So what is a real example of petri dish in this context?
Some examples from the antedeluvian past.
In the 80’s and early 90’s the most common petri dish was a “for-fee” SDK. The Business Unit Manager pulling out his trusty spreadsheet decided that the SDK for his world changing product would be available for 699$ after faxing a 10 page qualification questionnaire. After all it was going to be world changing and they wanted to be suer they had the right partners not just the “amateur developer”. This, while companies like Borland were charging 49$ and 99$ for world class developer tools.
And then in the early-to-mid 90’s along came Open Source and Linux …..
When Linux began to proliferate in the early 90’s I was doing development on Microsoft platforms as well as Unix platforms. Once I went to Linux I didn’t go back and never paid Microsoft another $ for a development tool. Needless to say, Linux grew virally. Last I looked, Microsoft still charges 2000$+ or so a year for developer tools.
But money is not the only barrier to proliferation. Ease of deployment – or rather, lack of it is another “petri dish”.
In the early 90’s Sun did one thing massively right which was to give the Java run time environment and SDK away for free so developers could play with it. But they also to made it available on Windows with native installers – as much they hated Microsoft and Windows at that time, they saw the strategic importance of not having any obstacles. The Java VM infected Windows and IE and Microsoft’s best efforts did not stop this juggernaut. Although this virus rapidly grew API’s and mutated into a pig called J2EE ( been there, got emotional scars from that) by that time it had pretty much established a solid beachhead in the enterprise, effectively stopping Microsoft from taking over.
The petri dish in the form of a bad installer was something IBM did not see with OS/2 . It had this problem in the early days, even though it was becoming a stable and useful development environment and it never broke out of a very narrow niche of developer build machine and Lotus Notes Server class of machine. Some OS’s attempting to crack the ’86 market even required you to have SCSI drives during a time when the commonly used PC’s had IDE drives and SCSI drives cost upwards of 500$. Someone somewhere wasn’t thinking it through was looking straight through the petri dish without noticing the barriers.
Takeaway: If you want your app to have rapid proliferation, make sure you don’t put it in a petri dish.
I am sure you have your own examples of petri dishes. What are they? I haven’t thought through what the petri dishes are for Web 2.0 apps. Any ideas?