subscribe to this page
The story of Linux and open source software is one of the most sensational tales of technology in recent history. What started as the brainchild of a handful of dedicated individuals (Torvalds, Stallman, et al) has ballooned to a multi-million-member movement that is both idealistically appealing and financially sound - just ask the multitude of companies relying on - or profiting from - the use of Linux. But this movement has created something of a parallel universe in the software world - one where intellectual property rights are turned on their head. While most companies in the technology and entertainment industries (which are increasingly influenced by each other) launch intellectual property battles on a grand scale, those behind the free software movement eschew protection of intellectual property rights and have created both products and business models that are successful without these protections.
I take a critical look at the output of the Free Software movement (both products and business models based on it) and specifically the way that its views toward protection of intellectual property rights has affected that output. What is the nature of the free software movement and its products, especially with respect to corporate involvement and sponsorship? I show that although the free software movement has been successful in many of its endeavours, the ideal of a world where all software is essentially a community-developed public good, provided unrestricted and free of charge to everyone, is unrealistic. The free software movement is as helped by traditional software-for-profit business models as it seeks to overturn them. Futhermore, there are areas where the free software industry is especially hindered (although not doomed), particularly in the areas of entertainment and usability.
tagged computers copyright entertainment free_software linux open_source oss software
by haw
...on 28-NOV-06
Krishnamurthy, Sandeep, Cave or Community? An Empirical Examination of 100 Mature Open Source Projects, May 2002.
The value of this paper is represented in its byline: “An empirical examination of 100 mature open source projects.” The author used as his source one of the premier open source project management websites, home to tens of thousands of projects, and picked a sample that had reached the highest level – “mature.” As the paper notes, the projects sampled had been in existence for 18 months on average, and had released several versions of their product, therefore having the best chance of representing the community development possible within open source projects.
The paper’s most dramatic finding is that most mature open source projects are fairly small – the median number of developers in the sampled projects was four, with a lone developer being the most common case.
Other findings included that most projects did not generate very much discussion, in contrast to the portrait painted by the media of a bustling, communicative group of developers. The study found that products with more developers were viewed and downloaded more often, and also that products with more developers had smaller leadership bases.
Although this study is straightforward and not accompanied by a wealth of discussion, the findings speak fairly loudly toward discrediting a lot of the prevailing image of the open source project. Even the author’s tone in compiling this bibliography suggests that most projects are large networks of disparate talent, colluding to create products that are extensively peer-reviewed for quality. This study shows that to not necessarily be the case, although it is unclear what subjective level of success the surveyed projects had obtained – projects selected for other variables could yield different data, and the discussion in the study suggests that projects in other stages of life (earlier than “mature”) could carry different characteristics as well.
West,J . "How open is open enough? Melding proprietary and open source platform strategies" Research policy [0048-7333] 32.7 (2003). 1259-.
This paper explores the influential relationship that has developed over the last decade between open source software and commercial software houses. In contrast to other portrayals, this paper begins with the assertion that purely open source and purely proprietary are equally ineffective extremes, and that the truth lies in some hybrid of the two. The article continues as a case study of three companies: Apple, IBM, and Sun Microsystems.
By way of introduction, the paper makes two points – first the obvious point that a complete abandonment of traditional property rights in favor of totally open licensing would have taken away the very thing that had made these companies successful in the first place – the proprietary differences between their software and their competitors. It points out as well that an initial hurdle for a potential alliance between corporation and open source is the latter’s lack of central management – with whom can a corporation negotiate without a central leader to definitively represent an open source project as large as, say, Linux?
The first case study is that of Apple, a company that faced increasing obsolescence of its core operating system (Mac OS) by the mid-1990s, and was unable to come up with a viable proprietary alternative. Apple’s strategy was to “embrace and enhance” existing open source technologies, and to this end it made headlines when it released the core of its new operating system, Mac OS X, as a fully open source project. It retained its competitive advantage, however, by releasing only material which was essentially already available, keeping proprietary the graphical interface which differentiated its product from competitors’ and other high-level components.
IBM embraced open source products in a similar way when the chose Apache, the open source web server, as the basis for their new line of server products. This adoption proved to be a boon for the Apache project, which received support from a major corporation. IBM’s adoption of Linux came later, but its portability (one of the foci of the open source movement) eventually allowed IBM to use Linux as the standard platform for a variety of products. In IBM’s commercial model, money isn’t made off the products themselves, but in the pairing of software with hardware, support, consulting, and other services.
Sun, although initially hesitant to embrace open source, eventually opened up several of its projects under restrictive licenses that allowed people to view and modify the source, but not to redistribute it for profit without paying royalties. In this way, Sun protected its property rights and proprietary advantage while reaping the benefits of community involvement with and contribution to its products.
Two important points can be drawn from these cases and from the article itself: firstly it is interesting to note that in the first two cases, where companies adopted previously existing products, they adopted products whose licenses allowed commercial derivative works. The license governing Linux and many other open source projects does not allow this; this is an important distinction. The second point is the contrast between Apple and Sun’s strategy – open parts vs. partly open. While Apple retains competitive advantage by opening only parts of their product (open parts), Sun retains their advantage by opening their products with important limitations that preserve that advantage (partly open).
By way of introduction, the paper makes two points – first the obvious point that a complete abandonment of traditional property rights in favor of totally open licensing would have taken away the very thing that had made these companies successful in the first place – the proprietary differences between their software and their competitors. It points out as well that an initial hurdle for a potential alliance between corporation and open source is the latter’s lack of central management – with whom can a corporation negotiate without a central leader to definitively represent an open source project as large as, say, Linux?
The first case study is that of Apple, a company that faced increasing obsolescence of its core operating system (Mac OS) by the mid-1990s, and was unable to come up with a viable proprietary alternative. Apple’s strategy was to “embrace and enhance” existing open source technologies, and to this end it made headlines when it released the core of its new operating system, Mac OS X, as a fully open source project. It retained its competitive advantage, however, by releasing only material which was essentially already available, keeping proprietary the graphical interface which differentiated its product from competitors’ and other high-level components.
IBM embraced open source products in a similar way when the chose Apache, the open source web server, as the basis for their new line of server products. This adoption proved to be a boon for the Apache project, which received support from a major corporation. IBM’s adoption of Linux came later, but its portability (one of the foci of the open source movement) eventually allowed IBM to use Linux as the standard platform for a variety of products. In IBM’s commercial model, money isn’t made off the products themselves, but in the pairing of software with hardware, support, consulting, and other services.
Sun, although initially hesitant to embrace open source, eventually opened up several of its projects under restrictive licenses that allowed people to view and modify the source, but not to redistribute it for profit without paying royalties. In this way, Sun protected its property rights and proprietary advantage while reaping the benefits of community involvement with and contribution to its products.
Two important points can be drawn from these cases and from the article itself: firstly it is interesting to note that in the first two cases, where companies adopted previously existing products, they adopted products whose licenses allowed commercial derivative works. The license governing Linux and many other open source projects does not allow this; this is an important distinction. The second point is the contrast between Apple and Sun’s strategy – open parts vs. partly open. While Apple retains competitive advantage by opening only parts of their product (open parts), Sun retains their advantage by opening their products with important limitations that preserve that advantage (partly open).
This is an interview between an open-source focused news site and a self-described open-source zealot. Although it covers a number of topics with only peripheral importance to my thesis, it highlights a lot of very specific and contemporary issues facing the open source movement.
Van der Linden spends quite a bit of time railing on the inferiority of prevailing proprietary software standards, but also notes that Linux has a long way to come, especially in the areas of software availability and integration. When asked about the biggest barrier, he states that it’s the fact that Linux is not already number one. While this is not a specific failing of the open source model, the fact that (at least on the desktop) open source came along fairly late in the game, and with substantially less marketing clout suggests that there are perhaps markets where Linux is not destined to succeed.
Van der Linden spends quite a bit of time railing on the inferiority of prevailing proprietary software standards, but also notes that Linux has a long way to come, especially in the areas of software availability and integration. When asked about the biggest barrier, he states that it’s the fact that Linux is not already number one. While this is not a specific failing of the open source model, the fact that (at least on the desktop) open source came along fairly late in the game, and with substantially less marketing clout suggests that there are perhaps markets where Linux is not destined to succeed.
This is a blog post that outlines the history of reverse engineering in the technology industry, and comments on some of its implications today. With increasing legal challenges from the DMCA – a law that (among other things) prohibits reverse engineering of any technology meant to limit access, it is interesting to recognize what reverse engineering can and has accomplished for us.
The first two examples of reverse engineering that the article gives are open source projects. The ability of open source developers to reverse engineer the competing instant messaging clients developed by internet companies like Yahoo, AOL, and Microsoft has had a dual effect – firstly, the article points out, it has allowed innovation by letting third-party developers (open source or otherwise) to create hybrid programs that bridge the inherent gaps in these incompatible protocols. Additionally, the presence of quality open source messaging software has helped to further the legitimacy of open source platforms such as Linux.
The second example is that of Samba, an open source program that allows Microsoft Windows based file sharing services to be both hosted on or accessed by any number of platforms. Because of Samba, users of Apple’s Mac OS X or Linux can interoperate with Microsoft Windows networks. The article points out that this has (also) lent legitimacy to Linux as a platform and helped it to compete in a world of proprietary standards.
The first two examples of reverse engineering that the article gives are open source projects. The ability of open source developers to reverse engineer the competing instant messaging clients developed by internet companies like Yahoo, AOL, and Microsoft has had a dual effect – firstly, the article points out, it has allowed innovation by letting third-party developers (open source or otherwise) to create hybrid programs that bridge the inherent gaps in these incompatible protocols. Additionally, the presence of quality open source messaging software has helped to further the legitimacy of open source platforms such as Linux.
The second example is that of Samba, an open source program that allows Microsoft Windows based file sharing services to be both hosted on or accessed by any number of platforms. Because of Samba, users of Apple’s Mac OS X or Linux can interoperate with Microsoft Windows networks. The article points out that this has (also) lent legitimacy to Linux as a platform and helped it to compete in a world of proprietary standards.
tagged computers decss dvd free_software instant_messaging linux open_source oss samba software
by haw
...on 28-NOV-06
LERNER,J . "Some Simple Economics of Open Source" The Journal of industrial economics [0022-1821] 50.2 (2002). 197-.
This paper represents the seminal work on the structure and workings of the open source movement – many of the other works in this bibliography contain references to it and recapitulations of its points. Beyond its description of the general structure of open source projects and incentives (see author’s annotation of Bonaccorsi and Rossi, 2003), it provides an in-depth analysis of the relationship between corporations and open source projects.
The paper draws an interesting comparison between the corporate sponsorship of the open source movement, which the literature suggest is related to scientific research both in its driving motivations (Bonaccorsi and Rossi, 2003) and its origins, and the employment of the scientific community by pharmaceutical companies. The benefits of both the volunteer open source and academic scientific communities are similar, and companies find success in leveraging these benefits by sponsoring those communities.
An essential point is made when the article points out that open source projects have been most effective in communities where the users are technically-minded, presumably because these users are more willing and able to compensate for the open source community’s lack of progress in the areas of user friendliness and documentation (Bonaccorsi and Rossi, 2003). The paper describes the history and structure of four specific successful open source projects; all of them products meant for system administrators and programmers, rather than end users. This and the paper’s characterization of the open source community as “elitist” seem to support my contention that a community of technically-minded developers creates products suitable for technically-minded users, rather than everyday end users.
The paper discusses at length the contrast between the open source model of leadership, in which there is no “formal authority” that must be obeyed, but only the “real authority” of respected peers who have made leading contributions that are congruent with the developer’s goals. The paper cites evidence that there is little mirroring in commercial software development operations of the open source principles of community visibility of individual contributors and the general desire to make the project accessible to all potential contributors.
Three commercial strategies embracing open source are outlined: the symbiotic relationship, in which companies provide components of an open source project that are either missing from or complimentary to the community’s development; the “code release” strategy, in which companies find it profitable to release internally-developed code as open source in order to stimulate other parts of their profit model; and the support model, in which companies provide products that assist the mass success of the open source model itself, rather than working within it.
The paper draws an interesting comparison between the corporate sponsorship of the open source movement, which the literature suggest is related to scientific research both in its driving motivations (Bonaccorsi and Rossi, 2003) and its origins, and the employment of the scientific community by pharmaceutical companies. The benefits of both the volunteer open source and academic scientific communities are similar, and companies find success in leveraging these benefits by sponsoring those communities.
An essential point is made when the article points out that open source projects have been most effective in communities where the users are technically-minded, presumably because these users are more willing and able to compensate for the open source community’s lack of progress in the areas of user friendliness and documentation (Bonaccorsi and Rossi, 2003). The paper describes the history and structure of four specific successful open source projects; all of them products meant for system administrators and programmers, rather than end users. This and the paper’s characterization of the open source community as “elitist” seem to support my contention that a community of technically-minded developers creates products suitable for technically-minded users, rather than everyday end users.
The paper discusses at length the contrast between the open source model of leadership, in which there is no “formal authority” that must be obeyed, but only the “real authority” of respected peers who have made leading contributions that are congruent with the developer’s goals. The paper cites evidence that there is little mirroring in commercial software development operations of the open source principles of community visibility of individual contributors and the general desire to make the project accessible to all potential contributors.
Three commercial strategies embracing open source are outlined: the symbiotic relationship, in which companies provide components of an open source project that are either missing from or complimentary to the community’s development; the “code release” strategy, in which companies find it profitable to release internally-developed code as open source in order to stimulate other parts of their profit model; and the support model, in which companies provide products that assist the mass success of the open source model itself, rather than working within it.
Nichols,DM . "The Usability of Open Source Software" First Monday [1396-0466] 8.1 (2003). 59-.
This paper establishes what could potentially be one of the greatest shortcomings of the open source model – the inability to create software usable by the general populous. The paper begins by establishing that proprietary software dominates the average user’s experience. It points out that usability is a problem for all software, not just open source projects, but also that users of open source software tend to be more technically-inclined (Lerner and Tirole, 2002).
There is an established idea in the usability community that software developers do not make good usability designers. This proves problematic for the open source movement, since one of the central tenets is that the software is conceived and developed by individual software developers. There is neither outside perspective available to mandate the hiring of usability professionals, nor capital available to do so. Usability professionals, the paper states, are not prevalent in open source projects the way that developers are because there are fewer of them to begin with, and therefore fewer peers to recognize any individual contributions to usability – peer recognition being one of the most agreed upon incentives for open source development.
The paper outlines some of the other problems related to usability in open source, notably that usability design works best when done before any software development, anathema to the open source model of progressive improvement on rough development. Furthermore, many open source projects try to emulate commercial software, leaving little room for usability innovation. Finally, in a collaborative community with little central authority, it is logistically delicate to remove excessive functionality that may confound usability.
There is an established idea in the usability community that software developers do not make good usability designers. This proves problematic for the open source movement, since one of the central tenets is that the software is conceived and developed by individual software developers. There is neither outside perspective available to mandate the hiring of usability professionals, nor capital available to do so. Usability professionals, the paper states, are not prevalent in open source projects the way that developers are because there are fewer of them to begin with, and therefore fewer peers to recognize any individual contributions to usability – peer recognition being one of the most agreed upon incentives for open source development.
The paper outlines some of the other problems related to usability in open source, notably that usability design works best when done before any software development, anathema to the open source model of progressive improvement on rough development. Furthermore, many open source projects try to emulate commercial software, leaving little room for usability innovation. Finally, in a collaborative community with little central authority, it is logistically delicate to remove excessive functionality that may confound usability.
tagged computers free_software human_interface_design linux open_source oss software usability
by haw
...on 28-NOV-06
Simons,B . "To DVD or Not to DVD" Communications of the ACM [0001-0782] 42.5 (1999). 31-.
This article outlines the tremendous obstacle presented to users of technology by the content-owning industry. Although the article is fairly short in length, it outlines the challenges posed by the DMCA and the entertainment lobby in general. It outlines the fallout from the release of DeCSS, the controversial program that allows users to break content encryption on DVDs. While DeCSS certainly has illegal uses, its released proved to be a boon to the open source community, as it allowed DVDs to be played on Linux.
Because of the decentralized nature of the open source movement uses of technology that require strict licenses is necessarily limited as there is no governing body to obtain and regulate use of licenses. This is especially true with licenses that prohibit disclosure of the underlying technology, as does the license from the DVD Copy Control Association. As a result of this, the extremely aggressive legal tactics of the content-owning industry pose a potential threat to the ability to choose what computer software to use, although it is interesting to note that it’s not clear that they have actually posed any hindrance to the open source movement.
Because of the decentralized nature of the open source movement uses of technology that require strict licenses is necessarily limited as there is no governing body to obtain and regulate use of licenses. This is especially true with licenses that prohibit disclosure of the underlying technology, as does the license from the DVD Copy Control Association. As a result of this, the extremely aggressive legal tactics of the content-owning industry pose a potential threat to the ability to choose what computer software to use, although it is interesting to note that it’s not clear that they have actually posed any hindrance to the open source movement.
tagged computers copy_protection decss dmca dvd free_software linux open_source oss software
by haw
...on 28-NOV-06
Bonaccorsi,A . "Why Open Source software can succeed" Research policy [0048-7333] 32.7 (2003). 1243-.
This paper takes a more theoretical approach to why open source software is successful as a model, although in contrast to other literature (von Hippel, 2001), it relates this theory extensively with real world examples from the open source movement. The paper starts with three questions: why do people work on open source projects, how is work on open source projects organized, and how can open source projects challenge established commercial standards.
In its examination of the first question (why do people work on open source projects?), this paper highlights a point essential to my thesis – that there is a substantial group of software users who are incapable of being software developers – i.e. that the “users as developers” model (von Hippel, 2001) is at best partially true. A subset of users who are either computer hobbyists or “hackers” are the ones doing the actual development of open source software. The article lists several potential motivations: a intellectual gratification similar to that found in scientific research, a passion for the art form of software development, a pleasure taken in an unrestricted creativity not found in today’s corporate world, and (as in Crowston, et al, 2003) visibility to potential employers.
This paper describes the genesis of an open source project as stemming from an “unfilled market” – an individual has a problem for which no commercial product exists, identifies others facing the same problem, and as progress is made in solving that problem, the community of people working to solve their common problem builds and is fostered by constant communication of progress. Leadership emerges naturally from this process – those most involved in the project and most willing/able to progress the project become natural leaders. Specific tasks are not delegated – the project relies on the willingness of its members to solve problems of their choosing as they arise. If this does not effectively solve the project’s problems, an impasse is created, and the project will fade.
This model relies on the assumption that all problems faced by a project will be interesting to and solvable by some member of that project. This paper points out that this is not always the case – certain “non-sexy” problems, including user-friendliness, documentation, and support, fall by the wayside. Their solution in the open source community has been brought by commercial ventures with a “hybrid” business model – that is, they rely on volunteer efforts for the product themselves, but then profit by providing the elements not provided by volunteers themselves. This establishes the essential symbiosis between open source projects and commercial ventures in which the benefits of the volunteer/community model are present, yet corporate sponsorship lends both security and profitable, requisite gap filling.
This paper is less clear in its answering of the third question (how can open source projects challenge established commercial standards?) although it introduces two important points. The first is that there exists “the tendency for that which is ahead to get further ahead, for that which loses advantage to lose further advantage.” The second point the paper introduces is that choice of a product is influenced less by total popularity of that product and more by popularity within a social network.
In its examination of the first question (why do people work on open source projects?), this paper highlights a point essential to my thesis – that there is a substantial group of software users who are incapable of being software developers – i.e. that the “users as developers” model (von Hippel, 2001) is at best partially true. A subset of users who are either computer hobbyists or “hackers” are the ones doing the actual development of open source software. The article lists several potential motivations: a intellectual gratification similar to that found in scientific research, a passion for the art form of software development, a pleasure taken in an unrestricted creativity not found in today’s corporate world, and (as in Crowston, et al, 2003) visibility to potential employers.
This paper describes the genesis of an open source project as stemming from an “unfilled market” – an individual has a problem for which no commercial product exists, identifies others facing the same problem, and as progress is made in solving that problem, the community of people working to solve their common problem builds and is fostered by constant communication of progress. Leadership emerges naturally from this process – those most involved in the project and most willing/able to progress the project become natural leaders. Specific tasks are not delegated – the project relies on the willingness of its members to solve problems of their choosing as they arise. If this does not effectively solve the project’s problems, an impasse is created, and the project will fade.
This model relies on the assumption that all problems faced by a project will be interesting to and solvable by some member of that project. This paper points out that this is not always the case – certain “non-sexy” problems, including user-friendliness, documentation, and support, fall by the wayside. Their solution in the open source community has been brought by commercial ventures with a “hybrid” business model – that is, they rely on volunteer efforts for the product themselves, but then profit by providing the elements not provided by volunteers themselves. This establishes the essential symbiosis between open source projects and commercial ventures in which the benefits of the volunteer/community model are present, yet corporate sponsorship lends both security and profitable, requisite gap filling.
This paper is less clear in its answering of the third question (how can open source projects challenge established commercial standards?) although it introduces two important points. The first is that there exists “the tendency for that which is ahead to get further ahead, for that which loses advantage to lose further advantage.” The second point the paper introduces is that choice of a product is influenced less by total popularity of that product and more by popularity within a social network.