|
|
 |
When to give away the technology
Jerome Camus wants clarification of a statement from yesterday's Scripting News. Where you want competition, give away the technology. Where you want to be competitive, keep it to yourself. It's a confusing statement. I know what it means, but it seems I'd have to write a whole book with lots of examples to fully explain it. I don't have time to write a book, so here's an instant brain dump.
First, change "you" to "I". Where I want competition, I give away the technology. Where I want to be competitive, keep it to myself." As often is the case, when I write something quickly I say you when I really mean me. Lots of people do this. It's almost always a mistake. So hopefully that should clarify at least one part of the confusion. I'm not talking about anyone other than myself. I'm stating the blueprint for how I plan new software.
Now, I don't know if software is different from other kinds of technology. I've immersed myself in software, I admit that I don't know much about TV, or lawn mowers, or cars, or almost any other kind of technology. So I don't know if this applies to the others.
Let's say you're developing a new piece of software, something for which no prior art exists, or very little, or the prior art is very old (the world changed), or you can't find it on Google. If you're a small relatively unknown developer, you have a problem here. You have to create a big enough thing so that a BigCo can't come in and create a competitive product that's not compatible with yours. That's sure death for your product. Most people prefer the security that comes from a big brand name, esp when they're confused, and the Big's certainly can make things confusing, even when they don't want to, most of what emanates from them is very confusing.
In other words, if you want to profit from your innovative ground-breaking work, you'd better make a big target, and plan in advance for the incursion of the Big's, and make sure when they arrive, their customers know that a standard format or protocol exists, even if they don't know that you or your product exists. If not, they'll invent their own format or protocol, and design it so that you need a multi-billion dollar R&D budget to implement it, and even then you'll find the slope quite slippery as they "innovate" you out of the market.
In other words, it's even harder to be successful when you're small than it seems it should be. It's not "build a better mousetrap and the world will beat a path to your door." Nope. First the customers have to get an idea that a market exists, and then it has to seem natural to them that your product is the best in this market. There's lots of ways to be best. Hopefully you can be best in all ways (except Bigness of your company, which is not an option).
So what you do is pick some people or companies you want to compete with and entice them to adopt your format or protocol. This is quite hard. Usually they want to wait until a BigCo tells them it's cool. But if you're persistent, sometimes you can get updraft, and that's when your product has a chance. The best way I've found to do this, is to do something that power users understand, publicize it (having a popular weblog helps here), and entice them to nag your would-be competitiors until they give in and see that they can eat your lunch (heh) and go ahead and implement support for the open part of what you're doing. I've tried a lot of things that didn't work. Like enticing the search engine companies to support an XML-RPC interface so we could optimize indexing, and improve the timeliness of their service. My take on this is that there wasn't enough competitive juice to interest them. You have to find the right balance.
Somehow XML-RPC itself did work. As did the Blogger API, an example of the fumes flying the other way. When I saw what Evan was doing I jumped on board right away. Not a moment's hesitation. Now that XML-RPC is an established protocol for distributed computing, our strategy is very clear. Be the open alternative to development environments that are built around complex and expensive alternatives to XML-RPC. And as a sub-strategy, we catch the curveballs that the Big's throw at the market, and also take a leading position in supporting their protocols. I like this position, that's why we invested in SOAP in addition to XML-RPC. If the SOAP slope gets too slippery, no problem, we already have XML-RPC as a solid unconfusing simple way of doing what we need to do. That actually helps SOAP stay simple. It has to, if it wants to be competitive with XML-RPC. All of a sudden simplicity is an issue in the market. They can't ignore it, although I'm certain that they'd like to. 
Another thought -- when the open part of it is simple enough (it must be very simple) the work is almost all politics. I want the Omni guys to support OPML. If they decide to do it at a strategic level, I want the programmer who does the work to be delighted with how easy it is, to be so excited that he wants to go all the way and make it their default format. This gives users choice, and it's been proven over and over that they don't move until they have choice (or believe they will get it). Omni is hardly a threat to my company, they're not much larger than we are, and their product is loved by many of the same people who love our software, so what the heck, let's be compatible. It just takes two. Once we're compatible, any other entry can compete by producing a better outliner, one that performs better, or runs on different platforms, or prints better, or you name it. The best scenario for users is one where the documents move between apps fluidly without glitches. This is when they will sing our praises and recommend us to our friends, which is a vital part of success in software, whether you're Big or not.
We got into this habit with HTML. It's a perfectly awful format, virtually impossible to make a wizzy editor for it, yet that's what all the users want. But no one, not even the biggest of the Big's felt they could ignore it. Even better, the users have gotten the message too. Formats that are closed and not accessible from other software are bad news. Yes they still adopt them, but they shouldn't, not if they want to use their power, and act in their own self-interest. I am an optimist. The maturation of this industry is measured in the power of the users to shape the software they use. I think most of them already can smell a locked-trunk before they hop in.
I've been emailing with Shane McChesney, the author of the excellent Skipping Dot Net site. He says his Fetch product may be competing with the aggregator that's built into Radio. No problemmo. I hope he does very well with his product. Our competition is based on an open standard that's brain-dead simple -- RSS. He's also got the right idea -- he's not pushing his software as much as he's pushing alternatives to Microsoft. We are totally aligned in that. I point to him and he points to me. Of course I'd like everyone who wants to read RSS-based news to use my product. But I consider it a victory if they use Shane's product and not Microsoft's. I can compete with Shane. If they like his product they might find out about mine and buy it too. No one in their right mind who likes to make software wants to compete with Microsoft (they don't have integrity, even though they settled with the DOJ, we read the transcripts of the trial).
So if we want to create innovative products, we need to have permission to innovate and compete, and be believed when we do it, and have the respect of other developers and our mutual customers. We can only get there if we help each other. And therein lies the reason why you must give away some of the juice if you want to have a growing and prosperous software business. It's how you create a market for you to compete in. One little company selling a product does not make a market, no matter how unfair that seems.
Thanks for listening and have a happy 2002!
Dave Winer
|
|
