Nicholas Carr has got it wrong. Open Source follows Bazaar model and it is democratic

Open Source Add comments

Recently, Nicholas Carr, an acclaimed writer and ex-editor of Harvard Business Review, wrote an article titled The Ignorance of the Crowds in the Strategy+Business Magazine (free registration required). In the article, he tries to portray open source as a hybrid Bazaar-Cathedral model and warns the businesses against any reliance on the open source process to drive innovation. I follow Carr’s writings regularly (through his blog and other media outlets). I have great respect for his work. But he has got this one totally wrong. In this post, I am going to take his arguments and show how he has got it totally wrong. Since Mr. Carr is an influential writer, I feel that he should have avoided the stereotypes and misunderstandings about the open source process. I just hope that he sees this post, as a response to his article, and considers my arguments for its merit.

In his article, he tries to portray open source process as one that drives optimization rather than innovation. In fact, the open source process owes its origin and philosophy to the scientific process, the fountain head of innovation. There are several hundred years of records to prove the “innovative value” of the scientific process. Similarly, the open source process is also an innovative process as it is based on the same framework as that of the scientific process. Once we understand the similarity between these two processes, we would, then, be able to appreciate the potential for innovation in the open source process too. Let us now dissect the flaws in the argument of Mr. Carr.

He points out three weaknesses in the open source process. I will first list his points and then offer my views on them. Mr. Carr says

  • First, peer production works best with routine or narrowly defined tasks that can be pursued simultaneously by a big crowd of people. It is not well suited to a job that requires a lot of coordination among the participants. If members of a large, informal group had to coordinate their efforts closely, their work would quickly bog down in complexity. The crowd’s size and diversity would turn from a strength to a weakness, and the speed advantage would be lost.
  • Second, because it requires so many “eyeballs,” open source works best when the labor is donated or partially subsidized. If Linus Torvalds had had to compensate all his “eyeballs,” he would have gone broke long ago.
  • Third, and most important, the open source model — when it works effectively — is not as egalitarian or democratic as it is often made out to be. Linux has been successful not just because so many people have been involved, but because the crowd’s work has been filtered through a central authority who holds supreme power as a synthesizer and decision maker. As the Linux project has grown, Torvalds has gathered a hierarchy of talented software programmers around him to help manage the crowd and its contributions. It’s not a stretch to say that the Linux bureaucracy forms a cathedral that coordinates the work of the bazaar and molds it into a unified product.

I do not agree with his first point. It is not just the peer production that works best in routine or narrowly defined tasks, any production works best only if the scope is very narrow or limited. Even the Windows operating system developed by Mircosoft, which is a perfect example of the cathedral model, is not developed by a single team. The whole Windows development process is split into many small teams and these teams are supervised and coordinated by leaders forming the hierarchy in the cathedral process. Large projects, whether it is a proprietary system or an open source system, will be bogged down by the complexities of managing smaller units. I really don’t understand why he uses this argument against the open source process while this is also the weakness in the development process of large projects in any model. Isn’t Microsoft of today is full of complexity and bureaucracy compared to the Microsoft of the first couple of years? Isn’t this the case with any large company / organization / project / government? I consider this argument as an weak attempt to portray the open source process as the only complex approach.

I really don’t understand why he pointed out the second weakness at all. In fact, what he calls as the weakness in this case is actually the strength of the open source process. It is true that many open source projects are done at the “volunteered time” of many of its participants. In fact, the very concept was born in this fashion only. Only recently, we are seeing many contributors working full time on open source projects. This is happening due to the generous contribution of resources by many big companies, who are either fascinated by the open source process or owe their existence/success to it. If we take out this recent phenomena of “full time open source developers”, there is nothing new or surprising about the open source development taking place due to the donated/subsidized labor. In fact, this is one of the biggest strengths of open source development process. A developer volunteers his/her extra time to a project because he/she uses the project and likes it very much. Who, in their sane mind, will spend their valuable time coding for a project if they find no use or liking for it? It is this passion of these developers, that drives the whole open source software development process. In the cathedral world, even if a company pays a hefty amount as salary for a developer, they cannot derive such a high passion from anyone. This passion in the open source development process is the main reason for the high quality and security of the open source software. So, this development in the “volunteered time” is not a weakness of the open source process but its greatest strength. The very fact that myself, instead of Linus, is refuting Mr. Carr’s arguments, itself, is a testimony to this strength of open source. Open source need not employ a PR firm to refute Mr. Carr’s arguments. Thousands of passionate supporters, like me, can give an effective rebuttal to his article.

The third point is completely wrong. It is true that Linux Torvalds approves all the patches that goes into his kernel tree. However, there are two things to be considered here.

  1. First, unlike the cathedral model, one need not get Torvalds’ approval to develop a new “feature” or fix an existing issue. The developers can write the code and patch the kernel internally. By the time they finish this successfully, the whole issue is discussed to death (quoting Torvalds himself) in the kernel mailing list. If the code withstands this discussion, it gets into the main kernel code, even if Linus has some issues with it. The entire process is perfectly democratic and any attempt to portray this process as something similar to the bureaucracy in the cathedral model, only amounts to the lack of understanding of the kernel development process.
  2. Second, it is not necessary that we should only have one kernel. Linus’ kernel is not the supreme one. It so happened that many of the distributions use this kernel due to the wide acceptability and participation in its development process. If any company or individual wants to have their own kernel, they are free to do so. This is the beauty of open source model. No vendor lock-in like the proprietary systems.

