What did we learn from open source?
First Monday

What did we learn from open source? by Ilkka Tuomi


The following commentary is part of First Monday's Special Issue #2: Open Source.

++++++++++

Since Eric Raymond wrote his landmark article, the global interest in open source has exploded. Open source software has become important for everyone who uses the Internet. It has redefined business strategies and generated heated political discussions. It has created new innovative start-ups and new business models. Economists, sociologists, and organization and innovation theorists have explored the phenomenon, benefiting from the historically unique opportunity of gaining access to data that records in great detail the development of open source projects.

What, then, would be the most important thing we learned, with the most fundamental impact and consequences in the coming years?

Most probably, it is the fact that we need to redesign intellectual property rights.

The current system of intellectual property rights was created with the assumption that optimal production new knowledge and new useful innovations requires careful balancing of common and private interests. The economic argument was that innovators need monopoly rights to their inventions. Without such rights, they would underinvest in innovative work. As a result, technical progress would slow down. New useful knowledge and new technologies would be generated at a slow pace, and, in the end, the society would be worse off.

Successful open source projects have shown that this argument cannot be right. Without open source, we would not have the Internet or the World Wide Web. Open source projects generate a complex ecology of innovation, where new ideas are tested and developed. The projects have also created large pools of highly skilled software professionals, often through a somewhat miraculous alchemy that has transformed teenagers into globally leading system architects, sometimes with little supporting formal computer education. Open source projects have shown that our traditional theories about innovation, organization, and technical advances are not valid in a networked world where software is a major driver for social and economic change.

In general, successful open source projects are projects that provide platforms for development. They are often projects that generate system innovations, where new incremental improvements lead to rapidly increasing system functionality. As the improvements are incremental, open source development projects are able to recruit new developers who bring their knowledge and learning capability to the overall project. This leads to organic growth and rapid expansion of system capabilities. New developers are able to focus on areas where their contribution matters and where their skills provide added value. As novices typically enter the developer community as peripheral participants, their efforts rarely create chaos in the critical parts of the system.

This organic growth resembles the cumulative process of science. In contrast to science, open source software projects, however, operate on a shared technical artifact. Theories about good solutions can be readily tested by running the code that implements theories. In this sense, open source projects fulfill the theoretical ideal of empirical science better than science itself. Code is both a detailed specification of a theory of how the system works, and the objective reality, which the developers construct. When the code works, the theory works and becomes real.

This all, of course, is true only as long as the developers share the criteria for evaluating good designs. In operating system kernel development, for example, important criteria include the compactness and efficiency of code and—as the system is produced by a geographically distributed team—the readability of the source code.

Successful open source projects, therefore, require that developers share values that allow them to distinguish good and bad. Some pieces of code are ugly, others clean. Some code does what it is supposed to do, without unnecessary and unessential tricks. Other pieces of code are a mess, and reveal that their developers do not know what beautiful code looks like.

In this sense, open source development is value-driven development. Although it is technical problem-solving, it is not instrumental. The developers do not produce for others; instead, they create code to create themselves. This is one of the reasons why open source developers are often highly committed to their projects and why they can in a short time acquire skill-levels that otherwise might take years of formal education. Open source developers construct simultaneously technical artifacts and their identity.

This is the same energy that Aristotle called poiesis. It has driven innovators, artists, and revolutionaries through the ages. It is the urge to make a meaningful difference in life, listen to a calling, and to become real by participating in a project shared by others who value the same values.

So what does this mean for intellectual property rights?

Since the heated debates on the patent system in the 19th century, the controversy has focused on the idea that social and economic development would slow down without the protection of intellectual property. One camp argued that inventors would stop inventing if they could not secure benefits from their innovations. The other camp argued that new inventions always rely on earlier knowledge, and that it is impossible to fairly divide the glory and the benefits among the contributors, many of whom have died centuries ago. In addition, the free-market proponents fought the patent system by pointing out the harmful effects of monopolies, well-known throughout the history.

Open source is an example of the ongoing socio-economic transformation that is enabled by global information and communication networks. We are now moving from the classical economy of scarcity towards an expansive economy of meaning, where culture, values, identity, and communication matters. This new economy requires a new concept of intellectual property.

