When to give away the technology

Wednesday, January 2, 2002 by Dave Winer.

Good afternoon 

Happy new year and good afternoon. Let's try taking the discussion about technology, the Internet, and developers in a different direction.

There was a great article in the SF Chronicle yesterday about the post-dotcom venture capital industry, about the money they make, even when they aren't making investments, or when their investments aren't doing very well (like now). I come from the same place they do, but choose to create technology instead of investing in other people making technology. I don't make the kind of money they do. Not even close.

Of course there's nothing wrong with financiers, we need them to get our stock public. But as a group they did something really stinky to the software industry in the last part of the last decade -- they helped promote the myth that programmers work for free. In their folklore we're so selfless that we're willing to write new software and fix bugs, without being paid to do so. Another way of looking at it -- they get to keep all the money and programmers get nothing.

The software industry was wrecked by this idea, software development is expensive, many companies didn't weather the storm, and good software was lost. Now it's hard to compete on such a wrecked landscape, but we're doing better now that it's become clear with the customers that every software developer has to make money to grow or even exist. Today the venture capital industry is no longer investing in open source, and the companies they started in the 90s that still exist are transitioning to a mixed model, as fast as they possibly can. There's no more support for the "we'll figure out how to make money someday" model they were pursuing. For many, "someday" is in the past.

But along with the end of mythology, the pendulum is swinging too far. There are times when it's important to give away technology, not only for altruistic reasons, but also because it makes good business sense to do so. In this piece I offer some anecdotes from my own experience that explain why this is so. It's important that we not over-react to the ridiculous idea that all software must always be free. Let's find a moderate balance that works, and rebuild the industry and not make the mistake again. You can't give away everything and be in business, but you can't start up a new company without seeding the market with some of your brilliance.

My rule 

Simply stated, here's my rule. Where you want competition, give away the technology. Where you want to be competitive, keep it to yourself.

Discussion 

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 philosophy 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 necessarily want to.

In other words, if you want to profit from your innovative ground-breaking work, you'd better create 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 are lots of ways to be best. Hopefully you can be best in all ways (except the 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 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 their 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 many of them already can smell a locked-trunk before they hop in, enough to make a market for the Small's who want to run the software race, keeping users (i.e. customers) well-supplied with the features and fixes they want most.

I've been emailing with Shane McChesney, the author of the excellent Skipping Dot Net site. He says his Fetch product may compete 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 a BigCo's. I can compete with Shane. If they like his product they might find out about mine and buy it too.

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 I must give away some of the juice if I want to have a growing and prosperous software business. It's how I create a market 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

PS: Congrats to NEA for being the example of high-road VC. The Chronicle piece explained how their compensation is related to performance. I bet they treat their entrepreneurs fairly too.