There is a relation between technology and capitalism. And there is a relation between open source and free software movement and so to be called post-capitalism. What is post-capitalistic society and where are these relations?
Capitalism as the social structure was founded in order to support further evolution and development of human race, to support the innovation which was oppressed by the former system. It was brought up by the two industrial revolutions. The technology was obviously the main to blame for the outcoming capitalistic society. The new capitalism was more liberalistic promoting free trade and pushing globalization in order to support further development and growth of technology.
But, it seems like the technology has been pushed so far and so high that the now old capitalism formed to support it starts to act as it\'s oppressor. The world of software technology is the obvious example of it. The first signs of these events can be recognized far back into 70s and 80s when the software technology\'s started to emerge.
Now, the capitalism oppresses the further technology growth by oppressing the development of software. How? By making it proprietary, creating monopoly\'s. To capitalism, everything is property, including software. And that is where the problem is. The software cannot be considered as property, it is more like an information. It is simply too easy to copy it without ANY effort and that is what led to it becoming a commodity which is a reason more why it just cannot be proprietary. If it is considered proprietary and created and used in such manner, we are getting monopolies created, patents issued and other restrictions that do no good to the further development of software technology, but to oppress it.
Look at the capitalistic giant, Microsoft! Imagine that there were no free software movement and open source. Microsoft would be the ultimate monopolist, the whole world would be their empire. In such case, there would be no real progress and innovation because there is no force to drive it.
THAT is the very proof of capitalism being simply too old and incompetent to handle the new technology of today properly, in the information age run by computers and software.
The open source and free software movement are already taking steps further, outgrowing the limitations of the old and incompetent capitalistic system in order to create what may be called a post-capitalism, true liberalistic, society where the technology will be freely developed at the rates the open source software gets developed today.
More to this, open source and free software movement being the major sign is not the only sign of the sickness of capitalism and it\'s fall.
Simply look at the way things are going at this point in history regarding the major events. When there was a war in Iraq, masses of global and organized people, ordinary people like you and me, used internet to start the organized real time and worldwide demonstrations against the war in Iraq. The same happens with any other major event. There is a global network of people united in their fight for freedom and peace. It shows how the technology of today gives the power to the ordinary people instead of power being in hands of a few big shots. And those people, masses, globally networked masses, ask for one thing: FREEDOM!
Their (our) �enemies� are therefore everyone that anyhow try\'s to restrict the freedom and impose the control over them.
The entity\'s that fall into that category include:
the greatest corporations such as Microsoft and oil companies (imposing monopolies and restrictions in order to control as much as possible)
political entities such as USA and European Union (imposing wars such as the one in Iraq, pushing restrictions of freedoms to use and develop technology through software patents etc.)
And when we say �enemy�, we don\'t mean that the corporations, companies and governments as the organizations should be terminated in order for us to have the freedom we deserve nor we in any case mean to fight them with violence acting like terrorists. We should simply raise our voices using the internet and technology in order to change the way these entities function today so that they are no longer the oppressors of freedom, but it\'s supporters.
These global networked movements, such as open source and free software movement are actually forming a third industrial revolution which may crush capitalism as a social structure and finally bring the power to the majority and support the unrestricted growth of technology.
Tuesday, November 28, 2006
Open-source development models fall flat
Typical open-source project development strategies work well for free software but don't flourish in commercial settings, according to one expert.
Jim Herbsleb, a professor at Carnegie Mellon University's International School of Computer Science, part of the Institute for Software Research, previously worked at Bell Labs at Lucent Technologies Inc., where he studied why open-source projects such as Apache have been so successful in employing a distributed development method. He spoke at the Open Source Conference in Toronto this week.
Herbsleb looked at cases where many developers around the world would successfully collaborate on one piece of software. He also examined why this distributed development model hasn't thrived in industry. In fact, Herbsleb said he found that it takes companies more than twice as long to develop software in disparate locations than in one location.
One of the reasons why free and open-source software development has been successful over disparate locations is that the work has been done by the users, and these developer-users determine the functionality, Herbsleb said.
"Because work is done by the users, they're more likely to get the functionality right, so a major class of errors is eliminated," he noted, adding that developers of commercial software are rarely users of the software, and the functionality is determined by project managers.
"Project managers tend to understand purchasing designs -- why companies buy software -- so they'll build a project that plays into those hands," Herbsleb explained. This means that commercial software can be created without fully meeting user requirements. Because free and open-source software developers are its users, they create the functions they specifically need.
But one of the drawbacks to the open-source software development model is that mainstream users often get left behind because the really technical people create the software design functionality for themselves, not for the average user. The geek creed -- "If you can't install it, you don't deserve to use it" -- is still alive in many open-source projects, said Nancy Frishberg who works on user-centered software design in the software division at Sun Microsystems Inc.
As a result, "it is sometimes said [that lack of] usability is the Achilles' heel of open source," said Steve Easterbrook, associate professor in the department of computer science and associate director of the Knowledge and Media Institute at the University of Toronto.
Sun's Frishberg added that the open-source mantra that "everyone can contribute" is actually misleading because adding to an open-source project is basically limited to code, bugs and patches.
Jim Herbsleb, a professor at Carnegie Mellon University's International School of Computer Science, part of the Institute for Software Research, previously worked at Bell Labs at Lucent Technologies Inc., where he studied why open-source projects such as Apache have been so successful in employing a distributed development method. He spoke at the Open Source Conference in Toronto this week.
Herbsleb looked at cases where many developers around the world would successfully collaborate on one piece of software. He also examined why this distributed development model hasn't thrived in industry. In fact, Herbsleb said he found that it takes companies more than twice as long to develop software in disparate locations than in one location.
One of the reasons why free and open-source software development has been successful over disparate locations is that the work has been done by the users, and these developer-users determine the functionality, Herbsleb said.
"Because work is done by the users, they're more likely to get the functionality right, so a major class of errors is eliminated," he noted, adding that developers of commercial software are rarely users of the software, and the functionality is determined by project managers.
"Project managers tend to understand purchasing designs -- why companies buy software -- so they'll build a project that plays into those hands," Herbsleb explained. This means that commercial software can be created without fully meeting user requirements. Because free and open-source software developers are its users, they create the functions they specifically need.
But one of the drawbacks to the open-source software development model is that mainstream users often get left behind because the really technical people create the software design functionality for themselves, not for the average user. The geek creed -- "If you can't install it, you don't deserve to use it" -- is still alive in many open-source projects, said Nancy Frishberg who works on user-centered software design in the software division at Sun Microsystems Inc.
As a result, "it is sometimes said [that lack of] usability is the Achilles' heel of open source," said Steve Easterbrook, associate professor in the department of computer science and associate director of the Knowledge and Media Institute at the University of Toronto.
Sun's Frishberg added that the open-source mantra that "everyone can contribute" is actually misleading because adding to an open-source project is basically limited to code, bugs and patches.
Academic Research Ideology Accords with Open Source
Research
While many research initiatives are well integrated, humanities research sometimes works at cross-purposes with itself. Though its scholars and "mission" generally strive to share their research with one another and the general public, the academic publishing market's policies and practices restrict circulation of, access to, and use of such research. These conflicting movements underline the need for a different model of research and publication. However, in order for Open Source to act as a model for academic publishing, academic administration also needs to change. Currently, academics are offered jobs, tenure, and promotions based on their publishing. Within the requirements for publishing are hierarchies for published materials that view single-authored and printed publications more favorably than electronic or collaborative texts. For Open Source to serve as a valid and useful model for academia, academic standards for hiring and tenure would also need to change to reflect the value of collaborative and non-print works.
Academic Research Ideology Accords with Open Source
The Open Source property model predicates on a field of shared knowledge that developers use to create their own works. Azeem Azhar explains this idea, dubbed "commons-based peer production":
The commons refers to the sharing of the underlying code or the output that is open to all, akin to the public land that farmers once grazed their livestock upon. Peer production means that producers participate for their own varied reasons and in ad hoc ways, not necessarily via legal contract or management fiat. (2004)
Academic research works in similar ways—researchers contribute to journals and publish books that can be used by other scholars to produce more research. The general "body of knowledge" for a discipline covers all contributions to the discipline, and analogizes to the "commons" in the passage above. Academics contribute to this commons because they benefit from it simultaneously.
Gift cultures. Raymond suggests that the parity between Open Source and academia stems from their economic models; specifically, he notes that both systems are gift cultures:
In populations that do not have significant material-scarcity problems with survival goods [. . .] abundance makes command relationships difficult to sustain and exchange relationships an almost pointless game. In gift cultures, social status is determined not by what you control but by what you give away [. . .] (2001, p. 81)
The economic conditions shaping both fields allow for the development of gift cultures, in which members give away knowledge and acquire reputation based on their generosity. Raymond also suggests that this model's ubiquity makes it "the globally optimal way to cooperate for generating (and checking!) high quality creative work" (2001, p. 107). Both academia and Open Source development benefit from the quality control created by gift cultures.
As a gift culture, academia usually uses citation to give scholars credit for their work. However, most academic citation methods serve to further re-inscribe outdated notions of individual authorship even for collaboratively authored works. For instance, some systems focus only on the first author, affording less credit to any additional authors for the work. Further, many academic departments do not have guidelines for collaboratively written works so that collaboratively written works often do not factor, or factor much less for issues like tenure and promotion. In Singular Texts/ Plural Authors: Perspectives on Collaborative Writing, Lisa Ede and Andrea Lunsford explore both issues of collaborative writing and their own struggles for credit for work they wrote together (1990). Open Source, however, provides a model in which individual and collaborative authors are given equal credit for their work.
Distributed control. Academia and Open Source also benefit from their distributed systems of control. Unlike hierarchical research projects, distributed projects lead to a wide range of solutions. For instance, both academia and Open Source development models allow for divergences. In the Open Source model, programmers who disagree with a project's direction can start a splinter group, or "fork," that takes the application in a new direction. Academia allows for similar splits in its conversation. Such splits differ distinctly from corporate research or other forms of collaborative work that use more centralized control structures.
While many research initiatives are well integrated, humanities research sometimes works at cross-purposes with itself. Though its scholars and "mission" generally strive to share their research with one another and the general public, the academic publishing market's policies and practices restrict circulation of, access to, and use of such research. These conflicting movements underline the need for a different model of research and publication. However, in order for Open Source to act as a model for academic publishing, academic administration also needs to change. Currently, academics are offered jobs, tenure, and promotions based on their publishing. Within the requirements for publishing are hierarchies for published materials that view single-authored and printed publications more favorably than electronic or collaborative texts. For Open Source to serve as a valid and useful model for academia, academic standards for hiring and tenure would also need to change to reflect the value of collaborative and non-print works.
Academic Research Ideology Accords with Open Source
The Open Source property model predicates on a field of shared knowledge that developers use to create their own works. Azeem Azhar explains this idea, dubbed "commons-based peer production":
The commons refers to the sharing of the underlying code or the output that is open to all, akin to the public land that farmers once grazed their livestock upon. Peer production means that producers participate for their own varied reasons and in ad hoc ways, not necessarily via legal contract or management fiat. (2004)
Academic research works in similar ways—researchers contribute to journals and publish books that can be used by other scholars to produce more research. The general "body of knowledge" for a discipline covers all contributions to the discipline, and analogizes to the "commons" in the passage above. Academics contribute to this commons because they benefit from it simultaneously.
Gift cultures. Raymond suggests that the parity between Open Source and academia stems from their economic models; specifically, he notes that both systems are gift cultures:
In populations that do not have significant material-scarcity problems with survival goods [. . .] abundance makes command relationships difficult to sustain and exchange relationships an almost pointless game. In gift cultures, social status is determined not by what you control but by what you give away [. . .] (2001, p. 81)
The economic conditions shaping both fields allow for the development of gift cultures, in which members give away knowledge and acquire reputation based on their generosity. Raymond also suggests that this model's ubiquity makes it "the globally optimal way to cooperate for generating (and checking!) high quality creative work" (2001, p. 107). Both academia and Open Source development benefit from the quality control created by gift cultures.
As a gift culture, academia usually uses citation to give scholars credit for their work. However, most academic citation methods serve to further re-inscribe outdated notions of individual authorship even for collaboratively authored works. For instance, some systems focus only on the first author, affording less credit to any additional authors for the work. Further, many academic departments do not have guidelines for collaboratively written works so that collaboratively written works often do not factor, or factor much less for issues like tenure and promotion. In Singular Texts/ Plural Authors: Perspectives on Collaborative Writing, Lisa Ede and Andrea Lunsford explore both issues of collaborative writing and their own struggles for credit for work they wrote together (1990). Open Source, however, provides a model in which individual and collaborative authors are given equal credit for their work.
Distributed control. Academia and Open Source also benefit from their distributed systems of control. Unlike hierarchical research projects, distributed projects lead to a wide range of solutions. For instance, both academia and Open Source development models allow for divergences. In the Open Source model, programmers who disagree with a project's direction can start a splinter group, or "fork," that takes the application in a new direction. Academia allows for similar splits in its conversation. Such splits differ distinctly from corporate research or other forms of collaborative work that use more centralized control structures.
Unhappiness drives open source adoption
A common reason why more governments and enterprises around the world are moving to open source software is unhappiness, it was revealed during a panel discussion at the LinuxWorld Conference in San Francisco yesterday.
Google Inc open source programs manager Chris DiBona said the search giant has stuck with Linux throughout the company's life, in part, because it was unhappy with the terms of another software company.
For instance, DiBona pointed out that if Google used Windows, or any other non-open source software program, to make changes to that system he would be required to essentially ask permission from that vendor. "Why should we hand over the control of our software support to another company?"
Other benefits of Linux for Google was being able to determine exactly what was running on any server at any given time and being able to plan what kind of power that machine would have, according to DiBona. This would not be possible, he said, using proprietary software. "Worse than that, if I want to expand ... I have to rip things out. But why would I want to spend money on something for which I only want to use a small part?"
While showing a slide show of Google's hardware evolution, which began humbly with an odds-and-ends collection of "spare computers that were lying around Stanford" (hobbled together, literally, with pieces of Lego and duct tape) and ended with a present-day photo of Google's current server room (darkened to the point of being indistinguishable, for competitive reasons), DiBona said Google has used Linux all the way.
Research firm and LinuxWorld sponsor IDC projects Linux revenue would reach $35bn worldwide within the next three years. "It's growing twice as fast as Windows," said CEO of Open Source Development Labs Inc Stuart Cohen. "If you're skeptical, just visit the SAP booth -- here for the first time at LinuxWorld."
More governments in the US and elsewhere are adopting Linux and to help pave the way are striking down software patent legislation, said Red Hat VP of corporate affairs Tom Rabon. During the past few months, governments in India and the European Union have struck down software patents and the US Congress is currently considering patent reform, Rabon said.
In addition to reducing total IT purchase costs, governments in several countries have opted for Linux as an economic development decisions, he said. "They hope that open source would encourage [the] growth of an indigenous software industry," he said.
Also, "Unhappiness with the United State's lead in software" is driving some countries' governments to move toward open source, Rabon said. Some governments see open source as "a way to move away from US-based software company products," he said.
More than 125 national open-source policies have been proposed worldwide during the past few years, Rabon said. Governments are using open source to run applications, entire agencies and, in some cases, entire governments. He highlighted the Venezuelan government's decree on July 13 that within 90 days all government institutions in the country must present a migration plan to move to open source software. "This is a presidential mandate ... so we think it's going to happen," he said.
Google Inc open source programs manager Chris DiBona said the search giant has stuck with Linux throughout the company's life, in part, because it was unhappy with the terms of another software company.
For instance, DiBona pointed out that if Google used Windows, or any other non-open source software program, to make changes to that system he would be required to essentially ask permission from that vendor. "Why should we hand over the control of our software support to another company?"
Other benefits of Linux for Google was being able to determine exactly what was running on any server at any given time and being able to plan what kind of power that machine would have, according to DiBona. This would not be possible, he said, using proprietary software. "Worse than that, if I want to expand ... I have to rip things out. But why would I want to spend money on something for which I only want to use a small part?"
While showing a slide show of Google's hardware evolution, which began humbly with an odds-and-ends collection of "spare computers that were lying around Stanford" (hobbled together, literally, with pieces of Lego and duct tape) and ended with a present-day photo of Google's current server room (darkened to the point of being indistinguishable, for competitive reasons), DiBona said Google has used Linux all the way.
Research firm and LinuxWorld sponsor IDC projects Linux revenue would reach $35bn worldwide within the next three years. "It's growing twice as fast as Windows," said CEO of Open Source Development Labs Inc Stuart Cohen. "If you're skeptical, just visit the SAP booth -- here for the first time at LinuxWorld."
More governments in the US and elsewhere are adopting Linux and to help pave the way are striking down software patent legislation, said Red Hat VP of corporate affairs Tom Rabon. During the past few months, governments in India and the European Union have struck down software patents and the US Congress is currently considering patent reform, Rabon said.
In addition to reducing total IT purchase costs, governments in several countries have opted for Linux as an economic development decisions, he said. "They hope that open source would encourage [the] growth of an indigenous software industry," he said.
Also, "Unhappiness with the United State's lead in software" is driving some countries' governments to move toward open source, Rabon said. Some governments see open source as "a way to move away from US-based software company products," he said.
More than 125 national open-source policies have been proposed worldwide during the past few years, Rabon said. Governments are using open source to run applications, entire agencies and, in some cases, entire governments. He highlighted the Venezuelan government's decree on July 13 that within 90 days all government institutions in the country must present a migration plan to move to open source software. "This is a presidential mandate ... so we think it's going to happen," he said.
How Linux and open-source development could change the way we get things done
An army of disheveled computer programmers has built an operating system called Linux based on a business model that seems to have been written with everything but business in mind. Instead of charging customers as much as the market can bear, Linux is given away for free; instead of hiding information from competitors, Linux programmers share their work with the world; instead of working for money, Linux developers are motivated primarily by adrenaline, altruism, and the respect of their peers.
Despite this unusual foundation, Linux is booming and even beginning to challenge Microsoft's control of the operating system industry. Linux may eventually pull the rug out from under the richest company in the world. It may not. But no matter what happens, it has already shown that money doesn't have to make the world, even the business world, go round. In fact, as technology improves and computers connect and create even more of our society, the principles of cooperation and collaboration that drive Linux may well spread to other fields: from computers, to medicine, to the law.
The Source
The Linux movement kick-started in 1991 when Linus Torvalds, a puckish graduate student at the University of Helsinki, got frustrated with his rickety computer. Refusing to buy another one, he wrote a new operating system--the core programs by which applications (like Microsoft Word) talk to hardware (like microprocessors). When finished, instead of running down to the patent office, he posted his code on the Internet and urged other programmers to download it and work with him to improve it. A few emailed back suggestions, some of which Torvalds took. A few more wrote the next day and a couple more the day after that. Torvalds worked constantly with these new colleagues, publicly posting each improvement and delegating responsibility to more and more programmers as the system grew. By 1994, Linux (a combination of "Linus" and "Unix," another operating system) had 100,000 users. Today, it has between 10 and 20 million users and is the fastest growing operating system in the world.
But Linux (rhymes with 'cynics') is different from almost every other operating system available. For one thing, it's downloadable for free straight off the Web. It's also open source, meaning that the source code, the program's all-important DNA, is open for anyone to look at, test, and modify. Most software is developed so that only the original authors can examine and change the code; with open-source models, however, anyone can do it if they have a computer and the right intuition.
To see the power of this model, consider what happens when you're running Microsoft Windows or Macintosh OS and your computer crashes: You stamp your feet and poke a twisted paper clip into a tiny reset button. You probably don't know what happened and it's probably going to happen again. Since you've never seen the source code, it probably doesn't even occur to you that you could fix the problem at its root. With Linux, everything's transparent and, even if you aren't an expert, you can simply post your question on a Linux-help Web page and other users can usually find solutions within hours, if not minutes. (The amorphous Linux community recently won InfoWorld's Product of the Year award for Best Technical Support.) It's also entirely possible that someone--perhaps you--will write some new code that fixes the problem permanently and that Linux developers, led by Torvalds, will incorporate into the next release. Presto, that problem's fixed and no one will need paper clips to fix it again.
To make another analogy, fixing an error caused by a normal software product is like trying to fix a car with the hood welded shut. With Linux, not only can you easily pop the hood open, there is extensive documentation telling you how everything works and how it all was developed; there's also a community of thousands of mechanics who will help you put in a new fuel pump if asked. In fact, the whole car was built by mechanics piecing it together in their spare time while emailing back and forth across the Web.
The obvious threat to this type of open development is appropriation. What if someone lifts all the clever code off the Web, copyrights it, and sells it? What if someone takes the code that you wrote to fix your crashed computer (or busted fuel pump), copyrights it, and markets it for $19.95? Well, they can't. When Torvalds created Linux, he protected it under the GNU General Public License, an intriguing form of copyright commonly known as copyleft. Under copyleft, anyone who redistributes the program, with or without changes, must pass along the freedom to further copy, change, and distribute it. Theoretically one can download Linux off the Web, add a string of useful features, and try to sell it for $50. But anyone who buys this new version can just copy it, give it away, or sell it for a dollar, thus destroying the incentive for piracy. An equivalent would be if I were to write the following at the end of this article: "Verbatim copying and redistribution of this entire article is permitted in any medium provided this notice remains at the end."
Use the Source
From the Oxford English Dictionary to hip-hop music, open-source development has always been with us to some degree. Since the mid-19th century, contributors to the OED have defined words and sent them to a centralized location to be gathered, criticized, sorted, and published. With music, as long as you stay within certain copyright laws, you can take chunks of other people's compositions and work them into your own. Most academic research is also built on open-source cooperation. Even the compact fluorescent light bulb above my head comes from data shared by researchers over centuries about electricity, properties of glass, and centralized power.
But still, most business isn't done with open source. Coca-Cola keeps its formula secret, Microsoft won't tell you how it builds its programs, and when a researcher for Ford suddenly stumbles upon the means to a more efficient fuel pump, she doesn't reflexively email her friend at Honda with a precise description of her discovery. A great deal of scientific and medical research is also done through closed source as individual laboratories race each other to determine who'll be the first to find the answer and earn the patent.
But two extraordinary changes are making open source substantially more plausible as a development and research model for 2000 than it was for 1990--and they'll make it even more so for 2010. First, the Internet. Today, I can open my Web browser and communicate instantly with Burmese refugees or writers working on projects similar to mine. Secondly, computer power has been increasing exponentially for generations and will probably continue to do so--in large part because every time you build a faster computer it allows you to build a faster one still. It's difficult to overestimate the change. The standard laptop to which I'm now dictating this article (with technology unavailable just two years ago) has more power than almost any computer owned by the government a decade ago. In four years, it could well be obsolete. As author Ray Kurzweil and others have pointed out, if cars had improved as much over the past 50 years as computers, they'd cost less than a nickel and go faster than the speed of light.
Intellectual and Physical Properties
This rate of progress is critical because the advantages of open-source development depend on the powers of technology and the balance between what can be done through thinking and what has to be done by building. Every product has certain intellectual components and certain physical components built into it. With a car, for example, the intellectual component is the thought about how to build it, how to set up the assembly lines, and how to process data you have on different kinds of tires. The physical components include the actual rubber in the tires, the machines that ran the tests, the operation and maintenance of factories.
Faster computers and increased connectivity are drastically changing the relationship between these components in two ways. First, some things that used to require physical components no longer do. You may not have to buy rubber to test the tires if you can just run a simulator online. (The 777 project at Boeing was designed so that nothing physical was produced before the plans hit the factory floor.) Second, connectivity makes the flow of information much faster and smoother and greatly facilitates the sharing of ideas and data. There is a saying known as "Linus' law" that "given enough eyes, all bugs are shallow." In other words, given enough people working on them, all problems are solvable. And the Internet has not only helped coordinate a lot more eyes: in some ways, it's given everyone glasses.
Open-source development benefits from this transition because its advantages are almost all in the realm of intellectual property. Open source improves communication and facilitates sharing ideas. But it doesn't mean that you can buy a ton of concrete for free or drive a nail into a wall without a hammer. This is why open source has come first and most prominently to computer programming: a profession where almost all of the development is intellectual, not physical, and where people have been connected over the Internet for more than 20 years. Programming also employs highly specific, common tools--computers--that a fairly large number of people have access to and that some people, such as university students, can even access for free. If a solution or improvement is found, nothing additional needs to be built; code just needs to be entered and then downloaded.
But there is still one great problem standing firmly in the way of even the most modern open-source software development project. As a 21-year-old Bill Gates asked in an angry letter to open-source programmers in 1976: "One thing you do is prevent good software from being written. Who can afford to do professional work for nothing?"
Microsoft's empire, and a great deal of the rest of our society, is built upon the assumption that there isn't an answer to this rhetorical question. To survive, organizations need to patent their information, protect their secrets, and earn as much money as they can. But the success of Linux shows that there's a way around that model. Something extraordinary has been built with a completely different set of rules. I asked David Soergel, a researcher in the department of genetics at Stanford, whether people could use the open-source model to develop medicines. "My first reaction: they'd rather get paid, and if they were any good at it, then they would be paid by somebody. My second reaction: wait a minute, that argument obviously fails for software."
Money for Nothing
Naive as it may be to think that people aren't motivated by money, it is just as naive to think that people are only motivated by money. People are motivated by a variety of factors: money, recognition, enjoyment, a belief that one is doing something good for the world, and so on. We each weigh these factors and make decisions based on our perceptions of their relative importance. At different points in our lives, we give different factors different weights. When we're poor, we tend to value simply high-paying work more than we do when we're well-off; it usually takes a high-paying job to get someone to do something really boring and it generally takes a very fulfilling job to get someone to work for less than what he should normally be able to earn.
Since people working on open-source projects generally earn nothing, or very little, there need to be other incentives. In Linux, there seem to be principally three. First, enjoyment. Computer programming can be addictive, exciting, and extraordinarily intense. Linux can be particularly enjoyable because almost every problem solved is a new one. If your Windows machine crashes, fixing the problem generally entails tediously working through scores of repair procedures which you may have used a thousand times. If A fails, try B. If B fails, try C. If a Linux computer crashes, anyone who repairs it is not only working on that one specific machine, he's finding a solution for the whole Linux community.
Eric Roberts, a computer science professor at Stanford, once explained to The New York Times that people in the profession must be "well trained to do work that is mind-numbingly boring." This is particularly true of work on most closed-source systems where programmers must continually reinvent the wheel. But with open-source projects, the things that need to be done haven't been done before. According to one only slightly hyperbolic programmer, Ali Abdin, writing to a Linux news group about how he felt after creating his first open-source project: "The feeling I got inside when I knew that I had some code out there that I can share with people is indescribable... I felt on top of the world, that I can program anything...I felt as mother would feel giving birth to a child, giving it life, for the first time."
Secondly, and similarly, Linux programmers are motivated by a feeling that they are changing the world and developing an operating system that really works. Torvalds laid out this philosophy well in a speech this summer: "I don't resent Microsoft for making lots of money. I resent them for making bad software."
Thirdly, but most significantly, Linux programmers seem motivated by prestige and, in particular, respect from their peers. Having "hacked the kernel" (contributed to the core of the operating system) gives programmers a certain stature--much as completing a four-minute mile does among runners--and, since the program is open source, everyone knows exactly who contributed what. I was once introduced to a programmer described as "the guy who wrote all the Ethernet device drivers!" as though I was meeting Jonas Salk "who came up with the cure for polio!" And, in fact, Linux programmers often discuss their work as falling in the tradition of eminent scientists. As three well-known programmers put it in the introduction to their book Open Sources: "It would be shortsighted of those in the computer industry to believe that monetary reward is the primary concern of open source's best programmers... These people are involved in a reputation game and history has shown that scientific success outlives financial success... When the history of this time is written a hundred years from now, people will perhaps remember the name of Bill Gates, but few other computer industrialists. They are much more likely to remember names like... Linus Torvalds."
Importantly, this philosophy may well be helping Linux develop creatively. There is a great deal of psychological research that shows that people actually do more creative work when they aren't motivated primarily by money. Tell a child that you'll pay her for reading a book and she'll read it with little imagination. Have one group of college poets think about getting rich and famous through their writing, according to research done by Harvard Professor Teresa Amabile, and they tend to turn out less creative work than a second group that's just asked to write poems. Is it possible that Linux programmers created such an extraordinary operating system in part because they were driven by other factors and weren't doing it for the money? I asked Professor Amabile if the implications of her research cross over to open-source programming and whether it could explain some of the remarkable innovations that have come from people working without pay. "Yes," she responded, "this [would be] entirely consistent."
Making free software affordable
Still, Linux programmers are not completely locking themselves out of the economy and there's a second response to Gates' rhetorical question: If your core open-source project is successful enough, it's possible to eventually make money off of it indirectly. No, it's not possible to make as much money as a proprietary company can--open source and copyleft will ensure this--and there's always going to be an astounding amount of work that has to be done without financial reward. But open-source programmers don't have to starve.
The trick to making money off Linux, or any open-source development, is to profit off of derivatives. No one actually makes money off the Linux code, but they can make money by offering technical support or helping customers install the program. Companies that do this follow a well-trodden path: give something away in order to sell something else. This is what cellular phone companies do when they give you the actual telephone handset for free if you agree to pay for using it a certain number of minutes a month. We do the same thing with the Monthly's Web page. We post some articles (giving them to readers for free) in the hope that visitors' interest will be piqued and that they'll subscribe.
Red Hat, the best-known Linux company, sells the operating system and other open-source programs in a box for $80, though you can download their product for free from redhat.com. Their revenue comes from the technical support they offer and from consumers' need for trust. It's much less unsettling to buy a program like Linux if you get it shrink-wrapped with a manual than if you have to download both. VA Linux, another well-known company, sells Linux hardware: You choose the memory and the motherboard; it builds you a computer.
Has the money these companies brought into the open-source movement corrupted it and made it more like the traditional model that Microsoft uses? Surely, there are a lot of people doing promotional and administrative work at Red Hat for the money and there are probably even some people working on Linux for Red Hat because they get paid a lot to do it (the company hires programmers to write code that anyone, including Red Hat's competitors, can use). But programmers mostly see the money as an added and surprising plus, and Linux is still driven by adrenaline, altruism, and peer recognition.
While it is possible that this could change, it hasn't so far. I asked Richard Stallman--the creator of copyleft, as well as many of the programs that run with the Linux through a system called GNU, and the man often considered to be the father of the open-source movement--whether he thought that money would change the attitudes of people who used to work on GNU/Linux without being paid. "In general, I don't think that wealth will make a hacker into a worse person. It would be more likely to enable the hacker to spend more time volunteering for free software instead of on work for pay."
This point is particularly germane because most open-source programmers have always had to work other jobs, and many have only been able to contribute to the project during the evenings or when their employers weren't looking. Linus Torvalds, for example, helps design microprocessors for a company called Transmeta in the daytime and does all his Linux coding after work. When I asked John Hall, vice president of VA Linux, what motivates programmers, he responded: "For some, it's altruism. For some, it's fame. For some, it's religion. For a very few, it's money."
So what's next?
To determine where open source is likely to move next, one has to imagine a scenario where these obstacles can be overcome. A project would need to be fun, or at least rewarding, to get going and it would have to primarily pose intellectual, not physical, challenges. Once it began to move, derivative financial incentives could help push it along. There also has to be a certain amount of luck, particularly with regard to organization. It's hard enough to get six people to agree to a restaurant for dinner; it's much harder to coordinate thousands of people known to each other only by email addresses. Linux has gotten around this latter problem in no small part because of Torvalds himself. He is a benevolent dictator who has earned the trust and respect of virtually everyone on the project. He's a relaxed, friendly, funny guy whose strength of character keeps his distended organization free from the internal battles that sink so many others. He also has learned how to delegate and has developed a core of equally well-respected close associates who coordinate different parts of the project.
One intriguing possibility for future open-source development comes from medicine, an area where people can become passionate and where intellectual components can far exceed physical components. Consider a smart doctor who loses a friend to rare disease X and decides to devote her life to finding a cure. Ten years ago, trying to develop anything more than a local network to collaboratively design a drug to cure the disease would have been extremely difficult. Communication would have had to be done over the phone or with photocopies slowly and expensively mailed. It made much more sense to have small groups of developers working together in laboratories, foundations, or universities.
Today the possibilities for open collaboration have improved. An ambitious doctor can network online with other researchers interested in disease X and, at the least, can quickly exchange data about the newest research techniques. In fact, there are already medical networks that pass around information about acute medical cases, using email and computers that can automatically send out patient files over a network and put X-rays into the overnight mail.
Now think another decade ahead when everyone will have high-speed Internet lines at least 500 times as fast as standard connections today (this will probably happen in three years), where it is fairly likely that we all will be able to simulate the movement of disease X online, and where it will surely be possible for medical students to run tests that approximate the human immune system on high-powered laboratory computers. Now the same doctor can farm out parts of the project to interested collaborators, many of whom have also lost friends to X and are passionate about finding a cure. If the coordinator is a good organizer and can hold people together the way that Torvalds has, the organization could grow, attracting even more people to join the collaborative effort with each success. Every breakthrough or improvement in the model could be posted online so that other participants could begin work on the next challenge. If a sample test is performed, data could be transferred to the Web simultaneously.
Eventually a prototype could be developed and adopted by an established drug company (or perhaps even a non-profit company, funded by foundations, that specializes in distributing open-source drugs and selling them at minimal costs) that licenses the product with the FDA, runs it through the necessary tests, and then manufactures, distributes and sells it--keeping prices relatively low both because no company would have exclusive copyrights and because research costs (drug companies' largest expense) would be drastically reduced.
Law
A real-life example of another possible opportunity for open source comes from Harvard where law Professors Larry Lessig and Charles Nesson have started the Open Law Project, an attempt to try cases using the open-source model. Interested people sign into the Website, read what other contributors have written, and help to develop arguments and briefs. According to the site description, "what we lose in secrecy, we expect to regain in depth of sources and breadth of argument." The program is run under the same sort of benevolent dictatorship model as Linux, with Lessig serving as chief. People brainstorm, debate, and then Lessig synthesizes and writes the briefs. Currently, the group is constructing arguments challenging, appropriately enough, the United States Copyright Extension Act.
There are great advantages to this model for law: The problems faced by lawyers are mostly intellectual, not physical; there is an abundance of people (especially law students) who are potentially willing to work on the projects for free; and there is the powerful draw of doing something you believe is a public service. If you don't agree with current copyright laws, join the group and figure out how to change them.
Of course, open-law will never be able to handle certain kinds of cases. As Nesson said to me, "open-law is not conducive to ambush." If you need to rely on secret arguments or evidence that the other side doesn't know about, you're not going to post everything on the Net. But if you just need to develop the best argument and rely on increased information flows, the model could work quite well.
Future
It is very difficult to determine exactly where open-source projects will take off next. So much depends on the personalities of the coordinators and the excitement they are able to generate; a great deal also depends on the different ways that technology develops and the way that different markets and research fields change. For some organizations, open-source development will make more sense in a couple of years than it does now. For others, it will make less. But the overall trends of technology are likely to push open source closer and closer to the mainstream.
Imagine a scale with all the advantages of a proprietary model on the left and all the advantages of an open-source model on the right. Pretend everybody who wants to solve a problem or build a project has a scale like this. If it tips to the left, the proprietary model is chosen; if it tips to the right, the open model is chosen. Now, as connectivity increases with the Internet, and computer power increases exponentially, more and more weight accumulates on the right. Every time computer power increases, another household gets wired, or a new simulator is built online, a little more weight is added to the right. Having the example of Linux to learn from adds some more weight to the right; the next successful open-source project will add even more.
Not enough is added to the right side to tip the scale for everybody and everything, but open source is presently growing and it should only continue that way. Netscape has made its Web browser open source. Sendmail, the program that routes most of our email, is open source. Most Web sites use an open-source program called Apache at their core. Even some microchip developers are starting to use open source.
Perhaps the next boom in open source will come from the law; perhaps from drug X; perhaps it will be something entirely different. Although it's difficult to tell, it is quite likely that the scale is going to tip for some projects and that there will be serious efforts at open-source development in the next decade. Moreover, it's quite likely some of these projects will work. Open source has created the fastest growing operating system in the world and it's done so by capitalizing on changes in technology that will almost certainly seem commonplace in a decade or two. Linux will continue to grow; but 10 years from now, it will probably no longer be the largest open-source project in the world.
Despite this unusual foundation, Linux is booming and even beginning to challenge Microsoft's control of the operating system industry. Linux may eventually pull the rug out from under the richest company in the world. It may not. But no matter what happens, it has already shown that money doesn't have to make the world, even the business world, go round. In fact, as technology improves and computers connect and create even more of our society, the principles of cooperation and collaboration that drive Linux may well spread to other fields: from computers, to medicine, to the law.
The Source
The Linux movement kick-started in 1991 when Linus Torvalds, a puckish graduate student at the University of Helsinki, got frustrated with his rickety computer. Refusing to buy another one, he wrote a new operating system--the core programs by which applications (like Microsoft Word) talk to hardware (like microprocessors). When finished, instead of running down to the patent office, he posted his code on the Internet and urged other programmers to download it and work with him to improve it. A few emailed back suggestions, some of which Torvalds took. A few more wrote the next day and a couple more the day after that. Torvalds worked constantly with these new colleagues, publicly posting each improvement and delegating responsibility to more and more programmers as the system grew. By 1994, Linux (a combination of "Linus" and "Unix," another operating system) had 100,000 users. Today, it has between 10 and 20 million users and is the fastest growing operating system in the world.
But Linux (rhymes with 'cynics') is different from almost every other operating system available. For one thing, it's downloadable for free straight off the Web. It's also open source, meaning that the source code, the program's all-important DNA, is open for anyone to look at, test, and modify. Most software is developed so that only the original authors can examine and change the code; with open-source models, however, anyone can do it if they have a computer and the right intuition.
To see the power of this model, consider what happens when you're running Microsoft Windows or Macintosh OS and your computer crashes: You stamp your feet and poke a twisted paper clip into a tiny reset button. You probably don't know what happened and it's probably going to happen again. Since you've never seen the source code, it probably doesn't even occur to you that you could fix the problem at its root. With Linux, everything's transparent and, even if you aren't an expert, you can simply post your question on a Linux-help Web page and other users can usually find solutions within hours, if not minutes. (The amorphous Linux community recently won InfoWorld's Product of the Year award for Best Technical Support.) It's also entirely possible that someone--perhaps you--will write some new code that fixes the problem permanently and that Linux developers, led by Torvalds, will incorporate into the next release. Presto, that problem's fixed and no one will need paper clips to fix it again.
To make another analogy, fixing an error caused by a normal software product is like trying to fix a car with the hood welded shut. With Linux, not only can you easily pop the hood open, there is extensive documentation telling you how everything works and how it all was developed; there's also a community of thousands of mechanics who will help you put in a new fuel pump if asked. In fact, the whole car was built by mechanics piecing it together in their spare time while emailing back and forth across the Web.
The obvious threat to this type of open development is appropriation. What if someone lifts all the clever code off the Web, copyrights it, and sells it? What if someone takes the code that you wrote to fix your crashed computer (or busted fuel pump), copyrights it, and markets it for $19.95? Well, they can't. When Torvalds created Linux, he protected it under the GNU General Public License, an intriguing form of copyright commonly known as copyleft. Under copyleft, anyone who redistributes the program, with or without changes, must pass along the freedom to further copy, change, and distribute it. Theoretically one can download Linux off the Web, add a string of useful features, and try to sell it for $50. But anyone who buys this new version can just copy it, give it away, or sell it for a dollar, thus destroying the incentive for piracy. An equivalent would be if I were to write the following at the end of this article: "Verbatim copying and redistribution of this entire article is permitted in any medium provided this notice remains at the end."
Use the Source
From the Oxford English Dictionary to hip-hop music, open-source development has always been with us to some degree. Since the mid-19th century, contributors to the OED have defined words and sent them to a centralized location to be gathered, criticized, sorted, and published. With music, as long as you stay within certain copyright laws, you can take chunks of other people's compositions and work them into your own. Most academic research is also built on open-source cooperation. Even the compact fluorescent light bulb above my head comes from data shared by researchers over centuries about electricity, properties of glass, and centralized power.
But still, most business isn't done with open source. Coca-Cola keeps its formula secret, Microsoft won't tell you how it builds its programs, and when a researcher for Ford suddenly stumbles upon the means to a more efficient fuel pump, she doesn't reflexively email her friend at Honda with a precise description of her discovery. A great deal of scientific and medical research is also done through closed source as individual laboratories race each other to determine who'll be the first to find the answer and earn the patent.
But two extraordinary changes are making open source substantially more plausible as a development and research model for 2000 than it was for 1990--and they'll make it even more so for 2010. First, the Internet. Today, I can open my Web browser and communicate instantly with Burmese refugees or writers working on projects similar to mine. Secondly, computer power has been increasing exponentially for generations and will probably continue to do so--in large part because every time you build a faster computer it allows you to build a faster one still. It's difficult to overestimate the change. The standard laptop to which I'm now dictating this article (with technology unavailable just two years ago) has more power than almost any computer owned by the government a decade ago. In four years, it could well be obsolete. As author Ray Kurzweil and others have pointed out, if cars had improved as much over the past 50 years as computers, they'd cost less than a nickel and go faster than the speed of light.
Intellectual and Physical Properties
This rate of progress is critical because the advantages of open-source development depend on the powers of technology and the balance between what can be done through thinking and what has to be done by building. Every product has certain intellectual components and certain physical components built into it. With a car, for example, the intellectual component is the thought about how to build it, how to set up the assembly lines, and how to process data you have on different kinds of tires. The physical components include the actual rubber in the tires, the machines that ran the tests, the operation and maintenance of factories.
Faster computers and increased connectivity are drastically changing the relationship between these components in two ways. First, some things that used to require physical components no longer do. You may not have to buy rubber to test the tires if you can just run a simulator online. (The 777 project at Boeing was designed so that nothing physical was produced before the plans hit the factory floor.) Second, connectivity makes the flow of information much faster and smoother and greatly facilitates the sharing of ideas and data. There is a saying known as "Linus' law" that "given enough eyes, all bugs are shallow." In other words, given enough people working on them, all problems are solvable. And the Internet has not only helped coordinate a lot more eyes: in some ways, it's given everyone glasses.
Open-source development benefits from this transition because its advantages are almost all in the realm of intellectual property. Open source improves communication and facilitates sharing ideas. But it doesn't mean that you can buy a ton of concrete for free or drive a nail into a wall without a hammer. This is why open source has come first and most prominently to computer programming: a profession where almost all of the development is intellectual, not physical, and where people have been connected over the Internet for more than 20 years. Programming also employs highly specific, common tools--computers--that a fairly large number of people have access to and that some people, such as university students, can even access for free. If a solution or improvement is found, nothing additional needs to be built; code just needs to be entered and then downloaded.
But there is still one great problem standing firmly in the way of even the most modern open-source software development project. As a 21-year-old Bill Gates asked in an angry letter to open-source programmers in 1976: "One thing you do is prevent good software from being written. Who can afford to do professional work for nothing?"
Microsoft's empire, and a great deal of the rest of our society, is built upon the assumption that there isn't an answer to this rhetorical question. To survive, organizations need to patent their information, protect their secrets, and earn as much money as they can. But the success of Linux shows that there's a way around that model. Something extraordinary has been built with a completely different set of rules. I asked David Soergel, a researcher in the department of genetics at Stanford, whether people could use the open-source model to develop medicines. "My first reaction: they'd rather get paid, and if they were any good at it, then they would be paid by somebody. My second reaction: wait a minute, that argument obviously fails for software."
Money for Nothing
Naive as it may be to think that people aren't motivated by money, it is just as naive to think that people are only motivated by money. People are motivated by a variety of factors: money, recognition, enjoyment, a belief that one is doing something good for the world, and so on. We each weigh these factors and make decisions based on our perceptions of their relative importance. At different points in our lives, we give different factors different weights. When we're poor, we tend to value simply high-paying work more than we do when we're well-off; it usually takes a high-paying job to get someone to do something really boring and it generally takes a very fulfilling job to get someone to work for less than what he should normally be able to earn.
Since people working on open-source projects generally earn nothing, or very little, there need to be other incentives. In Linux, there seem to be principally three. First, enjoyment. Computer programming can be addictive, exciting, and extraordinarily intense. Linux can be particularly enjoyable because almost every problem solved is a new one. If your Windows machine crashes, fixing the problem generally entails tediously working through scores of repair procedures which you may have used a thousand times. If A fails, try B. If B fails, try C. If a Linux computer crashes, anyone who repairs it is not only working on that one specific machine, he's finding a solution for the whole Linux community.
Eric Roberts, a computer science professor at Stanford, once explained to The New York Times that people in the profession must be "well trained to do work that is mind-numbingly boring." This is particularly true of work on most closed-source systems where programmers must continually reinvent the wheel. But with open-source projects, the things that need to be done haven't been done before. According to one only slightly hyperbolic programmer, Ali Abdin, writing to a Linux news group about how he felt after creating his first open-source project: "The feeling I got inside when I knew that I had some code out there that I can share with people is indescribable... I felt on top of the world, that I can program anything...I felt as mother would feel giving birth to a child, giving it life, for the first time."
Secondly, and similarly, Linux programmers are motivated by a feeling that they are changing the world and developing an operating system that really works. Torvalds laid out this philosophy well in a speech this summer: "I don't resent Microsoft for making lots of money. I resent them for making bad software."
Thirdly, but most significantly, Linux programmers seem motivated by prestige and, in particular, respect from their peers. Having "hacked the kernel" (contributed to the core of the operating system) gives programmers a certain stature--much as completing a four-minute mile does among runners--and, since the program is open source, everyone knows exactly who contributed what. I was once introduced to a programmer described as "the guy who wrote all the Ethernet device drivers!" as though I was meeting Jonas Salk "who came up with the cure for polio!" And, in fact, Linux programmers often discuss their work as falling in the tradition of eminent scientists. As three well-known programmers put it in the introduction to their book Open Sources: "It would be shortsighted of those in the computer industry to believe that monetary reward is the primary concern of open source's best programmers... These people are involved in a reputation game and history has shown that scientific success outlives financial success... When the history of this time is written a hundred years from now, people will perhaps remember the name of Bill Gates, but few other computer industrialists. They are much more likely to remember names like... Linus Torvalds."
Importantly, this philosophy may well be helping Linux develop creatively. There is a great deal of psychological research that shows that people actually do more creative work when they aren't motivated primarily by money. Tell a child that you'll pay her for reading a book and she'll read it with little imagination. Have one group of college poets think about getting rich and famous through their writing, according to research done by Harvard Professor Teresa Amabile, and they tend to turn out less creative work than a second group that's just asked to write poems. Is it possible that Linux programmers created such an extraordinary operating system in part because they were driven by other factors and weren't doing it for the money? I asked Professor Amabile if the implications of her research cross over to open-source programming and whether it could explain some of the remarkable innovations that have come from people working without pay. "Yes," she responded, "this [would be] entirely consistent."
Making free software affordable
Still, Linux programmers are not completely locking themselves out of the economy and there's a second response to Gates' rhetorical question: If your core open-source project is successful enough, it's possible to eventually make money off of it indirectly. No, it's not possible to make as much money as a proprietary company can--open source and copyleft will ensure this--and there's always going to be an astounding amount of work that has to be done without financial reward. But open-source programmers don't have to starve.
The trick to making money off Linux, or any open-source development, is to profit off of derivatives. No one actually makes money off the Linux code, but they can make money by offering technical support or helping customers install the program. Companies that do this follow a well-trodden path: give something away in order to sell something else. This is what cellular phone companies do when they give you the actual telephone handset for free if you agree to pay for using it a certain number of minutes a month. We do the same thing with the Monthly's Web page. We post some articles (giving them to readers for free) in the hope that visitors' interest will be piqued and that they'll subscribe.
Red Hat, the best-known Linux company, sells the operating system and other open-source programs in a box for $80, though you can download their product for free from redhat.com. Their revenue comes from the technical support they offer and from consumers' need for trust. It's much less unsettling to buy a program like Linux if you get it shrink-wrapped with a manual than if you have to download both. VA Linux, another well-known company, sells Linux hardware: You choose the memory and the motherboard; it builds you a computer.
Has the money these companies brought into the open-source movement corrupted it and made it more like the traditional model that Microsoft uses? Surely, there are a lot of people doing promotional and administrative work at Red Hat for the money and there are probably even some people working on Linux for Red Hat because they get paid a lot to do it (the company hires programmers to write code that anyone, including Red Hat's competitors, can use). But programmers mostly see the money as an added and surprising plus, and Linux is still driven by adrenaline, altruism, and peer recognition.
While it is possible that this could change, it hasn't so far. I asked Richard Stallman--the creator of copyleft, as well as many of the programs that run with the Linux through a system called GNU, and the man often considered to be the father of the open-source movement--whether he thought that money would change the attitudes of people who used to work on GNU/Linux without being paid. "In general, I don't think that wealth will make a hacker into a worse person. It would be more likely to enable the hacker to spend more time volunteering for free software instead of on work for pay."
This point is particularly germane because most open-source programmers have always had to work other jobs, and many have only been able to contribute to the project during the evenings or when their employers weren't looking. Linus Torvalds, for example, helps design microprocessors for a company called Transmeta in the daytime and does all his Linux coding after work. When I asked John Hall, vice president of VA Linux, what motivates programmers, he responded: "For some, it's altruism. For some, it's fame. For some, it's religion. For a very few, it's money."
So what's next?
To determine where open source is likely to move next, one has to imagine a scenario where these obstacles can be overcome. A project would need to be fun, or at least rewarding, to get going and it would have to primarily pose intellectual, not physical, challenges. Once it began to move, derivative financial incentives could help push it along. There also has to be a certain amount of luck, particularly with regard to organization. It's hard enough to get six people to agree to a restaurant for dinner; it's much harder to coordinate thousands of people known to each other only by email addresses. Linux has gotten around this latter problem in no small part because of Torvalds himself. He is a benevolent dictator who has earned the trust and respect of virtually everyone on the project. He's a relaxed, friendly, funny guy whose strength of character keeps his distended organization free from the internal battles that sink so many others. He also has learned how to delegate and has developed a core of equally well-respected close associates who coordinate different parts of the project.
One intriguing possibility for future open-source development comes from medicine, an area where people can become passionate and where intellectual components can far exceed physical components. Consider a smart doctor who loses a friend to rare disease X and decides to devote her life to finding a cure. Ten years ago, trying to develop anything more than a local network to collaboratively design a drug to cure the disease would have been extremely difficult. Communication would have had to be done over the phone or with photocopies slowly and expensively mailed. It made much more sense to have small groups of developers working together in laboratories, foundations, or universities.
Today the possibilities for open collaboration have improved. An ambitious doctor can network online with other researchers interested in disease X and, at the least, can quickly exchange data about the newest research techniques. In fact, there are already medical networks that pass around information about acute medical cases, using email and computers that can automatically send out patient files over a network and put X-rays into the overnight mail.
Now think another decade ahead when everyone will have high-speed Internet lines at least 500 times as fast as standard connections today (this will probably happen in three years), where it is fairly likely that we all will be able to simulate the movement of disease X online, and where it will surely be possible for medical students to run tests that approximate the human immune system on high-powered laboratory computers. Now the same doctor can farm out parts of the project to interested collaborators, many of whom have also lost friends to X and are passionate about finding a cure. If the coordinator is a good organizer and can hold people together the way that Torvalds has, the organization could grow, attracting even more people to join the collaborative effort with each success. Every breakthrough or improvement in the model could be posted online so that other participants could begin work on the next challenge. If a sample test is performed, data could be transferred to the Web simultaneously.
Eventually a prototype could be developed and adopted by an established drug company (or perhaps even a non-profit company, funded by foundations, that specializes in distributing open-source drugs and selling them at minimal costs) that licenses the product with the FDA, runs it through the necessary tests, and then manufactures, distributes and sells it--keeping prices relatively low both because no company would have exclusive copyrights and because research costs (drug companies' largest expense) would be drastically reduced.
Law
A real-life example of another possible opportunity for open source comes from Harvard where law Professors Larry Lessig and Charles Nesson have started the Open Law Project, an attempt to try cases using the open-source model. Interested people sign into the Website, read what other contributors have written, and help to develop arguments and briefs. According to the site description, "what we lose in secrecy, we expect to regain in depth of sources and breadth of argument." The program is run under the same sort of benevolent dictatorship model as Linux, with Lessig serving as chief. People brainstorm, debate, and then Lessig synthesizes and writes the briefs. Currently, the group is constructing arguments challenging, appropriately enough, the United States Copyright Extension Act.
There are great advantages to this model for law: The problems faced by lawyers are mostly intellectual, not physical; there is an abundance of people (especially law students) who are potentially willing to work on the projects for free; and there is the powerful draw of doing something you believe is a public service. If you don't agree with current copyright laws, join the group and figure out how to change them.
Of course, open-law will never be able to handle certain kinds of cases. As Nesson said to me, "open-law is not conducive to ambush." If you need to rely on secret arguments or evidence that the other side doesn't know about, you're not going to post everything on the Net. But if you just need to develop the best argument and rely on increased information flows, the model could work quite well.
Future
It is very difficult to determine exactly where open-source projects will take off next. So much depends on the personalities of the coordinators and the excitement they are able to generate; a great deal also depends on the different ways that technology develops and the way that different markets and research fields change. For some organizations, open-source development will make more sense in a couple of years than it does now. For others, it will make less. But the overall trends of technology are likely to push open source closer and closer to the mainstream.
Imagine a scale with all the advantages of a proprietary model on the left and all the advantages of an open-source model on the right. Pretend everybody who wants to solve a problem or build a project has a scale like this. If it tips to the left, the proprietary model is chosen; if it tips to the right, the open model is chosen. Now, as connectivity increases with the Internet, and computer power increases exponentially, more and more weight accumulates on the right. Every time computer power increases, another household gets wired, or a new simulator is built online, a little more weight is added to the right. Having the example of Linux to learn from adds some more weight to the right; the next successful open-source project will add even more.
Not enough is added to the right side to tip the scale for everybody and everything, but open source is presently growing and it should only continue that way. Netscape has made its Web browser open source. Sendmail, the program that routes most of our email, is open source. Most Web sites use an open-source program called Apache at their core. Even some microchip developers are starting to use open source.
Perhaps the next boom in open source will come from the law; perhaps from drug X; perhaps it will be something entirely different. Although it's difficult to tell, it is quite likely that the scale is going to tip for some projects and that there will be serious efforts at open-source development in the next decade. Moreover, it's quite likely some of these projects will work. Open source has created the fastest growing operating system in the world and it's done so by capitalizing on changes in technology that will almost certainly seem commonplace in a decade or two. Linux will continue to grow; but 10 years from now, it will probably no longer be the largest open-source project in the world.
Open Source Software and Documents: A Literature and Online Resource Review
Introduction
Open source software (OSS) and open source documents (OSD) are a rising star in technology today. The term "open source" was coined merely two years ago (1998)1, and is now a media buzzword (Raymond, 205). With its rapidly growing market share and corporate and public interest to match, open source as a concept will not stay a fringe phenomenon for long; in fact, it is rapidly entering the mainstream. This literature and online resource review is a starting point for anyone interested in the subject.
The Open Source Revolution
Since open source is relatively novel (as far as the mainstream, non-hacker2 culture is concerned) and largely exists online, there are only two printed works on the subject-and most of the material in these two books is also freely available online. One of the things that make the open source movement so unusual is that as it has developed over the last twenty years or so, it has done little self-documenting. This is one reason that Eric S. Raymond , self-appointed chief advocate for open source, wrote his now-famous essay "The Cathedral and the Bazaar."
ESR (as the hacker community refers to Mr. Raymond) wrote "Cathedral and Bazaar" largely to ameliorate this condition of non-documentation. Fascinated by the rapid development and growing sophistication of the Linux3 operating system, ESR began studying the open source development model (Raymond, 198). Why was Linux so mature, when the Free Software Foundation had been trying to develop a similar operating system for years without success? He found that while the corporate, mainstream, closed-source method (the "cathedral" model) of coding large programs like operating systems is bound by Brooke's Law, the open source development process (the "bazaar" model) actually reverses it. Brooke's Law states that programming work performed increases with direct proportion to the number of programmers (N), but the complexity of a project increases by the square of the number of programmers (N2). Therefore, it should follow that thousands of programmers working on a single project should become mired in a nightmare of human communication and version control. As "Cathedral and Bazaar" explains, the open source model (the "bazaar") overcomes this problem through customary central version control, mutual respect, and an army of developers and bug testers. This is summed up in a famous statement by ESR known as "Linus' Law" (so named for Linus Torvalds, original author and maintainer of the Linux kernel4): "Many eyes make all bugs shallow." "The Cathedral and the Bazaar," first given in 1997 at the Linux Kongress in Bavaria, led directly to the release of the Netscape browser source (see http://www.mozilla.org) and the current open source boom (Raymond, 200).
History
So how did all this come about? The open source concept is as old as the history of computing, and is closer to the original academic development of computing systems than the corporate model of today. These early days are illustrated in two excellent essays, "A Brief History of Hackerdom" by Eric S. Raymond, and "The GNU Operating System and the Free Software Movement" by Richard M. Stallman. Both of these essays trace the simultaneous beginnings of modern computing, the Internet, and open source software development. More historical information (along with the origins of many arcane computer terms) can be found at the Jargon File (at http://www.tuxedo.org/~esr/jargon/) or in its published counterpart, The New Hacker's Dictionary (which was, incidentally, one of the first books to be commercially published and simultaneously available online for free).
The first organized effort to produced open source software was the Free Software Foundation (FSF), founded by Richard M. Stallman (known as RMS) in 1985 (Stallman, 60). RMS formed the nonprofit foundation for two reasons: to further develop GNU5 software, and to create a thinktank to further the notion of "Copyleft." Copyleft is a pun-the idea being to turn copyright around upon itself. The FSF developed this concept into the GNU Public License (GPL), a software distribution license that stipulates (in a nutshell):
* Software released under the GPL shall be freely distributable
* The software shall be distributed along with its source code
* Anyone is free to modify the source code and change the program, as long as the resulting program is also freely distributable and modifiable
This ensures that all of the GNU software (and any other software released under the GPL) is protected from those who would use the code to create proprietary, closed-source programs. Around half of the open source software available today is made available under the terms of the GPL. Today there exist several similar licenses of varying restrictions and attitudes toward commercial use and sale of covered software (see http://www.opensource.org/licenses/).
Open Source Documents
The first documents that truly followed the open source model (in the sense of having many contributors and reviewers coupled with online availability) were Frequently Asked Questions lists, known as FAQs. The first online FAQ to go by that title is attributed to Eugene Miya, a NASA employee (Hersch, 1). His SPACE-digest mailing list FAQ was written in 1982, when the Internet was a little-known experimental network known as the Advanced Research Projects Agency Network (ARPANET) (see http://www.faqs.org/faqs/faqs/about-faqs/ ). Unfortunately, little is known about the history of these now-ubiquitous informational documents. An attempt was begun in 1996 to write a book about FAQs, but the web page for this project has not been updated since 1997 (see http://www.faqs.org/faqbook/ ).
Unfortunately, documentation is one of the weakest aspects of open source program (Stallman, 68). This is, perhaps, a result of the fact that hackers enjoy coding so very much; updating the documentation is sometimes an afterthought. Conversely, the idea that programmers make poor writers is an unfortunate stereotype. Eric Raymond insists that the very best hackers are also excellent writers, since good programming involves both logical analysis of a problem and a high level of creativity (Raymond, 246). This is evident in the fact that ESR (author of the popular Fetchmail program and numerous modules for the Emacs text editor), Richard Stallman (author of GNU Emacs, the GNU C compiler, and other keystone programs), Larry Wall (creator of the Perl programming language), and other open source luminaries have written numerous (and excellent) essays, manuals, and technical books.
This is changing, however. Since open source software, particularly the Linux operating system, needs good documentation to expand to new users, much work has been done to improve this situation. Open source programs are usually documented in three forms:
* README files that are distributed with each individual program
* Manual pages ("man pages", so named after the man command used to access them), technical references which are also distributed with each program (see ftp://ftp.win.tue.nl/pub/linux/docs/manpages/)
* HOWTO documents, which are instructional in nature, and usually task- (as opposed to program-) oriented (see http://www.linux.org/help/ldp/howto/howto.html). There is also a smaller, less step-by-step subset of the HOWTO documents known as Mini-HOWTOs (see http://www.linux.org/help/ldp/mini/minihowto.html )6
The maintenance of these documents is made difficult by the very nature of the open source development model. Since there are so many developers, running under a directive of "release early, release often," open source software can change at a rapid pace. To facilitate better documentation and document management, the Linux Documentation Project was founded by Matt Welsh in 1992 ( http://www.linuxdoc.org/ ). There is a recent interview of Deb Richardson, the current head of the LDP, at Slashdot (http://slashdot.org/article.pl?sid=00/03/27/0717244&mode=thread ). Another similar resource is the Open Source Writer's Group ( http://www.oswg.org:8080/oswg ), which serves as a database for open source volunteers willing to do documentation and other open source writing projects, based on skill and interest.
As an offshoot of the concept of freely available and modifiable documentation, OpenContent was created by David Wiley to create a license similar to the GPL that would apply to any information that is not a program (http://www.opencontent.org/). The idea is that if computer programs can be debugged (edited) and improved by making them modifiable by anyone with the desire to help, documents and other content should benefit from a similar process. A similar license, the GNU Free Documentation License (GNU FDL) was authored by Richard Stallman and released in March, 2000. The idea of "freely modifiable and distributable" music, stories, instructions, and other documents and media is still new, and the nature of any applicable distribution license is (as of March 2000) widely debated (see http://www.linuxmall.com/news/features/000324fdl , and http://opencontent.org/announce.shtml ).
Online Forums and Other Resources
Open source is a community as well as a method of software and document development. There are several "watering holes" that open source advocates, developers, writers, and the curious frequent. The most famous of these forums is Slashdot (so named for the dot-and-slash (/.) notation used to denote the directory structure used in UNIX systems), an open source news and discussion forum ( http://slashdot.org/ ). Journalists who are unfamiliar with the open source community usually go to Slashdot to get their first taste of the quirky, often irreverent world of open source adherents. The site consists of articles, which are usually submitted by Slashdot readers, and discussion of those articles. With the slogan of "News for nerds, stuff that matters," Slashdot topics range from open source issues to science fiction, the role of "geeks" in society, science and technology, and the occasional essay. Other forums and news sites are:
* Segfault7 ( http://www.segfault.org/), a sort of anti-Slashdot that posts parodies and humorous stories
* Freshmeat ( http://www.freshmeat.net/), which announces new releases of open source software and other relevant news such as security issues
* Kernel Notes ( http://kernelnotes.org/ ), which publishes announcements regarding the Linux Kernel4 (which is sometimes updated with a new release several times per day!)
* Linux Forum ( http://www.linuxforum.com/ ), a currently-defunct site for general Linux discussion
There are also other websites, mailing lists, and Usenet8 newsgroups too numerous to mention; a Web search for the term "Linux" at www.google.com yields 1,560,000 results. Examining www.linux.org or the comp.os.linux hierarchy of newsgroups should point the curious in the right direction.
In addition, there are specialized development forums dedicated to open source. Since any open source business model depends on the abundance of quality software, several companies host free development sites, which offer a combination of development tools, shell accounts, FTP (File Transfer Protocol) and Web hosting, version control software like CVS (Concurrent Versions System), and "matchmaking" (introducing developers and users who are looking for each other), all for free. Some of the most significant are:
* Sourceforge ( http://www.sourceforge.net ), which offers news, Web and FTP site hosting, shell accounts, CVS, and discussion forums for open source projects
* The Free Software Bazaar ( http://visar.csustan.edu/bazaar/ ), which serves as a link between open source developers and open source users who need development work done
* SourceXchange, ( http://www.sourcexchange.com/ ) where developers and users can barter code, documents and ideas
Closing
These are just the tip of the iceberg, though I have consciously tried to denote those resources which will provide the most valuable information and point the reader toward other resources of more specialized interest. There are thousands upon thousands of Linux-related pages on the World Wide Web. There are also Usenet newsgroups, mailing lists, magazines (see http://www.linuxworld.com/ ), and Linux User Groups (LUGs), in addition to the many different Linux distributions (see http://www.linux.org/dist/index.html ).
Open Source is a phenomenon that is growing in momentum, membership, and market share. It has already touched the lives of everyone who uses the Internet (since many of the services and programs that make the Internet go are either open source, or based on an open source program). It will continue to do so, and anyone required to keep up with technology in the world today needs at least some familiarity with its precepts and concepts. I hope this review will assist those that would like to learn more.
Notes
1. The term "open source" was coined by Eric Raymond and ratified in a meeting between himself, Richard M. Stallman, and other notable open source advocates. It is intended to replace the previous term, "free software," used by Richard Stallman. Despit e the constant admonishment that the "free" in "free software" meant "Free as in speech, not as in beer," corporate-minded people were leery of the idea of software that could not be sold (Raymond, 212). [Back]
2. "Hacker" is how programmers describe someone who enjoys solving problems in ingenious ways. It is a term of praise that must be earned in the hacker community. Unfortunately, people who exploit software bugs to crash, interfere with, or gain unauthorized access to other people's computer systems also sometimes refer to themselves as "hackers." The popular media has seized upon this misnomer and popularized it, to the confusion of the general public. People in the open source community refer to such miscreants and criminals as "crackers." [Back]
3. Linux (named after Linus Torvalds, its creator) is the most popular of the open source operating systems. Linux is a "workalike" clone of the UNIX operating system, based on the Linux kernel (see note 4, below), the suite of GNU (see note 5, below) t ools and applications, and other software packages depending on which Linux you are using. There are many flavors of Linux (called distributions), a few of which are RedHat ( http://www.redhat.com/ ), Slackware ( http://www.slackware.com/ ), and Debian ( http://www.debian.org ). [Back]
4. The kernel is the heart of any operating system. The kernel performs low-level tasks such as memory allocation, process management, and communication with hardware. It serves as the negotiator between programs and the hardware of a computer system. Kernels are some of the most difficult and complex of all types of computer programs. [Back]
5. GNU is a recursive acronym that stands for "GNU's Not UNIX." (which stands for "GNU's Not Unix Not Unix," which stands for. . .) It is the "brand" for software developed by the Free Software Foundation. Another well-known recursive acronym name is the PINE mail reader ("PINE Is Not Elm" (Elm is another mail reader upon which Pine was based)). A book could easily be written on the quirky names for UNIX commands and acronyms. For example, the biff command (used to check for new email) is not a recursive acronym; it was named after a dog. [Back]
6. There are HOWTO documents on all sorts of Linux concepts. Including how to get Linux to make coffee (see http://www.linux.org/help/ldp/mini/Coffee.html )! [Back]
7. Segfault is named, appropriately, after an error known as a "Segmentation Fault." This is an error that occurs when a program tries to access an incorrect segment of memory (see http://www.tuxedo.org/~esr/jargon/html/entry/segmentation-fault.html ). The program will then perform a core dump, which, as far as most users (and many programmers) are concerned, means that a meaningless gobbledygook of numbers and letters is dumped onto the screen or into a file called "core." [Back]
8. Usenet is the collective term for the collection of Internet-wide newsgroups. Usenet was originally a handful of forums intended for ARPANET developers to use as a common bulletin board. It now contains many thousands of newsgroups, arranged in hierarchical dotted notation (e.g., under rec.pets, one may find rec.pets.dogs, rec.pets.cats, and rec.pets.cats.siamese). [Back]
Open source software (OSS) and open source documents (OSD) are a rising star in technology today. The term "open source" was coined merely two years ago (1998)1, and is now a media buzzword (Raymond, 205). With its rapidly growing market share and corporate and public interest to match, open source as a concept will not stay a fringe phenomenon for long; in fact, it is rapidly entering the mainstream. This literature and online resource review is a starting point for anyone interested in the subject.
The Open Source Revolution
Since open source is relatively novel (as far as the mainstream, non-hacker2 culture is concerned) and largely exists online, there are only two printed works on the subject-and most of the material in these two books is also freely available online. One of the things that make the open source movement so unusual is that as it has developed over the last twenty years or so, it has done little self-documenting. This is one reason that Eric S. Raymond , self-appointed chief advocate for open source, wrote his now-famous essay "The Cathedral and the Bazaar."
ESR (as the hacker community refers to Mr. Raymond) wrote "Cathedral and Bazaar" largely to ameliorate this condition of non-documentation. Fascinated by the rapid development and growing sophistication of the Linux3 operating system, ESR began studying the open source development model (Raymond, 198). Why was Linux so mature, when the Free Software Foundation had been trying to develop a similar operating system for years without success? He found that while the corporate, mainstream, closed-source method (the "cathedral" model) of coding large programs like operating systems is bound by Brooke's Law, the open source development process (the "bazaar" model) actually reverses it. Brooke's Law states that programming work performed increases with direct proportion to the number of programmers (N), but the complexity of a project increases by the square of the number of programmers (N2). Therefore, it should follow that thousands of programmers working on a single project should become mired in a nightmare of human communication and version control. As "Cathedral and Bazaar" explains, the open source model (the "bazaar") overcomes this problem through customary central version control, mutual respect, and an army of developers and bug testers. This is summed up in a famous statement by ESR known as "Linus' Law" (so named for Linus Torvalds, original author and maintainer of the Linux kernel4): "Many eyes make all bugs shallow." "The Cathedral and the Bazaar," first given in 1997 at the Linux Kongress in Bavaria, led directly to the release of the Netscape browser source (see http://www.mozilla.org) and the current open source boom (Raymond, 200).
History
So how did all this come about? The open source concept is as old as the history of computing, and is closer to the original academic development of computing systems than the corporate model of today. These early days are illustrated in two excellent essays, "A Brief History of Hackerdom" by Eric S. Raymond, and "The GNU Operating System and the Free Software Movement" by Richard M. Stallman. Both of these essays trace the simultaneous beginnings of modern computing, the Internet, and open source software development. More historical information (along with the origins of many arcane computer terms) can be found at the Jargon File (at http://www.tuxedo.org/~esr/jargon/) or in its published counterpart, The New Hacker's Dictionary (which was, incidentally, one of the first books to be commercially published and simultaneously available online for free).
The first organized effort to produced open source software was the Free Software Foundation (FSF), founded by Richard M. Stallman (known as RMS) in 1985 (Stallman, 60). RMS formed the nonprofit foundation for two reasons: to further develop GNU5 software, and to create a thinktank to further the notion of "Copyleft." Copyleft is a pun-the idea being to turn copyright around upon itself. The FSF developed this concept into the GNU Public License (GPL), a software distribution license that stipulates (in a nutshell):
* Software released under the GPL shall be freely distributable
* The software shall be distributed along with its source code
* Anyone is free to modify the source code and change the program, as long as the resulting program is also freely distributable and modifiable
This ensures that all of the GNU software (and any other software released under the GPL) is protected from those who would use the code to create proprietary, closed-source programs. Around half of the open source software available today is made available under the terms of the GPL. Today there exist several similar licenses of varying restrictions and attitudes toward commercial use and sale of covered software (see http://www.opensource.org/licenses/).
Open Source Documents
The first documents that truly followed the open source model (in the sense of having many contributors and reviewers coupled with online availability) were Frequently Asked Questions lists, known as FAQs. The first online FAQ to go by that title is attributed to Eugene Miya, a NASA employee (Hersch, 1). His SPACE-digest mailing list FAQ was written in 1982, when the Internet was a little-known experimental network known as the Advanced Research Projects Agency Network (ARPANET) (see http://www.faqs.org/faqs/faqs/about-faqs/ ). Unfortunately, little is known about the history of these now-ubiquitous informational documents. An attempt was begun in 1996 to write a book about FAQs, but the web page for this project has not been updated since 1997 (see http://www.faqs.org/faqbook/ ).
Unfortunately, documentation is one of the weakest aspects of open source program (Stallman, 68). This is, perhaps, a result of the fact that hackers enjoy coding so very much; updating the documentation is sometimes an afterthought. Conversely, the idea that programmers make poor writers is an unfortunate stereotype. Eric Raymond insists that the very best hackers are also excellent writers, since good programming involves both logical analysis of a problem and a high level of creativity (Raymond, 246). This is evident in the fact that ESR (author of the popular Fetchmail program and numerous modules for the Emacs text editor), Richard Stallman (author of GNU Emacs, the GNU C compiler, and other keystone programs), Larry Wall (creator of the Perl programming language), and other open source luminaries have written numerous (and excellent) essays, manuals, and technical books.
This is changing, however. Since open source software, particularly the Linux operating system, needs good documentation to expand to new users, much work has been done to improve this situation. Open source programs are usually documented in three forms:
* README files that are distributed with each individual program
* Manual pages ("man pages", so named after the man command used to access them), technical references which are also distributed with each program (see ftp://ftp.win.tue.nl/pub/linux/docs/manpages/)
* HOWTO documents, which are instructional in nature, and usually task- (as opposed to program-) oriented (see http://www.linux.org/help/ldp/howto/howto.html). There is also a smaller, less step-by-step subset of the HOWTO documents known as Mini-HOWTOs (see http://www.linux.org/help/ldp/mini/minihowto.html )6
The maintenance of these documents is made difficult by the very nature of the open source development model. Since there are so many developers, running under a directive of "release early, release often," open source software can change at a rapid pace. To facilitate better documentation and document management, the Linux Documentation Project was founded by Matt Welsh in 1992 ( http://www.linuxdoc.org/ ). There is a recent interview of Deb Richardson, the current head of the LDP, at Slashdot (http://slashdot.org/article.pl?sid=00/03/27/0717244&mode=thread ). Another similar resource is the Open Source Writer's Group ( http://www.oswg.org:8080/oswg ), which serves as a database for open source volunteers willing to do documentation and other open source writing projects, based on skill and interest.
As an offshoot of the concept of freely available and modifiable documentation, OpenContent was created by David Wiley to create a license similar to the GPL that would apply to any information that is not a program (http://www.opencontent.org/). The idea is that if computer programs can be debugged (edited) and improved by making them modifiable by anyone with the desire to help, documents and other content should benefit from a similar process. A similar license, the GNU Free Documentation License (GNU FDL) was authored by Richard Stallman and released in March, 2000. The idea of "freely modifiable and distributable" music, stories, instructions, and other documents and media is still new, and the nature of any applicable distribution license is (as of March 2000) widely debated (see http://www.linuxmall.com/news/features/000324fdl , and http://opencontent.org/announce.shtml ).
Online Forums and Other Resources
Open source is a community as well as a method of software and document development. There are several "watering holes" that open source advocates, developers, writers, and the curious frequent. The most famous of these forums is Slashdot (so named for the dot-and-slash (/.) notation used to denote the directory structure used in UNIX systems), an open source news and discussion forum ( http://slashdot.org/ ). Journalists who are unfamiliar with the open source community usually go to Slashdot to get their first taste of the quirky, often irreverent world of open source adherents. The site consists of articles, which are usually submitted by Slashdot readers, and discussion of those articles. With the slogan of "News for nerds, stuff that matters," Slashdot topics range from open source issues to science fiction, the role of "geeks" in society, science and technology, and the occasional essay. Other forums and news sites are:
* Segfault7 ( http://www.segfault.org/), a sort of anti-Slashdot that posts parodies and humorous stories
* Freshmeat ( http://www.freshmeat.net/), which announces new releases of open source software and other relevant news such as security issues
* Kernel Notes ( http://kernelnotes.org/ ), which publishes announcements regarding the Linux Kernel4 (which is sometimes updated with a new release several times per day!)
* Linux Forum ( http://www.linuxforum.com/ ), a currently-defunct site for general Linux discussion
There are also other websites, mailing lists, and Usenet8 newsgroups too numerous to mention; a Web search for the term "Linux" at www.google.com yields 1,560,000 results. Examining www.linux.org or the comp.os.linux hierarchy of newsgroups should point the curious in the right direction.
In addition, there are specialized development forums dedicated to open source. Since any open source business model depends on the abundance of quality software, several companies host free development sites, which offer a combination of development tools, shell accounts, FTP (File Transfer Protocol) and Web hosting, version control software like CVS (Concurrent Versions System), and "matchmaking" (introducing developers and users who are looking for each other), all for free. Some of the most significant are:
* Sourceforge ( http://www.sourceforge.net ), which offers news, Web and FTP site hosting, shell accounts, CVS, and discussion forums for open source projects
* The Free Software Bazaar ( http://visar.csustan.edu/bazaar/ ), which serves as a link between open source developers and open source users who need development work done
* SourceXchange, ( http://www.sourcexchange.com/ ) where developers and users can barter code, documents and ideas
Closing
These are just the tip of the iceberg, though I have consciously tried to denote those resources which will provide the most valuable information and point the reader toward other resources of more specialized interest. There are thousands upon thousands of Linux-related pages on the World Wide Web. There are also Usenet newsgroups, mailing lists, magazines (see http://www.linuxworld.com/ ), and Linux User Groups (LUGs), in addition to the many different Linux distributions (see http://www.linux.org/dist/index.html ).
Open Source is a phenomenon that is growing in momentum, membership, and market share. It has already touched the lives of everyone who uses the Internet (since many of the services and programs that make the Internet go are either open source, or based on an open source program). It will continue to do so, and anyone required to keep up with technology in the world today needs at least some familiarity with its precepts and concepts. I hope this review will assist those that would like to learn more.
Notes
1. The term "open source" was coined by Eric Raymond and ratified in a meeting between himself, Richard M. Stallman, and other notable open source advocates. It is intended to replace the previous term, "free software," used by Richard Stallman. Despit e the constant admonishment that the "free" in "free software" meant "Free as in speech, not as in beer," corporate-minded people were leery of the idea of software that could not be sold (Raymond, 212). [Back]
2. "Hacker" is how programmers describe someone who enjoys solving problems in ingenious ways. It is a term of praise that must be earned in the hacker community. Unfortunately, people who exploit software bugs to crash, interfere with, or gain unauthorized access to other people's computer systems also sometimes refer to themselves as "hackers." The popular media has seized upon this misnomer and popularized it, to the confusion of the general public. People in the open source community refer to such miscreants and criminals as "crackers." [Back]
3. Linux (named after Linus Torvalds, its creator) is the most popular of the open source operating systems. Linux is a "workalike" clone of the UNIX operating system, based on the Linux kernel (see note 4, below), the suite of GNU (see note 5, below) t ools and applications, and other software packages depending on which Linux you are using. There are many flavors of Linux (called distributions), a few of which are RedHat ( http://www.redhat.com/ ), Slackware ( http://www.slackware.com/ ), and Debian ( http://www.debian.org ). [Back]
4. The kernel is the heart of any operating system. The kernel performs low-level tasks such as memory allocation, process management, and communication with hardware. It serves as the negotiator between programs and the hardware of a computer system. Kernels are some of the most difficult and complex of all types of computer programs. [Back]
5. GNU is a recursive acronym that stands for "GNU's Not UNIX." (which stands for "GNU's Not Unix Not Unix," which stands for. . .) It is the "brand" for software developed by the Free Software Foundation. Another well-known recursive acronym name is the PINE mail reader ("PINE Is Not Elm" (Elm is another mail reader upon which Pine was based)). A book could easily be written on the quirky names for UNIX commands and acronyms. For example, the biff command (used to check for new email) is not a recursive acronym; it was named after a dog. [Back]
6. There are HOWTO documents on all sorts of Linux concepts. Including how to get Linux to make coffee (see http://www.linux.org/help/ldp/mini/Coffee.html )! [Back]
7. Segfault is named, appropriately, after an error known as a "Segmentation Fault." This is an error that occurs when a program tries to access an incorrect segment of memory (see http://www.tuxedo.org/~esr/jargon/html/entry/segmentation-fault.html ). The program will then perform a core dump, which, as far as most users (and many programmers) are concerned, means that a meaningless gobbledygook of numbers and letters is dumped onto the screen or into a file called "core." [Back]
8. Usenet is the collective term for the collection of Internet-wide newsgroups. Usenet was originally a handful of forums intended for ARPANET developers to use as a common bulletin board. It now contains many thousands of newsgroups, arranged in hierarchical dotted notation (e.g., under rec.pets, one may find rec.pets.dogs, rec.pets.cats, and rec.pets.cats.siamese). [Back]
The Open Source Definition
Introduction
Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:
1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
Rationale: By constraining the license to require free redistribution, we eliminate the temptation to throw away many long-term gains in order to make a few short-term sales dollars. If we didn't do this, there would be lots of pressure for cooperators to defect.
2. Source Code
The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost–preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
Rationale: We require access to un-obfuscated source code because you can't evolve programs without modifying them. Since our purpose is to make evolution easy, we require that modification be made easy.
3. Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
Rationale: The mere ability to read source isn't enough to support independent peer review and rapid evolutionary selection. For rapid evolution to happen, people need to be able to experiment with and redistribute modifications.
4. Integrity of The Author's Source Code
The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.
Rationale: Encouraging lots of improvement is a good thing, but users have a right to know who is responsible for the software they are using. Authors and maintainers have reciprocal right to know what they're being asked to support and protect their reputations.
Accordingly, an open-source license must guarantee that source be readily available, but may require that it be distributed as pristine base sources plus patches. In this way, "unofficial" changes can be made available but readily distinguished from the base source.
5. No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of persons.
Rationale: In order to get the maximum benefit from the process, the maximum diversity of persons and groups should be equally eligible to contribute to open sources. Therefore we forbid any open-source license from locking anybody out of the process.
Some countries, including the United States, have export restrictions for certain types of software. An OSD-conformant license may warn licensees of applicable restrictions and remind them that they are obliged to obey the law; however, it may not incorporate such restrictions itself.
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
Rationale: The major intention of this clause is to prohibit license traps that prevent open source from being used commercially. We want commercial users to join our community, not feel excluded from it.
7. Distribution of License
The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
Rationale: This clause is intended to forbid closing up software by indirect means such as requiring a non-disclosure agreement.
8. License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.
Rationale: This clause forecloses yet another class of license traps.
9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
Rationale: Distributors of open-source software have the right to make their own choices about their own software.
Yes, the GPL is conformant with this requirement. Software linked with GPLed libraries only inherits the GPL if it forms a single work, not any software with which they are merely distributed.
10. License Must Be Technology-Neutral
No provision of the license may be predicated on any individual technology or style of interface.
Rationale: This provision is aimed specifically at licenses which require an explicit gesture of assent in order to establish a contract between licensor and licensee. Provisions mandating so-called "click-wrap" may conflict with important methods of software distribution such as FTP download, CD-ROM anthologies, and web mirroring; such provisions may also hinder code re-use. Conformant licenses must allow for the possibility that (a) redistribution of the software will take place over non-Web channels that do not support click-wrapping of the download, and that (b) the covered code (or re-used portions of covered code) may run in a non-GUI environment that cannot support popup dialogues.
Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:
1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
Rationale: By constraining the license to require free redistribution, we eliminate the temptation to throw away many long-term gains in order to make a few short-term sales dollars. If we didn't do this, there would be lots of pressure for cooperators to defect.
2. Source Code
The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost–preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
Rationale: We require access to un-obfuscated source code because you can't evolve programs without modifying them. Since our purpose is to make evolution easy, we require that modification be made easy.
3. Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
Rationale: The mere ability to read source isn't enough to support independent peer review and rapid evolutionary selection. For rapid evolution to happen, people need to be able to experiment with and redistribute modifications.
4. Integrity of The Author's Source Code
The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.
Rationale: Encouraging lots of improvement is a good thing, but users have a right to know who is responsible for the software they are using. Authors and maintainers have reciprocal right to know what they're being asked to support and protect their reputations.
Accordingly, an open-source license must guarantee that source be readily available, but may require that it be distributed as pristine base sources plus patches. In this way, "unofficial" changes can be made available but readily distinguished from the base source.
5. No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of persons.
Rationale: In order to get the maximum benefit from the process, the maximum diversity of persons and groups should be equally eligible to contribute to open sources. Therefore we forbid any open-source license from locking anybody out of the process.
Some countries, including the United States, have export restrictions for certain types of software. An OSD-conformant license may warn licensees of applicable restrictions and remind them that they are obliged to obey the law; however, it may not incorporate such restrictions itself.
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
Rationale: The major intention of this clause is to prohibit license traps that prevent open source from being used commercially. We want commercial users to join our community, not feel excluded from it.
7. Distribution of License
The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
Rationale: This clause is intended to forbid closing up software by indirect means such as requiring a non-disclosure agreement.
8. License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.
Rationale: This clause forecloses yet another class of license traps.
9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
Rationale: Distributors of open-source software have the right to make their own choices about their own software.
Yes, the GPL is conformant with this requirement. Software linked with GPLed libraries only inherits the GPL if it forms a single work, not any software with which they are merely distributed.
10. License Must Be Technology-Neutral
No provision of the license may be predicated on any individual technology or style of interface.
Rationale: This provision is aimed specifically at licenses which require an explicit gesture of assent in order to establish a contract between licensor and licensee. Provisions mandating so-called "click-wrap" may conflict with important methods of software distribution such as FTP download, CD-ROM anthologies, and web mirroring; such provisions may also hinder code re-use. Conformant licenses must allow for the possibility that (a) redistribution of the software will take place over non-Web channels that do not support click-wrapping of the download, and that (b) the covered code (or re-used portions of covered code) may run in a non-GUI environment that cannot support popup dialogues.
Subscribe to:
Posts (Atom)