As I re-read Craig Mundie's speech and came to the bullet
pointed principles of shared source philosophy, several thoughts
were percolating to the fore of my consciousness. Not least a cow
like creature moo-ing GCC.
The whole shared source philosophy is like a one way plumbing
valve. Say I come up with a great new feature, such as a tap
dancing pirate paper-clip that stabs old temporaray files with its
cutlass and tosses the trash in to the recycle bin . The paper-clip
would flow one way. Would you like my tap-dancing pirate paper-clip
and could you improve it? You could not lobby Microsoft for my work
- you would not of heard about the tap dancing pirate paper clip.
If Microsoft did like the tap dancing pirate paper-clip would
it be MY tap dancing pirate paper-clip?
Maybe if the intellectual property belongs to me and it is
bundled as part of the Windows next-gen supermegahyperglobalNET I
still give it away. Maybe I want to port the tap dancing pirate
paper-clip to MacOS, Gnome or KDE. Can I still do that? It isn't
entirely clear from the speech.
So, for now I drop the tap dancing pirate paper-clip, which was
just silly and decide to build a five inch orange zombie that
repeatedly says "Where Do You Want To Go Today" in a variety of
voices, such as Homer Simpson's, Barry White's and Bill Gates'. It
would have variable pitch voice control and stomp about the Windows
task bar occasionally leering "Brains, must eat brains". I may run
Windows NT 4. The first thing I need is a compiler and the shell
source code because I want the zombie to be integrated, maybe tied,
to the task bar.
I drive to my local Provantage. I'm inherently cheap so I buy
the Standard Version of Microsoft Visual C++ 6 ($85). I believe
certain features of the shell are written in Microsoft Visual
Basic, so I also pick up the Learning Edition ($87). The strange
sub-conscious cow like creature moos GCC again.
I write to Microsoft saying that I have a great idea and can I
have your access to their source code? Microsoft say no. My
employer is not part of the Enterprise Source Licensing Program. I
write back and ask for a research license. Apparently this is only
possible if I'm a member of one of 100 Academic institutions that
have access to the code. A guy with an idea cannot profit from it.
Isn't this anti the American way?
Well, Microsoft have lost the zombie and I have lost $172.
However, Luke, quite dual edged is the Microsoft source. Now that I
don't have access to the Microsoft source I'm free to show others
my paper-clip and zombie. BUT it will never truly be tied to the
taskbar. If I GPL the zombie I'm afforded a lot of protection and
others can improve on it. I can, note, still sell it. BUT it will
never truly be tied to the taskbar.
But the cost of so called professional compilers/development
environments! I've used Provantage as a price reference. Visual
Studio v6.0 Enterprise with Plus Pack for Windows 2000 $1387.45, a
nice integrated bundle. SuSE Linux v7.1 Professional Edition
$63.12, a full operating system, several compilers and several
SDK's (or development libraries as they used to be known). RedHat
Professional Server Edition $179.95 with a huge bundle of compilers
and libraries. The non Microsoft products all come with phone and
web based installation support.
Now I know that this standard argument does not factor in the
training costs. But standard training costs are not a big deal for
big companies especially as a long term investment. Compare the
costs of Microsoft and RedHat/SuSe training schemes and generally
speaking the RedHat/SuSe training schemes are cheaper. Staff may
already have Windows training, but then some staff may be Unix
savvy. In my own experience most IT departments of any great age
have at least one Unix guru gathering dust.
Which in a about-round way brings me to one of the scarier
features of Microsoft's shared source.
Compartmentalised systems usually allow information to flow in
one direction. Which given the usage of most compartmentalised
systems is a good thing. One of the things that protects open
source code from crackers (not hackers - where would the kernel
be?) is the fact that it is open to peer review and any academic
will confirm that sometimes peer review is harsh. This is not to
say that peer review is bad. Sometimes harsh is good. This is
almost an opposite model to compartmentalised systems.
But what stops a company with access to Microsoft code screwing
up? Either through human error or deliberately. If it isn't open to
peer review how will it be reviewed internally and without
For instance: Airline X writes a windows kernel level
accelerator for Airline X's ticket system. This becomes integrated
with the kernel. However a side effect of this is that Airline Y's
payroll system no longer functions correctly. This could be
Microsoft's fault, Airline X's fault or maybe a mis-configuration
of Airline Y. Without general peer review it is common sense that
it will take a lot longer to find the problem. Airline Y has to
request the code from Microsoft and then review the code. How is
Versions - are we going to see incremental Windows editions?
Will the new feature created through the hard work of universities,
corporations and other organisations be added in the next version?
I don't think it would be an incremental release, especially if the
feature can shift more units. Rev-ups for ad campaigns take weeks
to co-ordinate alone. So the hard work that you put into a
product or system is released when it suits somebody else and how
it suits somebody else.
To sum up shared source is rather like a salmon swimming up
stream only to have its young sold back by a third
party for profit.
Interested in submitting a Community Column or a letter to the
editor for publication on Linux Today? Contact the editors with a
brief summary of what you'd like to write about (or just mail the
letter). Not everything will be accepted, and we do reserve the
right to edit submissions.