Mr. Carr argues that the open source process needs both bazaar style and cathedral style, in some sort of a symbiotic relationship. He implies that Mr. Raymond missed this point completely in his seminal paper The Cathedral and the Bazaar. From my clarification above, to Mr. Carr’s arguments, it is quite easy to see that the open source process is only a bazaar style process and the cathedral style is not necessary for its success. Mixing of cathedral style, however, is not prohibited but it is just not necessary.

Mr. Carr, then, uses the Wikipedia as an example to substantiate his point. I wouldn’t compare Wikipedia with Linux Operating System. First, the barrier to the entry in the case of Wikipedia is very low compared to that of Linux. Any Tom, Dick and Harry, with an internet connection, can add/edit/change the Wikipedia content whereas you need a higher level of understanding, of operating systems and programming, to even participate in the development of Linux. This higher barrier to the entry is the main reason for the high quality of Linux rather than any imagined bureaucracy. The weakness of Wikipedia lies not in its open source approach but in its accessibility to the much wider audience with absolutely no barrier on the entry. This cannot be considered as a weakness in the open collaboration process itself. Rather, the weakness is due to lack of participation of enough experts in the Wikipedia itself. Let us say if the world sets out to create “vertical wikipedias” for each and every narrow field, then the quality of content in each of these vertipedias will be much better than the Wikipedia because the experts in those narrow fields will be contributing to it out of interest. They will participate with so much passion that we will get far superior information than what we can get in any commercially made encyclopedia. The same experts may not show the same interest in Wikipedia due to its wider scope. The collection of such expert driven vertipedias can then form a “Superior Wikipedia” with the best possible information. We can see the real effects of the open source process in this “Superior Wikipedia”. The flaw in the execution of an approach should not be construed as a flaw in the approach itself.

Mr. Carr’s article consists of many misunderstandings about the open source process itself and also some wrong examples (like the comparison of Wikipedia to Linux). Under such a scenario, I would also argue that his conclusion below is flawed.

It seems fair to say that although the bazaar should be defined by diversity, the cathedral should be defined by talent. When you move from the bazaar to the cathedral, it’s best to leave your democratic ideals behind.

I will conclude my article with another conclusion, one that takes into account the flaws I have highlighted in Mr. Carr’s arguments. It is only fair to say that the bazaar model is defined both by diversity and by talent. Open source process drives innovation much in the same way as the scientific process. When there is absolutely no need for us to move into the cathedral model, it is best to do our best to uphold the democratic ideals. It is time for an awakening in the open source community about these misunderstandings, spins and stereotypes. It is time for us to tell the business community that they will only benefit from the open source platform. As I have already mentioned in my previous blog posts, open source is neither socialism nor a business model. It is a perfectly suitable platform on which capitalism can thrive.

PS: I just hope that Mr. Carr sees this post and takes it seriously for its merit instead of dismissing it as a rant. This is a legitimate argument on the true nature of open source and also an attempt to remove the misunderstanding that exists in the minds of many entrepreneurs, managers and writers like Mr. Carr.

