Memo from Marketing

Monday, July 9, 2001 by Dave Winer.

Executive summary 

This is a longish rambly piece. I'm not totally happy with it, but I want the conclusion to get out asap. The intended audience is the leadership of various non-Microsoft scripting communities. If we had a common marketing department, and if I were your director of product marketing, I'd write a memo like this.

Ever have an epiphany? 

If you've ever had an epiphany, you'll know what I felt like debating Web Services on the FoRK mail list in response to a question from analyst and venture capitalist Clay Shirky. He wanted to know if any Web services had actually been deployed. Oh yeah, you betcha, I said.

Then the Unix guys speak up and say they've been doing it all along, and too bad people like me are just discovering them now. The usual arrogance, of course I know what Unix does, that's where I learned to program, but then I figured out something new.

Source-level integration 

First I want to say that having the source to someone else's work can make bug-reporting a more precise art, if people bother to dig in and understand the source code. But if you want to integrate without forcing a fork, you need a higher level approach. And while some kinds of functionality are better if integrated at a source code level, with today's fast CPUs and ubiquitous networking, there are lots of places where it's not necessary if the interfaces exist.

OK, so here's part of the epiphany -- what people were calling open source is mostly Unix with a new name. It makes total sense that Unix would be strongly associated with open source, because source-level integration is the custom on platforms that have no easy higher-level way to bolt together functionality in different source code bases. It's a total difference in culture, but not so different on closer examination.

In the early 90s we invented higher level protocols on Windows and Mac -- COM and Apple Events, at their best they are Unix-inspired, clean, low-tech, free of lock-in. And interestingly it was done on Unix too, it's called HTTP, and it's the basis for the Web, and is a marvel of simplicity and power. Right on. It was quickly adopted on all platforms, not just Unix. But still, to this day, source-code-level integration is the norm on Unix where it's practically unheard-of in the commercial world. Is it any wonder that commercial developers invented SOAP and XML-RPC? We couldn't make the Web work for our software without doing that.

So why is this interesting? Because it explains why Unix developers, to the extent that they have leadership, are going the source code way, by cloning .NET, when a much less expensive and more likely to work strategy is staring them in the face. The epiphany that's waiting for others, is that to meet Microsoft in the market, you must adopt a bit of their culture, and that's all you have to do.

Miguel and Craig 

I've watched over the last few months as Miguel de Icaza, who I respect enormously, who also contributed to the epiphany, has approached competing with Microsoft. He's leading a group that's cloning Microsoft .NET at a company called Ximian. His project is called Mono.

Now, at the same time, Craig Burton, the former chief strategist at Novell, who I also admire, is counseling what he calls "redirection" which, on investigation, proves to be a much lighter burden to carry.

The first clue 

The first clue should be that Microsoft is not protecting the source of .NET, in fact they're publishing it, with some constraints, but if you want to see how they do it, they say there will be no mysteries and no poison pills. So they're making it not impossible to clone. Why are they being so generous? (A little sarcasm, sorry.)

Further if you can get all the services by coming to Miguel or you or me, plus freedom of choice, some part of the market is going to go for that. I'd argue it's the most important part -- independent developers. The new ideas will happen everywhere but Microsoft. If we do it right, where they have the burden of protecting all parts of Microsoft, and the rest of us have none of that.

But cloning .NET is a lot of work, and a path that Microsoft controls. Is it really necessary to do all that to compete with them? I think not, read on.

The second clue and a zig 

Microsoft is flashing a big red light called SOAP and it's a big clue. If you just make sure that your current environment, Python, Perl, Tcl, Java, whatever, can plug into the SOAP network and interop with everything Microsoft is doing, there is (drum roll please) nothing more to do, at least at that level. (There will be interfaces at higher levels that need to be supported, eventually.)

We already have the perfect zig to their zag. .NET is about integrating all popular programming languages in one runtime and development system. The rest of us love diversity, and that's a good bet because diversity is what we have right now.

So while I admire Miguel's courage, the first thing to do is to make sure that we all have excellent interop with each other and Microsoft. Look for appropriate points of integration using protocols and not source code integration and we've got it nailed. And hope that the courts keep them from being too destructive (so far so good). In other words, keep doing what we're doing.

Conclusion 

Any scripting language can be boosted to .NET-competitive status simply by making SOAP 1.1 and XML-RPC support a standard part of the install and docs. Hardly any technical work is needed.

In other words Python is already a worthy competitor to .NET. Anyone developing in Python should know they don't have to budge an inch to be part of the new network. Same with every other scripting language and environment. There's no reason to switch or freeze or wait. Get unconfused now.

Yes, it's mostly marketing, and yes my programmer friends, marketing counts.

Dave Winer