Networked information systems and software programs are often constructed from small building blocks that are joined together. Sometimes the pieces do not fit well. Sometimes a new piece is plugged in to make the whole system better and more robust. Yet, the "goodness" and "fitness" of a specific piece can only be evaluated in the context of the whole system, and often only after the fact, by running the system and checking whether the piece fits.

In this development model, classical intellectual property rights tend to work against progress. They create entry barriers for new developers, and they can easily be used to lock out unwanted developers. First entrants easily dominate competition in such technical environments. As the first entrants can also act as gatekeepers and to some extent dictate the terms of entry, the latecomers often have to pay entry fees. This guarantees that first comers maintain effective monopolies as long as the system architecture does not radically change.

Intellectual property rights need to be redesigned for several good reasons. The productive economic lifetime of software-related innovations is now measured in months and perhaps years, whereas monopoly rights extend over decades. Software innovations are typically engineering solutions to problems that many competent designers face at roughly the same time, when the problem becomes a real and practical issue, and parallel invention is more a rule than an exception.

Most fundamentally, however, software innovations are now typically networked system innovations, built on existing technical platforms. To develop such innovations, inventors need access to the specifications of the existing systems and sometimes also the capability to modify existing systems. In principle, all the complex interactions and access rights can be negotiated among corporate lawyers. In practice, only large corporations can enter the level playing field. They do this by cross-licensing their intellectual property, thus avoiding separate agreements and the associated delays and costs.

Open source development avoids these complex negotiations of access rights. It can recruit developers from all around the world, and the developers can focus on incremental improvements where they believe they can show that they can make a difference. The repeated social interactions among the developers create social capital and reputations that facilitate effective collaboration.

The downside, of course, is that the developers tend to focus on challenges they themselves find interesting and important. There is no guarantee that open source developers would focus on societally important challenges. Here the open source model is no better nor worse than the market mechanism. The implicit idea underlying the granting of monopolies for innovators was that economic benefits have to reflect social benefits. If the inventors are being paid for their inventions, someone has to find them worth paying for. If someone pays for the inventions, they have to be beneficial for the society. The bottleneck here, of course, is money. Those who have no money to spend cannot vote on the market. Developing countries and poor people with low income easily hit this bottleneck. Markets and commercial software developers listen to those who have money, and markets are often very effective in solving problems that paying customers have. That does not guarantee socio-economic progress, however. In software business, first-mover advantages can create monopolies that are strong enough so that technology suppliers can in effect dictate which problems they are willing to solve.

There exist many ways in which intellectual property rights can be redesigned. Different types on inventions may have different lifetimes and dynamically changing costs of maintaining the monopoly. Intellectual property may be pooled to create easy access to key system elements and to lower negotiation costs and delays. Monopoly rights may be combined with the requirement to not only to publish inventions but also to grant modification rights.

All such proposals will lead to strong protests from those who now benefit from the existing intellectual property regimes. These voices typically represent historically accumulated interests. In many ways, they represent the gradual process of social and institutional optimization where the needs of the Industrial Age have become inscribed in laws, industrial structures, business models, professions, and social institutions. The emerging network society, however, will require new institutions, new laws, and new ways to understand intellectual property. Open source projects have shown than an alternative exists, that it is important in practice, and that it can potentially lead to important societal benefits.

 

About the Author

Ilkka Tuomi is Chief Scientist at Meaning Processing Ltd, an independent research center located in Helsinki, Finland. He has written articles, book chapters and books on computer networks, organizational knowledge management, open source software, and new innovation models. His most recent book is Networks of Innovation, Oxford University Press, 2002.

 


Contents Index

Copyright ©2005, First Monday

Copyright ©2005, by Ilkka Tuomi

What did we learn from open source?
First Monday, Special Issue #2: Open Source (October 2005),
URL: http://firstmonday.org/issues/special10_10/tuomi/index.html





A Great Cities Initiative of the University of Illinois at Chicago University Library.

© First Monday, 1995-2017. ISSN 1396-0466.