Sponsored by
BARGAIN HEADQUARTERS -- Quality Components at Liquidation Prices
The Linux community has recently posted a number of leaked memos that Microsoft admits are internal MS documents. These papers are Microsoft analyses designed to summarize the Linux phenomenon and help Microsoft focus on how to attack this alternative platform and prevent the public from enjoying it. Prominent Linux people have also commented on these memos and how they reveal Microsoft's internal culture and world-view.
But interest in understanding the Microsoft ethos is not limited to Linux supporters. OS/2 users and advocates can learn a great deal about Microsoft's inner workings and how to take advantage of their smug neglect of the OS/2 community. For example, the articles show a pervasive amnesia about OS/2 as an available option for computer users. These memos also confirm that such tactics as FUD, the threat of lawsuits, and the corruption of open standards are all normal, everyday tactics in the Microsoft repertoire. Let us analyze the memos and see what we can learn about "The Microsoft Way" and how to overcome its intentional obstacles to progress.
HALLOWEEN I
Executive Summary
Open Source Software (OSS) is a development process which promotes rapid
creation and deployment of incremental features and bug fixes in an existing code /
knowledge base. In recent years, corresponding to the growth of Internet, OSS
projects have acquired the depth & complexity traditionally associated with
commercial projects such as Operating Systems and mission critical servers.
Consequently, OSS poses a direct, short-term revenue and platform threat to Microsoft
-- particularly in server space. Additionally, the intrinsic parallelism and free idea
exchange in OSS has benefits that are not replicable with our current licensing model
and therefore present a long term developer mindshare threat.
Okay, what does this basically mean? Microsoft perceives a product to be a "threat" if it presents itself as any of these:
1. a revenue alternative -- somebody might spend money on a non-MS product
2. a platform alternative -- MS might lose its monopoly position
3. a developer alternative -- people might actually write software for a non-MS product.
Therefore, MS believes it can be harmed somehow if people can spend their money on alternatives, if people can buy a different O.S., or if software makers write code for a different O.S. Interestingly, Linux (in particular) and OSS software (in general) fit all three MS definitions of "threat": a free, non-MS O.S., that coders like because they can get access to the source code. Java has some of these qualities, despite not being open-source (yet?). What can we learn from this situation to better position OS/2 for future success?
Well, we have two possible approaches:
1. hide -- pretend not to be a "threat" to MS -- this seems to be IBM's strategy for OS/2.
2. make OS/2 a better way to spend technology dollars, a better platform, and increase developer mindshare
Remember, MS equates "alternative" with "threat". In their minds, any alternative is a threat. Therefore, freedom of choice is a source of fear and loathing to MS. The idea that there may be zero (or negative!) costs with leaving MS and migrating to another platform scares the daylights out of MS. If we want to see OS/2 succeed, we must make and market OS/2 into a full-fledged, zero-relative-cost alternative to MS platforms.
However, other OSS process weaknesses provide an avenue for Microsoft to garner
advantage in key feature areas such as architectural improvements (e.g. storage+),
integration (e.g. schemas), ease-of-use, and organizational support.
Therefore, improving OS/2's storage, integration, ease-of-use, and technical support are vital. Lest we overlook IBM's recent contributions, note that Aurora has 2 TB (Terabyte!) storage boundary, LVM (Logical Volume Manager) to eliminate drive-letter problems during storage upgrades, and superb network management and connectivity. What we as OS/2 advocates need to focus on are the other two issues: installation as an ease-of-use issue, and a credible technical support framework.
Open Source Software
What is it?
Open Source Software (OSS) is software in which both source and binaries are
distributed or accessible for a given product, usually for free. OSS is often mistaken for
"shareware" or "freeware" but there are significant differences between these
licensing models and the process around each product.
What follows is a long explanation of various categories of software, which we shall bypass at this point.....
Later, the document resumes:
OSS is a concern to Microsoft for several reasons:
1.OSS projects have achieved "commercial quality"
A key barrier to entry for OSS in many customer environments has been its perceived lack
of quality. OSS advocates contend that the greater code inspection & debugging in OSS
software results in higher quality code than commercial software.
Recent case studies (the Internet) provide very dramatic evidence in customer's eyes that
commercial quality can be achieved / exceeded by OSS projects. At this time, however
there is no strong evidence of OSS code quality aside from anecdotal.
Note the clever distinction here (which Linux advocate Eric Raymond missed in his analysis). "Commercial quality code" apparently involves "customer's eyes" (in Microsoft's own words) rather than any REAL code quality. In other words, to Microsoft and the software market in general, a software product has "commercial quality" if it has the "look and feel" of commercial software products. A product has commercial quality code if and only if there is a PUBLIC PERCEPTION that it is made with commercial quality code. This means that MS will take seriously any product that has an appealing, commercial-looking appearance because MS assumes -- rightly so -- that this is what the typical, uninformed consumer uses as the judgment benchmark for what is "good code."
Looking at it from a historical vantage point, MS broke off from IBM at exactly the point where IBM decided to go with WorkPlace Shell instead of the Windows 3.X GUI. (Bill Schindler wrote a superb chronological summary of these facts about two years ago in *Extended Attributes*.) OS/2 success depends greatly on getting the consumer to see and experience the WPS, which MS knows is clearly superior to any MS GUI (and, we believe, to any other GUI out there). As long as IBM wrote a "boring" OS/2 product with a "dull" command-line interface, MS was content to play along with them. As soon as the WPS became a reality, MS declared war on IBM and on OS/2.
What can we learn from this? That getting the WPS "look" in the hands of the consumer would have a significant positive impact on OS/2 sales and success. My own experience shows that consumers LOVE the WPS -- once they get a chance to try it.
2.OSS projects have become large-scale & complex
Another barrier to entry that has been tackled by OSS is project complexity. OSS teams are
undertaking projects whose size & complexity had heretofore been the exclusive domain of
commercial, economically-organized/motivated development teams. Examples include the
Linux Operating System and Xfree86 GUI.
OSS process vitality is directly tied to the Internet to provide distributed development
resources on a mammoth scale. Some examples of OSS project size:
Size matters! If a "small" product or project succeeds, nobody cares outside the group of implementers. However, a "big" project takes on a sense of worth solely by virtue of its size. In other words, a 40-milllion-lines-of-code product is accompanied by a hokey sense of technological wonder, something akin to Carl Sagan's "billions and billions of years ago." To sell the public on a small, tightly-integrated technological wonder is extremely difficult. What we consider "bloat" is spun by the Microsoft minions to imply power, capability, and a sense of achievement or accomplishment. This is related to the cultural decadence of the first point; people who consider code to be "commercial quality" solely because of its attractive user interface will also be improperly impressed by the sheer size and girth of a product's coding regimen. It will be harder to sell a "small" OS/2 than a "big" OS/2 -- after all, "thin clients" have been soundly rejected by most PC buyers, who believe "big is beautiful" and that needing more processing power and more storage means a program is *better* instead of *worse*. Shameful, isn't it?
We need OS/2 to achieve a "large" accomplishment of some sort. The fact that OS/2 did the Olympics well has not been celebrated enough. Perhaps Sydney 2000 will be our best chance (and maybe our last Olympic event, if the current contract is not unexpectedly renewed). Otherwise, we will have to find some other Everest-sized task for OS/2 to prove its mettle publicly.
1.OSS has a unique development process with unique strengths/weaknesses
The OSS process is unique in its participants' motivations and the
resources that can be brought to bare down on problems. OSS,
therefore, has some interesting, non-replicable assets which should be
thoroughly understood.
An interesting piece of terminology -- "non-replicable assets" -- implies that Microsoft's modus operandi typically involves copying anything that others do. This is one aspect of the "virus model" that Microsoft uses; namely, to act like some kind of rapidly-mutating DNA that gobbles everything up, installs itself everywhere, and infects anyone or anything that it can convert into a "host". Microsoft is a copycat, not an innovator.
What can we learn from this? That any innovation that we produce that has any signficance to Microsoft will likely be rudely abducted, carelessly re-engineered, and ruthlessly commoditized by MS. We therefore must decide which of the following responses is most appropriate:
1. Ignore them, let them steal everything in sight; just keep doing good products.
2. Take them to court at every turn.
3. Pick an occasional fight to make a point.
4. Innovate so fast that MS cannot keep up and loses ground.
Option #2 is simply too time-consuming and expensive. Option #3 likewise is difficult to implement and is risky. Option #1 seems like what we have seen happen in the industry at large -- which doesn't work to the benefit of the victims or the consumers at large. Having a free copy of a mediocre and unsafe product from MS while being denied superior alternatives is not a benefit to the consumer. Therefore, Option #4 is the most likely successful path, and this is what the Linux community does so well. WE SHOULD EMULATE THIS. This is one of the key benefits of OSS that Microsoft fears. We should make this our weapon as well.
The document then explains the genesis of the OSS movement and some of its features, but we shall move ahead to the discussion of the process itself....
Open Source Process
Commercial software development processes are hallmarked by organization around
economic goals. However, since money is often not the (primary) motivation behind
Open Source Software, understanding the nature of the threat posed requires a deep
understanding of the process and motivation of Open Source development teams.
In other words, to understand how to compete against OSS, we must target a process
rather than a company.
As Eric Raymond notes here, MS "gets it" at least on this point: OSS is not "owned" by anyone. It is a culture, a process, and a "life form" that Microsoft's command-and-control copy-and-leverage model must compete with.
NOTE: since MS FUD can now be expected to attack the OSS process and community, we in the OS/2 development, advocacy, and user community may be able to operate under the "cover" of OSS. They will be taking a lot of flak, and it may be possible to position OS/2 as the "best mix" of OSS-style innovation and rapid improvements, combined with the ultra-careful methodology of IBM as the custodian of the base OS. "The thrill of OSS with the safety of IBM." This is not to FUD anyone, but merely to clarify the similarities and the differences between the OS/2 community and its OSS comtemporaries.
Open Source Development Teams
Some of the key attributes of Internet-driven OSS teams:
Geographically far-flung. Some of the key developers of Linux, for example, are uniformly
distributed across Europe, the US, and Asia.
Note that this is also a key element of Java as well as (to a lesser extent) a province of OS/2's native-application community. Europe has long been a hotbed of OS/2 innovation and this will continue. Stirring up interest in other geographical areas could prove quite beneficial as well.
Large set of contributors with a smaller set of core individuals. Linux, once again, has had
over 1000 people submit patches, bug fixes, etc. and has had over 200 individuals directly
contribute code to the kernel.
Well, here the course certainly diverges. OS/2's kernel is under the watchful oversight of IBM, which contributes to the stability of the OS/2 development process. That is to say, maintaining compatibility with OS/2 is much easier than with Windows -- because MS has so many conflicting versions of its stuff out there -- but it may be easier to maintain such compatibility with OS/2 than with Linux as well. I'd be interested to find out what kind of compatibility issues currently exist among various Linux app development staffs, and how these will be resolved. It may be that divergent kernels make localized compatibility solutions possible, but may prevent a broader reach into the consumer market. On the other hand, that hasn't stopped MS. The OS/2 model of steady kernel-API foundations combined with a dynamic development community just seems to me to be the safe middle ground.
Not monetarily motivated (in the short run). These individuals are more like hobbyists
spending their free time / energy on OSS project development while maintaining other full
time jobs. This has begun to change somewhat as commercial versions of the Linux OS
have appeared.
Here we have one of the key element to Linux's success, whether or not MS or anyone else has noticed: you can't write great code if you don't have revenue, and you sure can't write great code for free if somebody else isn't footing the bill. Every Linux coder, like every OS/2 coder, needs a job. In the case of OS/2, that job has generally been trying to sell what you code. However, the Linux community is built on free code, which means that the MS tactic of shutting off software revenues to prevent an application from becoming self-supporting doesn't work. Essentially, the Linux community has developed sufficient non-Linux revenue to become self-supporting without needing to sell their Linux products. In order for MS to apply their usual revenue-squelching tactics, they would have to pressure the bosses who employ Linux people and try to get them all fired from their regular jobs, so they wouldn't have the necessary free time to code their apps. Don't think they won't try it on at least a small scale, particularly with NT's encroachment into the Unix space.
NOTE: OS/2 development can learn from this. To battle MS for market share and customer base requires a revenue stream more or less independent of the products you are pushing. To put it another way, non-OS/2 revenue must subsidize OS/2 development until a critical mass can be achieved. This critical mass is what Linux is building, and we need to have the same aim as well.
OSS Development Coordination
Communication -- Internet Scale
Coordination of an OSS team is extremely dependent on Internet-native forms of
collaboration. Typical methods employed run the full gamut of the Internet's
collaborative technologies:
Email lists
Newsgroups
24x 7 monitoring by international subscribers
Web sites
Hmmm, sounds like the OS/2 community, too, doesn't it? Never underestimate the Net's ability to collect "leftover" OS/2 users from around the world and assemble a "virtual community" that overcomes the geographical limitations of a low-OS/2-user-density in most geopolitical communities.
OSS projects the size of Linux and Apache are only viable if a large enough
community of highly skilled developers can be amassed to attack a problem.
Consequently, there is direct correlation between the size of the project that OSS can
tackle and the growth of the Internet.
Well, then, Bill, are you planning to prevent the 'Net from growing, or will you admit that Linux will get better and better as the 'Net continues to grow? Meanwhile, back at the ranch.... Application of this principle to OS/2 means we must get AS MANY OS/2 SUPPORTERS ON THE WEB as possible, and quickly. Building and improving this "virtual community" has been a key element in the survival and continued growth of OS/2 and OS/2 development. Keep up the good work, people.
Common Direction
In addition to the communications medium, another set of factors implicitly coordinate
the direction of the team.
Common Goals
Common goals are the equivalent of vision statements which permeate the distributed
decision making for the entire development team. A single, clear directive (e.g.
"recreate UNIX") is far more efficiently communicated and acted upon by a group
than multiple, intangible ones (e.g. "make a good operating system").
Okay, then we should set some concrete goals for OS/2, shouldn't we?
Common Precedents
Precedence is potentially the most important factor in explaining the rapid and
cohesive growth of massive OSS projects such as the Linux Operating System.
Because the entire Linux community has years of shared experience dealing with
many other forms of UNIX, they are easily able to discern -- in a non-confrontational
manner -- what worked and what didn't.
In other words, Linux users are here categorized as typically experienced coders. OS/2's user base is more varied, including a lot of SOHO and small businesspeople and regular end-users. This means that improving OS/2 tends to focus more on usability issues and applications, and less on raw technical details. OTOH, we become more dependent on application vendors than the Linux community is, at a time when most appmakers have failed to capitalize on the OS/2 opportunity and stubbornly refuse to recognize the established OS/2 user base. (Being too cowardly to add OS/2 development to their stable, these commercial vendors wish it would just "go away" so their foolish obstinance would somehow be proved "right.")
Well, we must make up for our generally less code-oriented user base by building better ties with the more open-minded app developers. VOICE has been particularly good at connecting users with developers from among the OS/2 community. Perhaps non-OS/2 developers could also be invited so they could get some positive feedback from people willing to pay for OS/2 versions of their products.
There weren't arguments about the command syntax to use in the text editor --
everyone already used "vi" and the developers simply parcelled out chunks of the
command namespace to develop.
Having historical, 20:20 hindsight provides a strong, implicit structure. In more
forward looking organizations, this structure is provided by strong, visionary
leadership.
This line of reasoning seems to imply that the OSS community is made up of nothing more than a bunch of fix-it men who happen to have worked on the same line of appliances before. The Linux developers are thus painted with the broad brush of being mere "followers" and "technicians" lacking in vision and leadership. This kind of stereotyping is dangerous. MS has become so cocky that it feels it can cubbyhole any perceived enemies neatly into little boxes for precise counterattacks. This is also why MS wrongly believes that there is no longer a viable OS/2 community, because they foolishly believe that only IBMers ever liked it in the first place.
Common Skillsets
NatBro points out that the need for a commonly accepted skillset as a pre-requisite for
OSS development. This point is closely related to the common precedents
phenomena. From his email:
A key attribute ... is the common UNIX/gnu/make skillset that OSS taps into and
reinforces. I think the whole process wouldn't work if the barrier to entry were
much higher than it is ... a modestly skilled UNIX programmer can grow into
doing great things with Linux and many OSS products. Put another way -- it's not
too hard for a developer in the OSS space to scratch their itch, because things
build very similarly to one another, debug similarly, etc.
Whereas precedents identify the end goal, the common skillsets attribute describes the
number of people who are versed in the process necessary to reach that end.
This characterization of OSS as a strictly UNIX-oriented phenomenon is interesting, because while this Unix/Linux origins of OSS are well-known, the fact is that the Netscape and Java communities are also moving toward an open-source model. In addition, we might consider HTML to be the prime example of open source code, since anyone with a Web development tool employing mirroring can open and read HTML website code and duplicate it -- without even the GNU license restrictions being involved. Focusing solely on attacking Linux or even the broader Unix community fails to take into account these other sprouting OSS variants. If OS/2 begins to combine some of the open-source features with its carefully-managed base kernel and APIs, the mix may exceed Microsoft's ability to model and attack.