Reading Mike comments on companies being responsive because of competing with
Open Source prompted me to send a few links into the blogsphere. Now I don't run a company
or anything, so this is theory only, but hey – it's the Internet – everyone's an expert.

Joel (of Joel on Software fame) wrote an
interesting piece a while ago called
Fire And Motion:

When I was an Israeli paratrooper a general stopped by to give us a
little speech about strategy. In infantry battles, he told us, there is only
one strategy: Fire and Motion. You move towards the enemy while firing your
weapon. The firing forces him to keep his head down so he can't fire at you.
(That's what the soldiers mean when they shout “cover me.” It means,
“fire at our enemy so he has to duck and can't fire at me while I run
across this street, here.” It works.) The motion allows you to conquer
territory and get closer to your enemy, where your shots are much more likely to
hit their target. If you're not moving, the enemy gets to decide what happens,
which is not a good thing. If you're not firing, the enemy will fire at you,
pinning you down.

If you haven't read it, you should.

I was alway impressed by the thinking in that article, and when I found Paul Graham's
Beating the Averages article, I though the
bit

Sometimes, in desperation, competitors would try to introduce features
that we didn't have. But with Lisp our development cycle was so fast that we could
sometimes duplicate a new feature within a day or two of a competitor
announcing it in a press release. By the time journalists covering the press
release got round to calling us, we would have the new feature too.

was another interesting datapoint in the whole agile-business strategy thing.

Very recently, I read an
article about John R. Boyd, who invented a concept called the OODA loop
(OODA stands for Observation, Orientation, Decision, Action). If you can execute the
correct action before your opponent then you are inside their OODA loop, and you win.

From the software point of view, this is instinctivly true. Remember the browser wars?
Microsoft got inside Netscape's OODA loop, and pushed new browser versions out too quickly for
Netscape to compete with.

I believe that open source projects can have very tight OODA loops, and it can be difficult
for a company to gets its loop tight enough to compete with them. However, if a company can
get its OODA loop smaller than a competing open source project, it can probably sustain it
longer – most open source project rely too much on volenteers to sustain a really tight OODA
loop for a long period of time.

If your company finds itself up against an open source competitor then I believe this is the key strategy in winning.
Just make sure the competition is not something like Linux, where the workers can actually
get paid – You won't be able
to compete in that market forever, unless you have very deep pockets
indeed. If it isn't a critical market for you, it might
be better to join them.