It's the other way around:
|
| Author | Content |
|---|---|
| claus Mar 18, 2006 3:04 AM EDT |
The Economist still has all its marbles. Unfortunately, the author of this opinion piece failed to earn some. The original article is not about open source software, it's about the open way of collaboration, the potential benefits of using it outside the realms of software, and the dangers of doing so. And it's using existing examples to discuss these issues. The article of the Economist is balanced, and well written. It enables the reader to make a better decision whether this 'new' way is worth to be researched further for the reader's own purposes -- whatever that may be. The opinion piece presented here fails completely because it fails to understand the original article. This, in fact, is a proof for lots of the issues pointed out by the Economist, and it sheds doubt on the editorial control of LXer. The presented opinion has additional flaws that are harder to detect. Basic logic, for example, tells us that the mere existence of thousands of dead projects doesn't proof that only the high-quality ones survived. You'd need an independent measure of quality to proof it. Without such a measure, the argument is tautological: "Just high-quality projects survive!" Why? "Because the low-quality ones died!" Why? "Because the high-quality ones survived, obviously!" In fact, it's rational to assume that at least one high-quality project died just because nobody ever heard about it. Or is there anybody researching the "quality" of every new project on Sourceforge, ringing a bell when he found one? Probably not. This is also why the reference to "The Cathedral and the Bazaar" fails: It was written several years ago, when there were just a few projects for every area. How do you determine quality when you cannot even know about all potential alternatives? How do you determine quality when all alternatives use a different programming language, and a different programming philosophy? And this does not even touch the question: What is quality? The perfection of the code or the ability of the project to satisfy a user's wants and needs? People who have trouble to understand this may like to proof the following argument wrong: "All high-quality projects die because all surviving projects are low-quality." This is meant to be an exercise. It's not my opinion. An analogy to a biological theory constitutes no proof. It might be worth to point out here that some researcher refuse to call evolution a theory because they say it's nearly impossible to proof wrong. The article of the Economist helps to improve the management of open source software. For example, open source is not just about quality, it's also about mass -- very much like the industrial revolution starting with Ford. The smaller the pieces you split a chain of actions into, the more people are able to help. This is what made Wikipedia big. In the beginning, everybody could write stuff, no matter whether it was good or bad, right or wrong. As long as people wrote. Open source projects flourish by the same principle in certain respects: Bug reports are rather easy to write, so projects get many bug reports and, initially, it doesn't matter whether they are right or wrong. Of course, we also need quality in certain respects, too: For Wikipedia, it gets time to improve quality control. Open source projects need maintainers otherwise it's just a mess of code that may work or not. The trick is to understand under which circumstances you need quality or quantity or a mixture of both. The trick is to determine under which circumstances open business makes sense. This is what the article of the Economists was about; not to disparage open source software. |
| crusadingknight Mar 18, 2006 6:16 AM EDT |
I have to take the opposition to each and every view on 'dead projects' expressed here. Hundreds of sourceforge projects aren't dead, just complete. Several projects I've run across, while they died about 3 years ago, at version 0.01, 'died' because they'd achieved what they'd set out to do. These are, in essence, the simple, one-goal projects. Also, this is the strength of open source - as long as the source exists somewhere, the project is never dead. Take didiwiki, for example, which, although it appears to be dead, I was still able to download, patch (with the Debian patches), fix a few holes in, and deploy. Or, perhaps, the editor levee, which has remained essentially unchanged since the 80's, not because it is dead, but because it's achieved its purpose. Quality isn't only created by the originator, but can be created by the deployer, the maintainer, the community, or even the distributor. Anyway, quality is measured by the end-user, not the 'indepedent' (in any sense) observer. The dead projects are dead because there was no quality perceived by their maintainers, originators, communities, and end-users, and thus were abandonned. Thus, any completely dead project must be entirely devoid of quality, or else it would still have some niche users. Also, I find it odd that they use the word 'rigid'. Compared to most companies, open source efforts may be well managed, but are hardly rigid. For example, see FreeBSD, Apache, Debian, Gentoo, etc - they management and positions are clear, but, compared to a commercial venture, are only about as rigid and heirarchical as a startup; compared to, for example, IBM, they have very flexible chains of management. |
| grouch Mar 18, 2006 9:03 AM EDT |
claus:
You're certainly entitled to your opinion. Asserting that The Economist article is "balanced and well written" does not make it so. I attempted to point out the errors in the article and cite references supporting my claims. If you can cite references to the contrary, I would be very happy to take the time to read them. If you are interested in a detailed analysis of the ways in which The Economist was wrong regarding SCO, and see additional evidence, by way of a snippet of a pre-article email interview, of the predetermined agenda of the author of The Economist article, see "The Economist Article: Looking at Open Source at a Tilt" by Pamela Jones at http://www.groklaw.net/article.php?story=20060317090404388 You said, 'Without such a measure, the argument is tautological: "Just high-quality projects survive!" Why? "Because the low-quality ones died!" Why? "Because the high-quality ones survived, obviously!"' Nowhere did I present such an argument. Perhaps you did not read: "Projects which do not begin with a working base, or which do not appear destined to accomplish something useful, or which fail for other reasons to attract developers, will be abandoned." Failure of a project to thrive could be due to something as simple as a poorly chosen name or a poor description of the project, which could cause it to be largely overlooked in searches. The quality of the code of the base, beginning project is not necessarily sufficient to ensure the project will thrive. Perhaps you also failed to read: "Natural selection will cause most to fail early. It is not a perfect selection process, but it does result in higher quality software." Notice there is no claim equivalent to your "just high-quality projects survive". I do not know of any "low-quality" projects with long survival times, but that, of course, would depend upon defining the difference between "high-quality" and "low-quality". There have been well-publicized studies comparing bug counts between open and closed source, in which open source was found better, by the way, but "quality" could be defined in other ways, such as fitness of purpose or ease of use. http://www.infoworld.com/article/03/07/01/HNreasoning_1.html http://www.zdnet.com.au/insight/soa/Study_Open_source_produc... http://scan.coverity.com/ The Economist article did not define its measure of quality when making the assertion that "it [open-source] lacks ways of ensuring quality". I presented a very easily observed way in which open source ensures quality: the world is free to examine it and vote by adopting or ignoring. You state: "The article of the Economist helps to improve the management of open source software." I fail to see how, since the author failed to observe how open source deals with quality, "intellectual property", accountability, failed to recognize the fact that open source may only be considered a "niche" if you stretch the common definition beyond recognition, failed to observe motivation for open source, and cast doubt on the ability of open source to scale ("open source might already have reached a self-limiting state") and therefore its long-term viability. |
| jkouyoumjian Mar 18, 2006 10:15 AM EDT |
Claus wrote: "This is what the article of the Economists was about; not to disparage open source software." Not so. The Economist was tossing bombs to sell copies of their rag sheet and LXer called them on it. Like everyone, The Economist has an agenda, even if they hide behind what they call "presenting both sides". They exist to sell subscriptions which gets them advertisers -- period. My agenda is getting work done. Open source software is great for that. Those of us who knowingly use open source software can see right through what the Economist wrote. The Economist relies on the ignorance of their audience to protect them when they make statements like they did. For example: the Internet is a killer application which is built on open source software -- everyone who uses it proves the worth of the open source development process -- even if they are ignorant of this fact themselves (i.e. they unknowingly use open source software like Apache, DNS, JBoss, MySQL, any of the many Linux based email servers, countless Linux-powered routers and network devices, etc. because these things power the net). The author of LXer's reply didn't even have to break a sweat to blow away The Economist's torrent of illogic. The fact that The Economist will make money off their yellow journalism is really sad. And please don't flame me -- my pointed, sarcastic tone is a rhetorical device intentionally employed to enhance my point! :) |
| claus Mar 18, 2006 3:04 PM EDT |
grouch, the problem is that you -- according to your article -- probably read the Economist article as an Open Source vs. Closed Source conflict story. And here you got it wrong. The original article is talking about "all sorts of endeavour that amalgamate the contributions of private individuals to create something that, in effect, becomes freely available to all." This is in the second paragraph. It's talking about the "Open Source Method" Note: Method! It uses several different examples: Open Source Software, Wikipedia, and also open sharing of "research to biotechnology". It talks to people considering to use the "Open Source Way" for their business. Note: Not about Open Source Software! this is just an example. In fact, this is a great victory for the basic ideas of Open Source. It thereby acknowledges the basic idea: that the art of sharing ideas could be useful for businesses. It also acknowledges that "open source" has become a "business hype" recently. And it also points out areas where the "Open Source Way" might fail -- which, in fact, is just responsible considering that every sort of "Hype" is to some degree misleading information. The "Open Source Way" has problems inherent in its way -- there's no doubt about it. This is also obvious for several leading persons, although I don't have the links ready: * When Eric Steven Raymond speaks about the problems of configuring CUPS, * when Jeff Waugh of Ubuntu and GNOME fame admits that GNOME 1.4 got it wrong when presenting the user the option to configure irrelevant stuff in milliseconds, * when a KDE developer admits that some KDE software has too many tabs. They all point out that Open Source Software has problems in getting stuff right sometimes. When you consider to use contributions of private individuals for your business, you should ask yourself "how innovative and sustainable" this can ultimately be. You should ask yourself whether this makes you "open to abuse, either by well-meaning dilettantes or intentional disrupters." And it's a indeed a problem that you may "fall by the wayside" if you "fail to cope with open source's vulnerabilities." And you should be concerned about "the question of accountability." And the article points out all the benefits of using the "Open Source Way" for your own business, although I won't to cite them all here. Read the article without your "Open Source vs. Closed Source" glasses on, and you will quickly spot all the advantages it cites. The article, published in a major business magazine, is a victory for the idea that knowledge should be shared. It's just careful to tell why and when it might be useful for a company. And No! It's not always useful. To cite the classics (Adam Smith): "It is not from the benevolence of the butcher, the brewer, or the baker that we expect our dinner, but from their regard to their own interest." I've noted the response of Pamela Jones of Groklaw fame after I wrote my above comment. The problem is: Even PJ didn't understand the Economist article. Read my reply labeled "Sorry, but PJ missed the point." This is soo disencouraging: Even young, intelligent guys and gals trained in logical thinking prefer to ignore the meaning of a simple text when it's published by a business magazine. I'm sorry I can't respond to all the other answers: It's late here. I'll try to do this tomorrow. |
| grouch Mar 18, 2006 3:28 PM EDT |
claus:
I eagerly await your future response and hope that it will cite references to refute the points I made regarding where The Economist was wrong. You say I got the intent of the article wrong. I say I got it right: that their intent was to forward an agenda. You point out that their article was about the open source "method". I agree with that, but how can they discuss the open source method when they base that discussion on as many errors and misrepresentations of open source as I pointed out? Please show me how The Economist article is "a great victory for the basic ideas of Open Source", when it is based upon such a demonstrably incorrect view of the open source development model. I have pointed out what I think are errors in the article. Show me specifically where I am wrong in my judgment, please. Please do not simply give me real examples of problems encountered with open source software projects. I did not and do not deny that problems exist. I argued, and provided references in support of my arguments, that The Economist article is wrong in its discussion of open source. Please show me where I am wrong. So far, I have seen no evidence that a retraction of a single claim I made is warranted. I enjoy a good debate, but that requires specifics and supporting evidence, otherwise it is simply chatter or banter. |
| tarvid Mar 18, 2006 9:49 PM EDT |
There is a tendency to criticize things for what they are (intrinsically). For example, people are criticizing Google mail because they scan your mail and archive it. That is a bit like criticizing ice cream because it is cold. Not to be left out, the Economist makes a good read but they are apologists for a system that Linux and Open Source thumbs their nose at. Reason and wit are wonderful tools but it is the resonance of intuition that moves things on. The heart is down and to the left. Jim Tarvid |
| claus Mar 19, 2006 2:47 AM EDT |
grouch, please bear with me that I have no time to comment every detail of your article. I'll try a last time -- sorry to those I cannot comment on. Thanks for reading. The article ask whether a business men or women should start an endeavour that uses the "Open Source Method": Make the access open and free (as in beer), and hope for volunteers that build something. For example, an on-line music store with the sources open so everybody can 'produce' its own songs and put them back on-line for free. Now, the Economist writes: "The open-source method has vulnerabilities that must be overcome if it is to live up to its promise." and mentione several of them. Let's see whether this is true for our on-line music store: * Yes, we will get quality problems. Most people are really bad musicians and offering lots of bad songs will just prevent the good ones from being heard. * Yes, we might get problems whether these songs are really innovative and not just copies of something. See above: Most people are bad musicians. * Yes, we will need to ask ourselves whether this is sustainable: People might find out producing music is boring, and move on. We invested millions in the on-line technique and it's lost. * Yes, some people might even come to abuse the service, either because they are just bad musicians, or because they are paid chills from the RIAA which is worried that free music is a competitor it cannot sue. * However, the RIAA may sue us because some idiots used copyrighted material in their songs, and we distributed it. You see: All points of the Economist are absolutely valid. They are even valid when you replace "music" and "musicians" with "software" and "developer". And the article mentions all protective means that Open Source Software, and Wikipedia use to prevent the dangers mentioned above: * In mentions editorial control used by Wikipedia. * It mentions maintainership used by the Linux kernel, and Apache. This is a victory: Business people look at Open Source to learn from their failures. And the movement made failures. The Economist article says: Don't expect that your product will become high-quality just because you make its blueprints open. And this is correct. You are looking at the Economist story from a completely wrong angle. This is apparent when you write: What "cracks in the management"? Gosh, there are so many cracks I have problems mentioning them: 1. Open Source Software usually has a maintainer. Sometimes, this is a complete idiot. My very first OSS project was maintained by an idiot, and the other developers forked. However, this was a real difficult birth. The bitching and biting between both projects still continues -- years after the fork! 2. When decisions are not about software but something different, the project is sometimes unable to make any decision at all. Just think of the design of a website. 3. When the decision is not about software, sometimes an incompetent fool (usually developers when the problem is not about software developement) make the decision. Again, think of website design. Nearly all Perl and Python projects prove that developers have no clue about web design. ;-) 4. Volunteers often tend to say: "I do that" but most of the times, they don't. You gotta run after every bloody volunteer. This sucks. 5. Mix two or more of the above. However, when even Pamela Jones is unable to understand a simple business article, you're in good company. I don't blame you. Making mistakes is human. But I really blame the editor of LXer: When they are unable to deal with a simple business article, why should I trust the other stuff they wrote? And lately, they tend to write a lot, commenting nearly every entry. The publishing of your article here -- which should have never happen -- is a sign of the decreasing quality of LXer. This is sad. |
| grouch Mar 19, 2006 2:59 AM EDT |
claus:
You still present anecdotes. You still present no refutation of the points I made.
Thank you. [edited to add:] I am confident the editors of LXer would welcome an article presenting a viewpoint counter to mine. Mr. Adelstein has written a guide for articles. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!