billwg wrote:
> "Roy Schestowitz" <newsgroups@xxxxxxxxxxxxxxx> wrote in message
> news:1337312.RP8gSAQNQ8@xxxxxxxxxxxxxxxxxx
> > Can Open Source Defeat Microsoft?
> >
> > ,----[ Quote ]
> > | While Microsoft has had some 20 years to make Office what it is
> > today,
> > | most industry analysts say that new open-source contenders, such as
> > | OpenOffice, measure up reasonably well against Redmond's suite.
> > `----
> >
> > http://news.yahoo.com/s/nf/20060504/bs_nf/43132
>
> You seem to have missed the boat as usual, boy roy! LOL!!! The exact
> quote is:
> "While Microsoft has had some 20 years to make Office what it is today,
But let's put that in terms of staff-years. Microsoft jealously guards
most of the technology related to Office. Only a very small team
actually does Office development, and most of the resources being pourd
into office are Marketing and Legal team hours.
The one very valuable thing Microsoft did, back in 1990, was maintain
it's own "help desk" which anyone could call and ask for help (for a
nominal fee, of course). This helped Microsoft generate a really good
"self-help" system, including Wizards, pop-ups, and even dancing
paperclips and puppy dogs.
Open source on the other hand, has been evolving over nearly 25 years,
since BSD on multiple platforms made it necessary to have source code
for Unix applications. BSD 4.0 came out in something like 1983?
As a result, Open Source software engineers stand on the shoulders of
other Open source software engineers. Concepts used in Open Office go
back to Emacs, X11 Athena Widgets, Project Athena, AUIS, and other
technologies that have been evolving for over 15 years, much of which
even predates Microsoft "Office". Microsoft had multiplan, and maybe
Word, but UNIX had EZ, Applix, Asterix, Framework, SGML, LaTeX, and
even Nroff back when MS-DOS was still using TSR programs as a
substitute for multitasking.
Let's just assume that EZ came out with Linux in 1993. Since then,
thousands of engineers and contributors have offered enhancements and
upgrades, including WYSIWYG editors and content managers. PERL and AWK
can do 'spreadsheets' that would completly cripple Excel. MySQL can
run circles around access, PostGreSQL has capabilities SQL Server 2005
hasn't even begun to master.
Of course, Microsoft can also use this technology, especially BSD
licensed technologies, and frequently does. Of course, many
contributors retaliate by ONLY releasing their bug fixes, enhancements,
and upgrades under GPL. Microsoft can't even admit they have reverse
engineered the code to this stuff.
> most industry analysts say that new open-source contenders, such as
> OpenOffice, measure up reasonably well against Redmond's suite. But they
> also say that while these suites do have most of the features of
> Microsoft Office, they lack certain advanced capabilities that make all
> the difference."
Often these advanced features are available through other mechanisms.
With Excel, I have to embed the entire VBA application within the Excel
spreadsheet. The one application must do everything. With Linux,
applications can be very specialized, and generate content that can be
processed by other applications. A 'base" application could generate a
database query which can be fed to PERL which can do statistics which
can be fed to CALC. Something which would take hours of cut-and-paste
in Windows applications takes a few seconds in Linux/Unix.
True, the script takes a while to produce, but so do VBA scripts.
> The article goes on about volunteers vs paid developers and how maybe
> the volunteer force is somehow more mobile and less regimented and can
> be more reactive.
The average Linux distribution has around 3,000 'packages' and each
package typically involves several hundred developers, and the
'product' is fed to distributors who package and market these packages.
Linux has millions of lines of application code, available in source
code format. This can inspire others, who can use libraries, concepts,
and even applications, to create new applications.
Linux is also more 'modular'. Back in the days of MS-DOS, Windows 3.x,
and even Windows NT 4.0, the application had to be self-contained.
Many applications even managed their own displays, they managed their
own databases, they managed their own memory management, they managed
their own peripherals and I/O routines. They even had to coordinate
communication between threads and between applications. The Windows
programming model was based on putting activities into an "Event Queue'
and having a thread manager run different methods based on the events
received. It worked fairly well for smaller and simpler applications,
but as more threads run concurrently, there is an exponential increase
in the risk of race conditions, deadlocks, and other self-corrupting
applications.
Ironically, when Microsoft introduced Windows 2000 and Windows XP, they
tried to encourage the use of apartment threading and other methods of
isolating the various threads so that there was less risk of corrupting
each other's memory. MTS, MSMQ, and .NET actually did improve the
quality of Microsoft Applications, making them less inclined to crash -
when properly developed and deployed - but the 'one huge application
model' still prevails. This is largely because context switches in
Linux and Unix are about 100 times faster than process switches in
Windows 2000, XP, and 2003. Microsoft has hinted that they are doing a
major rework of the kernel, which will probably be based on the BSD
kernel, and will probably be released with Vista.
Unix on the other hand, has always had a robust operating system and
system libraries which are so well documented that they can do much of
the work. In addition, the operating system does those fast process
level context switches almost as fast as threads, which means that it's
often much easier to combine a number of relatively simple and stable
applications than to write one huge complex application. These simple
commands are combined using scripts, especially 'shell' scripts.
Often, a graphical application, such as a web browser, calls the shell
script which then runs a pipeline of applications which format the
request, send the request to a server, get the response, and format the
output for the graphical interface (HTML, XML, gd,...), with each
module performing a 'specialty' act.
Linux even has 'wrapper generators' that can generate simple graphical
user interfaces for applications. There are also graphical 'shells'
such as TCL/TX, PERL/TK, Ruby, and even Java, which can call these
simple 'pipelines' or shell scripts, and outperform many far more
complex 'general purpose' applications.
>From 1983 to almost 1990, UNIX rarely used a database, because so much
work colud be done so easily with awk, sed, grep, and even ed. BSD
Unix even had Join, which made it possible to format result sets and
create join views with other tables. BSD did have 'YARD' (yet another
relational database) but it was often considered too much trouble and
effort for something that could be done so easily in Awk or Sed. Even
today, many database applications are leveraged with Middleware which
can perform powerful transformationsn and enhancements - and can be
easily customized.
The real key to the success of Linux then, is it's ability to run
applications which can be very easily customized, yet can be used with
familiar interfaces such as Web Browsers, AJAX, and XML based
applications such as Open Office.
Keep in mind that Linux has been using SGML for their documentation
almost since before the release of HTML, let alone XML. SGML is a more
powerful and flexible 'Standardized General Markup Language' which
forms the foundation of subsets such as HTML and XML.
> That all sounds good until you try to get a
> commitment. Then it's like the proverbial ham and eggs at breakfast:
> the chicken is involved, but the pig is the only one committed.
Ironically, this is the argument in favor of Open Source. When
Microsoft sells a Windows/Office bundle, they sell it to the OEM or the
CIO. They don't even get involved with the end-user. Unless the user
purchases a 'full retail' version from an authorized retailer, they are
not a "Microsoft Customer".
When a consultant uses Windows and Office in an engagement, he is
normally using it to provide the customer with documentation.
Microsoft is 'involved' only in the sense that a product which is not
even sold to the end user, is used in the most general way, to create a
document which can only be used by that office application.
If I take a visio diagram to draw a work-flow diagram, I can't feed
that diagram directly into Project and get a project plan for that
workflow, including costs, hours, timelines, and schedules. With some
creative cutting and pasting, I might be able to copy information from
a spreadsheet into Project - but even then, this will be a very
laborious process.
This isn't so bad for 'one shot' environments and applications, but
when you have routine tasks being performed by hundreds of employees
every week, or even every day, all this cut/paste can be very labor
intensive - and costly.
In the Linux environment, if you take advantage of the Unix/Linux
model, you can quickly create applications which can take information
from one program and feed it into something else, and even do it
automatically, in real time.
So in exchange for a marginal loss, say 10%, in productivity because
you are using Open Office intstead of MS-Office for general 'printed
documents, slide shows, and spreadsheet based estimations', you can get
that back many times by using Open Source applications to handle those
routine chores that are so labor intensive and just seem to waste time,
especially the time of Project Managers.
|
|
