I did a survey of Scripting News readers and found that most of them want to work together, crossing the boundary between open source and commercial software. As I was trying to process the hype of open source, I incorrectly concluded that the philosophy of open source was against commercial software. This created a disconnect, people who do open source would say "We think your stuff is cool" but I couldn't reconcile that with the hype which seemed to say otherwise, quite strongly. I have finally reconciled it, the disconnect is between the leadership of open source, or the most vocal leadership, and the people who actually do the work, many of whom are moonlighting commercial developers, who like their jobs, and also like to do pro bono work. Duh. I wish I had figured that out earlier.

... ... ...

So, if open source projects behave like all other software projects, is there actually such a thing as open source? You may be surprised to hear that I believe there is. But it's not in agreement with what the open source leaders say it is. I'm going to give you Dave's definition of open source, and you can see if you agree.

What is open source? 

A program is said to be open source if the full source code for the program is available publicly, with no constraints on how it can be used.

That's it. We've looked at so many other possibilities, I've even discussed it publicly with Stallman, and he agrees that his philosophy is not open source, because there are constraints on what you can do with his code.

So, if this is what open source is, how long has it been going on? The answer -- a long time. Programmers are not the money-grubbers that some make us out to be. Most programmers want their creations to exist beyond their lives, both in space and time. We want to make things that people use, and we want respect, and mostly we want respect from our peers. Sometimes we release the source, and other times we don't. When we do, and when it's done unconditionally, that's open source.

Sometimes people distribute source to balance a similar kindness that they benefited from. In the mid-1970s I learned how to program reading the Unix source code from Bell Labs. To this day that experience influences the code that I write, and I've passed the lessons on to my team at UserLand and to people who learn to program using Frontier.

I learned to write software for the Apple II by reading Woz's code. Peter Norton taught me how to write IBM PC software, again by giving me code that works. Same on the Macintosh, and every other platform I've coded for, including the Web. The View Source command in the Web browser makes it virtually impossible to hide the secrets of the Web. You can always find out how something works. That's part of the magic of the Web.

Programming is a human endeavor, an artistic one, like writing or music. The art is in the process. What is this program? How do we decide which features to add? Who does it serve? Where should it run? Which bugs should we fix? Whether or not it makes money is often secondary to the purpose. The primary purpose is to make the world a little smarter, and to get the good feeling that comes from playing a part in that.

Free source code releases, or open source, is an essential part of being a programmer, and it dates back to the beginning of programming. It's not a new thing, and not complex. Basically the rule is, here's the source, have fun with it, if you want.

After the hype, the world is much as it was. Some have new fortunes, and new software is still being made, some of it commercial and some open source. That's as it is, and imho, as it should be.

[Sept 7, 2000] Scripting News

Linux Today: Guido van Rossum responds to Python Licensing Issues. "In any case we don't want to use *just* the GPL for Python, because there are many proprietary software developers in the Python community who don't want to work with the GPL. Python has always had a BSD'ish license which was perfect for them. I see no reason to suddenly confront everyone in the Python world with the GPL."

Thank you. Don't give in to Stallman. Open source should not have restrictions. Stallman's philosophy is not open source, it's not the spirit of sharing, it's not generous. It has other purposes, it's designed to create a wall between commercial development and free development. The world is not that simple. There are plenty of commercial developers who participate in open source. Python belongs in commercial products. How does that hurt Python? Why should Python adopt Stallman's goals? What has he done to build Python? (Maybe I'm missing something.) I have a different philosophy which is incompatible with GPL, I will support any open source developer who truly lets the source go. Also, I much prefer the term "commercial" to "proprietary", which is perjorative, imho. (It's possible to make commercial software which is quite open and has major non-proprietary elements.)

BTW, I spoke with Nicholas Petreley this afternoon. We're in agreement on a lot of things. The world is much bigger than it may seem. Just because people send hate mail that doesn't mean we have to hate each other. Ignore the barriers, in the end guys like Stallman can have their way, inside their walls, inside a very small world. If you can see a way to avoid the GPL, you can count on our support. Petreley told me the story of KDE and it made me sick. They were so generous. Keep it simple. Generosity is good. Period.
See also Linux Today - Richard Stallman Response to Dave Winer on Python Licensing

Open Source Projects Manage Themselves Dream On

Raymond lists the responsibilities of traditional software managers as: define goals and keep everybody pointed in the same direction, monitor the project and make sure details don't get skipped, motivate people to do boring but necessary work, organize the deployment of people for best productivity, and marshal resources needed to sustain the project over a long period of time. Raymond then states that none of these tasks are needed for open source projects. Unfortunately, the majority of The Cathedral and the Bazaar describes, in detail, how important these management functions are and how Raymond performed them.

Eric Raymond decided what piece of software he would use as a test for open source programming. He decided what features fetchmail would have and would not. He generalized and simplified its design, defining the software project. Mr. Raymond guided the project over a considerable period of time, remaining a constant as volunteers came and went. In other words, he marshaled resources. He surely was careful about source code control and build procedures (or his releases would have been poor quality) so he monitored the project. And, most significantly, Raymond heaped praise on volunteers who helped him, which motivated those people to help some more. (In his essay, Raymond devotes considerable space to describing how he and Torvalds motivate their helpers.) In short, fetchmail made full use of traditional and effective management operations, except Eric Raymond did all of them.

Another compelling (and often-quoted) section of The Cathedral and the Bazaar is the discussion about debugging. Raymond says: "Given enough eyeballs, all bugs are shallow" and "Debugging is parallelizable." These assertions simply are not true and are distortions of how the development of fetchmail proceeded. It is true that many people, in parallel, looked for bugs and proposed fixes. But only one person (Raymond) actually made fixes, by incorporating the proposed changes into the official code base. Debugging (the process of fixing the program) was performed by one person, from suggestions made by many people. If Raymond had blindly applied all proposed code changes, without reading them and thinking about them, the result would have been chaos. A rare bug can be fixed completely in isolation, with no effect on the rest of the program.

.... .... ....

The first method (traditional) shows a Vice President of Development at the top, with several Directors of Engineering reporting to the VP. Below the Directors are Engineering Managers, and finally the engineers who write the code. Many organizations use this model, and everyone agrees it is sometimes grossly inefficient. The second method (cathedral or open source) uses a single designer/architect at the top, with many engineers reporting directly to the architect. The third method (bazaar) is a peer-to-peer network of many engineers, all reporting to and coordinating with each other, without central control. In The Cathedral and the Bazaar, Raymond claims open source projects are run in the third style. In fact, they are run in the style shown by the second diagram.

For more information about the parallel between software construction and cathedral building, see the classic work of software engineering The Mythical Man-Month by Fred Brooks. In this book , now 25 years old, Brooks describes the chief-programmer (or surgeon) method of software development. It is remarkably similar, in its basic philosophy, to the open source method that Raymond and Torvalds used. Interestingly, the book even contains a picture of a cathedral and relates it to this style of development.

... ... ...

To be fair, Raymond does address the issue of project leader control in his essay. He quickly dismisses the great importance of this control however, by claiming he and Torvalds did not have a crucial role in the design or creation of their software projects. He states he and Torvalds did not design anything new, but merely recognized good ideas from others. Raymond is not seeing clearly his and Torvalds's contributions. It is very hard to shift through thousands of suggestions from swarms of users, find the good ones, synthesize them together, and incorporate them into an existing code base. This constitutes strong management and central control.

The need for good management suggests the scalability of the open source method may be limited. How many people have the technical sophistication to make good software design decisions, the people skills to motivate hundreds of contributors, and the time to dedicate to a complex project? We should be wary about assuming that the open source method can solve the world's software problems. It is possible only a small number of humans, such as Raymond and Torvalds, have the requisite skill set to run an effective open source project. If this is the case, as I suspect it is, the number of true success stories in open source development will be small. The open source method will run into the same wall as traditional software development. Good technical managers are few and far between.

developerWorks Linux Features - Library - Papers An excerpt from Don Rosenberg's book, Open Source: The Unauthorized White Papers by Don Rosenberg [Aug 02, 2000]

Community Power
Although not well organized, the Open Source Community can bring its weight to bear upon problems it believes to be sufficiently threatening. In 1994 an opportunist filed for a trademark on the word "Linux," and after obtaining it a year later began to send letters to various Linux companies demanding 10 percent of their revenues for the use of the trademark. The trademark apparently held good, for after bringing suit, a coalition of Linux plaintiffs who had called for its cancellation acquired it in a private settlement on undisclosed terms; they subsequently put it in the hands of Linus Torvalds. The danger was averted, but the Community was upset by the close call.

They consequently descended with all the wrath of public opinion on a set of individuals who presumed in 1998 to set up a "Linux Standards Association" without any discussion of it within the Linux Community. The surprise was followed by rumors that the association was a cat's paw of large computer industry companies plotting to hijack Linux. The association proposed (like many standards bodies) that only fee-paying members could vote on the standards, and that the two companies who sponsored the association would be the final arbiters of those standards. The promoters withdrew from public view under withering scorn, and no small part of the outrage was the idea that the perpetrators might give a watching world a picture of a disorganized Community at a time when it was trying very hard for public acceptance. The Community-based Linux Standard Base (LSB) found itself strengthened by the episode as at least one independent-minded Linux company decided to give it more support as a means of filling what was obviously a dangerous vacuum.

Businesses venturing into Open Source waters can draw two lessons from these incidents: first, that it is important to deal carefully with the Community when doing something other than straightforward business under Open Source licenses (some companies appoint ambassadors to the Community, a variation on the Apple use of evangelists to drum up interest and support from developers); and second, that the Community can find resources to use to serve its ends. In the case of the Linux trademark, the Community summoned up the necessary effort, funding, and the pro bono services of attorneys. Sun software has begun experimenting with more open licensing in the face of scornful Community opinion, perhaps aided by pressure from IBM, which wants Java, to which IBM has contributed so much code, finally made an Open Source product. The osmotic and networked nature of the Community mean that efforts do not necessarily have to be planned or coordinated to be effective.

The Coming IP Struggle
The crusader aspects of Open Source, first seen by the public as David versus Microsoft, have not gone away; this time the Children of Light will be fighting the dark forces of IP lockdown. If modern digital technology has given users unlimited powers to filch copyrighted material (particularly popular music), the holders of copyrights are learning to use digital technology along with legislatures to enlarge their IP rights at the expense of users. Not directly connected, but sharing the same goals, the litigious proprietors of software patents are also spreading their domain.

Each side of the contest has its extreme positions. Although the GNU GPL and the Open Source movement rest on copyright as a means of ensuring the freedoms they seek, there are elements on this side of the struggle that believe that once information is digitized it is free for everyone. A Free Music movement, for instance, regards itself as justified on moral, if not legal grounds, to take and freely disseminate any copyrighted form of digitized music. The other side of the struggle has no such fundamental split; it sees digitized IP as uniquely able to be portioned out for payment, and intends to capitalize on this windfall. Extended IP rights will make fair use (loaning or giving your copy of a book to a friend, or selling it to a second-hand shop) disappear, along with making a tape of your copy of a CD to take on a picnic. Instead books and music will be tied to particular devices, and transfers among them will be difficult if licensed or impossible if not provided for.

The polarity between the two sides reflects the natural division between business and the Internet culture. Businesses continually seek to erect barriers to entry to protect themselves and their markets from competition; the best barrier is a government-granted and -enforced monopoly, which is what copyright and patent law confer. Open Source, on the other hand, is partly a product of university research laboratories that are publicly funded and that freely publish the results of research to open those results to question or improvement by others; consequently, Open Source supporters believe that only excellence in execution constitutes a real barrier to entry. They believe this not only as a principle, but as a practical truth: a project that fails to serve its constituency will either fail or be forked.

Free Riding on Gnutella   See also Slashdot The Tragedy of the Digital Commons

An extensive analysis of user traffic on Gnutella shows a significant amount of free riding in the system. By sampling messages on the Gnutella network over a 24-hour period, we established that 70% of Gnutella users share no files, and 90% of the users answer no queries. Furthermore, we found out that free riding is distributed evenly between domains, so that no one group contributes significantly more than others, and that peers that volunteer to share files are not necessarily those who have desirable ones. We argue that free riding leads to degradation of the system performance and adds vulnerability to the system. If this trend continues copyright issues might become moot compared to the possible collapse of such systems.

Some Slashdot comments

