Shipping Software

[Guy Macon]

From:
http://mark-lucovsky.blogspot.com/2005/02/shipping-software.html

"I am not sure I believe anymore, that Microsoft "knows how to ship
software". When a Microsoft engineer fixes a minor defect, makes
something faster or better, makes an API more functional and complete,
how do they "ship" that software to me? I know the answer and so do
you... The software sits in a source code control system for a minimum
of two years (significantly longer for some of the early Longhorn
code). At some point, the product that the fix is a part of will
"ship" meaning that CD's will be pressed and delivered to customers
and OEM's. In best case scenarios, the software will reach end users a
few months after the Release To Manufacturing (RTM) date. In many
cases, particularly for users working in large corporations, they
won't see the software for a year or more post RTM...

"Consider the .NET framework for a second. Suppose you wrote something
innocent like a screen saver, written in C# based on the .NET
framework. How would you as an ISV "ship your software"? You can't.
Not unless you sign up to ship Microsoft's software as well. You see,
the .NET Framework isn't widely deployed. It is present on a small
fraction of machines in the world. Microsoft built the software,
tested it, released it to manufacturing. They "shipped it", but it
will take years for it to be deployed widely enough for you, the ISV
to be able to take advantage of it. If you want to use .NET, you need
to ship Microsoft's software for them. Isn't this an odd state of
affairs? Microsoft is supposed to be the one that "knows how to ship
software", but you are the one doing all the heavy lifting. You are
the one that has to ship their software the last mile, install it on
end user machines, ensure their machines still work after you perform
this platform level surgery.

"When an Amazon engineer fixes a minor defect, makes something faster
or better, makes an API more functional and complete, how do they
"ship" that software to me? What is the lag time between the engineer
completing the work, and the software reaching its intended customers?
A good friend of mine investigated a performance problem one morning,
he saw an obvious defect and fixed it. His code was trivial, it was
tested during the day, and rolled out that evening. By the next
morning millions of users had benefited from his work. Not a single
customer had to download a bag of bits, answer any silly questions,
prove that they are not software thieves, reboot their computers, etc.
The software was shipped to them, and they didn't have to lift a
finger. Now that's what I call shipping software.

"I would argue that Microsoft used to know how to ship software, but
the world has changed... The companies that "know how to ship
software" are the ones to watch. They have embraced the network,
deeply understand the concept of "software as a service", and know how
to deliver incredible value to their customers efficiently and quickly."

[Charles Kincaid]

Post by Guy Macon
"Consider the .NET framework for a second. Suppose you wrote something
innocent like a screen saver, written in C# based on the .NET
framework. How would you as an ISV "ship your software"? You can't.
Not unless you sign up to ship Microsoft's software as well.

Which is exactly what many of us do. It makes our installers gigantic but
they work.

How is this different from many of the third party components that many of
us use every day? I "sign up" by buying the component and the manufacturer
licenses me to include it in the software I sell. We avoid components that
are not "royalty free" largely because of the cost and hassle of keeping up
with the licensing paper work.

I can write multi-threaded system services in Power Basic and VB.Net both.
Power Basic does not enable me to write code for Windows CE (or Pocket PC)
devices. I can use VB.Net for the desktop and the device. If I design my
device app right I can even run on the desktop. This is a wonder for
training and demos.