Reading 2 - Ass. 3: Mosco - From the Myth of Cyberspace to the Political Economy of Computer Communication

Mosco, V. (2005). From the myth of cyberspace to the political economy of computer communication.Comunicação e Sociedade, 7(1), (pp. 49-67).

Question: This article reinforces the critique of the earlier claims about the Internet as a liberalising force ending oppression and reinforcing democracy. How does Mosco support his claim that the Internet "might be little more than an highly commercialized space with scarce room for diversity and debate" (p.49)?

p.50
Digitalisation refers to the transformation of communication. incuding words, images, motion pictures, and sounds into common language. Providing the grist () of cyberspace, it offers enourmous gains in speed and flexibility over earlier forms of electronic communication which were largely based on analogue techniques (Longstaff, 2002). [...] Rather than the multiplicity of  mechanical analogues that were employed to process oral, verbal and image signals, digitization enables one language to govern practically all electronic media. The fundamentals of translating, processing and distributing electronic communication no longer distinguish  among a page of newspaper copy, or a radio broadcast, a CD recording, a telephone call, a television situation comedy, an an e-mail message. Each can be sent at high speed over various wired and wireless networks.

(In terms of diversity, Mosco makes an important point here. While everything media is available online, it is all nothing more than a digital footprint of an equivalent in the physical world. It is all reduced to one single medium - digital signals. This is the commodification of media.)

p.51
[...] Commercial forces deepen and extend the process of digitization because it enables them to expand the commodity form in communication. From a cultural or mythic perspective, cyberspace may be seen as the end of history, geography and politics. But from a political economy perspective, cyberspace results from the mutual constitution of digitisation and commodification. 