And this is some suprise? (Score:4, Informative) by Dman33 (dtisher@nospam.umich.edu) on Monday August 21, @02:20PM EDT (#15) (User #110217 Info)

C'mon people! Do you really think that this is any shock? I could have told you that people would rather receive than give. Especially when it is anonymous. I think a ratio type of thing would be a great idea, but how in the world can this be done? Obviously this is not too practicle in an anonymous situation; so is this the great paradox of anonymous vs quality? In other words, if it is purely anonymous as many would insist it to be, then it will lack quality and usability by nature. So in order to have good quality, you have to sacrifice security? Can anyone think of a better way?

> I think a ratio type of thing would be a great > idea, but how in the world can this be done? It has already been done. The Mojo Nation system was designed as a way for people to exchange services using a micropayment system. This system is different from other micropayment systems because the "coins" are backed in digital resources. It is like the old upload and download ratios of BBS days. You contribute services to the system by "selling" to others and when you need services you "buy" them from other agents. Toss in a distributed, de-centralized data sharing services and you have a pretty cool little item. The coins are like tokens at an arcade, except those who contribute more than they consume end up with a surplus they might be able to sell later; greed is a powerful motivation to get people to Cheating is controlled (or at least minimized) by using market-based mechanisms like reputations. By basing the service on something like a market it is possible for distrustful parties to conduct transactions and exchange services. Look around at any stable social structure and you will see a lot of the same techniques employed to fairly allocate resources and control parasites and cheaters.

Ratios never worked very well (Score:2, Informative) by nd (nd@kracked.com) on Monday August 21, @02:25PM EDT (#36) (User #20186 Info) http://demonic.net

What CmdrTaco said about file ratios is pretty accurate. I ran a BBS for several years and found this to be true. It was also true for Post/Call ratios when implemented on some boards (ie, not letting the user play LORD until he has reached a Post/call ratio of 1, or whatever). This basically created a message base full of crappy 1-line posts (also true on some web-based forums where users with X posts are rewarded with a special 'ranking').

NOT a tragedy, just another Keg party. (Score:5, Insightful) by tylerh (garbage1@home.com_nospam) on Monday August 21, @02:30PM EDT (#51) (User #137246 Info)

Programmers know this as the "90/10" rule: 90% of the useful work will be done by 10% of the code This applies to people as well. I helped organize keggers in college. A small number of us did the organizing/financing/clean up -- everyone else just showed up and partied. That was kind of the whole point. So this "ecology" result is NOT a tragedy of the commons, it' just a another keg party - and you know how hard those are to stop 8)

C'mon, file ratios weren't that bad (Score:2, Interesting) by MWoody (slashdot@mwoody.com) on Monday August 21, @02:30PM EDT (#53) (User #222806 Info) http://mwoody.com

Don't dismiss file ratios as a legitimate means of submission encouragement. Yes, the system can be abused, but after years of BBS hopping I've seen excellent methods to prevent it. My favorite method involved an account system, whereby uploads that other members voted as 'spam' or just worthless space were counted against that user. Upload enough crap and you're booted; add a two-day account activation delay and even the most 'disciplined' media hog is curtailed. Of course, a ratio of both file size and number of files is necessary, else you'll get people uploading one worthless 1GB file every few days, and then going to town before they're booted. Now, these systems worked fine with one server, but systems like Napster and Gnutella present a new paradigm. How to enforce ratios when there is really no such thing as an 'upload'? A few ideas, based more on the general concept of user-controlled servers than any specific service's setup: * For every file downloaded off a user's server, give that user a point. Servers can set a score limit on their machine for downloads (i.e. 'only people with a score of 100 can download from me'). Drop by a point or two for each download, but give 100 points or so when you sign up. * Same system as above, but base on file size instead of number of downloads. Or perhaps a combination of the two? * Keep track of everything on some centralized computer, and enforce the ratio much like it would be in days of lore. * Enforce a per-server ratio, the setup of which is determined by the owner. Not a great system on this scale, but worth a look. * Rather than 'earning' downloads, penalize users who download too much too fast with a negative score. Doesn't take into account whether or not they serve, though... And, of course, what will probably happen in the end anyways: * Keep the system as it is now. As the bandwith dissappears, all the hosers who don't know how to share will leave, and all the savvy slashdot readers and linux lovers will get their connection speeds back. Any other ideas for control systems, or arguments against them?

The dark side of anonimity (Score:5, Insightful) by Kiwi (kiwi-nody4la@koala.samiam.org) on Monday August 21, @02:38PM EDT (#75) (User #5214 Info) http://linux.samiam.org/linux_links.html

Anonimity definitely has a dark side. A few years ago, Time magazine did an excellent piece on the problems to today's society. One of the things they pointed out is that the privacy of a modern household has greatly increased the incidents of child abuse. In the society that we evolved in, one large factor that stopped people from abusing their child was the fact that there was no privacy--if you abuse your child, the whole village knew about it. The anonimity of the internet causes similar problems. Any system administrator knows that if they put any pornographic images on their web server, their machine or their machine's connection will quickly get overloaded. For example, one of my users put up pictures of attractive women. The women were not even naked, yet the server's connection was still overloaded. I have heard it said that the most common term asked for in the leading search engines is "pornography". People who would normally be too embarassed to go in to a liquor store or a peep show have no problem getting porno on the net. The internet makes people do what they would not normally do. While pornography is somewhat harmless, other activity on the internet isn't. The actions of the anonymous person who brought down Kiro5hin come to mind. As does the random bannings on many IRC channels (where the operators as often as not broke in to accounts or engaged in credit card fraud to get a system they could run a bot on to control the channel), the efforts people go to to cheat in online games, countless breakin attempts any experienced system administrator sees in their logs, the nonstop tide of spam, and so on. All of these are things that poeple do when they do not get a chance to look in the eyes of the person who they are harming with their selfish actions. It does not surprise me that the internet is full of people who take but do not give back. Human nature has always had the takers who complain when the stuff they are not taking is not good enough for their selfish purposes, and the givers who get little in return for their giving except complaints from the takers. The anonimity of the internet makes this problem worse.

File Ratios (Score:2, Funny) by Zulfiya on Monday August 21, @02:45PM EDT (#90) (User #44302 Info) http://www.eclipse.net/~srudy/

Reminds me of the BBS days of file ratios - 'course then we'd just take an image, resize and upload it, so that idea didn't exactly work as intended. Ahh, file ratios. An anecdote: I was too honest to rename files, but didn't have a worthy collection to upload to keep my ratios up. Finally, in what I thought was surely a nasty trick, I uploaded a collection of short stories I had written, one by one (all dreck - because everything written when you're fifteen is dreck). Imagine my surprise at returning to the board weeks later to find a story I had deleted from my archive for being exceptionally lame marked as a sysop-preferred download. The moral: One man's trash is another's treasure -or- Fifteen year old boys are as bad judges of writing as fifteen year old girls are writers -or- At least file ratios get things out there that might otherwise stayed buried (even if maybe they should have). -- I'm not evil, I'm ... differently motivated!

Money and trust (Score:5, Interesting) by raph (raph+slash@acm.org) on Monday August 21, @02:47PM EDT (#94) (User #3148 Info) http://www.levien.com/

There are two solutions, I think, to the tragedy of the commons. One is to pay people for their disk space and bandwidth. As several other comments have pointed out, this is exactly what Mojo Nation does, using "mojo" micropayment tokens as the currency. I've been playing with it, and though it's been a bumpy ride, it looks very promising. Check it out. There is another solution, I think, which is using trust to define a community. The set of "Gnutella users" is too large and diffuse to actually define a community. Why should I donate my bandwidth for other people who I don't know and don't really care about? If, on the other hand, I were sharing files with a much smaller group of people, many of whom I know personally, then it starts feeling more like a community. Of course I want my friends to be able to listen to the music I like. I propose that the trust system as deployed on Advogato might be a good way to define these communities. Of course, I might be totally wrong about this as well. Only one way to find out :) Incidentally, the way Mojo Nation is set up right now, it still has Tragedy of the Commons problems. Currently, you don't get mojo for uploading tasty content. In fact, you actually have to pay for the privilege. However, when you share a file, it's not a continual drain on your bandwidth (or diskspace, fwiw). The actual distribution is handled by "block servers", who do charge for their services. Of course, the Mojo economy is still in its formative stages. I hope, and expect, that actual markets will develop for providing and identifying tasty content. In any case, file sharing sure promises to be an interesting ride.

Marxist Leeching (Score:4, Insightful) by angst_ridden_hipster (angst_ridden_hipster@yahoo.com) on Monday August 21, @03:01PM EDT (#111) (User #23104 Info) http://www.andthehorseyourodeinon.com/

We used to paraphrase Marx's "From each according to his ability,   to each according to his need." into "From each according to their assets,   to each according to their greed." Of course, this was in our godless commie Warez swappin' Hotline-usin' phase... In the long run, it's OK. There are 90% leeches. But the 10% who make up the providers is not always the same 10% of the people. Today's leech is tomorrow's provider, and vice versa. Sometimes. It all tends to work out eventually.

so it dies out or gets stale (Score:2) by kootch on Monday August 21, @03:01PM EDT (#115) (User #81702 Info) http://www.jambase.org/~nugget/freebies.html

That just shows you that the entire thing is a fad, and when it dies out, the whole Napster lawsuit will just have been a small bump in everyone's collective memory. These things come and go... we've had BBS's, FTP sites, IRC, Hotline servers, and now Napster, Gnutella, Scour, et all. They come and go, as the fad takes em. And the whole reason why they go stale is that users take more than they give. DUH. So eventually the people with the fat pipelines that were giving so much get sick of giving and want stuff in return. And as soon as they go to the "membership" model or the "ratio" model, it quickly gets abused or the majority of people leave, giving you a select membership only service (which is what most hotline servers are now). Then again, you still have great places like #macfilez... but those places are becoming fewer and further between. Napster will die, same with Scour and Gnutella... lets just see how long they stay around. And again, everyone that's really into pirating will stay with their favorite IRC site, FTP site, or BBS. All of the other's that were recently introduced to the fine art of pirating will get sick of Napster and attempt to learn IRC but will find it too difficult to use so they'll give up and start going back to buying CDs and nothing will change. Visit Dave's Cheapies!

History repeats yet again.. (Score:2, Interesting) by Lumpy (spamsucks.timgray@lambdanet.com) on Monday August 21, @03:07PM EDT (#121) (User #12016 Info) http://www.lambdanet.com

I remember back in my college days. we had set up a "kiosk" of 3 pc's in the processing department that along with access to UUnet there was a huge (500 megabyte) file sharing database. users could walk in and use floppies to get what they needed and upload that which was useable by all. when we went online we loaded the thing up with gobs and gobs of shareware, tons of free documents and along with the UUnet connection lots of cool things.. We also kept close track of the users activities (No username attached it was all anon access) for the Phyc grad-students that were researching basic human though patterns when exposed to the digital information age. Well there was a ratio of 900 to 1. of every 900 items downloaded there was 1 item uploaded (and usually by one of us maintainers via modem) people are greedy, they take and take and take. and WILL NOT give. need proof of that statement? look at the fact that there are starving people in the USA. There is absolutely NO reason for anyone in the USA to go hungry, without shelter.. yet it happenes because of GREED. Every pattern we found on that Kiosk matched the Phyc patterns they had with people giving cheritably.. Face it, Homo-sapiens are self centered greedy weenies. And that is one of the first things that will be seen by any sentient visitor.

It may not even be intentional. (Score:2, Insightful) by shren on Monday August 21, @03:20PM EDT (#134) (User #134692 Info) http://www.io.com/~shren

Files that you download are not shared by default. Let me say that again : Files that you download, with Gnutella, are not shared by default. Which means that, regardless of what people might say, Gnutella is not, by default, from a practical standpoint, a peer-to-peer network. It's just like any other client-server network - the clients take and the servers give. It takes work to be a server, even if it's 20 seconds of work in copying files and clicking rescan, and most people are short-sighted nitwits who don't realize they need to do that and wouldn't care if they did. At the very least, files you download on Gnutella network should be shared by default. I think, if it's supposed to be a peer-to-peer network, then sharing should be the default behavior, and not sharing an option. If you download a file and the file you have is the same length as the source (it's finished) then the file should be shared. I'm feeling like enough of a jerk right now to say that it should be shared regardless of where it is put on the hard drive. Gnutella should keep track of the stuff it's downloaded (Stolen Album-Stolen Song 1.mp3, Stolen Album-Stolen Song 2.mp3) and search your hard drive for those files, and offer them to the net if they are found. What part of "peer-to-peer" do you not understand? I don't use Gnutella anymore. It's not what it was said to be. I think of a hundred thousand users who can't even be bothered to put thier incomings in thier outgoing directory, and decide not to bother with it.

MacOPINION Jeff Lewis The Cathedral and the Bizarre -- interesting critique that discuss some points from the point of view of Mac user and consultant that were discussed in my papers from the point of view academic researcher 

... Interestingly, the number one problems with Linux, from a consumer perspective, are that it doesn't have a standardised UI; its tools are simply too difficult to use and configure, and it requires far too much upfront learning to get up to speed. The last is the most telling: the Linux model moves the cost of learning from the developer to the user.

As for upfront developer time, well, that's true - it is harder to learn MacOS than it is to learn, say, the ANSI C libraries... but in truth, Raymond overstates the issue. In fact, MacOS can be divided in several large chunks. I regularly write 'console' apps in MacOS to do little tasks which don't warrant a lot of UI. I also have several shells for drag and drop functionality which handles all that sort of stuff. In fact, I tend to stick to the ANSI C libraries. There are some deficits in MacOS, relative to the 'standard' libraries - MacOS has overwhelmingly complex networking support compared to sockets and streams, but it also offers more complex functionality.

Ironically, it's the focus on UI, perhaps taken to obsession, which gives MacOS its edge over... well, it has to be said this way - over all other OSes. Windows comes close, but misses simply because Windows developers really do not have that obsession to make the UI perfect. Linux and the various X-Window interfaces rarely even come close. The obsession with sticking to a standard behavior means that MacOS users experience a consistency of behavior that no other OS can offer (although again, Windows is getting closer - Linux is not even close).

...Linux, on the other hand, pops up around 1995 after the GUI market had twelve years of development - and promptly reinvents the wheel and badly at that. (In defense of Linus Torvalds, he wasn't trying to build a consumer OS, he was trying to create a freely available Unix-like kernel in the spirit of Andrew Tannenbaum's Minix, which had been the hot mini-OS on Atari and Amiga computers...)

The core 'advantage' Raymond puts forward, many programmers improving the code, many eyes looking for bugs, is also its chief weakness. Programmers - at least the kind who are likely to get involved in OpenSource project - are a notoriously independent lot. They love to do their own thing and always think they have a better way to do things.

Normally, this is an advantage because, with filtering and discipline, this is from whence the fountain of creativity which drives this industry comes. Unchecked and unfiltered, though, and you have unbridled chaos. As a result, you have no less than six different desktop systems and two different configuration systems and tools whose command line options change not only from system flavour - but from revision to revision....

Raymond touts the stability of Linux as proof of the OpenSource concept, but that's a bit misleading. The core of Linux was written by one person - Linus Torvalds. Moreover, there is a small group who shepherds the contributions to the kernel to keep it stable and clean. In other words, there's a priesthood at the top of the bazaar. If you check into each successful OpenSource project, you see the same thing: a small group of referees who filter the input and weed out the bad ideas. The bazaar has cops. The chaos is contained.

When you get a company the size of Apple or Microsoft, you have thousands of developers who do peer review of code. You have the referees who determine what goes in to a product and what doesn't... but they have one thing that the OpenSource method doesn't: they have markets to answer to.

...See, when commercial developers create a product, they start by trying to solve a problem that customers need solved. The focus is always on the customer. What do they need? What do they want (which isn't always the same thing :)? Can they use this software? How much handholding will they need to make this work? Can we make this experience so great that the competition can't sway them back?

... ... ...

...once a group buys into a specific solution, the cost of changing grows with time. That's true even if the software is 'free' because the maintenance costs and time to convert to another solution are not. 

You want fries with that operating system?

The other core point Raymond tried to make is that software is a service industry. To be honest, this is a disturbing concept in several ways.

First, let me ask you a question: if you make your living by selling service on software, what's the motivation to make the software as easy to operate and maintain as possible? The answer? Well - not much. And so we have Linux. Very powerful. Very flexible. Very hard for average computer users to configure and maintain.

Now, that's not to say that commercial developers always have a motivation to make their software easier... I would argue that any software which needs a certification program is bad software. Any software which needs an entire section at Chapters (errr, Computer Literacy... Barnes and Nobel) devoted to rack after rack of MSCE books, cheat cards and training CDs (and it's not just Microsoft - Novell started this idea, but everyone is getting into it - Cisco just joined the gang) is badly written from a user's perspective.

Actually, let me go back to Cisco for a moment. Cisco used to have a great freeware configuration tool. You could download it from their website. That tool has quietly vanished and has been replaced with CiscoWorks and of course, Cisco certified training. A very ominous trend.

... ... ...

OpenSource fans tend to believe that they are quality fanatics, but what definition of quality are we using? To them, the most important kind of quality is stability - software shouldn't crash. The problem is that OpenSource software does crash. Does it crash less often than say, a Mac app? Well, probably, but most OpenSource projects tend to be much simpler and smaller than Mac apps and in general, tend to be very minimalistic. So they have the 'quality' of simplicity - for the programmer, but the lack of quality for the end user.

The argument is that since everyone who uses the software has the source, if you find a bug you can fix it then submit the bug fix to someone and it becomes part of the product - if you can figure out who to contact. But there again, we see a confusion as to whom the customer is: most people who use computers do not know how to program in BASIC, let alone C or C++, and more importantly - they do not want to. They buy a computer to solve a problem - to get work done - not to debug someone's code.

... ... ...

Raymond points out that Windows 2000, which reportedly shipped with 63,000 bugs, shows that OpenSource works because under Brook's "Law", the number of bugs is roughly proportional to the square of the number of programmers. Since Linux has 40,000 developers working on it - there should be 2 billion bugs in Linux. The flaw is that he perceives Linux as a collection of small projects, but sees Win2K as a single monolithic application - much as he seems to see MacOS. In reality, Win2K and MacOS aren't monolithic. They are composed of many smaller parts which are handled by smaller teams. Much like Linux.

As for comparing bug counts - at least Microsoft has a bug count. If Raymond had bothered to check the number, he'd have found that a rather large proportion of the 63,000 bugs are cosmetic - and none were considered 'showstoppers'. We don't even have a way to determine the real bug count for Linux since there's no central repository for this sort of information. 

... ... ...

Eric Raymond made one other comment: that the elitism of Mac programmers is a danger to its long term survival... and I ask him - where has be been? This same 'elitism' is what pulled us into a GUI based world of computing. It's what made computing accessible to the average person. This sounds like a weird echo of the 'Apple is doomed' argument we used to hear so often - but in case he's missed it - Apple is still here and doing better than ever.

... ...

        See also: Slashdot The Cathedral And The Bizarre discussion of macopinion.com article

LinuxPlanet - Reports - .comment Lawyers Guns and Money - KDE and Corel Working in the Real World Dennis E. Powell contains an very nice quote from old Peanuts cartoon and several very interesting observations about KDE development.

I'm reminded of a Peanuts cartoon from 35 years ago or so.

"I'm very idealistic," says Lucy. "I want to make the world a better place for me to live in." She was speaking, in delicious irony, to her little brother, if my recollection is accurate. Her little brother was named Linus.

A number of companies have become involved in development of particular open-source applications and packages. The involvement has included monetary support, payment of salaries to programmers already working on free Linux applications, development and contribution of new features or extensions (I'm talking about features and extensions that are then returned, open source, to the projects, not the always-helpful Microsoft seizing upon the Kerberos code, making it incompatible, and slamming a proprietary lid on it), or actually hiring programmers to work under the aegis of the company itself on particular packages, the code going to the open source organization that originated the packages. The dominant view is that this is generally a good thing.

And it can be. But it can also become a bad thing, and unless some lines are drawn, it's a sure bet that it will.

... ...

Even uglier, one could imagine--and this example is entirely hypothetical--a situation where the top people in a development effort accepted what lawyers call "valuable considerations" in exchange for looking the other way as a project got steered in a way that benefits a particular company. Nothing illegal about it.

Less sinister but troublesome nonetheless is the simple culture clash when open source meets commercial software. Corporations play it close to the vest, open source does anything but. The place where they meet can be awkward and frictional--it's hard to imagine them being otherwise. The potential for abuse is real as well. Indeed, Jon "Maddog" Hall of Linux International has done and is doing much to educate corporations about a crucial reality: they don't own the system and they cannot mandate changes in it. He has helped many companies understand the differences between closed, proprietary software and open source.

... ...

The leading voice of open source is Eric S. Raymond, again one of the few in the Linux community recognized just by his initials. ESR is watching more and more corporations become involved; his philosophy embraces the idea that closed development is old and creaky, while open source development is young and robust. A company will do it the new way or die:

"I'm not worried. What I see is corporations realizing that if they want our results, they have to buy into our process--and if they don't, they'll be eaten by a competitor who does."

... ... ...

I don't know of any lawyers who would be eager to try to defend the GPL if offense came to judge and jury. Commercial software companies have over the last decade tended to give the best parking spaces not to programmers but to lawyers. It would take some heavy-duty mobilization to take on a big software company and not die of attrition before a dispute ever came to trial. I think there will be offenses, as surely as there will be another VBX macro virus.

It's frightening, the idea that Linux and its applications could fall victim to its own success. But wherever there's money, big money as there is now in Linux, there is someone very clever who will try to take it away.

Corporations and open-source development are for the most part diametrically opposed as to organization and goals. Neither is bad; indeed, neither is better and both can be abused. But when the two come together, it's oil and vinegar--it needs a little shaking up before it can go onto the salad. And these are indeed the salad days of Linux.

It's not difficult at all, though, to imagine the companies that make commercial software for other platforms looking upon Linux as some kind of odd little brother. And, with a smile, saying, "I'm very idealistic. I want to make the world a better place for me to live in."

[June 04, 2000] Linux for the Masses and Other Popular Myths by by: Todd Burgess tburgess@krait.com
http://www.krait.com

As Linux popularity spreads so will the number of computers and users who use Linux. While Linux offers many advantages over many of the traditional operating systems, Linux is not suitable for all applications. Unfortunately many of the Linux advocates overlook this fact in their zeal to promote the Linux operating system.

The purpose of this article is to look at some of the fundamental arguments being put forth by many of the advocates. Specifically this article will seek to prove:

1. The Linux operating system on every computer system is a bad thing. More specifically, why the numbers game is a bad thing.
2. The attempt to make Linux more user friendly will hurt Linux not help it. Why hacking, the command line and vi are a good thing.
3. Linux for the sake of Linux is a bad thing. Just because you are running Linux does not mean you are smarter then any of the rest of us.

The Numbers Game

The numbers game is something that everybody plays. Web sites inflate their hits, software companies inflate the number of users using their software and operating systems advocates inflate the number of people who use their operating systems.

The reasons vary. Web sites will inflate hits to make themselves more attractive to advertisers, software companies inflate users to make themselves attractive to shareholders and operating systems advocates inflate operating system numbers to attract development efforts by outside companies. Which in turn, sells more operating systems.

While some may point out that Linux is essentially free, there are many commercial companies with commercial interests in Linux. Inflating the number of installed users will help the companies grow financially. No company will develop for an operating system that nobody uses so it is in the Linux community's best interest to raise the numbers.

Listen to any mainstream press promote Linux and you will always hear a wide range of numbers. Most of the numbers range from as low as five million and as high as ten million. For the purpose of this discussion assume there are ten million Linux users.

What does the number ten million mean? It means that ten million users have either:

1. installed and use Linux
2. installed Linux and never used it again
3. installed Linux and then uninstalled it
4. bought the Linux CD but never installed it

[May 28, 2000]  Here is a rather  authoritative opinion of John Viega, a Senior Research Associate in the Software Security Group at Reliable Software Technologies, an Adjunct Professor of Computer Science at the Virginia Polytechnic Institute, the author of Mailman, the open source GNU Mailing List Manager, and ITS4, a tool for finding security vulnerabilities in C and C++ code. He has authored over 30 technical publications in the areas of software security and testing, and is responsible for finding several well-publicized security vulnerabilities in major network and e-commerce products, including a recent break in Netscape's security. In his recent paper open source resources at open source it The Myth of Open Source Security he wrote:

...Even if you get the right kind of people doing the right kinds of things, you may have problems that you never hear about. Security problems are often incredibly subtle, and may span large parts of a source tree. It is not uncommon to have two or three features spread throughout a program, none of which constitutes a security problem alone, but which can be used together to perform a security breach. For example, two buffer overflows recently found in Kerberos version 5 could only be exploited when used in conjunction with each other.

As a result, doing security reviews of source code tends to be complex and boring, since you generally have to look at a lot of code, and understand it pretty well. Even many experts don't like to do these kinds of reviews.

And even the experts can miss things. Consider the case of the popular open source FTP server wu-ftpd. In the past two years, several very subtle buffer overflow problems have been found in the code. Almost all of these problems had been in the code for years, despite the fact that the program had been examined many times by both hackers and security auditors. If any of them had discovered the problems, they didn't announce it publicly. In fact, the wu-ftpd has been used as a case study for vulnerability detection techniques that never identified these problems as definite flaws. One tool was able to identify one of the problems as potentially exploitable, but researchers examined the code thoroughly for a couple of days, and came to the conclusion that there was no way that the problem identified by their tool could actually be exploited. Over a year later, they learned that they were wrong, when an expert audit finally did turn up the problem.

In code with any reasonable complexity, it can be very difficult to find bugs. The wu-ftpd is less than 8000 lines of code long, but it was easy for several bugs to remain hidden in that small space over long periods of time.

To compound the problem, even when people know about security holes, they may not get fixed, at least not right away. Even when identified, the security problems in Mailman took many months to fix, because security was not the the core development team's most immediate concern. In fact, the team believes one problem still persists in the code, but only in a configuration that we suspect doesn't get used.

An army in my belly

The single most pernicious problem in computer security today is the buffer overflow. While the availability of source code has clearly reduced the number of buffer overflow problems in open source programs, according to several sources, including CERT, buffer overflows still account for at least a quarter of all security advisories, year after year.

Open source proponents sometimes claim that the "many eyeballs" phenomenon prevents Trojan horses from being introduced in open source software. The speed with which the TCP wrappers Trojan was discovered in early 1999 is sometimes cited as supporting evidence. This too can lull the open source movement into a false sense of security, however, since the TCP wrappers Trojan is not a good example of a truly stealthy Trojan horse: the code was glaringly out of place and obviously put there for malicious purposes only. It was as if the original Trojan horse had been wheeled into Troy with a sign attached that said, "I've got an army in my belly!"

...Currently, however, the benefits open source provides in terms of security are vastly overrated, because there isn't as much high-quality auditing as people believe, and because many security problems are much more difficult to find than people realize. Open source programs which appeal to a limited audience are particularly at risk, because of the smaller number of eyeballs looking at the code. But all open source software is vulnerable, and the open source movement can only benefit by paying more attention to security.

[Jan 18, 2000]  Open-Source Software Development by Davor Cubranic Department of Computer Science University of British Columbia cubranic@cs.ubc.ca was added to Webliography

[Dec. 12, 1999] Accidentally found on the Web and added to the Webliography  Comments by Chuck Cranor about CatB

[Dec. 9, 1999] A second look at The Cathedral and The Bazaar was published by First Friday

[Dec. 8, 1999] Today I accidentally found  and added to the Webliography comments of Dave Winer using Goggle search engine. They are very insightful early comments on the CatB paper.

Brooks Law and Open Source Development

General

See also

What should be done? I will conclude with a suggested agenda for everyone, whether a commercial software developer or merely a computer user.

1. Recognize the major contributions of the free software community, from Linux and GCC to TEX, LATEX and Ghostscript.
2. Accept that both commercial and free software have a role to play, and that neither will ever go away.
3. Be respectful of the authors of good free software.
4. Try to convince them to apply the reciprocal goodwill (in some of the cases cited this may be hard, but one should try).
5. Refuse and refute the moral defamation of commercial software developers. If you are a software developer, be proud of your profession.
6. Call the extremists' bluff by questioning their moral premises. Re-establish ethical priorities.
7. Refuse the distortion of moral values and the use of free software as a pulpit from which to spread ideologies of violence.
8. Demand (in the spirit of faithful advertising) that the economic origin of "free" software be clearly stated, and that the products be classified as one of "donated", "taxpayer-funded" and the other categories described in this article.
9. For Microsoft, whose unique position in the community creates unique responsibilities: promote a more open attitude towards the rest of the world; open up; be less mean. You can afford to be.
10. For everyone: focus on quality. Work with every competent person--free or commercial software developers--to address the increasingly critical, and increasingly ethical, issue of software quality.
11. Strive to combine the best of what the two communities have to offer.

Salon Technology Of greed, technolibertarianism and geek omnipotence

In her new book "Cyberselfish: A Critical Romp Through the Terribly Libertarian Culture of High Tech," Borsook sounds a round challenge to the techie conceit of total autonomy. She asserts -- among other highly flammable propositions -- that decades of government funding for basic research, aerospace electronics, housing and higher education are conspicuously absent from the standard story of privatized technology heroics. She sees the prevailing libertarian ethos of Silicon Valley and the technology sector as merely a strain of geeky, adolescent narcissism masquerading -- and dignifying itself -- as politics.

It seems like you're contending that technolibertarianism is a rhetorical projection of control-oriented, non-communitarian, arrested-adolescent urges of the preponderantly male geek technocracy. You document a collective, industry-wide failure to grow up and participate in society, as well as a culture that celebrates a massive underdevelopment of its humanity. Did I get that right?

Well, yes, I suppose. Though I should say this book was written over several years, and the culture has changed a bit over that time. One of the very recent changes has been that the übergeek libertarian culture I wrote about has been mated with MBA culture, which brings its own prejudices and religious beliefs to the party.

That's an interesting melding: the masters-of-the-universe MBA culture colliding with awkward geek, "I don't have the world's best social skills" culture. But they love each other's rhetoric and ideology and there's a strange sort of symbiosis going on. Geeks and MBAs intrigue each other for complementary reasons: MBAs like being associated with the geek shibboleths of inventiveness and revolution; Geeks are attracted to the MBAs' promise of making things real through the glamour of money. And both of them like money because it's something that can be counted.

So now, when we talk about high-tech culture, a lot of what we're talking about is really business-speculation culture, and a transplanted Midtown Manhattan advertising culture, or Wall Street financial culture. So, though we may use the words "high tech" these days to refer to this group, they're not all the same kind of person -- but they are finding lots of common ground.

Absolutely. I noticed that at some point in the mid-'90s, we got major culture-creep, when programmers and systems administrators all became covert stock traders on the Web.

Yes. It's horrifying. [laughs] Because -- and I'm not anti-technology or anti-geek -- what is really best about these people is what I call their "curious child" quality -- scientists have it -- that kind of noodling around with code, and zoning out for 36 hours at a time working on something. That's where the really good creative work can happen. But if you have one corner of your monitor that's constantly watching the stock market, or you're thinking about what sort of play you can come up with to impress the institutional investors, well, that's not how really serious technology work gets done. That, to me, is kind of sad and scary, and -- not to sound patronizing -- but kind of a loss of their innocence in a way that I don't think is good.

...It's really important to stress the number of times I've heard computer people say, "Well, I'm not a libertarian like that wacko over there, but I think the government is in people's lives too much," or "I believe in the free market," or advance this fantasy that there's no interdependency or no mesh and that somehow the government doesn't make this a safe, reasonable place to live and make lots of money.

You write about the willful blindness by techies to the prior contributions of government and universities in creating the foundations of the Internet. In your own perfect hypothetical world, what kind of evil torture might you contrive to open their eyes?

I want to say something like an "It's a Wonderful Life" kind of scenario: "Look, Jimmy Stewart -- what would it be like if you hadn't lived!" I mean, you'd have to think of something like that, because, the problem with the Internet example, and all the other examples in the book -- there's nothing new in there, I'm just pulling it all together -- is that the really important thing to remember is the Internet/ARPANET was sheltered from having to make any money for, like, 15 years. So how can you give people an image of what it would be like to live in a world without economic shelter of any kind?

What would it be like to live in a world in which there was never a time-out from the philosophy and pressure of the marketplace? It's kind of like trying to explain to people the notion of prior restraint, or how their world is impoverished by the absence of something they've never seen. And that's a very hard thing to do, and since I'm not fundamentally sadistic, it's hard for me to come up with a torture.

There seems to be this hidden assumption in geekdom that cleverness at coding must naturally generalize to all other areas of knowledge -- as if being a good hacker qualifies geeks to be philosopher-kings as well. Would you agree? Where do you think this feeling of intellectual entitlement comes from?

I would totally agree, but then again I must be a little bit fair -- there are lots of doctors and lawyers and other people who think, well, if I ran the world, I'd know what I was doing. I think perhaps that in the geek world -- because you're basically always creating a system that will work and respond, you're creating little, bounded universes all the time -- I think perhaps it's more tempting to think that this kind of general omnipotence can extrapolate out from that. Because [as a programmer] you're often being brought in to solve a problem -- whatever it is -- and even if you solve that problem poorly, or with unnecessary complexity, the fact is that you're confident in your skill set as a problem-solver. So why wouldn't that extend to everything else?

If the shakeout of the dot-coms continues as we've seen recently, if more companies die off or are eaten by larger companies, and the prevailing technolibertarian meritocracy pose becomes less and less tenable, do you think the rhetoric within the industry will change? As the losers file for protection or seek government intervention, do you anticipate a, shall we say, softening of the libertarian hard line?

I'm very, very curious to see what happens -- whether [technolibertarians] are going to hew to the social Darwinist line or maybe be more intellectually honest, and say it's more a matter of luck -- but I don't see that happening in high tech.

It's a lottery -- it's a less rigged lottery than other things, but it is still a lottery -- so, I'm going to be very curious to see what happens when people want to say, "It's not fair, it's not fair, my company never IPO'ed, but my friend's company went public six months ago, and he got his money out and I didn't, and it's not fair."

So, it's going to be hard to tell because -- you know the notion of cognitive dissonance -- it's like some chiliastic cult that thinks the end of the world is going to happen, and then it doesn't happen, and their fearless leader comes up with an explanation of why the end of the world didn't happen. This ideology is so pervasive and largely invisible that I'm not going to say yes, they're going to have a more sober and mediated view of human life because of witnessing a NASDAQ wobble. I could hope that might happen, but I'd be reluctant to predict it.

ZDNet PC Week Open source is (so far) an open road to nowhere

[ESR Open Source Movement] It's best at tearing apart the establishment because it consists of underappreciated programmers who suddenly have a voice.

"Vigor lives. Or, more accurately, it interrupts. Vigor's sole purpose is to annoy users with snide comments that must be acknowledged with a click on the OK button before work can continue."

Linux Today WebReference.com BeOS 5 Bounds onto the Scene -- a real competition to Linux in desktop space emerged.

Amid the on-going furor of the OS wars, one contender has often slipped under the radar of most users - the BeOS. This is a shame, really, because the BeOS is one of the most powerful and well- designed operating systems available today. And now, to sweeten the deal, Be Inc. has taken a clue from their Linux competitors, and have started offering up the Personal Edition of the new BeOS 5 for free download.

Some have called this offer a last-ditch attempt to generate popularity for the OS. To be honest, they may be right. Be Inc. was founded by ex-Apple exec Jean-Louis Gassee in 1990, and though its OS has garnered a good deal of critical acclaim since then, it's never developed much of a user base. That might be changing, however. Since BeOS 5 was posted on the Web on March 28, there have been over 870,000 reported downloads of the 40 meg base installation from partner sites - maybe not enough to scare anyone in Redmond, but by no means a shabby number! The freely downloadable Personal Edition of BeOS 5 is fully operational; the BeOS 5 Pro edition is available for purchase for $69.95, and comes bundled with additional development tools, software and add-ons.

Let's take a look at BeOS and see what the buzz is about.

So What is it?

The BeOS is just that - a whole new operating system. Built from the ground-up in the 90s, Be sought to leverage the fact that they did not have to support a large number of legacy applications like other existing OSes. Though each new version of the MacOS and Windows adds additional features (and slowly removes some of the support for outdated system calls, features and hardware), they still have a lot of their history embedded in them, either in the form of actual code, or in philosophical approach. Since Be was starting from a blank slate, they were able to design their OS to use modern hardware to its fullest potential, as well as incorporating the latest developments in OS design. It's this modern design that gives the BeOS some of it's most appealing features.

The Pros

So what are those appealing features?

Stability.

First off, the BeOS is remarkably stable. Though individual applications may crash, it's exceedingly rare for the whole OS to go down. (Chalk up a point for truly modern threading and memory management!) One popular BeOS screensaver points to the chutzpah that Be users have about system crashes - the BSOD screensaver mockingly simulates the Windows "Blue Screen of Death", as well as system crashes on SCO Unix, Sparc-Linux, AmigaDOS, Atari ST and Mac OS.

It's also a fully journaled OS, which means that you can pull the plug out of the wall at any time and not lose any information. Nor will you have to spend several minutes running checkdisk or rebuilding your desktop next time you boot up.

Speed & Media Optimization.

As a newcomer to BeOS, I immediately noticed the speed at which the OS boots up (and later, how fast it shuts down). The lack of the standard Windows "almost there, almost there" boot up/shutdown song and dance, and the endless parade of extensions on my Mac's startup screen were not things I missed.

BeOs has an internal 64-bit pipeline, and has been built from the ground up to deliver extremely fast response for file access and for a large variety of multimedia types. The typical reviewer remark about this is "imagine playing 6 Quicktime movies at the same time!" I decided to take a different approach, and played 11 MP3 files simultaneously. It was a heck of a sonic mess, but the OS mixed all the output in realtime without flinching.

Attributes.

Every file system saves some sort of information about the attributes of individual files. For most operating systems, this information is limited to the name, size, date of creation and perhaps ownership/access permissions for the file. Under the BeOS, attributes are enormously customizable, and new types can be created by the user. These new attributes can contain data of almost any format, and powerful database-like search and sort functions can be performed system-wide (MP3 files could be sorted by information embedded in their ID3 tags, to offer one very simple example). The OS and your applications can also use attribute information to automate a large number of tasks.

POSIX Compliance.

The Unix-like kernel is accessible from a powerful command line running bash, a command shell which will instantly be familiar to Linux users. Mac and Windows users need not be afraid - the GUI is great, and you'll never have to deal with a command shell if you don't want to. Since the kernel is almost fully POSIX compliant, recompiling existing Unix applications is much easier.

Cross-Platform Support.

You can run BeOS on both Intel and PowerPC platforms and there's specific support for Pentium III enhancements build into the OS. This is great for programmers, since you can immediately start developing for both sets of hardware. BeOS can also mount, read, and write to any FAT16, FAT32, and Mac HFS formatted discs.

You can't, however, run BeOS on G3 or G4 processors (in other words, any recent Macintosh). The word on the street is that Apple is making it difficult for Be to be ported to these newer machines, but I don't have any firm information about that.

The Downsides, & Getting Started

The Cons

Ok, if it's so great, why isn't everyone using it? Well, admittedly, it's not all roses and multi-threaded moonbeams in Be-land. There are some definitely cons to the BeOS, and for many people, these may be enough to keep them from even trying it.

Software and Hardware Support.

This is the big one. BeOS, being the "little kid on the block," doesn't have anywhere near the software support of either the Microsoft or Macintosh OSes. It's the catch-22 of any new operating system - if the OS doesn't have any applications, it won't attract any users. And if it doesn't have any users, no one will want to write applications for the OS. And if it doesn't have any applications...you get the idea.

This is not to imply that there are no applications available for BeOS, just that the number is far lower than on other platforms. A quick glance at the BeWare Catalog (http://www.be.com/software/beware/), or at sites like BeBits (http://www.bebits.com) will give you a good idea of range and scope of available applications. Being both media-optimized and programmer-friendly, Be has software available from several big names in the the audio/video/image software community, including MetaCreations, Steinberg, Arboretum, eMagic, VideoWave and more. Most importantly, much of the software available seems to be high in quality, which might make the total number of choices less of a concern.

Hardware support is good, but not complete. While the company and existing user base has done an admirable job of writing drivers and keeping Be compatible with most major hardware, there are definite gaps. As with the software catch-22, most manufacturers won't spend the time and money to develop drivers for a platform with a small user base. On the plus side, BeOS does a wonderful job of automatically recognizing the hardware it does support, so installation of new (supported) devices is extremely easy. For speed demons, the OS also has multi-processor support built into the kernel. More information about currently supported hardware can be found at: http://www.be.com/products/beosreadylist.html

Ease of Use/Learning Curve.

This isn't necessarily a con, as much as it's just a fact of life. BeOS 5 is a complete and independent operating system, so learning to use it will take a little time. Elements of the interface can be changed to more closely resemble other OSes and there are aspects of the interface that will make users migrating from Windows, MacOS or Unix feel more comfortable. The core is distinctly Be though, and to get the most out of it, a new user is going to have to realize that there will be a learning curve. This is especially true for new features like the powerful attributes system that don't have a clear equivalent in other existing OSes.

Getting Going with BeOS 5

I found BeOS 5 to be a breeze to install. After downloading the installation archive (which, at 40 megs, is somewhat large for modem users, but still smaller than most game and application demos these days), I walked through a fairly brainless and painless install process. The new version simply installs itself and it's file structure as a one 500 meg file in your existing system, so there was no need to worry about repartitioning, dual-boot voodoo, or file system changes. Booting into BeOS is just as easy - just click on an icon on your desktop. Your OS shuts itself down, and Be pops up. Since I'm running Windows NT, I did have to make an additional boot floppy, but that was equally painless.

Final Words

I have no vested interest in the BeOS - I don't own stock in the company, and had never used it before this review. Though I get as grumpy as the next guy about the foibles of Windows, MacOS and the various flavors of Unix that I work on in any given day, I have no major grudge or agenda against any of those platforms or their parent companies. So bottom line - will I continue use BeOS 5 in the future? My honest answer is a qualified "maybe". The OS itself seems great: it's zippy, looks nice, and "feels good", if that makes any sense. Though I'm certainly at the start of the learning curve, and need to get much more familiar with the details of the user interface, I like what I see. Every time I use BeOS 5, different elements of the design jump out at me and small but elegant features come to light.

For me, the deciding factor will ultimately come down to software support. Will the available software allow me to accomplish my work? Perhaps more on point, will it make life easier for me, and make up for any time I need to spend learning to use a new OS? I'm not entirely sure yet, but I enjoyed BeOS 5 enough to invest a little more time putting it through its paces and surveying the available software. I'd recommend anyone with an interest in alternative, well-designed operating systems to take a look.

For more information on BeOS 5 and download locations, check: http://free.be.com/

Linux and BeOS -- a real competition to Linux in desktop space emerged.

Linux and BeOS are both getting close to 10 years old, but they have very different histories and are quite different products. The one thing they have in common is they are both alternative operating systems. Rather than looking at them as competitors, let's explore how they can work together to satisfy the needs of a greater audience.

Linux has proven itself to be the fastest-growing server operating system. Its reliability and performance per dollar have helped it get there. Any objective viewing shows Linux as the best choice in the web server world, and its support of the SMB, IPX and Appletalk protocols makes it an excellent choice as a file and print server in a mixed environment.

Linux has also made great inroads into the desktop environment. With the KDE or Gnome GUI and office applications such as Applix, WordPerfect and StarOffice, most users familiar with any GUI-based system can comfortably use Linux on their desktop.

In previous columns, we discussed how Linux is a multi-user operating system, where you generally work in a peer-to-peer environment. That is, any Linux system can be a server or a client. While this has lots of advantages, it does have one disadvantage: administration of a client is almost as complicated as a server.

Enter BeOS, an operating system designed to be running on a workstation. BeOS is not multi-user, but it is multi-tasking. To make matters even more interesting, the GUI is part of the operating system, rather than being an add-on like X is with UNIX/Linux or Microsoft Windows is on MS-DOS. What this means is:

• the user interface for applications is consistent, because it is part of the OS;
• system administration is simplified, because there is no multi-user configuration and there need not be any server configuration;
• GUI performance is excellent, because the layers of overhead associated with translation of GUI functions from the application to the OS are eliminated; and
• writing GUI-based applications is simplified, thanks to a very clean Applications Program Interface (API).

Linux and BeOS Working Together

What all this means is that BeOS offers easy-to-configure clients with excellent performance. BeOS includes a POSIX-compliant command layer, meaning anyone familiar with Linux or UNIX can bring up a terminal window and use their favorite program--whether it be ftp or vi--and those who want a GUI interface won't be disappointed, either.

With NFS available for BeOS (for free), a Be workstation can be connected to a Linux-based network and just look to Linux like any other workstation. For the home user, BeOS connects to the Internet with virtually no effort, making it an ideal home system and offering home users the same system they have on their desktop at work.

What's Missing from BeOS

This may sound like a rerun of Linux statements, but the answer is applications. Link any "new to mass market" operating system, and it is going to take some time to catch up. The only office suite available is GoBeProductive. Netscape isn't there yet, but with Be's recent announcement about working with Sun Microsystems to add Java support to BeOS, I expect Netscape is not far behind.

In the last six months, BeOS has gone from a virtual unknown to a serious alternative operating system. Moving into the OS market on the coattails of Linux and in an environment that finally supports alternatives to the Microsoft answer, expect BeOS to get its applications out a lot faster than Linux did.

Recent Announcements About BeOS

Part of what supports my assertions regarding Be's growth into the mass market is related to recent announcements. Here are a few:

• Be Announces Software Licensing Agreement with Compaq that allows Compaq to pre-install and distribute Stinger, the code name for Be's software platform for Internet appliances, on future Internet Appliance computing devices ...
• Be and Opera Software Team to Enable Rich Web Content On Internet Appliances
• Be, Inc. and SSC announce Be Magazine ... (yes, that's us; the first issue will be out in March, 2000.

[Apr 15, 2000] Slashdot /Several Stampede Developers Depart Stampede is in trouble and might unfortunately became a history. It looks like they overextended themselves and tried to produce an alternative user-friendly distribution. Some problems with leadership also surfaced. But resourcewise they cannot complete with Corel and have no resource for sustainable development.

We have been developers, end-users and general supporters of the Stampede Linux (Stampede GNU/Linux) project for over two years. We have enjoyed working together as a team and pursuing many of our own interests in conjunction with expansion of the distribution. Many of us have grown up on Stampede.

It is now time for us to part company. Due to a number of reasons based on the current administrative nature of the Stampede Linux distribution, we are unable to continue supporting the efforts of the distribution. As a group, we feel that the needs of the group have not been supported by the current model of operations. Though we have tried, we have not been able to affect change in this regard. Despite our strong long-term commitment to the project, it is time to move on.

As a group, we shall endeavor to find a more suitable, democratic forum to express our interests. To those who have supported our efforts over the last two years, we thank you.

Signed...

[Feb.22, 2000] Linux A Bazaar at the Edge of Chaos -- an attempt to explore the phenomena by a sociology student that turned in a very nice example of Raymondism --  naive, on the border of blind-folded chauvinism, view of OSS. IMHO there is very little actual sociology research in the paper. But it does represent a rather good attempt to market Raymondism postulates.  Please note that the web site for the paper contains several interesting letters; One of them I really recommend to read:

DOS is a classic example of this same sort of process. A product gains an early distinctive lead against a competitor based on the bias of a particular group of early adopters. In this case that bias was product branding and reputation associated with IBM. Past the point at which those early adopters acting with that motivation caused a sufficient threshold of marketshare to occur, subsequent growth and success of that particular product is due primarily to a feedback loop.

People don't bother to consider the Macintosh an option because it doesn't have the wide adoption that DOS does or doesn't have the sort of reputation in business associated with IBM.

This EXACT problem is why some of us are drawn to free software. Linux and other products that are free from the constraint of 'surviving' in a free market are better able to compete with products that are similarly 'unconstrained'. Since DOS achieved it's 'watershed marketshare', Microsoft has been free of market constraints or the need to quickly adapt in function or quality. This allowed Microsoft to 'sandbag' technologically and not be punished by the market. This lead to a situation where the predominant product had significant technical flaws from the point of view of consumers with a different bias.

OSS/Free Software allow for the existence of alternatives that can compete against a natural monopoly.

An OS competing against DOS or Windows not only has to provide the functionality that the core OS itself is meant to provide but also support the usage of a wide range of hardware and have available for it a wide array of useful software. An entire collection of products has to be functionally replicated. This is a heavy burden for any company and historically has been unachievable.

The paper itself is not that impressive either form technical or sociological points of view. Here is an example of the author thinking (after that you can expect a hug from ESR and that's really the case; see ESR letter to the author ;-) :

However improbable it might seem that the chaotic, frenzied activities of the bazaar can ever outdo the top-down coordination of the cathedral, it is exactly what happened in the case of Linux. Raymond attributes the success of the Linux project to several important characteristics of the bazaar, summarized in the following imperatives:

"As useful as it is to have good ideas, recognizing good ideas from others can be even more important and productive. Build only what you need to. Be modular. Reuse software whenever possible.

Prepare to change your mind, and be flexible to changing your approach. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. "Plan to throw one away; you will, anyhow."

Feedback is key to rapid, effective code improvement and debugging. Release early and often. Treat your customers as co-developers, and listen to their feedback. Treat your beta testers as your most valuable resource, and they will become your valuable resource.

Peer review is essential. Given enough co-developers, problems will be characterized quickly and the fix obvious to someone: "Given enough eyeballs, all bugs are shallow."" [14]

Most fundamentally, what these attributes suggest is the importance of frequent version updates. Conventionally, updates are released no more than once or twice a year, only after a majority of the bugs have been fixed so as to not wear out the patience of the users. In comparison, updates of the Linux kernel were released as often as every day or every week. But rather than wearing out the users, the frequent updates not only kept the developers stimulated, but also exposed bugs directly to the eyes of the users for quick detection. Raymond elaborates:

"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 quickly when exposed to a thousand eager co-developers pounding on every single new release." [15]

Much of the same process is also at work in the development of the code. Given a user and developer base as large as the Linux community, Torvalds can safely rely on others to write and test the code for him. More likely than not, he can also expect multiple versions of the code from people who are more knowledgeable or interested in the specific component than he is. His task, then, is to simply select the best code to incorporate into the next release of the kernel.

[Feb.22, 2000] Speculative Microeconomics for Tomorrow's Economy -- contains probably the first discussion of comparative merits of dual-track software versus open source software.

A fourth, increasingly important, solution to the transparency problem is open-source software [17]. Open source solves the software opacity problem with total transparency; the source code itself is available to all for examination and re-use. Open source programs can be sold, but whenever the right to use a program is conferred, it brings with it additional rights, to inspect and alter the software, and to convey the altered program to others.

In the case of the "Copyleft license," for example, anyone may modify and re-use the code, provided that they comply with the conditions in the original license and impose similar conditions of openness and re-usability on all subsequent users of the code [18]. License terms do vary. This variation itself is a source of potential opacity [19]. However, it is easy to envision a world in which open-source software plays an increasingly large role.

Open source's vulnerability (and perhaps also its strength) is that it is, by design, only minimally excludable. Without excludability, it is harder to get paid for your work. Traditional economic thinking suggests that all other things being equal, people will tend to concentrate their efforts on things that get them paid. And when, as in software markets, the chance to produce a product that dominates a single category holds out the prospect of enormous payment (think Windows), one might expect that effort to be greater still.

Essentially volunteer software development would seem particularly vulnerable to the tragedy of the commons. Open source has, however, evolved a number of strategies that at least ameliorate, and may even overcome, this problem. Open-source authors gain status by writing code. Not only do they receive kudos, but the work can be used as a way to gain marketable reputation. Writing open-source code that becomes widely used and accepted serves as a virtual business card, and helps overcome the lack of transparency in the market for high-level software engineers.

The absence of the prospect of an enormous payout may retard the development of new features in large, collaborative open-source projects. It may also reduce the richness of the feature set. However, since most people apparently use a fairly small subset of the features provided by major packages, this may not be a major problem. Furthermore, open source may make proprietary designer add-ons both technically feasible and economically rational.

In open source, the revenues cannot come from traditional intellectual property rights alone. One must provide some sort of other value - be it a help desk, easy installation, or extra features - in order to be paid. Moreover, there remains the danger that one may not be paid at all.

Nevertheless, open source has already proven itself to be viable in important markets. The World Wide Web as we know it exists because Tim Berners-Lee open-sourced HTML and HTTP.

• [Apr. 18, 2000] Document-centered Peer Collaborations An Exploration of the Educational uses of Networked Communication Technologies

  Document-centered software, such as the CoNote application developed at Cornell University, supports cooperative work systems by facilitating communication within work groups via shared annotations (marginal notes) on a set of documents. The central idea is that shared annotations provide an effective communications forum for groups whose work involves frequent reference to some set of documents (e.g., teachers and students, field service workers, editors and publishers, organizations). In this study we examined how students used annotation tools for communication and learning and attempted to identify which factors influenced students’ interpretations of these collaboration tools. It appears that the beliefs that users hold about what constitutes a legitimate educational experience can influence the value they ascribe to educational software. Gender also seemed to have an impact on whether students felt that the annotations helped them create better Web sites and learn more effectively.

  Existing literature presents conflicting evidence of how CMC affects group coordination and communication. It is difficult to make any meaningful generalizations or predictions about the role of different communication technologies in fostering or inhibiting group participation because the particular characteristics and objectives of a group and its members largely determine the need for different modes of communication. By altering expectations, behavior and group dynamics, CMC systems sometimes facilitate, but at other times hinder, the accomplishment of group objectives. For instance, while Sproull (1986) argues that CMC systems allow for increased egalitarian participation, Herring (1993) claims that CMC groups are less democratic than their proponents claim, because gender-based communication styles, and therefore the power dynamics and biases associated with these styles, carry over into electronic environments. Bordia (1997) provides a synthesis of 18 CMC experiments reporting similar conflicting findings. Some examples of potentially favorable CMC impacts for learning include the disinhibited effect (Dutton, 1996), unblocking users' ability to produce ideas (Gallupe, Bastianutti & Cooper, 1991), and providing a built-in memory and repository of exchanged ideas (Chan, 1997; Gallupe et al., 1991)

  This paper examines the use of a document-centered CMC tool created for discussion grounded in and around an artifact. First, we review conceptual issues explored in educational CMC research. Next, we discuss the grounded approach to the use of communication tools by students. We then give the results of a study that examined how students made use of a situated annotation tool and the factors that influenced their perceptions of the usefulness of the tool in an educational context. Finally, we discuss some future research ideas in this paradigm.

   

• [Feb.22, 2000] Speculative Microeconomics for Tomorrow's Economy -- contains probably the first discussion of comparative merits of dual-track software versus open source software.

  A fourth, increasingly important, solution to the transparency problem is open-source software [17]. Open source solves the software opacity problem with total transparency; the source code itself is available to all for examination and re-use. Open source programs can be sold, but whenever the right to use a program is conferred, it brings with it additional rights, to inspect and alter the software, and to convey the altered program to others.

  In the case of the "Copyleft license," for example, anyone may modify and re-use the code, provided that they comply with the conditions in the original license and impose similar conditions of openness and re-usability on all subsequent users of the code [18]. License terms do vary. This variation itself is a source of potential opacity [19]. However, it is easy to envision a world in which open-source software plays an increasingly large role.

  Open source's vulnerability (and perhaps also its strength) is that it is, by design, only minimally excludable. Without excludability, it is harder to get paid for your work. Traditional economic thinking suggests that all other things being equal, people will tend to concentrate their efforts on things that get them paid. And when, as in software markets, the chance to produce a product that dominates a single category holds out the prospect of enormous payment (think Windows), one might expect that effort to be greater still.

  Essentially volunteer software development would seem particularly vulnerable to the tragedy of the commons. Open source has, however, evolved a number of strategies that at least ameliorate, and may even overcome, this problem. Open-source authors gain status by writing code. Not only do they receive kudos, but the work can be used as a way to gain marketable reputation. Writing open-source code that becomes widely used and accepted serves as a virtual business card, and helps overcome the lack of transparency in the market for high-level software engineers.

  The absence of the prospect of an enormous payout may retard the development of new features in large, collaborative open-source projects. It may also reduce the richness of the feature set. However, since most people apparently use a fairly small subset of the features provided by major packages, this may not be a major problem. Furthermore, open source may make proprietary designer add-ons both technically feasible and economically rational.

  In open source, the revenues cannot come from traditional intellectual property rights alone. One must provide some sort of other value - be it a help desk, easy installation, or extra features - in order to be paid. Moreover, there remains the danger that one may not be paid at all.

  Nevertheless, open source has already proven itself to be viable in important markets. The World Wide Web as we know it exists because Tim Berners-Lee open-sourced HTML and HTTP.

• [added Jan 28, 2000] Daemon News 199908 Structuring and Funding Free Software Organizations

• Funding a Free Software Organization

  Other than structure, the way resources are obtained and distributed is essential for the survival of any free software organization. The most appealing way to obtain resources is the creation of a non-profit organization, a model followed by the NetBSD Foundation and the Apache Foundation, this makes easier for companies and individuals to contribute due to the tax deduction advantages available in some countries.

  Many countries, though, have little or no legal provision for this type of organizations; in those cases some companies might feel motivated to register their contribution as an operational expense in their financial state of results and while this expense will not be deducted from the taxes, no tax will be paid for it (consult your accountant if in doubt). FreeBSD Inc. is a company created to take advantage of these donations in order to provide support to the FreeBSD Project, (And of course, FreeBSD is not really a Project since it does not have a defined deadline for it's objectives...confusing heh?).

  The real owners of a free software company should be their developers, this means that in order to be consistent companies that make money out of free software should pay at least part of their salaries in shares of the company.

  In recent weeks some companies, including Red Hat Software, have decided to sell shares to the public as a way to obtain additional resources. In general, it seems like a bad idea; everyone with the least financial background knows this is the most expensive way of getting resources for a company. Investors always expect to receive better dividends from their shares than any financial institution; otherwise they would simply leave their money in a bank.

  Red Hat has never produced dividends, and I suspect they never will, this probably means that Intel and the other companies that have invested their money there either wanted to lose it, or have some second intentions. The Red Hat case is particularly interesting: in order to produce at least some earnings for their owners they will have to become the number one Linux distribution, something that would be good for the commercial hardware producers that own it now since there would only be one Linux distribution to deal with, but that also means annihilating all other Linux distributors. To make things even more interesting, Red Hat won't be able to differentiate their product significantly due to the GNU license so it will be difficult to kill anyone without making REAL enemies in their own community; this is what I, and probably many people, would call really high financial risk.

   

• [added Jan 21, 2000] Open-Source Software Development by Davor Cubranic Department of Computer Science University of British Columbia cubranic@cs.ubc.ca

  Open-Source Development: Doomed by its own Success?

  Ted Lewis in his ``Binary Critic'' column in IEEE Computer [10] voiced a rare criticism aimed at the open-source development process itself (in particular the ``bazaar'' approach) and its ability to cope with its own success. Specifically, Lewis thinks that as open-source projects' popularity grows and they begin multiplying, the pool of talented programmers who devote their free time to such projects will become increasingly scarce. Furthermore, Lewis claims, as those projects mature, they will also grow in features and complexity, eventually overwhelming the resources of their handful of core developers and the capability of their typically ad-hoc organizational structure to cope with those stresses. This sentiment is also echoed by Microsoft: ``The biggest roadblock for open source software projects is dealing with exponential growth and management costs as a project is scaled up in terms of innovation and size'' [19].

  Lewis's article has generated a barrage of criticism on open-source-related mailing lists (which, because of their turn-around time, hasn't yet reached printed publications). One particularly strong counter-example to his argument is that Linux has managed its growth to over 1,500,000 million lines of code (comparable to other Unixes) over the last seven and a half years quite well. Its reliability hasn't suffered and features have, at the very least, kept pace with commercial operating systems (the press reports that IBM has recently announced its intention to ship Linux with some of its RS/6000 servers although it has its own version of Unix, AIX [22]), and the developers' structure has adjusted as the core developers took more responsibility for some areas of the kernel off Torvalds. (It should be noted, however, that releasing version 2.2 took longer than expected and that occasionally there is a backlog of submitted patches awaiting Torvalds's approval for inclusion into the kernel.)

  Conclusion

  Even if the current attention given to open-source software by the media and commercial software companies proves to be only a fad and it doesn't make the jump into the mainstream acceptance, I believe that open-source software development is here to stay. While it may not be the right development model for every software project, it is hard to argue against its effectiveness in the case of Linux or Apache. James Sanders [21] makes a good point that as the software companies struggle to find a way to meet the often conflicting requirements of developing software faster while making it more robust, they might be forced to embrace alternative development models. Using Linux as an example, open source gives a development model that ``creates a faster, leaner, and more reliable product than mainstream competitors, and does so essentially for free'' (p. 89). In addition, it can only be expected that new open-source projects will continue to be created and bring forward innovative software ideas that would be too large for resources of a single enthusiast, but generate enough interest in the Internet programmers's community to carry their development forward.

  What we should provide to these developers is the tools and knowledge to better manage such projects, reduce the entry barrier for those who want to join the development, and eliminate unnecessary manual work. Clearly, better configuration management (CM) tools are necessary --- drawbacks of CVS are well-known (e.g., [12], and are only more obvious when the collaborating programmers are so widely dispersed and loosely coordinated. Distributed CM systems, such as NUCM [25], would make a better fit, including keeping parts of the development tree on servers belonging to a subgroup of developers that temporarily branched off for work on a new feature (or that, like Netscape in case of Mozilla, has a proprietary version of the software). Announced and proposed changes could be better managed through a mechanism like that described by Narayanaswamy and Goldman [14] instead of a mailing list, like that for Apache Web server. Similarly, reviewing and testing patches would arguably be a lot easier if they were accessed through, for example, a fine-grained revision control mechanism like Historian [1], than as email messages thrown in together with the rest of development-related discussion.

  Lastly, effective knowledge management is all the more crucial in open-source development, where most developers won't ever see each other face-to-face and discussion is for practical reasons almost exclusively online and asynchronous. Furthermore, it should be made easier for the new developers to join in and get acquainted with the design decisions and the evolution of the code. Currently, this usually means going through the archives of the project's mailing list. A possibly better approach is suggested by Lougher and Rodden [11], where maintenance-related discussion is (literally) centred on the affected code; it could conceivably be extended to support the full development cycle and include an overview of the temporal change of the program as well.

  Through all of this, we should keep in mind the specificities of open-source software development that make it different from, for example, Internet-based development for a more monolithic entity, such as a commercial software company. In particular, open-source software development is extremely fluid: it depends on contributions from volunteers, whose commitments, available time, or interests may easily change. Enacting a traditional software process under these circumstances is much more difficult; it could also be counterproductive, if the contributors perceive that they are giving away their freedom. What is needed are the tools and techniques that are flexible, complement the tools currently in use, and support the existing open-source development model almost transparently.
  

• Tim Berners-Lee, 1996. "The World Wide Web: Past, Present and Future," http://www.w3.org/People/Berners-Lee/1996/ppf.html
• Tim Berners-Lee, 1997. "Realizing the Full Potential of the Web," http://www.w3.org/1998/02/Potential.html
• The Social Life of Documents by John Seely Brown and Paul Duguid - introduction by Esther Dyson

The sociologist Anselm Strauss explored the way new forms of document allowed new forms of community (or as he calls them, "social worlds") to come into existence. His work predates the proliferation of computers and so provides an interesting view of the way other developing technologies (copiers, faxes, and so forth) supported social relations in new ways. In particular, new media allowed small communities (enthusiasts of exotic breeds of birds or antique motorcycles) to form though their members were often few, and those few spread over large distances.

These groups can look surprisingly like modern equivalents of the scholarly communities that formed throughout the world in the Renaissance. These too were held together by common interests and shared communications. The letters circulating among the Fellows of the Royal Society in England formed the prototype for scientific journals, which still bind intellectual communities together. And indeed Strauss's initial observations were based on the new ways scholars were building communities of interest with the support of new communications technologies -- and, as we have argued elsewhere, may help understand the future of scholarly communities in the digital age.

• Bernard Lang, 1998. "Free Software For All: freeware and the issue of intellectual property," Le Monde Diplomatique (January), see http://www.monde-diplomatique.fr/md/en/1998/01/12freesoft.html
• Creativity and ownership where is the balance Ram Samudrala, Ph.D. Department of Structural Biology Stanford University School of Medicine Stanford, CA 94305 This paper was presented at the Third Annual Ethics and Technology Conference held at Santa Clara University, Santa Clara, CA, in June 1998.

• Abstract

  New technologies emerge from existing ones at an exponential rate. This growth usually outstrips any legal or government machinery designed to handle the implications of technology on society. Ethical decisions made by creators, producers, and users of new technology influences not only how the technology is regulated and who can access it, but also its acceptance and longevity in the mainstream populace.

  The nature of emerging technologies in two specific situations, in the music and the software industries, was analysed. The different ways in which they have been embedded into society or have failed to "catch on" were compared and contrasted.

  In the case of the music industry, a correlation exists between copying controls in the digital media and the failure of technologies that incorporate such controls. Copying controls in digital media have become law. The technologies with copying controls, even though superior to existing digital technology in some cases, have failed to become popular in the marketplace. One hypothesis is that it is the copying controls incorporated into these technologies that effectively led to their demise. This hypothesis is supported by the fact that the media/device currently popular for digital recording, the compact disc recorder, is largely available without digital copying controls, and that professional digital recording devices, also available without copying controls, have become an industry standard.

  In the case of the software industry, there is widespread distribution of freely re-distributable software which has resulted in technological innovations that may not have been possible using traditional proprietary models. There is presently a thriving commercial sector built around freely-redistributable software, and commercial software vendors have begun incorporating this model to distribute their software.

  These two scenarios illustrate that whenever new technologies emerge, it is the ethical decisions initially made by the inventors and creators regarding the ownership of information in these technologies that influence the governmental regulation of such ownership, the acceptance of new technologies in the marketplace, and the subsequent growth of superior technologies.

   

• Discussion and conclusions

  I have examined two specific situations, one in the music industry and the other in the software industry, to determine the effect that copying controls have on the emergence, utility, and dissemination of new technologies. In these situations, the rush to prevent copying is highly correlated with the stagnation and death of promising technologies. Further, encouraging free copying and modification is strongly correlated with the widespread dissemination of new technologies and greater innovation [25]. Similar scenarios exist in other industries as well and are not just limited to copyright issues. Consider the biotech industry where gene patenting is rampant: Would abridging the ability of an academic institution or a company to perform research on a given gene help progress in finding a cure for a disease related to the gene?

  In both the music and software industry scenarios presented above, the creators and inventors of the technology made the initial decision (an ethical one, to be sure) to encourage free copying or to abridge it. In the case of the music industry, some of these decisions became law, which has ramifications for the present and the future. Unless the law is repealed, ignored or bypassed (which appears to be case as far as CDRs are concerned, possibly accounting for their popularity), the industry appears to be doomed to repeat its failures just as it did with other digital recording technologies such as DATs, DCCs, and MiniDiscs. In the case of the software industry, the paradigm of freely re-distributing software appears to be becoming more and more acceptable, particularly as a means of marketing, even by mainstream software companies [24]. This has led to software becoming more of a service-oriented industry, to support development, rather than a product oriented one.

  The scenarios presented here do not present a comprehensive picture about intellectual property laws as a whole. They do raise questions of the general mantra chanted by many pro-IP advocates that creativity and innovation cannot occur without controlling copying, modification, and distribution, and that this control generally results in the promotion of "progress of science and useful arts."

  More importantly, the above scenarios illustrate important lessons as to what should be done the next time a new technology to reproduce audio and video recordings emerge, or a way to revolutionise how software is used is developed. It remains to be seen whether the inventors and distributors of new technology will make ethically responsible decisions based on this history.

• The original upstart -- Rachel Chalmers interviews Bruce Perens about his involvement -- with Debian, the LSB, the OSI, and SPI, among other things -- for LinuxWorld. Special guest appearances by Richard Stallman, Eric Raymond, and Tim O'Reilly round out this profile of one of the most peripatetic personalities in the open source movement.(2,800 words) 
• Linux and Decentralized Development by Christopher B. Browne

• Using the Software Peer Review Process to Obtain Measurable Pay Back by Alan N. Pryor,  Eugene G. McGuire
• Lex Networkia Understanding the Internet Community by Edward J. Valauskas
  • For the Internet and its diverse communities, the formalization of its many regulations and rules into a Lex Networkia might be its best hope for survival in the next century. Certainly, Internet experiences and education will slow politicians, legislators, and bureaucrats in their attempts at control. The Internet community already in a fashion has invented an informal Lex Networkia. What is needed is a certain flexible formalization to slow the controlling lunatic fringes in certain traditional governmental agencies around the world. I would hope that we would not need another Martha Siegel or Robert Morris or the United States Congress to force the Internet community to work towards self-governance and self-preservation. Indeed, a unified effort by Internet experienced lawyers, librarians, and programmers can formalize this environment of self-governance in such a way that will please even the most Internet paranoiac and network ignorant and encourage the educational and social activities of thousands of Internet communities. It will be the hardest work of all, but the threats to the Internet will not go away with a carefully programmed robot or smartly worded electronic message.
• The Visible Problems of the Invisible Computer: A Skeptical Look at Information Appliances by Andrew Odlyzko. Thanks to Andrew Odlyzko for this reference. Here is what the author said about OSS:

  To appreciate the wide range of computing that we have, and are likely to have in the future, consider open source software. It is often touted as a proof that a viable competitor to Microsoft's Windows can arise. Yet it seems that that the main lesson to be drawn from the success of Linux and Apache is different. These systems are built by experts to be used by experts. There are many people (although a tiny fraction of the whole population) who know what regular expressions are, and can use text commands to execute programs much faster than a graphical user interface would let them. They also tend to be in charge of important resources such as Web servers, and appreciate (and use effectively) the flexibility that access to source code provides. Apache and Linux are ideal for them. They are not satisfied with the black-box software from commercial vendors. On the other hand, it is doubtful whether those among them who contribute to the code, as opposed to just using it, have the interest in creating the easy to use but much less flexible interface that would appeal to a wider market. That is the province of Microsoft, Apple, and other software companies. (There might be a business opportunity for companies to put simple interfaces on top of Linux for the mass market, though.) These expert users do not account for a large fraction of desktop computers, but do control a large share of computing budgets. They form a substantial market for computers where flexibility is dominant, even at the cost of ease of use.
  

• The Catallactics of Free software

• David Bollier, The Power of Openness: Why Citizens, Education, Government and Business Should Care About the Coming Revolution in Open Source Code Software (10 March 1999).
• Richard P. Gabriel, "Lisp: Good News, Bad News, How to Win Big" -- presents a distinction between two approaches to design: the right thing and worse-is-better.
• Dan Kaminsky, Core Competencies: Why Open Source Is The Optimum Economic Paradigm for Software (2 March 1999).
• Paul Johnson, Commercializing Open Source Software
• Nathan Newman, The Origins and Future of Open Source Software: A NetAction White Paper

• The Case for Government Promotion of Open Source Software A NetAction White Paper by Mitch Stoltz
• The WebCommunicators Issues in research into online journalism and journalists by Mark Deuze
• News Article -- In Support of free music philosophy by Ram Samudrala, 1998-12-04 . Rather interesting pro-bazaar paper.

  Economics in the Bazaar

  I have dealt with the questions of "how will musicians make money" and "won't musicians starve", if they cannot control copying of creative works, extensively in the Free Music Philosophy, the primer on the ethics of "intellectual property", and other missives related to Free Music. Simply put, since a vast majority of musicians don't make a living from music anyway, the Bazaar model isn't going to make things worse and may make things better (because of the increased exposure), relative to what can be done with a major label. I quote from the Free Music Philosophy:

  Musicians currently make money through a variety of sources: sales of records, merchandise and concert tickets, and royalties from commercial airplay. Freeing music will certainly not be detrimental to the sales of merchandise and concert tickets, nor will it affect compulsory or performance royalties. If anything, it will improve sales since people will continue supporting artists they like by going to their concerts and buying their merchandise. Profits from record sales will also not be affected because people will be encouraged to buy directly from the artist for the added bonuses of liner notes, lyrics sheets, and packaging. Thus Free Music can be used as a marketing tool to ensure that musicians do not starve. An approach where people send the artist a "donation", if they found value in the music they copied, is another way to make money in a direct fashion. This could become an ingrained practice in society, like tipping, where even though there is no enforced requirement to tip for various services, people do anyway.

  As the Bazaar model follows its complex trajectory, the economic solutions will automatically arise in a complementary manner. Commerce abhors a vacuum.

  The Bazaar is thriving and the Cathedral is dying

  Imagine a complex adaptive web, where a musician records a song and distributes it with all the tracks. A listener adds reverb and echo to parts of certain tracks which is further distributed to other musicians and they sample or use parts of the modified track. Perhaps the original musician is fed back these modifications and creates a new variation which is further distributed. And so on. Imagine the richness of music that will result. That is the future. It's already happening.

   

Agora

• The Virtual Agora: Online Ethical Dialogues and Professional Communities by Alan Tidwell. First Monday, Vol. 4 No. 7 - July 5th. 1999
• The Agorics Papers -- argument for "distributed resource allocation algorithms that encourage adaptive modification based on local knowledge."

Classic Dilemmas

Garrett Hardin, 1968. "The Tragedy of the Commons," Science, Volume 162, pp. 1243-1248, and at http://dieoff.org/page95.htm

Status Competition

See also Softpanorama Lysenkoism and Pseudoscience Page

[LSH99] Status Competition and the Performance of Work Groups by Christoph H. Loch, Suzanne Stout and Bernardo A. Huberman

Status involves group members evaluating themselves relative to fellow group members according to some shared standard of value. Status has been described in economics, sociology and evolutionary anthropology. Based on this work, the authors treat status and the associated recognition by others as an intrinsic preference of all group members. There is disagreement about whether status competition enhances group performance by pushing group members to work harder, or whether it retards performance by causing unproductive behavior. The authors build a dynamic simulation model of a work group, where members are paid a bonus based on group performance. In addition to compensation, group members value a high status relative to their peers. Status is influenced both by contribution to group output and by non-productive, social activities of status enhancement. Group members allocate their total time between working and non-productive status enhancement, trying to maximize the combined utility from compensation and status rank. They show that status competition can serve to push group members to work hard and perform, provided that it is mainly based on merit. However, if status is also based on political manoeuvring, status competition can lead to low group performance, especially in larger groups. Moreover, group performance may fluctuate and be unstable over time if the result of effort is noisy or if the group does not allow the sharing of ranks. The susceptibility to fluctuation depends on how status is awarded and updated over time. Thus, although a firm may be able to avoid status competition, it may succeed in influencing its effects indirectly. They demonstrate these results analytically and via simulation. 

[Roberts99] Scholarly Publishing Peer Review and the Internet by Peter Roberts. First Monday, Vol. 4 No. 4 - April 5th. 1999 contains interesting criticue of scholarly review process that shed some light on the process of selection of OSS products and the power of site such as Slashdot and Freshmeat (bold is mine -- NNB)

... The process of peer review has attracted its share of criticism from academics (and others) over the years. A number of commentators (e.g., Agger, 1990; Readings, 1994) argue that scholarly refereeing is inherently conservative. Those selected to be referees, at least for 'established' international periodicals, are generally 'recognised' scholars in their field who have already passed through the various publication hoops themselves. Original work which challenges orthodox views, while ostensibly encouraged, is - in practice - frequently impeded by academics who have a stake in keeping innovative critical scholarship out of respected journals. For if a contributor to a major journal rubs against the grain of conventional scholarly wisdom in a given discipline, it is likely his or her submitted manuscript will have to pass through the hands of one or more academics who are prime representatives of prevailing opinion. In Readings' words,

"Normally, those who review essays for inclusion in scholarly journals know what they are supposed to do. Their function is to take exciting, innovative, and challenging work by younger scholars and find reasons to reject it. The same goes for book manuscripts: one receives a hundred dollars for rejecting a manuscript, but if you suggest that it should be published, the check never seems to arrive" [1].

In the case of journals, much depends on the goodwill of editors. Anecdotal tales of being 'set up' by editors abound in academic corridors. Such experiences - where referees known to be especially 'vicious' in their criticisms, or to have strong prejudices against particular perspectives, are selected - can be devastating for beginning scholars setting out on the path to an academic career. Equally, of course, there is considerable satisfaction for authors when they encounter conscientious referees who submit their reports promptly, with balanced comments, fair criticisms, and constructive suggestions for improvement. Indeed, on many occasions, referees perform an invaluable service in identifying faults the author may not have noticed - faults which, if left unattended, could prove professionally embarrassing. Undertaking refereeing duties can be a thankless task (although many authors make a point of acknowledging the helpful comments and constructive criticisms of referees in the final versions of their papers). It takes considerable time and effort to read scholarly papers and to respond to them thoughtfully. Refereeing can, however, also be a fickle, unpredictable and frustrating process for authors.

Agger (1990) maintains that, given the shortage of journal space and the abundance of manuscripts in most fields of study, the balance of power at present rests very much in the hands of those who edit, review for, and produce the journals. There is, his analysis suggests, simply not enough room for everybody - at least not in 'respected', international journals. Agger claims that much of the writing produced by academics is either never published or ends up in local, unrefereed publications. As a result, it remains - as far as the international scholarly community is concerned - largely 'invisible'. With so many academics competing to publish in prestigious refereed journals, traditional canons of collegial respect and scholarly support can sometimes disappear. Agger observes:

"Academic reviewing becomes even nastier in an extremely competitive marketplace.... [I]t is no longer enough in many disciplines to have two strongly positive reviews and one lukewarm one; all three must be sterling given the rate at which writers submit papers for publication. In this climate, reviewers learn (and teach themselves, circularly) not to read generously but to target the smallest issues in their overall evaluation" [2].

Agger argues that the 'value-free' process of scholarly exchanged envisaged by thinkers such as John Stuart Mill has failed to eventuate. Instead, he claims, 'reviewing is frequently done out of petty jealousy, ideological interest or simply incompetence' [3].

THE MERCEDES MENACE

overspent.htm

Postmodern Markets

• Juliet Schor Responds

The Constitution of Status-- Part I

Motivation

Famous Last Words Ed Muth on Linux  Copyright 1999 Michael Robinson

Integration is a big deal for Microsoft for two main reasons:

• Free value.
  Integration means never having to build it twice. Once you create the integration infrastructure, interoperable widgets, and graphical doodads for your first product, all that stuff gets transferred over to your second product for free. Furthermore, because of the interoperability, the first and second product together have a value greater than the sum of the parts. Your costs go down, and the market value goes up. The difference goes to the bank.
• Consumer lock-in.
  If you can control the integration framework, you can keep consumers who buy into it from straying off the ranch. Given the choice between a mediocre but integrated datadiddler, and a better, but completely incompatible datadiddler, they'll go for the integrated datadiddler nine times out of ten.

Linux isn't a product. Linux is an organic part of a software ecosystem. The Microsoft "long-term development road map" had everyone using MSN in the year 2000. Then the ecosystem produced CERN httpd and NCSA mosaic, and we all know what happened next.

Linux doesn't develop according to a proprietary product plan. Linux just automatically grows towards providing the greatest consumer value, because it is consumer built. If anyone anywhere in the ecosystem has a good and valuable idea, the consumers will absorb it into Linux without prejudice.

"We're all in the business of wanting the customer to have the information needed to make informed choices. We haven't seen a flavor of Linux coverage that addresses that. Some criticalness is needed. Some people say positive things about Linux when their message is anti-Microsoft, but I wonder, in 36 months is this the next [Network Computer] or is it a viable OS? We don't see people question the Linux numbers."

This, actually, is true. Press coverage rarely reflects reality because reality is boring. Press coverage needs horse races, conflict, building people up, tearing people down, because spectacle attract readers and readers attract advertising money.

So there is a hysteresis in press coverage. If it isn't a spectacle, the press will ignore it completely. If it is a spectacle, the press will pump it up into an even bigger spectacle.

While the latter is currently the case with Linux, however, this is still completely beside the point.

... ... ...

Out in the real world, however, the best computer scientists in the world give away the results of their work for a number of very sensible reasons:

• They get paid to.
  This covers university professors, graduate students, and researchers at public and private research organizations (unquestionably some of the best computer scientists in the world). This also covers employees of many successful companies for which free software is a part of the business model. There is the "give away the razors" model of companies such as Cygnus. There is the "grow the market" model of companies such as O'Reilly. There is the "commoditize the rest of the value chain" strategy of companies such as Oracle and IBM. And there is the good, old-fashioned, "hurt the competition" strategy of Corel.
• If you want something done right, you have to do it yourself.
  Perhaps the majority of design-by-community software originates because the existing tools for the job didn't meet someone's price/performance standards. Tools are not products. Tools are what you use to produce your products. When someone develops their own tool (as opposed to their own product), they can either sit on it (which helps no one), or they can contribute it to the community software ecosystem (in which case they will directly benefit from any improvements made to the tool by the community). To put it in concrete terms: networking software companies don't develop Samba; network administrators develop Samba.
• It's a cheap substitute for an expensive education.
  Many very good and experienced programmers work on community-based software projects in their spare time to keep their skill-set sharp and up to date. This translates directly into economic benefits at promotion and job-hunting time.
• It feeds the ego.
  If Ed wants to argue that it is foolhardy to develop mission-critical business software based on ego gratification, then I merely offer Dave Cutler as Exhibit "A". Ego-based software development may not be "sensible", but it is firmly based in human nature, so it is at least something you can depend on.

OSS organization and leadership

Linux Today - GNU-Linux -- Leader or Follower by Benjamin Sher

I would agree with your point of view -- Linux is a follower, and the task of re-implementing popular products ASAP although not absolute is very high on the movement agenda. The difference with FreeBSD is that  by-and-large Linux is an anti-Microsoft movement so re-implementation of Microsoft products is the top political issue for the movement.

If re-implementation issues are in the core of the movement, any attempt to move it elsewhere (like your recommendations) are doomed -- that actually make the solution proposed by Benjamin Sher irrelevant.

Another interesting thing is that with attempt of re-implementation of Microsoft products some or most of the advantages of open source are lost. The only thing that remains is the price difference and the creation of the alternative to monopolistic Microsoft. Again -- the main part here is the creation of the alternative to Microsoft -- the movement is fed by anti-Microsoft sentiments and without them investments in Red Hat and other Linux players would be much less.

Also I would like to note that open source movement is going by the "One Microsoft Way" the road of complexity and featurism. And without simplicity the value of open source is much less. My main conviction is that open source movement first of all was and is about simplicity, about attempt to avoid overload connected with what Harvard Business School professor Clayton M. Christensen called the technology mudslide -- a perpetual cycle of extending existing architecture in pursuit of the latest techno fashion that Microsoft represents so well.

Please compare with Linux Today - Wired MS Innovator or Integrator

IBM DeveloperWorks Open source Linux Features - Library - Papers  DeveloperWorks Open source Linux Features - Library - Papers Brooks' Law and open source: The more the merrier? Does the open source development method defy the adage about cooks in the kitchen?Paul Jones
Director of MetaLab, University of North Carolina May 2000

While Raymond tells us that "the more the merrier is the rule in an open source project" and Stallman bemoans the scarcity of programmers, Jamie Zawinski, formerly of Netscape and of the Mozilla project disagrees. "The dynamic of development inside a company is definitely different from development in an open source way. However, I don't think that saying 'adding programmers makes it later' isn't true for open source projects because of their (alleged) lack of deadlines: I think that it's true (in any sense that it is true) only because the definition of 'programmer' is slippery in that case. If you have a project that has five people who write 80% of the code, and a hundred people who have contributed bug fixes or a few hundred lines of code here and there, is that a '105-programmer project?'"

What Zawinski and others have seen is that in such undertakings as the Apache project, Linux Kernel, and other large software projects, the bulk of the work is done by a few dedicated members or a core team -- what Brooks calls a "surgical team."

"In most open source projects," says Zawinski, "there is a small group who do the majority of the work, and the other contributors are definitely at a secondary level, meaning that they don't behave as bottlenecks."

Zawinski goes on: "Most of the larger open source projects are also fairly modular, meaning that they are really dozens of different, smaller projects. So when you claim that there are ten zillion people working on the Gnome project, you're lumping together a lot of people who never need to talk to each other, and thus, aren't getting in each others' way."

Brian Behlendorf of Apache and of Collab.net agrees. "We don't consciously think about it, but I think that the philosophy of keeping things simple and pushing out almost anything extraneous or nonessential to external modules has been followed fairly carefully in Apache. We've also been fairly successful (I think) in 'federalizing' the Apache process to sister projects."

Bezroukov agrees that modularity is essential, but there are limits: "For example if a project logically consists of three parts and we have two developers, than adding third developer can be highly beneficial -- the structure of the project will now correspond to the structure of the team. If the project is decomposable into three major parts and we add fourth developer, the effect will be much less."

Leadership of OSS Projects: The Nature of Good Leadership by Douglas Ort (ort@northnet.org). Thanks to Roman Suzi  for pointing this reference.

Structuring and Funding Free Software Organizations by Pedro F. Giffuni, pfgiffun@bachue.usc.unal.edu.co -- interesting comments about democratic vs. authoritarian structures in a simple experiment as well as insightful comments on the Red Hat IPO (see Midas Touch and Linux IPO Casino for more information about the IPO staff and financial future of Linux companies):

In 1950 Alex Bavelas at MIT (1) was interested in the evolution of strategies and the perceptions of people with different skills that participated in group tasks. An experiment was designed where groups of participants were selectively isolated and a participative card game had to be solved:

As the figures suggest, two structures were tested, the circles represent the participants and the links represent the communication channels. The first structure, where all the participants are organized in a circular fashion was named the "democratic" structure to make emphasis on the similar status of all participants. The second structure, in form
of a star, was called the "authoritarian" structure as one of it's members had communication, and therefore influence, with all the others.

In the first part of the experiment, where all the symbols in the cards were identifiable and had names, members of the authoritarian structure finished first, however they did not feel like winners, they felt they had failed and should have done much better; 94% of the team members recognized the vertex as the leader of the group. The democratic
structure finished afterwards, however they were cheerful, they felt like winners,and they also stated they could have done it better; the leadership seemed to be equally distributed among them.

In the second part of the experiment a "noise" level was added by making the symbols in the cards more complex, some symbols didn't even have names to identify them. The "democrats" didn't vary much their performance, however this time the "authoritarians" didn't finish at all. Most interesting than the result is the fact that the "democratic" group extended their comunication language, inventing new names to some symbols, while the "authoritarian" group incremented the noise level by insulting each other.

 

The real owners of a free software company should be their developers, this means that in order to be consistent companies that make money out of free software should pay at least part of their salaries in shares of the company. In recent weeks some companies, including Red Hat Software, have decided to sell shares to the public as a way to obtain additional resources. In general, it seems like a bad idea; everyone with the least financial background knows this is the most expensive way of getting resources for a company. Investors always expect to receive better dividends from their shares than any financial institution; otherwise they would simply leave their money in a bank. Red Hat has never produced dividends, and I suspect they never will, this probably means that Intel and the other companies that have invested their money there either wanted to lose it, or have some second intentions. The Red Hat case is particularly interesting: in order to produce at least some earnings for their owners they will have to become the number one Linux distribution, something that would be good for the commercial hardware producers that own it now since there would only be one Linux distribution to deal with, but that also means annihilating all other Linux distributors. To make things even more interesting, Red Hat won't be able to differentiate their product significantly due to the GNU license so it will be difficult to kill anyone without making REAL enemies in their own community; this is what I, and probably many people, would call really high financial risk.

Does Free Software Production in a Bazaar Obey the Law of Diminishing Returns -- weak -- archtecturital problems are completely ignored.

Gift Economy and Anarcho-Communism

Beyond Portals and Gifts Towards a Bottom-Up Net-Economy by Felix Stalder. First Monday

Richard Barbrook and Andy Cameron, 1996. "The Californian Ideology," Science as Culture, number 26, volume 6 part 1, pp. 44-72, and at http://ma.hrc.wmin.ac.uk/ma.theory.4.2.db

The Hi-Tech Gift Economy by Richard Barbrook (see also reprint at The High Tech Gift Economy) Richard Barbrook, PhD. is the coordinator and a founding member of the Hypermedia Research Centre at the University of Westminster. He is co-author with Andy Cameron of "The California Ideology", an important critique of West Coast Neo-Liberalism, and has written a number of books including "Media Freedom" (Pluto, 1995). In this piece, excerpted from his forthcoming book "The Holy Fools" (Verso, 1999) Barbrook looks at DIY culture on the internet and other topics.

During the Sixties, the New Left created a new form of radical politics: anarcho-communism. Above all, the Situationists and similar groups believed that the tribal gift economy proved that individuals could successfully live together without needing either the state or the market. From May 1968 to the late Nineties, this utopian vision of anarcho-communism has inspired community media and DIY culture activists. Within the universities, the gift economy already was the primary method of socialising labour. From its earliest days, the technical structure and social mores of the Net has ignored intellectual property. Although the system has expanded far beyond the university, the self-interest of Net users perpetuates this hi-tech gift economy. As an everyday activity, users circulate free information as e-mail, on listservs, in newsgroups, within on-line conferences and through Web sites. As shown by the Apache and Linux programs, the hi-tech gift economy is even at the forefront of software development. Contrary to the purist vision of the New Left, anarcho-communism on the Net can only exist in a compromised form. Money-commodity and gift relations are not just in conflict with each other, but also co-exist in symbiosis. The 'New Economy' of cyberspace is an advanced form of social democracy.

"Cooking Pot Markets: an economic model for the trade in free goods and services on the Internet," by Rishab Aiyer Ghosh,   First Monday, 1997, Volume 3, number 3 (March).

"The Attention Economy: The Natural Economy of the Net", by Michael Goldhaber, First Monday,  1997, Volume 2, issue 4

Marxism, Anarchism and Libertarianism

 Manifesto of the Communist Party by Karl Marx and Frederick Engels.

A spectre is haunting Europe -- the spectre of communism. All the powers of old Europe have entered into a holy alliance to exorcise this spectre: Pope and Tsar, Metternich and Guizot, French Radicals and German police-spies.

Where is the party in opposition that has not been decried as communistic by its opponents in power? Where is the opposition that has not hurled back the branding reproach of communism, against the more advanced opposition parties, as well as against its reactionary adversaries?

Two things result from this fact:

I. Communism is already acknowledged by all European powers to be itself a power.

II. It is high time that Communists should openly, in the face of the whole world, publish their views, their aims, their tendencies, and meet this nursery tale of the spectre of communism with a manifesto of the party itself.

Slashdot Articles ESR Responds to Nikolai Bezroukov -- this discussion contains a lot of information about this three politial movements and probably could be a good start ;-). For example here is one responce:

Anarchism Triumphant Free Software and the Death of Copyright

Non-propertarian production is also directly responsible for the famous stability and reliability of free software, which arises from what Eric Raymond calls "Linus' law": With enough eyeballs, all bugs are shallow. In practical terms, access to source code means that if I have a problem I can fix it. Because I can fix it, I almost never have to, because someone else has almost always seen it and fixed it first.

For the free software community, commitment to anarchist production may be a moral imperative; as Richard Stallman wrote, it's about freedom, not about price. Or it may be a matter of utility, seeking to produce better software than propertarian modes of work will allow. From the droid point of view, the copyleft represents the perversion of theory, but better than any other proposal over the past decades it resolves the problems of applying copyright to the inextricably merged functional and expressive features of computer programs. That it produces better software than the alternative does not imply that traditional copyright principles should now be prohibited to those who want to own and market inferior software products, or (more charitably) whose products are too narrow in appeal for communal production. But our story should serve as a warning to droids: The world of the future will bear little relation to the world of the past. The rules are now being bent in two directions. The corporate owners of "cultural icons" and other assets who seek ever-longer terms for corporate authors, converting the "limited Time" of Article I, §8 into a freehold have naturally been whistling music to the android ear [26]. After all, who bought the droids their concert tickets? But as the propertarian position seeks to embed itself ever more strongly, in a conception of copyright liberated from the minor annoyances of limited terms and fair use, at the very center of our "cultural software" system, the anarchist counter-strike has begun. Worse is yet to befall the droids, as we shall see. But first, we must pay our final devoirs to the dwarves.

...Oscar Wilde says somewhere that the problem with socialism is that it takes up too many evenings. The problems with anarchism as a social system are also about transaction costs. But the digital revolution alters two aspects of political economy that have been otherwise invariant throughout human history. All software has zero marginal cost in the world of the Net, while the costs of social coordination have been so far reduced as to permit the rapid formation and dissolution of large-scale and highly diverse social groupings entirely without geographic limitation [32]. Such fundamental change in the material circumstances of life necessarily produces equally fundamental changes in culture. Think not? Tell it to the Iroquois. And of course such profound shifts in culture are threats to existing power relations. Think not? Ask the Chinese Communist Party. Or wait 25 years and see if you can find them for purposes of making the inquiry.

...28. Eric Raymond is a partisan of the "ego boost" theory, to which he adds another faux-ethnographic comparison, of free software composition to the Kwakiutl potlatch. See Eric S. Raymond, 1998. Homesteading the Noosphere.. But the potlatch, certainly a form of status competition, is unlike free software for two fundamental reasons: it is essentially hierarchical, which free software is not, and, as we have known since Thorstein Veblen first called attention to its significance, it is a form of conspicuous waste. See Thorstein Veblen, 1967. The Theory of the Leisure Class. New York: Viking, p. 75. These are precisely the grounds which distinguish the anti-hierarchical and utilitiarian free software culture from its propertarian counterparts.

An Anarchist FAQ Webpage

• F.1 Are "anarcho"-capitalists really anarchists?

...Political theories should be identified by their actual features and history rather than labels. Once we recognise that, we soon find out that "anarcho"-capitalism is an oxymoron. Anarchists and "anarcho"-capitalists are not part of the same movement or tradition. Their ideas and aims are in direct opposition to those of all kinds of anarchists.

...Furthermore, any such system of (economic and social) power will require extensive force to maintain it and the "anarcho"-capitalist system of competing "defence firms" will simply be a new state, enforcing capitalist power, property rights and law.

...Overall, the lack of concern for meaningful freedom within production and the effects of vast differences in power and wealth within society as a whole makes "anarcho"-capitalism little better than "anarchism for the rich."

...From a wider viewpoint, such a rejection of liberty by right-libertarians is unsurprising. They do, after all, support capitalism. Capitalism produces an inverted set of ethics, one in which capital (dead labour) is more important that people (living labour). After all, workers are usually easier to replace than investments in capital and the person who owns capital commands the person who "only" owns his life and productive abilities. And as Oscar Wilde once noted, crimes against property "are the crimes that the English law, valuing what a man has more than what a man is, punishes with the harshest and most horrible severity." [The Soul of Man Under Socialism]

...Carole Pateman, in her analysis of Liberal contract theory, indicates the religious nature of the "Natural Law" argument so loved by the theorists of the "Radical Right." She notes that for Locke (the main source of the Libertarian Right's Natural Law cult) "natural law" was equivalent of "God's Law" and that "God's law exists externally to and independently of individuals." [The Problem of Political Obligation, p. 154] No role for critical thought there, only obedience. Most modern day "Natural Law" supporters forget to mention this religious undercurrent and instead talk of about "Nature" (or "the market") as the deity that creates Law, not God, in order to appear "rational." So much for science.

Such a basis in dogma and religion can hardly be a firm foundation for liberty and indeed "Natural Law" is marked by a deep authoritarianism:

"Locke's traditional view of natural law provided individual's with an external standard which they could recognise, but which they did not voluntarily choose to order their political life." [Op. Cit., p. 79]

In Section F.7 we discuss the authoritarian nature of "Natural Law" and will not do so here. However, here we must point out the political conclusions Locke draws from his ideas. Pateman summary is worth repeating at length:

Locke believed that "obedience lasts only as long as protection. His individuals are able to take action themselves to remedy their political lot. . . but this does not mean, as is often assumed, that Locke's theory gives direct support to present-day arguments for a right of civil disobedience. . . His theory allows for two alternatives only: either people go peacefully about their daily affairs under the protection of a liberal, constitutional government, or they are in revolt against a government which has ceased to be 'liberal' and has become arbitrary and tyrannical, so forfeiting its right to obedience." [Op. Cit., p. 77]

Chomsky Discussion Salon

"Anarcho-capitalism, in my opinion, is a doctrinal system which, if ever implemented, would lead to forms of tyranny and oppression that have few counterparts in human history. There isn't the slightest possibility that its (in my view, horrendous) ideas would be implemented, because they would quickly destroy any society that made this colossal error. The idea of 'free contract' between the potentate and his starving subject is a sick joke, perhaps worth some moments in an academic seminar exploring the consequences of (in my view, absurd) ideas, but nowhere else."

[Noam Chomsky on Anarchism, interview with Tom Lane, December 23, 1996]

Anarchism vs. anti-Bolshevik Marxism,

How to organize societies.

Marxism and religion

McCain Library Title List -- books connecting Marxism and Christianity. this topic is studied in several university courses. See for example 383I. Christianity and Marxism,   Liberation Theology,  Department of Social and Economic Studies or RELIGION AND THE CULTURE OF THE TWENTIETH CENTURY I  

See also Movements and Issues in World Religions A Sourcebook and Analysis of Developments Since 1945 -- Religion, Ideology, and Politics that contains several essays in Part 4:

• IV. Marxism, Religion, and Politics
  • Marxism and Religion in the West by Paul Mojzes
    Religion and Politics in the USSR and Eastern Europe by Howard L. Parsons
    Religion and Politics in the Asian Communist Nations by David Yu
    Marxism and Religion: The Case of Islam by William R. Darrow
    Theravada Buddhism and Marxism in the Postwar Era by Nation Katz and Stephen D. Sowle

Finding A Social Voice; The Church And Marxism In Africa

DSS Links - Sociology (General)

Jerry Eades and Caroline Schwaller (eds.) Transitional Agendas- Working papers from the Summer School for Soviet Sociologists

• THEORIES OF SOCIAL MOVEMENTS AND THEIR CURRENT DEVELOPMENT IN SOVIET SOCIETY by Sergey Mamay

Etc

• Open-source approach fades in tough times - The ideological purity of the open-source software business is being diluted by a new era of pragmatism as start-ups adjust to the economic slump. Open-source describes a collaborative method of developing software by freely sharing programming code, with no single company owning the rights. Volunteers work on myriad open-source projects, and in many cases companies hoped to harness that talent to compete better with software titans such as Microsoft, with the Linux operating system being the most visible example. On the business end, companies typically seek customers with the free software and derive revenue by selling services and support. But that's proved easier said than done.
• Shared Source vs. Open Source: Panel from OSCon 2001 Transcript - O'Reilly Associates has posted the transcript of the Shared Source vs. Open Source Panel Discussion from the Open Source Conference 2001.
• How Linus Torvalds Found Fun, and a New Operating System - Linus Torvalds is the poster boy of the open source software movement, an arch enemy of Bill Gates and a guy who just wants to have fun. At least that's the message of his recently-published Just For Fun: The Story of an Accidental Revolutionary, in which Torvalds explains to us the humble origins of his Linux operating system.
• Military backs open-source security - Continuing its support of open-source operating systems, the U.S. Department of Defense granted $1.2 million to a community project aimed at adding advanced security features to FreeBSD, an open-source variant of Unix.
• An attempt to document the history of the GPL - The GNU GPL is the fundamental document for Free Software. Because of its importance, it is useful to document its history and evolution, for reference purposes.
• SV.com debate on Open vs. Shared Source ends - The interesting debate at SiliconValley.com, involving Craig Mundie, Bruce Perens, etc. has ended. Mundie does not really answer questions thrown at him but just paraphrases the Microsoft party line.
• Free Software ~ Free Trade? - An examination of the powerful economic forces driving the acceptance of Free Software/Open Source in corporations and businesses. When we realize that Free software is not just a (political) philosophy, or a social or anthropological movement, but an economic force akin to the removal of trade barriers, we can finally understand why its adoption by corporations promises to be a sea-change in the way that software is used. Reviews a business case study of a very large, failed technology project. If you thought the Internet was big ... this is bigger.
• Kudos to open-source - Microsoft Chairman Bill Gates doesn't hate open-source software; he's just concerned about the "Pac-Man-like nature" of the license that governs the distribution of such software. In an exclusive interview, Gates observed that Microsoft routinely shares the source code for its Windows operating system with its partners. In addition, the company uses some open-source software in its Hotmail e-mail service. However, Gates said, "there are problems for commercial users relative to the (GNU General Public License), and we are just making sure people understand the GPL."
• Microsoft license spurns open source - The license of the second beta version of Microsoft's Mobile Internet Toolkit--software used so programmers can create server software to connect with handheld computers over the Internet--prohibits customers from using the Microsoft software in conjunction with "potentially viral software."
• Open Source: Fast, Cheap and Out Of Control - People increasingly identify themselves by what kind of software they use and how that software is configured.
• Microsoft, TCP/IP, Open Source, and Licensing - I worked at Microsoft for ten years, most of it on the core Windows NT/2000 (hereafter referred to as NT) networking code. As such I briefly dealt with the Hotmail team, mostly to hear them complain about the lameness of the telnet daemon in NT (a valid point). I do know that when Microsoft bought Hotmail, the email system was entirely running on FreeBSD, and Microsoft immediately set about trying to migrate it to NT, and it took many years to do so. Now it seems that the transition is not complete. Well, what are you gonna do.
• Decoding the FUD surrounding open source - Contrary to Steve Ballmer's misinformed prognosis, the weight of evidence shows that Linux, and open-source software in general, can in fact coexist with proprietary software. Companies including Oracle, IBM and Hewlett-Packard are successfully using open-source software--including GPL software--with no harmful side effects or infection of their intellectual properties.
• The Rise of "Worse is Better'' - I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford style of design. The essence of this style can be captured by the phrase ``the right thing.'' To such a designer it is important to get all of the following characteristics right...
• An Open Letter to Hobbyists - письмо Билла Гейтса (датировано 1976 г.) любителям компьютеров, которые предпочитали не платить за Altair BASIC
• BSD Unix: Power to the people, from the code - BSD itself wasn't originally free software. Joy sold it, with the University of California's blessing, at a nominal cost only to people or institutions that had already purchased licenses permitting them access to the source code of AT&T Unix (although, in practice, Joy's efforts to verify whether would-be buyers really did own licenses may not have been overly vigorous). But in spirit, Berkeley Unix was indeed free: As Dennis Ritchie, Thompson's collaborator in creating Unix, observes, anyone who wanted to hack on Unix usually had access to the source code, one way or another. And if those hackers sent their modifications to Berkeley, and they were deemed good enough, they became part of a code base maintained by programmers who wanted nothing more than for their software to be widely used, for as low a cost as possible.
• The Bamboo Forest - The metaphor was more apt than I knew. Bamboo falls under a subclass of grasses that display "rhizome" reproductive habits; they are plants that propagate primarily through their root structure, rather than by seed or pollen. There are two main types of bamboo: clumping bamboo, which stays close to home, and so-called running bamboo, which botanists describe with no apparent sense of humor as "rampantly invasive."
• Linus Torvalds at the Villa Montalvo - To the uninitiated, free software sounds like a joke, a late-night psychic friends TV come-on or, at best, a fad for geeks and nerds who have nothing better to do than play with computer code all night long. But to a growing number of technology watchers, free software means much, much more: Its success points toward a possible future in which the simple act of sharing constitutes the bedrock of a new strain of capitalism. By early 2000, talk of initial public offerings, billion-dollar market capitalizations and venture-capitalist shenanigans had become increasingly common wherever free-software hackers hung out. A healthy and growing number of computing cognoscenti were even arguing that, in a truly free market, free software would inevitably dominate.
• Starting points - Free software is free speech. Bill Joy, a programmer* extraordinaire who co-founded the computer workstation manufacturer Sun Microsystems, suggests that that belief is an outgrowth of the academic tradition of sharing research results with others. And that tradition, he observes, is at least 1,000 years old, going back to the founding of what is generally considered to be the first modern European university -- Irnerius's University of Bologna.
• The security implications of open source software - Natalie Whitlock talks about the incongruence of closed security systems, and the open source solution. She discusses Eric Raymond's ideas, the famous "back door" in Microsoft's FrontPage, the concept of peer review, and the open source dilemma that no one is at the helm guaranteeing that everything will be checked. She then follows the idea from theory to practice and talks with leading IT executives about the viability and popularity of secure open source systems.
• Open source around the world - Although the open source community is international, many local characteristics of the community differ across borders. Hackers in Borneo work in a different political and cultural environment than hackers in Japan or Silicon Valley, for example. These differences can affect the international development of the open source community. Maya Stodte looks at development, structure, and community in some of the less-talked about countries around the world.
• How to make money with open-source software - The software may be free, but that doesn't mean you can't make money in open source. Consultant Donald Rosenberg tells how a developer with open-source skills can choose among various business models and licenses. Developers wanting to become software vendors will have to decide how much control they want over their software, from full proprietary protection to a completely open license (GNU General Public License), or degrees in between, such as the Mozilla Public License. Donald introduces you to the key licenses and explains how they differ from one another.
• To open source or not to open source - Open source represents both opportunities and threats that need to be taken into account when planning the future of any software project. Adam L. Beberg examines the times when open source is a good idea, and when it's not, from a business perspective.
• Open source: One agnostic's view - The response of Bruce Perens and nine other notables from the world of open-source software to Microsoft Senior VP Craig Mundie's recent speech will no doubt puzzle those who haven't paid much attention to the subject
• Software-based innovation - Software provides the critical mechanism through which managers can lower the costs, compress the time cycles, and increase the value of innovations. It is also the heart of the learning and knowledge processes that give innovations their highest payoffs. In many cases, software is the core element in process innovations or in creating the functionalities that make products valuable to customers. In others, software is the "product" or "service" the customer actually receives. Software provides the central vehicle enabling the inventor-user interactions, rapid distribution of products, and market feedback that add most value to innovations. Consequently, customers — and the software itself — make many inventions the company's technologists, acting alone, could not conceive.
• Open Source Reality Check - Want to be a hit at the next Linux-related conference? It's easy. Any time anything goes wrong, blame Microsoft. Everyone within earshot will be in hysterics -- every single time. For instance, if you see someone's computer crash, shout, "Hey, is that a Windows machine?" If someone trips while walking, say, "Are those sneakers running on NT?"
• Microsoft's Attack on Open Source: Linus Torvalds Replies - The basic argument seems to be that it's good for the economy to charge for intellectual property, so open source software cannot be good, while Microsoft is the most far-thinking company around and is doing it all for the good of the public. 

Last modified: March 09, 2002