31 Responses to “Nicholas Carr has got it wrong. Open Source follows Bazaar model and it is democratic”

  1. Tim Hodkinson Says:

    Nice rebuttal. I agree that what perplexes many people about Open Source is the motivation behind its development, which is harnessing people’s natural desire to contribute to their community. I think this motive is actually stronger than “making money” and, as you’ve suggested, makes Open Source development more reliable and of higher quality than proprietary software. I think the difficulty for some in accepting the validity of “community gain” (as opposed to personal gain) as an explanation for the current high quality and future potential of Open Source is that they’ve never seen this “community” thing in action before. This is why Open Source is such a revolutionary concept and also why it’s been labelled as utopian by its critics, because it’s reveals an alternative way for our entire society to operate by. But if you think about it, isn’t this the very foundation of civilization: contributing to the common good, instead of just ourselves or our own little tribe? Open Source is just the computing world becoming more civilized, that’s all.

  2. Tim Hodkinson Says:

    Nice rebuttal. I agree that what perplexes many people about Open Source is the motivation behind its development, which is harnessing people’s natural desire to contribute to their community. I think this motive is actually stronger than “making money” and, as you’ve suggested, makes Open Source development more reliable and of higher quality than proprietary software.

    I think the difficulty for some in accepting the validity of “community gain” (as opposed to personal gain) as an explanation for the current high quality and future potential of Open Source is that they’ve never seen this “community” thing in action before. This is why Open Source is such a revolutionary concept and also why it’s been labelled as utopian by its critics, because it’s reveals an alternative way for our entire society to operate by.

    But if you think about it, isn’t this the very foundation of civilization: contributing to the common good, instead of just ourselves or our own little tribe? Open Source is just the computing world becoming more civilized, that’s all.

  3. David Mohring (NZher Says:

    From April 2005 : Core, maintaining reputation and license to fork http://itheresies.blogspot.com....._archive...“Any so called analyst or even a journalist who covers open source software, that cannot grasp the above simple concepts must be lacking in either competence or integrity.”

  4. David Mohring (NZher Says:

    From April 2005 : Core, maintaining reputation and license to fork http://itheresies.blogspot.com....._archive...“Any so called analyst or even a journalist who covers open source software, that cannot grasp the above simple concepts must be lacking in either competence or integrity.”

  5. krishnan Says:

    Thanks Tim, Thatz exactly my point too. Contributing to the common good has existed from the days of primitive man. In fact, the scientific research is a perfect example of this approach.

  6. Sander Marechal Says:

    I have a far better rebuttal for Mr. Carr’s third point: The project leader a.k.a. benevolent dictator for life a.k.a. the “filter” he refers to is actually a requirement for a successful bazaar. Mr. Carr should re-read “The Catherdral and the Bazaar” and specifically the section titled ” Necessary Preconditions for the Bazaar Style”. It’s also exactly the reason why his comparison to wikipedia is flawed (and incidentally, what’s wrong with Wikipedia). Wikipedia isn’t based on an open source model. It’s based on a free-for-all. A commons. The fact that wikipedia does not have a central body that vets/filters contributions is exactly what makes it different from a general open source bazaar model. Incidently, I think it’s also the cause of Wikipedia’s trouble with trolling, spamming, vandals, etcetera. This is also my only point of disagreement with your (otherwise very nice) rebuttal. If Linux has a barrier to entry as low as Wikipedia has, it would still be better than Wikipedia because of the filtering/vetting process. Adding more experts to Wikipedia doesn’t make it a better site. It would only increase edit wars. I mean, have you ever seen a successful open source project that had no vetting/filter process in place on code contributions?

  7. David Mohring (NZheretic) Says:

    From April 2005 : Core, maintaining reputation and license to fork

    http://itheresies.blogspot.com.....chive.html

    “Any so called analyst or even a journalist who covers open source software, that cannot grasp the above simple concepts must be lacking in either competence or integrity.”

  8. krishnan Says:

    Thanks Tim,

    Thatz exactly my point too. Contributing to the common good has existed from the days of primitive man. In fact, the scientific research is a perfect example of this approach.

  9. Sander Marechal Says:

    I have a far better rebuttal for Mr. Carr’s third point: The project leader a.k.a. benevolent dictator for life a.k.a. the “filter” he refers to is actually a requirement for a successful bazaar. Mr. Carr should re-read “The Catherdral and the Bazaar” and specifically the section titled ” Necessary Preconditions for the Bazaar Style”.

    It’s also exactly the reason why his comparison to wikipedia is flawed (and incidentally, what’s wrong with Wikipedia). Wikipedia isn’t based on an open source model. It’s based on a free-for-all. A commons. The fact that wikipedia does not have a central body that vets/filters contributions is exactly what makes it different from a general open source bazaar model. Incidently, I think it’s also the cause of Wikipedia’s trouble with trolling, spamming, vandals, etcetera.

    This is also my only point of disagreement with your (otherwise very nice) rebuttal. If Linux has a barrier to entry as low as Wikipedia has, it would still be better than Wikipedia because of the filtering/vetting process. Adding more experts to Wikipedia doesn’t make it a better site. It would only increase edit wars.

    I mean, have you ever seen a successful open source project that had no vetting/filter process in place on code contributions?

  10. krishnan Says:

    I agree with you on the role of the vetting process in the open source projects. I think Mr. Carr didn’t spend enough time trying to understand this.

  11. krishnan Says:

    I agree with you on the role of the vetting process in the open source projects. I think Mr. Carr didn’t spend enough time trying to understand this.

  12. vinea Says:

    I read his piece and it seems fairly even handed and it seems that ESR agrees with his assessment that the bazaar is not a good place for innovation but that a strong individual (with code written) is a key element to successful application of a bazaar which, given that there’s semi-working code, happens AFTER innovation. This is easily seen by looking at abandoned innovative open source projects that never had working code to coalesce around…meaning that the founder was insufficiently capable in being a “wizard”. Neat ideas, are in the end, easy. Building enough code so other folks can see the vision on the horizon…harder. His second weakness is certainly a valid one. Looking at many small open source project without sufficient eyeballs you can see where the bazaar breaks down. Hence the need for donation or subsidization of eyeballs. Some open source projects get this in the form of QA departments from the corporation that donates code to the project. Others just live without. They can live without as long as they have a few key coders (even if its just one) churning out semi-working code. Being on two of these projects I know that weakness fairly well and it is the bane of many otherwise wonderful projects to have piss poor documentation and haphazard user interfaces because the core coders don’t care and there are no other eyeballs. I recall very few bazaar projects (I recall none actually) without those core coders slinging code in a cathedral…aka the commiters. You may be able to fork your own kernel but getting in a kernel change into the Linux kernel without the approval of the committers is not happening. It is “democratic” only in the sense that Linus and the kernel committers get to vote. Just sitting on LKML or being a “citizen” of Linux doesn’t get you a vote. That’s hardly a democracy. A democratically run linux kernel would be a disaster. Vinea PS As an aside, the contribution of full time coders to “open source” projects is not a recent thing. Heck, I remember the xemacs drama (early 90s) and a lot of that development was company supported. There was stuff prior to that but it was before my time…although you could make the case that unix as a whole adhered to the open source ideal for a long period and many of those folks came from the corporate world. I read a copy of Lions’ way back in the 80s.

  13. vinea Says:

    I read his piece and it seems fairly even handed and it seems that ESR agrees with his assessment that the bazaar is not a good place for innovation but that a strong individual (with code written) is a key element to successful application of a bazaar which, given that there’s semi-working code, happens AFTER innovation.

    This is easily seen by looking at abandoned innovative open source projects that never had working code to coalesce around…meaning that the founder was insufficiently capable in being a “wizard”. Neat ideas, are in the end, easy. Building enough code so other folks can see the vision on the horizon…harder.

    His second weakness is certainly a valid one. Looking at many small open source project without sufficient eyeballs you can see where the bazaar breaks down. Hence the need for donation or subsidization of eyeballs. Some open source projects get this in the form of QA departments from the corporation that donates code to the project. Others just live without. They can live without as long as they have a few key coders (even if its just one) churning out semi-working code.

    Being on two of these projects I know that weakness fairly well and it is the bane of many otherwise wonderful projects to have piss poor documentation and haphazard user interfaces because the core coders don’t care and there are no other eyeballs.

    I recall very few bazaar projects (I recall none actually) without those core coders slinging code in a cathedral…aka the commiters. You may be able to fork your own kernel but getting in a kernel change into the Linux kernel without the approval of the committers is not happening. It is “democratic” only in the sense that Linus and the kernel committers get to vote. Just sitting on LKML or being a “citizen” of Linux doesn’t get you a vote. That’s hardly a democracy.

    A democratically run linux kernel would be a disaster.

    Vinea

    PS As an aside, the contribution of full time coders to “open source” projects is not a recent thing. Heck, I remember the xemacs drama (early 90s) and a lot of that development was company supported. There was stuff prior to that but it was before my time…although you could make the case that unix as a whole adhered to the open source ideal for a long period and many of those folks came from the corporate world. I read a copy of Lions’ way back in the 80s.

  14. krishnan Says:

    Vinea,

    Actually, I was planning to elaborate on the question you have raised here. But I didn’t do it because Mr. Carr (and ESR if he had actually meant it) are overlooking an obvious aspect. Almost all of the ideas start with a person and then permeates into a group project. Take any idea. The initial seeds will start with one person and then goes to the second person and so on. Even in scientific projects, the initial seed for the project starts with a person and then permeates into the research group/collaborators. Under such a scenario, using this to argue against the bazaar style is just meaningless. Show me one idea, whose initial seed appeared simultaneously in the minds of many people and which was then completed by that group. If anyone says that ideas start with a single person (implying a cathedral model) and then goes onto bazaar style, it just means that the person couldn’t even comprehend the process of “idea formation”. Whether it is science (the best example and predecessor to the open source approach), any open source projects, or, for that matter, any project, it starts with the initial seed for the idea coming from one person and then becomes a group project. As far as I am concerned, this point is totally redundant.

    This is easily seen by looking at abandoned innovative open source projects that never had working code to coalesce around…meaning that the founder was insufficiently capable in being a “wizard”. Neat ideas, are in the end, easy. Building enough code so other folks can see the vision on the horizon…harder.

    It is true of any process. Blaming it on the open source approach doesn’t make any sense.

    It is “democratic” only in the sense that Linus and the kernel committers get to vote.

    You are doing the same mistake as Mr. Carr. If you cannot get the kernel commiters to support your code, you can still fork the kernel and “publish” your own kernel for the world citizens to use. This is the democracy behind open source and not the kind of democracy you are implying. You don’t have this democracy in the cathedral model. When open source advocates talk about democracy, they talk about your choice to have the kernel in any form you want and do anything you want with the kernel, provided you adhere to GPL 2. By democracy, they are not implying that you can put anything and everything into the kernel Linus is maintaining. The democracy implied by open source advocates is much more broader in definition than the ones implied by you, Mr. Carr and many detractors of open source movement. Please try to understand the real meaning of the term “democracy” in the open source context.

  15. krishnan Says:

    Vinea,

    Actually, I was planning to elaborate on the question you have raised here. But I didn’t do it because Mr. Carr (and ESR if he had actually meant it) are overlooking an obvious aspect. Almost all of the ideas start with a person and then permeates into a group project. Take any idea. The initial seeds will start with one person and then goes to the second person and so on. Even in scientific projects, the initial seed for the project starts with a person and then permeates into the research group/collaborators. Under such a scenario, using this to argue against the bazaar style is just meaningless. Show me one idea, whose initial seed appeared simultaneously in the minds of many people and which was then completed by that group. If anyone says that ideas start with a single person (implying a cathedral model) and then goes onto bazaar style, it just means that the person couldn’t even comprehend the process of “idea formation”. Whether it is science (the best example and predecessor to the open source approach), any open source projects, or, for that matter, any project, it starts with the initial seed for the idea coming from one person and then becomes a group project. As far as I am concerned, this point is totally redundant.

    This is easily seen by looking at abandoned innovative open source projects that never had working code to coalesce around…meaning that the founder was insufficiently capable in being a “wizard”. Neat ideas, are in the end, easy. Building enough code so other folks can see the vision on the horizon…harder.

    It is true of any process. Blaming it on the open source approach doesn’t make any sense.

    It is “democratic” only in the sense that Linus and the kernel committers get to vote.

    You are doing the same mistake as Mr. Carr. If you cannot get the kernel commiters to support your code, you can still fork the kernel and “publish” your own kernel for the world citizens to use. This is the democracy behind open source and not the kind of democracy you are implying. You don’t have this democracy in the cathedral model. When open source advocates talk about democracy, they talk about your choice to have the kernel in any form you want and do anything you want with the kernel, provided you adhere to GPL 2. By democracy, they are not implying that you can put anything and everything into the kernel Linus is maintaining. The democracy implied by open source advocates is much more broader in definition than the ones implied by you, Mr. Carr and many detractors of open source movement. Please try to understand the real meaning of the term “democracy” in the open source context.

  16. vinea Says:

    “If you cannot get the kernel commiters to support your code, you can still fork the kernel and “publish” your own kernel for the world citizens to use. This is the democracy behind open source and not the kind of democracy you are implying. You don’t have this democracy in the cathedral model.” When describing the cathedral vs bazaar development models ESR was comparing the FSF development model (cathedral) vs Linus’ (Bazaar). Thus you CAN have this kind freedom because both examples come from the open source world. I’m not certain how you construe the word “democracy” to mean the freedom to fork. That you have some strange definition of “democracy” doesn’t mean that Mr. Carr, ESR or I have an incorrect one. I get the impression that you seem to think that Cathedral must mean proprietary and Bazaar must mean open source. Also this is not an issue of “blame” with respect to weaknesses with the Bazaar model but an understanding that no one development methodology fits all. There are strengths and weaknesses to for open source software, free software, proprietary software, Cathedral, Bazaar, CMM, etc. Simply noting the weaknesses does not automatically equate to a “detractor of the open source movement” or a “detractor of CMM” or a “detractor of proprietary software”. Or is your implication that there are no weaknesses in the bazaar model? Because all you need to do is look at the smaller open source projects. The lack of eyeballs means that some underlying assumptions in the Bazaar model aren’t true (ie bugs aren’t shallow, etc) and some of the strengths simply aren’t there. In ESR’s Popmail/Fetchmail example he built a community around it with 200-300 folks. He achieved the critical mass of eyeballs and contributors. When you’re in a community of 5-20 folks, even with a Bazaar style method, in effect you’re still in Cathedral mode. Sure your repository is available to all but you’re still talking about a handful of eyeballs a handful of brains and a handful of perspectives. You can do Cathedral development (open or close source) with a small core team of devs (even just one dev). So at the beginning of every Bazaar development project is a Cathedral development process while the core software is being built into a state that other folks can take an interest in. Whether an open source project transitions to a Bazaar projects depends on two things: first is a desire to use the Bazaar style of development (which some teams don’t want to do) and second is the ability to form the community required to have a successful bazaar style project (which some teams don’t have that kind of leadership or vision). So not all open source projects will want or be able to do Bazaar style development. The corrollary is that not all closed source projects are Cathedral. Many of the best close source environments/projects are/were done in a Bazaar style because that’s one of the best methods of creating a functional large software team. The caveat in a closed source environment is that the pool of eyeballs is limited… Vinea

  17. vinea Says:

    “If you cannot get the kernel commiters to support your code, you can still fork the kernel and “publish” your own kernel for the world citizens to use. This is the democracy behind open source and not the kind of democracy you are implying. You don’t have this democracy in the cathedral model.”

    When describing the cathedral vs bazaar development models ESR was comparing the FSF development model (cathedral) vs Linus’ (Bazaar). Thus you CAN have this kind freedom because both examples come from the open source world. I’m not certain how you construe the word “democracy” to mean the freedom to fork. That you have some strange definition of “democracy” doesn’t mean that Mr. Carr, ESR or I have an incorrect one.

    I get the impression that you seem to think that Cathedral must mean proprietary and Bazaar must mean open source.

    Also this is not an issue of “blame” with respect to weaknesses with the Bazaar model but an understanding that no one development methodology fits all. There are strengths and weaknesses to for open source software, free software, proprietary software, Cathedral, Bazaar, CMM, etc. Simply noting the weaknesses does not automatically equate to a “detractor of the open source movement” or a “detractor of CMM” or a “detractor of proprietary software”.

    Or is your implication that there are no weaknesses in the bazaar model? Because all you need to do is look at the smaller open source projects. The lack of eyeballs means that some underlying assumptions in the Bazaar model aren’t true (ie bugs aren’t shallow, etc) and some of the strengths simply aren’t there.

    In ESR’s Popmail/Fetchmail example he built a community around it with 200-300 folks. He achieved the critical mass of eyeballs and contributors. When you’re in a community of 5-20 folks, even with a Bazaar style method, in effect you’re still in Cathedral mode. Sure your repository is available to all but you’re still talking about a handful of eyeballs a handful of brains and a handful of perspectives.

    You can do Cathedral development (open or close source) with a small core team of devs (even just one dev). So at the beginning of every Bazaar development project is a Cathedral development process while the core software is being built into a state that other folks can take an interest in. Whether an open source project transitions to a Bazaar projects depends on two things: first is a desire to use the Bazaar style of development (which some teams don’t want to do) and second is the ability to form the community required to have a successful bazaar style project (which some teams don’t have that kind of leadership or vision).

    So not all open source projects will want or be able to do Bazaar style development. The corrollary is that not all closed source projects are Cathedral. Many of the best close source environments/projects are/were done in a Bazaar style because that’s one of the best methods of creating a functional large software team. The caveat in a closed source environment is that the pool of eyeballs is limited…

    Vinea

  18. krishnan Says:

    Vinea, This is not an article justifying ESR and what he has told in his paper. This is about the true nature of open source. ESR had quoted FSF as a Cathedral Model because of his problems with Mr. Stallman’s approach. ESR’s personal opinions doesn’t describe the true nature of open source. If you are going base your definition of democracy with whatever ESR has in mind, I have nothing to discuss and I would just stick to my point that you haven’t understood the real meaning of democracy in the open source world. I suggest you talk to others in the open source world about it.

    I get the impression that you seem to think that Cathedral must mean proprietary and Bazaar must mean open source.

    No. But I put the altruistic definition of open source firmly into the bazaar model. There might be individuals who might impose the cathedral structure into their open source projects. But such acts doesn’t put open source approach in the cathedral model. I am taking a holistic view on the definition of open source than considering individual projects (the mistake Mr. Carr and yourself seems to be doing).

    Or is your implication that there are no weaknesses in the bazaar model? Because all you need to do is look at the smaller open source projects. The lack of eyeballs means that some underlying assumptions in the Bazaar model aren’t true (ie bugs aren’t shallow, etc) and some of the strengths simply aren’t there.

    I have already answered this in the previous paragraph. I am not responsible for your own assumptions. Actually, your whole argument is done by talking about individual projects whereas my argument is about the true nature of the open source process (not individual projects). Hope you get what I am trying to say here. This is exactly the mistake Mr. Carr did in his analysis.

  19. krishnan Says:

    Vinea,

    This is not an article justifying ESR and what he has told in his paper. This is about the true nature of open source. ESR had quoted FSF as a Cathedral Model because of his problems with Mr. Stallman’s approach. ESR’s personal opinions doesn’t describe the true nature of open source. If you are going base your definition of democracy with whatever ESR has in mind, I have nothing to discuss and I would just stick to my point that you haven’t understood the real meaning of democracy in the open source world. I suggest you talk to others in the open source world about it.

    I get the impression that you seem to think that Cathedral must mean proprietary and Bazaar must mean open source.

    No. But I put the altruistic definition of open source firmly into the bazaar model. There might be individuals who might impose the cathedral structure into their open source projects. But such acts doesn’t put open source approach in the cathedral model. I am taking a holistic view on the definition of open source than considering individual projects (the mistake Mr. Carr and yourself seems to be doing).

    Or is your implication that there are no weaknesses in the bazaar model? Because all you need to do is look at the smaller open source projects. The lack of eyeballs means that some underlying assumptions in the Bazaar model aren’t true (ie bugs aren’t shallow, etc) and some of the strengths simply aren’t there.

    I have already answered this in the previous paragraph. I am not responsible for your own assumptions.

    Actually, your whole argument is done by talking about individual projects whereas my argument is about the true nature of the open source process (not individual projects). Hope you get what I am trying to say here. This is exactly the mistake Mr. Carr did in his analysis.

  20. Alon Harpaz Says:

    A significant distinction between the Linux kernel and Wikipedia: Mr. Carr entirely missed this distinction which makes his comparison invalid to the point of irrelevance: Wikipedia is a collection of articles. Some of them may be accurate and profound, others may be wrong or misleading, but as a whole there is no connection between individual entries (other than convenient linking, of course). there is no inherent requirement that one entry be correct or consistent for other entries to be meaningful. In contrast, the Kernel is an intricate machine where all parts have to collaborate appropriately or disaster may strike. At the least individual components have to avoid breaking each others; at its best individual components enhance and improve the function of other components such that the Kernel is faster, more efficient in its use of memory, etc. Thus the quality of the Kernel can be judged by scientific means that do not actually require us to observe and analyze individual components. in this sense the kernel is subject to the Scientific Method of objective evaluation. Every contributor of every patch can build the kernel in their own controlled environment and figure out exactly what works and what does not. furthermore, anyone can repeat everyone else’s experiment so that there is very little room for outright obfuscation or deceit. As a result, the quality of any version of the kernel that if offered to the world tends to rise to the level of the smartest participant; all of this is possible only because of the ruthless meritocracy (I do not recall the originator of this expression) which is in control here. Thus the combination of openness and unavoidable meritocracy works to give the best result, much better than formal hierarchies or closed code.

  21. Alon Harpaz Says:

    A significant distinction between the Linux kernel and Wikipedia:

    Mr. Carr entirely missed this distinction which makes his comparison invalid to the point of irrelevance: Wikipedia is a collection of articles. Some of them may be accurate and profound, others may be wrong or misleading, but as a whole there is no connection between individual entries (other than convenient linking, of course). there is no inherent requirement that one entry be correct or consistent for other entries to be meaningful.

    In contrast, the Kernel is an intricate machine where all parts have to collaborate appropriately or disaster may strike. At the least individual components have to avoid breaking each others; at its best individual components enhance and improve the function of other components such that the Kernel is faster, more efficient in its use of memory, etc.

    Thus the quality of the Kernel can be judged by scientific means that do not actually require us to observe and analyze individual components. in this sense the kernel is subject to the Scientific Method of objective evaluation. Every contributor of every patch can build the kernel in their own controlled environment and figure out exactly what works and what does not. furthermore, anyone can repeat everyone else’s experiment so that there is very little room for outright obfuscation or deceit.

    As a result, the quality of any version of the kernel that if offered to the world tends to rise to the level of the smartest participant; all of this is possible only because of the ruthless meritocracy (I do not recall the originator of this expression) which is in control here.

    Thus the combination of openness and unavoidable meritocracy works to give the best result, much better than formal hierarchies or closed code.

  22. vinea Says:

    If you are unwilling to discuss Cathedral and Bazaar based on the accepted definitions of the terms (ie as software development methods) then its really hard for you to castigate Mr. Carr for missing the point because you choose to redefine the meaning (Rushkoff not withstanding) either willfully or because you misunderstand the discussion. [b]He isn’t talking about the “altruism of open source” but the mechanism with which it creates value.[/b] With respect to ESR…given that its his analysis and his metaphor I would say that by definition his assignment of the terms are correct. Given that I’ve been an open source developer since the mid 90s I would agree with his “professional” assessement of the development methodologies of FSF software vs Linux. Which is what it is…not “personal opinion”. That you wish to move what was and is a technical discussion on software development and peer production to a purely political/philosophical discussion is your perogative given its your blog. But it certainly does not show that Mr. Carr is incorrect in his analysis or that even that he would disagree with your position since its on an orthogonal issue. He didn’t “get it wrong” as much as you “read it wrong”. He isn’t attacking open source but outlining the stengths and weaknesses of a particular management or productivity style (peer production) associated with open source but which is only one among many in the open source toolbox. You confuse a single technique with the open source concept itself. Like you confuse democracy with freedom. You can point out weaknesses in democratic forms of governance/management without attacking freedom as a concept. The “open source approach” from a philosophical perspective is also not monolithic as you proclaim. While FSF advocates are more uniform the wider open source world is far more diverse ranging from pragmatic, technically oriented, open source folks to more the idealistic. Thus a single “true nature” of open source is illusory. There are many folks that really are only “scratching an itch” and while its nice that their work helps others the altruism (outside their core and typically small developer community) is a minor benefit. Far far lower in importance than technical elegance. This is a vast contrast to FSF proponents bent on social change through software firepower. The use of individual projects as examples provides data points that refute your thesis. You can ignore the data points or you can change your theory. Vinea

  23. krishnan Says:

    Vinea,

    I hope you understand that the freedom in the open source process is the one that ensures the democracy in the process (a perfect example is the Mambo-Joomla saga where freedom offered the developers to carry on with their democratic ideals). Anyhow, I am not here for a street fight. If you want to define democracy in a very narrow sense, you are free to do so. If you close your eyes and think that the whole world is dark, it is not open source’s problem. Equating maintainers with managers is the biggest mistake the critics are making.

  24. vinea Says:

    If you are unwilling to discuss Cathedral and Bazaar based on the accepted definitions of the terms (ie as software development methods) then its really hard for you to castigate Mr. Carr for missing the point because you choose to redefine the meaning (Rushkoff not withstanding) either willfully or because you misunderstand the discussion.

    [b]He isn’t talking about the “altruism of open source” but the mechanism with which it creates value.[/b]

    With respect to ESR…given that its his analysis and his metaphor I would say that by definition his assignment of the terms are correct. Given that I’ve been an open source developer since the mid 90s I would agree with his “professional” assessement of the development methodologies of FSF software vs Linux. Which is what it is…not “personal opinion”. That you wish to move what was and is a technical discussion on software development and peer production to a purely political/philosophical discussion is your perogative given its your blog. But it certainly does not show that Mr. Carr is incorrect in his analysis or that even that he would disagree with your position since its on an orthogonal issue.

    He didn’t “get it wrong” as much as you “read it wrong”. He isn’t attacking open source but outlining the stengths and weaknesses of a particular management or productivity style (peer production) associated with open source but which is only one among many in the open source toolbox. You confuse a single technique with the open source concept itself. Like you confuse democracy with freedom. You can point out weaknesses in democratic forms of governance/management without attacking freedom as a concept.

    The “open source approach” from a philosophical perspective is also not monolithic as you proclaim. While FSF advocates are more uniform the wider open source world is far more diverse ranging from pragmatic, technically oriented, open source folks to more the idealistic.

    Thus a single “true nature” of open source is illusory. There are many folks that really are only “scratching an itch” and while its nice that their work helps others the altruism (outside their core and typically small developer community) is a minor benefit. Far far lower in importance than technical elegance. This is a vast contrast to FSF proponents bent on social change through software firepower.

    The use of individual projects as examples provides data points that refute your thesis. You can ignore the data points or you can change your theory.

    Vinea

  25. krishnan Says:

    Vinea,

    I hope you understand that the freedom in the open source process is the one that ensures the democracy in the process (a perfect example is the Mambo-Joomla saga where freedom offered the developers to carry on with their democratic ideals). Anyhow, I am not here for a street fight. If you want to define democracy in a very narrow sense, you are free to do so. If you close your eyes and think that the whole world is dark, it is not open source’s problem. Equating maintainers with managers is the biggest mistake the critics are making.

  26. Krishwords » Order out of Chaos: Open Source isn't dying Says:

    [...] source community about GPLv3, difficulty in implementing open standards in the govt., etc. As I told in the case of Nicholas Carr’s article, this article is also the result of a misunderstanding [...]

  27. Krishwords » Huffington Post removes my valid comments Says:

    [...] post on Huffington Post. In his article, he has quoted the recent article by Nicholas Carr, which I rebutted in this blog. But they have removed my comments there without offering any reason. This is shameful and I [...]

  28. Krishwords » Huffington Post removes my valid comments Says:

    [...] Nicholas Carr’s article on open source. I have already rebutted Carr’s argument in my blog. So I posted the following comments. Nicholas Carr’s argument is weak. I have already [...]

  29. Helen Masters Says:

    The whole Wikipedia concept is fatally flawed. The notion that one can produce an authoritative encyclopedia without any kind of editorial control is patently ridiculous. There is a far greater and more insidious threat to Wikipedia than simple character assassination or falsehood. It can broadly be labelled “infomercial content” (i.e. content that purports to be informative but has a commercial bias). A good example is the entry on Barcelona (Spain). The whole article reads like a tourist brochure and any reference to the city’s pollution problems is swiftly removed by an army of self-appointed censors. There are strong indications that the Barcelona Tourist Board (or its army of acolytes) has effectively hijacked the site. This kind of thing is going to become more prevalent as Wikipedia becomes better known. Basically, there is nothing that can be done to stop this corporate take-over of Wikipedia without editorial control yet such control runs counter to the whole Wiki ethos. The idea that “a community of users” is going to apply some common sense criteria regarding content is a mistaken one. In the case of the Barcelona entry, the influence of Catalan/Spanish speakers on both content and style is all too evident. The locals seem eager to “sell” their city to the wider world and to show off their appalling English. Wikipedia not only lacks the control mechanisms to stop them, it also wilfully fails to recognize it has a serious problem.

  30. Helen Masters Says:

    The whole Wikipedia concept is fatally flawed. The notion that one can produce an authoritative encyclopedia without any kind of editorial control is patently ridiculous.

    There is a far greater and more insidious threat to Wikipedia than simple character assassination or falsehood. It can broadly be labelled “infomercial content” (i.e. content that purports to be informative but has a commercial bias). A good example is the entry on Barcelona (Spain). The whole article reads like a tourist brochure and any reference to the city’s pollution problems is swiftly removed by an army of self-appointed censors. There are strong indications that the Barcelona Tourist Board (or its army of acolytes) has effectively hijacked the site. This kind of thing is going to become more prevalent as Wikipedia becomes better known. Basically, there is nothing that can be done to stop this corporate take-over of Wikipedia without editorial control yet such control runs counter to the whole Wiki ethos.

    The idea that “a community of users” is going to apply some common sense criteria regarding content is a mistaken one. In the case of the Barcelona entry, the influence of Catalan/Spanish speakers on both content and style is all too evident. The locals seem eager to “sell” their city to the wider world and to show off their appalling English. Wikipedia not only lacks the control mechanisms to stop them, it also wilfully fails to recognize it has a serious problem.

  31. Krishwords » Tech Media doesn't get Open Source Says:

    [...] economic models. This has resulted in way too many misinterpretations about open source. We saw how Nicholas Carr had completely misunderstood the functioning of open source. We also saw how Dan Farber and others [...]

Leave a Reply

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in