(That is the cardinal error 'commercial forces' make: While they accept that cyberspace provides for a huge market, as commodification takes place at unseen levels, they don't realise, that unlimited access devalues media. Over the years since 2005, sharing has become a habit amongst consumers in cyberspace - possibly something that was not considered a threat in the first place)

P.52
(The product no longer is what is promoted to the consumer - the consumer has become the product and as such is promoted to the advertisers) 

Digital systems which measure and monitor precisely each information transaction can be used to refine the process of delivering audiences of viewers, listeners, readers, movie fans, telephone and computer users, to advertisers. Companies can package and repackage customers in forms that specifically reflect both their actual purchases and their demographic characteristics. These packages, for example, of 18-25 year old women who order pop music concerts on pay-per-view television, can be sold to companies, which spend more for this information because they want to market their products to this specific sector with as little advertising wasted on groups not interested or able to buy. [...] it is applied to almost every communicationmedium today. 

(Facebook, Amazon and Ebay are some of the major players in packaging users and promoting them to advertisers.)

P.53
Companies sell software well before it has been debugged in the understanding that the customer will report errors, download and install updates, and figure out how to work around problems. This ability to eliminate labour, combine it to perform multiple tasks, and shift labour to unpaid consumers, further expands the revenue potential (Hardt and Brennan, 1995; McKercher, 2002; Sussman and Lent, 1995)

(I doubt that this is a successful way of selling software. In Cathedrals and Bazaars (1998), Raymond explains the nature of open source development, in which volunteers (hackers) contribute to a piece of software on a voluntary basis. However, in general the software is free. This is a major criteria for consumers to tolerate bugs and to decide to go for the buggy beta version rather than using the establishes, previous stable version. Examples are the Linux operating system, the Joomla CMS, and PHP script language.)       

 P.54
(after describing the centralisation of power in the US, Europe and Canada, in regard to the communication sector, Mosco states:) 

[...] the combination of growing concentration and diminishing regulation certainly lead some, such as Cass Sunstein (2001), to fear that cyberspace will shrink from its mythic potential to advance democracy and become little more than a commercial space with less than adequate room for diversity and the clash of ideas.

(If Mosco would have experienced the Arab spring (reference), the emergence of crowdfunding and other examples of the power of the community in 2005, he would have rethought the above reasoning. While large media companies try to make an impact on the World Wide Web, individual Web users increasingly become aware that they are not at all a the mercy of big business or despotic regimes.)

P.62
(Referring to Naomi Klein's book No Logo (2002), Mosco makes an important remark, supporting his thesis that the Internet might become a highly commercialised space.) 

Starting from the view that the brand is "the core meaning of the modern corporation", she documents the global spread of brand identities made most successful in such visual brand icons as the golden arches of McDonalds and the Nike Swoosh. Brands have spread beyond the specific commercial product, like the hamburger or the running shoe, to encompass places, events, people, activities, and now governments.

[...]Concepts lead to questions. As a mythic brand, globalisation leads only to one response: Amen. In essence, brands are the depoliticised speech, the period, the exclamation point, and cultural or rhetorical stop signs* of globalisation. 

footnote on p. 62: *'Coca Cola has actually branded highway signs across Tanzania, so that it's brand is literally that nation's stop sign.  

(Things have obviously changed since 2005. There are no longer rhetorical stop signs around in Tanzania - not even on the clock tower in the centre of Dodoma.)

p.63
Global social movements are today based on the ability to strip the cover from the gloss from a brand to reveal not only the exploitation of labour, but also the commercialisation of life and threats to the earth's environment. Today's movements range widely and include some who's work is primarily in cyberspace, such as the open source movement, what one analyst calls a loose network army of 750,000 software programmers worldwide made up of hackers, crackers, and people running file sharing heirs to Napster like KaZaA. The force is typically far looser than  most armies, but it tends to unite against commercialism and the concentration of control over cyberspace (Hunter, 2002).

p.64

As Kline and Dyer-Whiteford describe (1999), many of the major opposition movements have been based on building global political networks through the use of communication systems. This strategy takes many forms including attacks on the communications system of transnational companies and their political organisations, such as occured in January 2001, when Microsoft computer networks and the servers containing private data,such as credit card information of the elite participants at the World Economic Forum in Davos , Switzerland were hacked and opened (Weisman, 2001; Reuters, 2001b). It also includes the use of computer communications to organise an alternative to the  annual Davos meeting that brought together some 20,000 people in Porto Allegre, Brazil before the World Social Forum, a six day meeting whoes theme "Another World is Possible" featured social movement groups representing labour, women, environment, minorities and numerous other communites. 

This potential for convergence between labour and consumption demonstrates, that convergence does not just mean plugging a cable modem into a PC, or AOL into Time Warner. For some these global social movements hold out hope for a renewed public sphere, cosmopolitan citizenship and a genuinly democratic cyberspace. The convergence of labour and consumption and the politics of citizenship, which seem to mark so much of what gets all too gibbly called the anti-globalisation movement, may be the most significant form of convergence to understand today. But there was more such hope before the events of September 11.

The end of history, geography and politics are compelling myths and they are made all the more powerful with the expansion of cyberspace. However, with the spread of anti-globalisation movements, and the substantial boost that cyberspace has provided them, even more so with the events on 9/11 and subsequent wars in Afghanistan and Iraq, it appears that time, space and power have returned with a vengeance. Indeed, we may be seeing the emergence of a new mythology, or the return of an old one. As John Cassidy put it, "After September 11 it seems luidcrous to speculate about an escape from history or geography." (Cassidy, 2002: 313) Putting it more powerfully, Robert Kaplan envisions a world ravaged by war, desease and environmental havoc, all of which lays the groundwork for what he calls The Coming Anarchy (1997).    

This article reinforces the critique of the earlier claims about the Internet as a liberalising force ending oppression and reinforcing democracy. How does Mosco support his claim that the Internet "might be little more than an highly commercialized space with scarce room for diversity and debate" (p.49)?

In references to alternative movements that reside outside the traditional capitalist western world, Mosco describes the liberating power the Web provides to the individual. Rather than being limited to the role of a consumer, the individual is producer and consumer in personal union. Therefor the individual actively participates in the commercialisation of the Internet. While this may initially sound like a bad thing, the upside is that the individual has the power to choose in all aspects of her/his commercial activity on the Internet. Companies lose the power to dictate consumer needs and demands (Van Dijck & Nieborg, 2009). However, the commodification of media might be the reasoning behind Mosco's argumentation, but I doubt that this is a bad thing for the individual Internet user. With commodification comes diversification - it is in he hands of the user to decide what to choose, not the media anymore. 

The Cathedral and the Bazaar - E.S. Raymond vs. N. Bezroukov

The Cathedral and the Bazaar by Eric S. Rayond

Highlighted and (commented):

The Cathedral and the Bazaar

Linux is [...] part-time hacking by several thousand developers scattered all over the planet, connected only by the tenuous strands of the Internet?

I had been preaching the Unix gospel of small tools, rapid prototyping and evolutionary programming for years. [...] a priori approach was required. I believed that the most important software needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time.

(What Raymond describes as the Bazaar, using Linus Torvald's development style as an example)

[...] release early and often, delegate everything you can, be open to the point of promiscuity - came as a surprise. [...] the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches out of which a coherent and stable system could seemingly emerge only by a succession of miracles.

[...] propose some aphorisms about effective open-source development. [...] understand exactly what it is that makes the Linux community such a fountain of good software - and help you become more productive yourself.

(Raymond's first conclusion)

1. Every good work of software starts by scratching a developer's personal itch.

[...] too often software developers spend their days grinding away for pay at programs they neither need nor love. But not in the Linux world - which may explain why the average quality of software originated in the Linux community is so high. (demand emerges from usability questions that are discussed in the community. Rather than starting from scratch, trying to develop something new, there might be someone around who has already pondered this thought and started to find a solution. Putting the projection into the open, the community is enabled to share the ideas and collaboratively search for solutions.)

So, did I immediately launch into a furious whirl of coding up a brand-new POP3 client to compete with the existing ones? Not on your life!

2. Good programmers know what to write. Great ones know what to rewrite (and reuse).

[...] An important trait of the great programmers is constructive laziness [...] not for effort but for results...

Linus Torvalds, for example, didn't actually try to write Linux from scratch. 

So spending time looking for some else's almost-good-enough is more likely to give you good results in the Linux world than anywhere else. (As it's already there you refine rather than design)

[...] The one I first settled on was 'fetchpop' by Seung-Hong Oh. I put my header-rewrite feature in it, and made various other improvements which the author accepted into his 1.9 release.

[...] you often don't really understand the problem until after the first time you implement a solution.

I sent my first set of popclient patches to Carl Harris on 25 June 1996, [...] he had basically lost interest in popclient some time before. I had many changes to make, and we quickly agreed that the logical thing for me to do was take over the program.

4. If you have the right attitude, interesting problems will find you.

5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.

(Mutual trust/respect will result in the will to share) Without ever having to discuss it, Carl and I knew we had a common goal of having the best solution out there. The only question for either of us was whether I could establish that I was a safe pair of hands. Once I did that, he acted with grace and dispatch. I hope I will act as well when it comes my turn.

[...] I inherited popclient. Just as importantly, I inherited popclient's user base. Users are wonderful things to have, and not just because they demonstrate that you're serving a need, that you've done something right. Properly cultivated, they can become co-developers.

[...] a lot of users are hackers too. Because source code is available, they can be effective hackers. (Those users who don't have the understanding of hackers might be left behind - they also think differently than hackers. Hackers have a certain level of command over the code behind the software and understand why and how things work. Users without hacker qualities only know the surface of the software and appreciate its qualities from this perspective alone. However, they are encouraged and use the opportunity to reveal bugs or to suggest improvements. Both hackers and users without hacking skills share these forums to mutually help improve the quality of the software. Altogether they make up the bazaar, which will be explained better later on)

6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

In fact, pretty well all of us in the open-source world drastically underestimated how well it would scale up with number of users and against system complexity, until Linus Torvalds showed us differently.

[...] something he (Linus Torvalds) has often said: "I'm basically a very lazy person who likes to get credit for things other people actually do." [...] too lazy to fail.

In contrast to the cathedral-building style of the Emacs C core and most other FSF (Free Software Foundation) tools, the evolution of the Lisp code pool was fluid and very user-driven. Ideas and prototype modes were often rewritten three or four times before reaching a stable final form. And loosely-coupled collaborations enabled by the Internet, a la Linux, were frequent.

One unexpected side-effect of FSF's policy of trying to legally bind code into the GPL (General Public License) is that it becomes procedurally harder for FSF to use the bazaar mode, since they believe they must get a copyright assignment for every individual contribution of more than twenty lines in order to immunize GPLed code from challenge under copyright law.

Linus was treating his users as co-developers in the most effective possible way:

7. Release early. Release often. And listen to your customers.

(The following 3 paragraphs explains how it is up to the user to be a leader and cope with bugs in fresh beta versions or to be a follower and only opt for the versions confirmed stable - it mostly depends on bug tolerance and involvement in the development of the software.)

This belief reinforced the general commitment to a cathedral-building style of development. If the overriding objective was for users to see as few bugs as possible, why then you'd only release one every six months (or less often), and work like a dog on debugging between releases. The Emacs C core was developed this way. The Lisp library, in effect, was not - because there were active Lisp archives outside the FSF's control, where you could go to find new and development code versions independently of Emacs's release cycle.

The most important of these, the Ohio State elisp archive, anticipated the spirit and many of the features of today's big Linux archives. But few of us really thought very hard about what we were doing, or about what the very existence of that archive suggested about problems in FSF's cathedral-building development model. I made one serious attempt around 1992 to get a lot of the Ohio code formally merged into the official Emacs Lisp library. I ran into political trouble and was largely unsuccessful.

But by a year later, as Linux became widely visible, it was clear that something different and much healthier was going on there. Linus' open development policy was the very opposite of cathedral-building. The sunsite and tsx-11 archives were burgeoning, multiple distributions were being floated. And all of this was driven by an unheard-of frequency of core system releases.

Linus seems to me to be a genius of engineering, with a sixth sense for avoiding bugs and development dead-ends and a true knack for finding the minimum-effort path from point A to point B. Indeed, the whole design of Linux breathes this quality and mirrors Linus' essentially conservative and simplifying design approach.

(The credo of Linus Torvalds) Linus was keeping his hacker/users constantly stimulated and rewarded - stimulated by the prospect of having an ego-satisfying piece of the action, rewarded by the sight of constant (even daily) improvement in their work.

(Point 8 is an essential remark)

8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

Raymond coins this Linus' Law: "Given enough eyeballs, all bugs are shallow."

(Coming back to the user/hacker relationship - A find bug and reports it to the community, b finds report and solves bug, reporting back to the community) "Somebody finds the problem", he says, "and somebody else understands it. And I'll go on record as saying that finding it is the bigger challenge." But the point is that both things tend to happen quickly.

(An essential differentiation between Cathedral and Bazaar) Here, I think, is the core difference underlying the cathedral-builder and bazaar styles. In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you've winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect.

In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena - or, at least, that they turn shallow pretty quick when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door.

(If Linus' law is true...) it is sufficient to explain Linux's relative lack of bugginess.

Sociologists years ago discovered that the averaged opinion of a mass of equally expert (or equally ignorant) observers is quite a bit more reliable a predictor than that of a single randomly-chosen one of the observers. They called this the "Delphi effect". 

Jeff Dutky <dutky@wam.umd.edu> rephrased Linus' law as "Debugging is parallelizable". Jeff observes that although debugging requires debuggers to communicate with some coordinating developer, it doesn't require significant coordination between debuggers.

(duplication of development is minimized by a rapid succession of releases) In practice, the theoretical loss of efficiency due to duplication of work by debuggers almost never seems to be an issue in the Linux world. One effect of a "release early and often policy" is to minimize such duplication by propagating fed-back fixes quickly.

"The total cost of maintaining a widely used program is typically 40 percent or more of the cost of developing it. Surprisingly this cost is strongly affected by the number of users. More users find more bugs".

[...] This effect is amplified when the users are co-developers. Each one approaches the task of bug characterization with a slightly different perceptual set and analytical toolkit, a different angle on the problem. The "Delphi effect" seems to work precisely because of this variation. 

So adding more beta-testers may not reduce the complexity of the current "deepest" bug from the developer's point of view, but it increases the probability that someone's toolkit will be matched to the problem in such a way that the bug is shallow to that person.

[...] users can make a choice either to run the last version designated "stable" or to ride the cutting edge and risk bugs in order to get new features.

9. Smart data structures and dumb code works a lot better than the other way around.

10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.

What I saw when I thought about SMTP forwarding was that popclient had been trying to do too many things. It had been designed to be both a mail transport agent (MTA) and a local delivery agent (MDA). With SMTP forwarding, it could get out of the MDA business and be a pure MTA, handing off mail to other programs for local delivery just as sendmail does.

Why mess with all the complexity of configuring a mail delivery agent or setting up lock-and-append on a mailbox when port 25 is almost guaranteed to be there on any platform with TCP/IP support in the first place? 

12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.

I had been trying to solve the wrong problem by continuing to develop popclient as a combined MTA/MDA with all kinds of funky local delivery modes.

[...] it's often time to ask not whether you've got the right answer, but whether you're asking the right question. Perhaps the problem needs to be reframed.

Also, the only way to lose mail vanished. If you specified delivery to a file and the disk got full, your mail got lost. This can't happen with SMTP forwarding because your SMTP listener won't return OK unless the message can be delivered or at least spooled for later delivery.

13. "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away." (Less is more)

14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected. (Scalability)

(How Bazaar works - preconditions) 

Your nascent developer community needs to have something runnable and testable to play with.

I think it is not critical that the coordinator be able to originate designs of exceptional brilliance, but it is absolutely critical that the coordinator be able to recognize good design ideas from others.

And I have already described how the single most powerful design idea in fetchmail (SMTP forwarding) came from somebody else.

A bazaar project coordinator or leader must have good people and communications skills.

(Raymonds' self impression) It is not a coincidence that Linus is a nice guy who makes people like him and want to help him. It's not a coincidence that I'm an energetic extrovert who enjoys working a crowd and has some of the delivery and instincts of a stand-up comic. To make the bazaar model work, it helps enormously if you have at least a little skill at charming people.

(Reference to Weinberg's book The Psychology of Computer Programming, 1971) In his discussion of "egoless programming", Weinberg observed that in shops where developers are not territorial about their code, and encourage other people to look for bugs and potential improvements in it, improvement happens dramatically faster than elsewhere.

(ESSENTIAL THOUGHT) [...] while coding remains an essentially solitary activity, the really great hacks come from harnessing the attention and brainpower of entire communities. The developer who uses only his or her own brain in a closed project is going to fall behind the developer who knows how to create an open, evolutionary context in which bug-spotting and improvements get done by hundreds of people.

But the traditional Unix world was prevented from pushing this approach to the ultimate by several factors. One was the legal contraints of various licenses, trade secrets, and commercial interests. Another (in hindsight) was that the Internet wasn't yet good enough.(This article was published in 1998 - 15 years ago, I wonder what Raymond would say, having the opportunities of Web 2.0 at hand)

Linux was the first project to make a conscious and successful effort to use the entire world as its talent pool.

But what is this leadership style and what are these customs? They cannot be based on power relationships - and even if they could be, leadership by coercion would not produce the results we see. Weinberg quotes the autobiography of the 19th-century Russian anarchist Pyotr Alexeyvich Kropotkin's "Memoirs of a Revolutionist" to good effect on this subject:

"Having been brought up in a serf-owner's family, I entered active life, like all young men of my time, with a great deal of confidence in the necessity of commanding, ordering, scolding, punishing and the like. But when, at an early stage, I had to manage serious enterprises and to deal with [free] men, and when each mistake would lead at once to heavy consequences, I began to appreciate the difference between acting on the principle of command and discipline and acting on the principle of common understanding. The former works admirably in a military parade, but it is worth nothing where real life is concerned, and the aim can be achieved only through the severe effort of many converging wills."

The "utility function" Linux hackers are maximizing is not classically economic, but is the intangible of their own ego satisfaction and reputation among other hackers. (One may call their motivation "altruistic", but this ignores the fact that altruism is itself a form of ego satisfaction for the altruist).

Linus, by successfully positioning himself as the gatekeeper of a project in which the development is mostly done by others, and nurturing interest in the project until it became self-sustaining, has shown an acute grasp of Kropotkin's "principle of shared understanding". This quasi-economic view of the Linux world enables us to see how that understanding is applied.

(Raymond confirms that the Bazaar approach doesn't only work for Linux -  he describes fetchmail as a positive result in the vein of Linux, trusting the community with enhancing the software and its capabilities) With the fetchmail project I have shown (albeit on a smaller scale) that his methods can be duplicated with good results. Perhaps I have even done it a bit more consciously and systematically than he.

(On free markets...) Many people (especially those who politically distrust free markets) would expect a culture of self-directed egoists to be fragmented, territorial, wasteful, secretive, and hostile. But this expectation is clearly falsified by (to give just one example) the stunning variety, quality and depth of Linux documentation. It is a hallowed given that programmers hate documenting; how is it, then, that Linux hackers generate so much of it? Evidently Linux's free market in egoboo works better to produce virtuous, other-directed behavior than the massively-funded documentation shops of commercial software producers.

19: Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

[...] perhaps not only the future of open-source software. No commercial developer can match the pool of talent the Linux community can bring to bear on a problem. Very few could afford even to hire the more than two hundred people who have contributed to fetchmail!

Perhaps in the end the open-source culture will triumph not because cooperation is morally right or software "hoarding" is morally wrong (assuming you believe the latter, which neither Linus nor I do), but simply because the commercial world cannot win an evolutionary arms race with open-source communities that can put orders of magnitude more skilled time into a problem.

Reference

Weinberg, G. P. (1971). The Psychology of Computer Programming. New York, Van Nostrand Rheinhold

A second look at the cathedral and the bazaar by Nikolai Bezroukov

Highlighted and (commented):

The Cathedral and the Bazaar is sometimes considered as a Manifesto of the Open Source Movement. This paper will try to analyze just CatB.

[...] the bazaar metaphor is internally contradictive. 

[...] open source is described as a revolutionary phenomenon. To me it is just another form of a scientific community. [...] not a new and revolutionary model, but just a logical continuation of the Free Software Foundation's (FSF) GNU project. 

[...] CatB and will try to provide a more objective picture of the status competition in the OSS environment.

The real problem with the CatB statement is that due to the popularity of CatB this statement could discourage OSS community from reading and studying The Mythical Man-Month, one of the few computer science books that has remained current decades after its initial publication. Actually the term "Brooks' Law" is usually formulated as "Adding manpower to a late software project makes it later". (To state that a project is late indicates that developers are working towards a deadline. Linux, as well as fetchmail and other OSS are engaged in ever ongoing developments. Version after version is released - as such the projects are not late. To state this would be more appropriate in the application of developed software in an industry setting.)

Most top-level software professionals are more like artists, in spite of the technical nature of their specialty. It is not a coincidence that another classic book on programming is entitled The Art of Computer Programming. Communication, personality and political problems definitely creep into any project, as any manager of a sizable programming project can attest. These problems certainly drag productivity down. (They do, but the impact on the individual is similar to the impact on the group, as they face similar problems. However, the larger the group, the simpler the problem solving)

It's simply naive to assume that for the same team Internet connectivity can improve performance in comparison with, say, LAN connectivity or using the same mainframe. (From a 2013 perspective, Bezroukov is plain wrong with this statement)

I believe that the illusion of the non-applicability of "mythical man-month postulate" and Brooks' Law is limited only to projects for which a fully functional prototype already exists and most or all architectural problems are solved. This may have been the case for Linux, which is essentially an open-source re-implementation of Unix.  

Given enough eyeballs, all bugs are shallow"

The debugging of a complex system is much more difficult undertaking that simply getting a huge number of "eager co-developers" to analyze lines of code. For most complex projects for every second or third bug located and fixed another one may be introduced. Here Linux distributions can serve as a pretty good illustration as most "production" versions in retrospect (taking into account the number of bugs and fixes applied to them before they became obsolete) probably can be reclassified as beta. (They can be classified as beta, but people keep working on betas to make them stable in the aims of creating the next full-version, while working on the runner-up beta.)

CatB assumes that several talented developers can successfully work on the same piece of code in parallel without any coordination other than e-mail; one of them eventually will fix the code quicker than in the commercial environment with specially trained testers. Certainly, if enough talented developers try to find the same bug simultaneously it probably will be found sooner or later. But there are several problems with this idea of parallel debugging. Several questions arise: (The mistake Bezroukov makes is that he puts users and developers into one stack. This might be the case for Linux, as most users are professionals who administrate the system and provide it for use to other IT-professionals. But this is not the case across the board. In many other cases there are front end users who have no relation to the development of OSS. These people also contribute to forums in which bugs are discussed, not to share a developer experience, but to make an existing OSS more useful and therefor more attractive to a broader audience.) 

• Is this the best way to utilize talented developers?
  [...] if we assume that ten talented developers work constantly to isolate one given bug, we might call this plan a kind of "Mongol horde" approach. Improved project management could be more beneficial than throwing ten programmers after a single bug. Talented developers who understand a given system are extremely scarce and this sort of approach is extremely wasteful. (problematic: assuming disorganised developers)
• Are all bugs created equal?
  The problem of stagnation of early architecture solutions, wasting time and effort in debugging instead of solving underling architectural problems, is common to OSS projects. The peculiarities of the open source status game give a higher priority to those "heroic" efforts in debugging rather than emphasizing software architecture or planning. (Bezroukov's claim lacks referencing)
• Is it easy to force gifted programmers to search for the same bug?
  Talented developers are first programmers not testers [...] (no! They are not) [...] For any sufficiently complex project there will be never be sufficient "eyeballs" to locate and eradicate all bugs. (Wrong again, the more users the higher the likeliness that bugs will be detected and eradicated)

(Bezroukov also forgets to distinguish between those who get paid fgor their efforts and those who volunteer their time - these are two different levels of attachment to problem solving. One is rewarded with recognition only, the other one also gets paid.)

Thompson: I view Linux as something that's not Microsoft - a backlash against Microsoft, no more and no less. I don't think it will be very successful in the long run. I've looked at the source and there are pieces that are good and pieces that are not. A whole bunch of random people have contributed to this source, and the quality varies drastically. (Meanwhile history has confirmed that it is still highly competitive and better quality than Microsoft Windows - and it is still free.)

Microsoft is really unreliable but Linux is worse. [...] if you want to use Linux in firewalls, gateways, embedded systems, and so on, it has a long way to go."

In his response to the ESR's letter on his interview, Ken Thompson noted that:

"I do believe that in a race, it is naive to think Linux has a hope of making a dent against Microsoft starting from way behind with a fraction of the resources and amateur labor. (I feel the same about Unix.)" (As already mentioned above: Meanwhile history has confirmed...)

This discussion suggests that limiting those who can directly contribute to the kernel to a few most qualified developers (the core team) is a good idea. The Bazaar model should be avoided in kernel development as much as possible. (Linus Torvalds developed the kernel and keeps control over it)

Metaphors for high centralization (Cathedral) and 
no centralization (Bazaar) 

In the opinion of Linus Torvalds:

The ultimate example is Linux itself. Creator Linus Torvalds has final say over all changes to the kernel of the popular open source clone of Unix. Because the Linux development community has grown so large, most software patches are reviewed by many different people before they reach him, Torvalds said.

[...] If the patch is rejected, there is no recourse, which sounds pretty un-democratic. (But what about the other way around? Isn't that lack of quality control?)

Jordan Hubbard noted:

"Despite what some free-software advocates may erroneously claim from time to time, centralized development models like the FreeBSD Project's are hardly obsolete or ineffective in the world of free software. A careful examination of the success of reputedly anarchistic or "bazaar" development models often reveals some fairly significant degrees of centralization that are still very much a part of their development process." (A bazaar cannot run itself either.Someone has to be at the helm to stir the organisational part of a bazaar, to prevent utter chaos. Linus torvalds is in this role with Linux. Developers do what they think might appropriately add to the model and Torvalds will either take it on or reject it. )

Jonathan Eunice remarked:

"The problem is not that it reaches wrong conclusions, but rather that it assumes an open-is-good/commercial-is-bad worldview that we doubt most IT managers share. Beyond proselytizing, it also paints all of software development against just two exemplars. The Cathedral represents a monolithic, highly planned, top-down style of software development. The Bazaar, which he recommends, represents a chaotic, evolutionary, market-driven model. Rarely do such simple categorizations do justice to reality. (Then why is OS so popular?)

... Raymond's paper touches upon, but never highlights, the synthesis of his antipodes: "when you start community-building, what you need to be able to present is a plausible promise. Your program doesn't have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is convince potential co-developers that it can be evolved into something really neat in the foreseeable future.

What a perfect explanation of the Microsoft juggernaut! As Redmond understands, your product need not be strong at first shipment as long as one has a "plausible premise" of later product strength, of setting a standard, or of uniquely satisfying a pressing need - and as long as the early versions provide a foundation of revenue, user base, and an investment pool that is wisely reinvested to achieve continual improvement and eventual leadership. The units of measurements may differ between the open source and commercial communities, but the concept of economic foundation is identical.

That Microsoft - the antithesis of the Linux/freeware/open source community - can so effectively utilize the same Bazaar principles suggests two conclusions. First, that the Cathedral and the Bazaar provide too few data points to use in plotting the programming process. Second, that there are a set of surprisingly universal guidelines involving flexibility, modularity, and an aggressive feedback loop that all software developers should seriously consider adopting as their guiding principles."

Many Microsoft business strategies have close analogs in open source. As the authors of the Halloween-I document put it:

"Different reviewers of this paper have consistently pointed out that internally, we should view Microsoft as an idealized OSS community but, for various reasons do not."

Based on the accounts in James Wallace and Jim Erickson's book Hard Drive: Bill Gates and the Making of the Microsoft Empire (New York: Harper Business, 1992) Microsoft's early business practice seemed to follow Bazaar-style ideas:

• Release early. Release often.
  Initiative is the key. Turn users into testers or co-developers. Attracting developers is very important as it helps bring in users. Microsoft could be considered a pioneer in utilizing the following recommendation from CatB:

  "Given a bit of encouragement, your users will diagnose problems, suggest fixes, and help improve the code far more quickly than you could unaided."
• The Importance of Having Users.
  Cultivate your user base. Avoid perfection like a plague. Consider lack of perfection not as a problem but as an opportunity for improvements in future versions. As Linus Torvalds noted:

  "... the future of the operating system software will be driven by user needs instead of programmers' curiosity ... The technology is not driving the market anymore. What people want is driving it... ."

  (For both the above statements and Bezroukovs comments: The difference is significant if you pay for a buggy software or if it is for free. For whch would you be more forgiving as a user?)
  
  Jonathan Eunice wrote:

"... The reality is that Microsoft turns out highly-capable programs, which it rapidly refines. While they do have a certain all-singing, all-dancing abundance of features, they are also unusually modular and cross-leveraged. Redmond's development model emphasizes many of those very attributes Raymond identifies with the Bazaar: quick turnaround, modular construction techniques, a large and active user base, many entities striving to improve it in a thousand parallel dimensions, and a strong feedback loop." (but these features are limited to the MS product range. There is very limited interaction with non-MS products) 

Software evolution, not revolution, is the theme. A large community of users inhibits revolutionary changes. From the perspective of those out in the trenches, Linux, gcc, Perl, Apache and other open source products are tools.
(Whentalking about users, Bezroukov is talking about IT-users. Not the large community of endusers who are not developers. It is my common experience to ignore non-developers, serving only their own needs rather than those of the end-user community. This is wht MS-products were so hard to understand and to use for average users - they were basically made for those who love to play around with programs, not for those who would like to have a convenient way of doing their job. Apple has always filled this gap, considering usability, making programs intuitive and considering the look & feel of their physical products, as well as desktops, icons etc.)


And in the opinion of users, a standard tool is much better than a non-standard tool. It is very difficult to unseat the dominance of an application that implements a standard. Nevertheless, success creates conditions that may lead to eventual stagnation. Like for any Posix-compatible OS, the possibility of innovation in Linux is limited by adherence to Posix standards. I am inclined to see part of the value and attractiveness of Linux as a new giant standard SuperBIOS not owned by any company. In a sense the game is over with stability becoming very important for application development. Eventually, we will see a lot of polishing of basic subsystems with better scheduling, SMP, TCP/IP, file systems and so on, but no radical architectural or API-related changes. In essence for Linux innovation will be, by and large, limited to applications. As Jamie Zawinski put it:

"There exist counterexamples to this, but in general, great things are accomplished by small groups of people who are driven, who have unity of purpose. The more people involved, the slower and stupider their union is."

Linux definitely passed the small group phase some time ago. Linux may become an innovative OS if it moves into a new domain, such as handheld devices, perhaps the most dynamic part of the OS market. But this is difficult due to a large installed base in the PC environment and architectural solutions that fit this particular environment better than others.

"People think just because it is open-source, the result is going to be automatically better. Not true. You have to lead it in the right directions to succeed. Open source is not the answer to world hunger."
- Linus Torvalds (So it requires a leader for a bazaar to be organized and pushed in the right direction.)

[...] I (Bezroukov) would agree with the first part of the following CatB quote:

"Perhaps this should have been obvious (it's long been proverbial that "Necessity is the mother of invention") but too often software developers spend their days grinding away for pay at programs they neither need nor love. But not in the Linux world - which may explain why the average quality of software originated in the Linux community is so high." (So, while he doesn't make any difference between paid and unpaid developers above, here he acknowledges the difference) 

(DEF.: Reverse Engineering - going from front end detail to the core program for documentation purposes)

[...] I do not agree with the arguments in CatB that turn Linux into a new development model, I now see one important innovation that already has started an important trend. For operating systems, the developmental and organizational complexity of the projects make the consequences of making code openly and freely available quite different from the consequences of opening source code in applications or other small or medium sized projects. (Who is the target audience? IT-people?)

[...] From the software engineering point of view, there are tremendous differences between a relatively simple project like Fetchmail and a large and complex project like the Linux kernel. (There are , but to replicate a successful approach to software development - does the project size really matter?)

[...] I believe that CatB fails to recognize several important dimensions of status competition. Among them I would like to outline:

• Hierarchical structure and corresponding distribution of political power in the open source environment;
• the possibility of unfair status hierarchies (favoritism);
• poisoning of the peer review process and problems with egoless programming;
• the danger of overload and burnout;
• the fear of exclusion as a motivational factor;
• the possibly of wrong status achievement lines;and,
• the role of the press.

They will be discussed below.

---

Hierarchical structure and corresponding distribution of political power in the open source environment.

"All issues are political issues, and politics itself is a mass of lies, evasions, folly, hatred and schizophrenia."
- George Orwell

CatB tends to describe open source as supportive, harmonious, trusting, collaborative and cooperative. Such non-political positioning can lead us erroneously to believe that members of the open source movement always behave in ways consistent with the interest of the movement. Let's start our discussion of this concept from the following quote from CatB:*

[...] But what is this leadership style and what are these customs? (Look at Linux - Torvalds& Co)

[...] * To operate and compete effectively, hackers who want to lead collaborative projects have to learn how to recruit and energize effective communities of interest in the mode vaguely suggested by Kropotkin's "principle of understanding". They must learn to use Linus' Law." (What is this supposed to mean?)

Sometimes the natural process of creation of hierarchical structures is considered by developers as a defensive reaction to noise and e-mail overload. Alan Cox described it in this way:

"Linux 8086 went on, the real developers have many of the other list members in their kill files so they can communicate via the list and there are simply too many half clued people milling around. It ceased to be a bazaar model and turns into a core team, which to a lot of people is a polite word for a clique. It is an inevitable defensive position in the circumstances." (That is a positive. Why let half clued people ruin your baby?)

We will define political behaviors as those activities that are not required as part of one's role in a given open source project or movement, but that influence, or attempt to influence, behavior of other members within the group. Some of these acts are trivial like flaming, bypassing chain of commands, forming coalitions, obstructing unfavorable decision of the leader or developing contacts outside the group to strengthen one's position within the group. Other are borderline like in-fighting, sabotage, whistle blowing and public protests that affect status of the project or movement as a whole. Most politics in open source communities is trivial although some individuals try to play "hardball". It's quite pragmatic; borderline political behaviors pose a very real risk of group sanctions, including loss of both status and membership in the project or group. (...and quality of the product. Again: Why is Linux so successful in the face of all these stumbling blocks?)

[...] The notion that the "principle of command" is abolished and of an "anarchist's paradise"in CatB are oversimplifications. The history of OSS projects provide plenty of convincing counterexamples:

"[...] The networking software at this time was still a large number of patches to the standard release of kernel code and was not included in the normal release. (!!!)

[...] There developed two distinct schools within the Linux networking community, one that had the philosophy of `make it work first, then make it better' and the other of 'make it better first'. [...] Fred continued to work for a short time and eventually stood down and Alan came to be the new leader of the Linux networking kernel development effort."

Actually all major OSS projects are hierarchically structured. This structure allows the head of a given project to dictate his will, which if necessary can be defended by political means - by direct exercise of power as in the example above. The claim that "They cannot be based on power relationships" has pretty superficial connections with reality.

(From here on I have no idea what Bezroukov is on about)

[...] Knowledge-based power is one of the most effective means to force others to perform as desired. Competence is the most legitimate source of political power and status in the OSS movement. No leader will ever distribute all the information he possess because ultimately it undermines his power. Actually, it is often physically difficult for a given leader to distribute all information given that any leader is usually overloaded. Open source is not immune from politically enforced limits on information sharing within a project. The mere availability of source code does not automatically translate into access to the most critical information.

(??? the following paragraph is utter nonsense. Is a political party a collective dictator to those who did not vote for them?)

Those with insufficient power are often seeking it, forming coalitions with others to enhance power and status. Coalitions are a natural phenomenon and cannot be avoided; there is a strength in numbers. The natural way to gain influence is to became a member of a coalition. Once a given coalition gains sufficient members it can challenge a single leader and promote any desirable changes. In this sense this sort of coalition becomes a collective dictator.

[...] typically in OSS projects the early followers display a high level of loyalty to their leader. It's natural for an OSS project leader to trust, respect and depend on early users and early co-developers, the old guard. This relationship is the result of experience, common interests, goals or backgrounds or simply the longevity of their relationship. 

Some contributing factors include:

• Long-term stress due to impossibly heavy workloads;
• Conflict between idealistic expectations and reality;
• E-mail overload;
• Poor time management (for example, debugging binges);
• Engaging in a rat race against commercial developers or commercial products;
• Role conflicts with conflicting priorities from a regular job, family and volunteer efforts;
• Architectural problems discovered late in the development cycle, with a failure to use the right tools or methods;
• Perfectionism; that is, difficulties in adapting to changes in feedback volume and an inability to reject user requirements for enhancements and bug fixes;
• Setting unrealistic deadlines with a parallel inability to meet multiple schedules; and,
• Lack of support from other developers in the OSS project.

But a significant aspect of Open Source development is that dvelopers are in it voluntarily -there is nothing binding in a volunteer position. They can simply leave, if it gets too hard) 

[...] For a complex and successful OSS product the volunteer stage should probably be a transitional one. (isn't tat exploitation?)

From my experience as a computer science teacher, (Bezroukov reveals that he is an academic - as such he has little exposure to the industrial world. This is an important aspect that may make his at times strange argumentation more understandable.) I suspect that the majority of people who are participating in OSS, especially those who spend more than nominal amounts of time, are young adults (ages 16-25). [...] It's not accidental that in the hacker community activities outside traditional the coding/compiling/debugging cycle are generally suspect, and regarded as lower status activities. "Code first, debug next, think later" seems to catch the essence of a hacker style. The related coding/debugging binges act in some circles as a way of distinguishing hackers from regular programmers. 

While partially escapist, hacking can become the main status achievement line. CatB does not really explain what is at stake that make status competition in open source development so intense and important. 

Linus Torvalds (like Microsoft to the Internet) was "Johnny-come-lately" to the Unix world. But his first and major success was the ability to overtake a very important stronghold - an existing development community (Minix community) and the corresponding channel of communication (Usenet group) and later to create his own. At that moment the Minix community - a very elite community of Unix enthusiasts - had approximately 40,000 members and included a substantial pool of talented developers (some who already successfully tried to rewrite parts of Minix to make it more Posix compatible). This redirection of the existing community toward a new goal was one of the most important events in Linux history, demonstrating the power of the Internet as a new press. None of other major OSes were developed this way. Of course the community was ripe for hijacking. There was some pre-existing discontent between the policy of the community leader (Andy Tannenbaum) and aspirations of the top layer of the community. Core members of the Minix community formed the core of the Linux team. The hierarchy of the members was already largely established, which probably helped to avoid unnecessary conflicts.

(The following paragraph gives an example of a great branding exercise.)

Specialized Linux magazines emerged in 1994 when Robert Young (one of the founders and former CEO of Red Hat) and the ACC Corporation published the first two issues of the Linux Journal. Later Phil Hughes became an editor. In March 1994 SSC, the publishers of Unix Pocket References, took over publication of the Linux Journal from Robert Young and the ACC Corporation. It's unclear to what extent these connections helped Red Hat but it's quite clear that from the beginning, the specialized press was a powerful, highly political and certainly pro-Linux force.

[...] Although Linuxtoday emerged as a leading news service for the community, recently commercialized Slashdot.org is a more interesting phenomenon. It is a unique blend of news service, technical discussion and advocacy forum that created a BBS-style community of "slashdotters". The number of participants is so large that the so-called "slashdot effect" is observed: when an interesting paper or application is reported on Slashdot there are often related server crashes from overload. (Occasionally, a story will link to a server causing a large surge of traffic, which can be overwhelming for smaller or independent sites. This phenomenon is known as the slashdot effect.)

Slashdot also serves as a political instrument for suppressing opposition, but an investigation of this phenomena is beyond the scope of this paper. I would like just to briefly mention "Slashnoise". Slashnoise can be generally described as letters and other forms of commentary from readers expressing opinions about programs or papers that have never been read or used by the commentators. [...] Slashdot zealots are prisoners of their own "Slashdot cage":

"On-line service is not as reliable as cocaine or alcohol, but in the contemporary world,it is a fairly reliable way of shifting consciousness ... . Compulsive gamblers are also drawn to the tug of war between mastery and luck. When this attraction becomes an obsession, the computer junkie resembles the intemperate gambler ... . Unlike stamp collecting or reading, computers are a psycho-stimulant, and a certain segment of the population can develop addictive behavior in response to that stimulant."

(There is no reference anywhere to slashnoise)

I suspect that the frequency distribution of postings among Slashdot correspondents is very uneven and is probably close to the Pareto Distribution. It is also informally known as 80-20 distribution, or in other words approximately 20% of the user population ("Slashaddicts") are participating in almost 80% of the discussions. Confirming this frequency distribution would be difficult. Many post under a generic handle like "Anonymous Coward" and any individual could use multiple handles. (!!! While he recognises it here, he doesn't seem to see the advantage of OSS development communities)

[...] It's not an accident that the best Linux books have been produced by commercial book publishers and some early participants in the Linux documentation project later published new books with commercial publishers. (No reference!)

Conclusion

The main problem with the Bazaar model is that it has no predictive power* for OSS's strong and weak points. [...]  I am strongly convinced that an academic model of OSS explains the phenomenon much better. (Raymond does not imply that Linux is popular because of the bazaar model definition, contributed to the quality of the software)

[...] CatB is an important paper that stimulated a discussion of OSS as a social organism and the value of using Internet for software development. 

CatB encouraged a whole re-thinking [...], especially the value of openness. 

[...] CatB [...] made an extremely important contribution by providing a framework of discussion of open source phenomena. In this role CatB should not be undervalued.

1. In the context of discussions over online economies, the words 'free', 'open source', and 'gift', are often applied as if they describe the same thing. What are the differences between them? Where do they overlap? Discuss with the class.

1. What sorts of relationship/s do you think operate between the exchange, free and open source economies? How compatible are they with capitalism?

1. Think of a software application that affects your Internet use. Is it free/open source or proprietory? What do the software developers 'get' out of providing this software? Search for alternatives, both free/open source and proprietory, and compare them. Which would you choose and why? Consider the value and future of open source alternatives.