Open

Open Source Biotechnology Project

Copyright (c) 2003 Janet Hope, Research School of Social Sciences, Australian National University, Canberra, ACT 0200. Verbatim copying and distribution of this site is permitted in any medium, provided this notice is preserved.

Open Source as a Business Approach

The purpose of this section of the website is to describe, in general terms, how open source business models work so as to provide a starting point for discussion of what would be involved in translating the open source approach from the software to the biotechnology context.

Preliminary points

What biotechnology businesses do I have in mind?

What "standard of proof" is required in order to make out a successful case in favour of generalising the open source business approach to biotechnology?

How open source business models differ from standard business models in software and in biotechnology

Standard models emphasise end value

Open source models emphasise use value

Essential elements of an open source business model

Maximising use value

How can harnessing the input of many users improve the use value of a tool?

Building a user community

(a) motivating participants

(b) structure and infrastructure

Translating increased use value into economic value for the firm

General competitive advantages

Specific business models

(a) Choosing a business model

(b) Choosing a licence

The open source/closed source trade-off

General predictors of outcome

Preliminary points

What biotechnology businesses do I have in mind?

I envisage two kinds of audience for my attempts to determine the viability of open source biotechnology as a business model. The first is made up of companies that release, sell and/or support biotechnology research tools commercially. In this category there are two subcategories: startups and established firms. Startups may be a tougher crowd because they are only likely to get one stab at getting established and may prefer what they see as the safer option of adopting the familiar IP-rent approach. On the other hand, established firms have more to lose by converting to a new approach.

The second audience is made up of companies and other institutions (such as universities and public research institutions) that use a particular research tool as a core component of their business process or research program. For example, large firms may conduct in-house gene sequencing even though such a service is not part of their commercial offering. Members of this group would benefit directly from any improvement in the use value of the tool. As many research tool companies (first group, above) also use their own proprietary tools as tools to produce their next round of IP, there is likely to be significant overlap between these categories.

The fact that both groups usually engage in some research also means they both need access to and freedom to operate with other people's tools and are therefore vulnerable to other intellectual property owners' attempts to restrict that access. This means both groups may have an interest in promoting open source licensing of other tools, even if they prefer to keep their own tools closed.

What "standard of proof" is required in order to make out a successful case in favour of generalising the open source business approach to biotechnology?

In the software context, it has been noted that the open source business model goes against years of commercial practice and therefore requires justification. (Of course, it might be as easily argued that commercial practice itself goes against years of academic practice, in both computer science and biological research, so it isn't clear where the onus of proof should lie!) In relation to the idea of open source genomics, skeptics have asserted that commercial practice in biotechnology has traditionally been even more closed than in software development, and that the closed approach to intellectual property management is therefore likely to be even more entrenched in the biotechnology arena; this assertion may or may not be correct, although in any case it is a generalisation.

Assuming justification is required, what standard of persuasiveness should be adopted? In my view, it should not be necessary to show that an open source approach to biotechnology business would succeed most cases (however "most cases" might be defined). Even in the software context, the open source model is not always - probably not even usually - appropriate. Rather, the standard I am aiming for in this study is simply to identify an open source biotechnology business model that could realistically appeal to some players, given the current state of the industry. It is important to bear in mind that in any industry, most new businesses fail, whether they follow an open or closed approach to intellectual property; as has been noted in the software context, considering that all businesses until recently have followed a closed approach, the closed approach is clearly not an easy way to make a living.

References:

Behlendorf, Brian. 1999. Open Source as a Business Strategy. In Open Sources: Voices from the Open Source Revolution, edited by C. DiBona, S. Ockman and M. Stone. Online version: O'Reilly. Available from http://www.oreilly.com/catalog/opensources/book/brian.html.

Hecker, Frank. 2003. Setting Up Shop: The Business of Open-Source Software [Internet]. hecker.org 2000 [cited 21 Jan 2003]. Available from http://www.hecker.org/writings/setting-up-shop.html.

Young, Robert. 1999. Giving It Away: How Red Hat Software Stumbled Across a New Economic Model and Helped Improve an Industry. In Open Sources: Voices from the Open Source Revolution, edited by C. DiBona, S. Ockman and M. Stone. Online version: O'Reilly. Available from http://www.oreilly.com/catalog/opensources/book/young.html

Raymond, Eric S. 2001. The Magic Cauldron. In The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. 2001. Online version: O'Reilly. Available from http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/. http://www.oreilly.com/catalog/cathbaz/

How open source business models differ from standard business models in software and in biotechnology

A tool can have two kinds of economic value: value as a final good -- an end product that can be sold or licensed -- and value as an intermediate good, i.e. as a tool. In principle, a business could extract value from either or, with respect to different aspects of the business' commercial offering, both.

Standard models emphasise end value

Standard business models in both software and biotechnology aim to extract economic benefit primarily from the value of tools as end products (ie their value as final goods). The business creates the tool, fences it around with intellectual property protection, and derives revenue by selling the tool or, more commonly, charging frees for access under a licensing agreement.

From a business perspective, this IP-rent extracting model has a number of advantages. The relevant property transactions can be tailored in a range of ways, e.g. to allow for price discrimination. Fees can be charged independent of any services provided, which makes it possible for a new business to start small but grow quickly. Most importantly, the price charged for the product need not bear any proportional relationship with the initial costs -- so profit margins can potentially get very large.

However, because the IP-rent extracting strategy relies directly on restricting access to the tool, it also has a number of costs. From a public interest perspective, the main costs are higher prices in the short term (the well-recognised cost of granting a monopoly) and threats to future innovation in the longer term. In the longer term, of course, the company itself also has an economic interest in ensuring continuing innovation so it can remain competitive as the market changes.

Less obviously, restricting access to intellectual property poses an immediate economic challenge to the company: it alone must generate all of the value offered to its customers. This is particularly hard for smaller companies because their resources - money, people, time - are more limited, but it is a cost for any company, no matter what its size.

References:

Young, Robert. 1999. Giving It Away: How Red Hat Software Stumbled Across a New Economic Model and Helped Improve an Industry. In Open Sources: Voices from the Open Source Revolution, edited by C. DiBona, S. Ockman and M. Stone. Online version: O'Reilly. Available from: http://www.oreilly.com/catalog/opensources/book/young.html

Hecker, Frank. 2003. Setting Up Shop: The Business of Open-Source Software [Internet]. hecker.org 2000 [cited 21 Jan 2003]. Available from http://www.hecker.org/writings/setting-up-shop.html.

The Magic Cauldron, in Raymond, Eric S. 2001. The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. 2001. Online version: O'Reilly. Available from http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/. http://www.oreilly.com/catalog/cathbaz/

Open source models emphasise use value

The open source approach offers an opportunity to address these economic challenges by expanding the resources available to the company to include resources that lie outside the firm boundary. In this model, the company allows users access to its intellectual property, and in return it gets help with developing the tool instead of having to do everything on its own. Open source licences support this strategy in two ways. The first is purely practical: users cannot become codevelopers of a tool unless they have access to that tool in a form that they can understand and modify. In the software context, this issue is addressed by the requirement to provide access to source code; an open source biotechnology licence would also need to guarantee such access one way or another. The second relates to users' incentive to contribute to a co-operative effort: if potential contributors expect to be prevented from using the tool that they helped to create, they will be reluctant to contribute in the first place. Seen in this light, the open source prohibition on terms restricting use, redistribution and modification of licenced subject matter is a way of shoring up the motivation of potential contributors.

Not only do open source business models offer a way around resource constraints for individual businesses, they also preserve many of the advantages (from a public interest/long term innovation perspective) of straight-out donations of intellectual property to the public domain as per traditional academic practice. Importantly, open source licensing of intellectual property does not entail giving up ownership of the property; rather, ownership rights are exploited (through licensing agreements) to harness the input of a large number of users or potential users to create and/or improve the tool. Yet because open source licences allow use, redistribution and modification of subject matter without imposing any fee, intellectual property that is subject to such licences has been characterised in efforts to map the public domain as "contiguous territory".

There is, of course, a downside from the business perspective. Clearly, open source prohibitions on restrictive licensing terms are incompatible with standard "proprietary" business models in both software and biotechnology contexts because they prevent intellectual property owners from charging for access and thereby eliminate what may be a business's primary source of revenue.

It is therefore not surprising that the idea of licensing proprietary tools on open source terms tends to meet with resistance from business audiences. By asking companies to allow everyone, including competitors, free access to their intellectual property, such licences appear to ask businesses to "give away the crown jewels" and commit financial suicide. But, as has been pointed out in the software context, intellectual property assets -- like any other assets -- are only valuable to the extent that owning them can be converted to some kind of income stream or other type of economic advantage for the company. If it were possible to create more value for the company by allowing free access to intellectual property than could be created by restricting access, it would make perfect business sense to "give away the crown jewels".

In summary, proponents of open source business models argue that, at least sometimes, it is possible to extract equal or greater economic benefit from a tool's value as an intermediate good (its use value) as from its value as a final good. Open source business models seek first, to maximise use value by gaining input of many users, and second, to extract economic benefit from that increased use value. The next section explores the details of these two essential elements of the open source business model.

References:

Open Source Initiative, "Open Source Case for Business", http://www.opensource.org/advocacy/case_for_business.php

Hecker, Frank. 2003. Setting Up Shop: The Business of Open-Source Software [Internet]. hecker.org 2000 [cited 21 Jan 2003]. Available from http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/.

Kennedy, Dennis M. A Primer on Open Source Licensing Legal Issues: Copyright, Copyleft and Copyfuture. Available at http://www.denniskennedy.com/index.htm.

Perens, Bruce. 1999. The Open Source Definition. In Open Sources: Voices from the Open Source Revolution, edited by C. DiBona, S. Ockman and M. Stone. Online version: O'Reilly. Available from http://www.oreilly.com/catalog/opensources/book/perens.html.

Essential elements of an open source business model

The last five years have seen the emergence of many successful commercial enterprises based on open source software licensing. Among them they represent a great variety of business models and a corresponding variety of open source licences. In this section, I outline what appear to be the common or essential elements of the open source approach to business. To show that the concept of "open source biotechnology" may be workable, these elements must somehow be translated into the biotechnology context.

This analysis is in its early stages; developing it to the point where the last sentence of the previous paragraph can be stated with confidence is a substantial part of the project described in this website. As with other sections of the website, comments are most welcome.

Maximising use value

The first essential element of an open source business plan is to maximise the use value of the intellectual property in question (in the context of this study, a biotechnology reserach tool). This section first explains how harnessing the input of many users can enhance the use value of a tool, then turns to the question of how to harness that input by building a community of users/codevelopers.

How can harnessing the input of many users improve the use value of a tool?

A number of factors contribute to the use value of any tool. Improvements in the value of a tool to its user could result from improved understanding on the part of the user as to how the tool works or from improved skill on the part of the user. They could result from improvements in the tool's quality, including improvements to accuracy, reliability, versatility and/or suitability for a specific job, interoperability, or adaptability/ robustness to changes in the working environment. They could result from improved availability in terms of physical access - e.g. more local suppliers, reductions in cost or assurances of continuing availability irrespective of the vendor's continued existence or of changes in the vendor's business strategies - or in terms of freedom from legal entanglements, eg freedom to use the tool to produce a commercial offering without the risk of an infringement suit.

The importance of any of these aspects of use value in relation to a particular tool will depend on the nature of the tool and the specific circumstances of the user. While most aspects of use value just listed have been drawn mainly from the popular "hacker" literature on open source software tools, it is certainly possible to envisage situations in which each of these aspects could be crucial in the biotech context as well.

For example, improved understanding of how a tool works may be extremely valuable in the biotech context because many biotechnology tools were not designed from scratch by humans, but instead consisting of living organisms that have useful functions but are incompletely understood because of their complexity.

The open source approach of involving a large number of users in the development of a research tool contributes to quality improvements in two ways. First, "given enough eyes, all bugs are shallow": as demonstrated by the Linux project, a large group of users can eliminate design flaws and introduce enhancements very rapidly. Second, the existence of a development community that includes both users and owners of the tool allows users to communicate needs and priorities to owners so that overall development efforts are more likely to be directed towards the most useful tasks.

The open source approach also contributes to improved availability. One way is by ensuring that the tool is possessed (even if not legally owned) by a community instead of just one company, or even a single employee. This makes its availability less vulnerable to changes in the fortunes or intentions of individual people or firms. Another way is by ensuring -- by definition, although the specifics depend on the license chosen -- some degree of freedom from legal entanglements, often expressed as freedom to operate. There is no doub that freedom to operate is an important consideration for partipants in the biotechnology industry.

Apart from improved understanding, quality and availability, improvements in use value sometimes result directly from an increase in the number of users of a given tool. By guaranteeing unrestricted access and attracting new users through improvements in availability and quality, the open source approach may maximise the positive network externalities associated with a particular tool. Because living organisms share common features at the molecular level (including but not limited to the genetic code) and yet are highly complex, such network effects are pervasive in biotechnology research.

References:

Knight, Tom. Idempotent Vector Design for Standard Assembly of Biobricks. MIT Artificial Intelligence Laboratory, www.syntheticbiology.org/docs/sa3.pdf http://www.syntheticbiology.org/docs/sa3.pdf

Open Source Initiative, "The Open Source Case for Customers", http://www.opensource.org/advocacy/case_for_customers.php

Hecker, Frank. 2003. Setting Up Shop: The Business of Open-Source Software [Internet]. hecker.org 2000 [cited 21 Jan 2003]. Available from http://www.hecker.org/writings/setting-up-shop.html.

Building a user community

A business that decides to license its intellectual property on open source principles in order to maximise the use value of the property is effectively setting out to become the "owner" (though not necessarily in a technical legal sense: users still own their own contributions, unless there is an assignment of contributions as in the case of the Free Software Foundation) or leader of an open source project. In the software world, the role of a project leader is to:

1. Provide the base intellectual content for the project and continue to seed it with new contributions. This may be relatively straightforward if the tool already exists and managment of the tool is changing from a standard proprietary model to an open source model, but may involve more effort in relation to a new tool. Experience in the software context suggests that cooperative development is most successful if developers can work with an existing body of material.

2. Set up and maintain an effective community structure that maximises users' motivation to contribute to the project. The next two sections address these issues.

3. Keep up morale. As Al Gilman, founder of the Alliance for Cellular Signalling, has said, there should be "money in the budget for pom-poms". To do this effectively, project leaders need certain social and communication skills (ie "leadership qualities"!).

These functions would presumably need to be performed in a biotech project as well.

Each of these tasks entail costs to the business in question that must be taken into account in calculating the trade-off between open source and conventional business strategies. In a successful open source business plan, by definition, the benefits of a having a large group of developers will outweigh these costs. In the standard proprietary approach, the first task just listed -- providing intellectual content -- falls in its entirety to the business that owns the research tool and presumably therefore involves higher costs to the business than in the open source model. Something like the third task is performed in most businesses by management. [See Benkler on advantages of firm mode of production.]

It might be assumed that the second task -- the building of a user community -- has no counterpart in the traditional proprietary business model. Interestingly, recent work in the sociology of science suggests that there is always substantial work to be done in transforming a new research tool into something that is useful outside the local context in which it is first developed, and that this work entails constructing extended user networks. In other words, even though the cost of building a user community may sometimes, perhaps even usually, be greater in relation to open source development, and the community itself will be qualitatively different,the closed source approach does involves some costs along these lines -- marketing costs, for example.

[Add note: AfCS is bearing many of these infrastructure-building costs out of the glue grant. Could you bear them out of returns?]

(a) motivating participants

The problem of how to motivate participants in a distributed cooperative development effort without paying for their labour in money terms has been discussed extensively elsewhere. (See Benkler's paper for a review of popular and academic literature on the subject). In the software context, such discussion attempts to explain why open source works -- evidently, in some circumstances at least, it does work -- whereas in the biotechnology context, it is not yet apparent whether an open source approach is feasible.

Possible motivations for contributing to an open source project that have been noted in the software context and would presumably also exist in the biotechnology arena include a desire for enhanced reputation among peers, either as a reward in itself or as a means of obtaining secondary benefits (including financial benefits, e.g. through lucrative consulting contracts); a desire for enhanced knowledge or for an improved tool; a hope of changing industry structure over the long-term, whether for ideological reasons or in response to frustration or injustice resulting from domination of the industry by a few big players;a desire to prevent business losses arising from vulnerability to other intellectual property owners' commercial strategies; and the prospect of possible future gains through providing related services or products on the shared technology platform established by the project.

One supposed problem with motivating participants in open source projects is that the cooperative effort will be undermined by the threat of free riding: if contributing to the development of a tool costs something, whereas using a tool that has been developed by others costs nothing, why should anyone become a contributor? The best answer is, I think, that contributors to a project are in a position to control its direction so that the outcome is more useful to them and to obtain other benefits (such as enhanced reputation) that cannot be obtained by free riding; at the same time, the costs of contribution to a properly designed cooperative project are smaller than the costs of developing a tool from scratch in-house. If there are enough potential developers for whom the rewards to be gained by contributing to the project are more attractive than free riding, the project will succeed; and because end-users would not be charged for or excluded from access either way, it does not matter how many of them are free riders. In fact, as long as there are enough people motivated to contribute to development to make a project viable, the more free riders there are, the better, as many of the advantages of open source hinge on expanding the total number of users of the tool in question. [But this is a matter for further consideration.]

Even if free riding is not a problem, there are some real potential obstacles to inducing researchers to participate in an open source project, whether in software or biotechnology. One issue is whether individual researchers will in fact be free to contribute intellectual property they have generated to a common pool. Provisions in employment contracts stipulating that intellectual property is to remain the property of the employer may prevent participation, as may similar constraints associated with the terms of sponsorship or of funding agency grants. Despite the stereotype of the hobbyist hacker, and contrary to some expressed objections to the idea of open source biotechnology, this kind of problem does exist in the software context: open source software development draws on the same talent pool as conventional development. Participants may be individuals working from home in their own time, but some are also employed programmers whose employers support their participation in open source projects. There is no reason in principle why biotechnology companies, research institutions or funding bodies might not endorse certain open source projects and allow their workers to participate in them. In practice, this issue will be worth investigating as part of the present study.

Another possible obstacle is that the costs of actually contributing to the project (as distinct from creating the contribution) may be too high relative to the motivation to contribute -- Eric Raymond calls these "friction costs", and notes that they are higher the more hoops the contributor must jump through in terms of quality control, documentation etc. [In Benkler's terms, these fall into the category of integration costs. Benkler's paper and the other academic OS literature has not yet been incorporated into this branch of the website.] It should be noted that there is a balance to be struck between setting up a project that is tightly organised and controlled, thereby optimising certain types of motivations such as enhanced reputation, and setting up a project that is loosely organised and therefore has lower friction costs. Friction costs in biotechnology research may be higher than in software development for the fundamental reason that much of the information involved may be less highly codified and therefore harder to check or verify, but this may not be so in every case.

Other costs of contributing are likely to be higher with respect to biotechnology research simply because most biotechnology research is more time-consuming and capital intensive than most software development. This is relevant to the question of motivation because the more a contributor must invest in order to contribute, whether in time, money or other resources, the greater must be the reward in order to make contribution worthwhile. However, we should not be too quick to make assumptions about the cost of contribution. Not all biotechnology research is equally costly, and there may be some links in the chain of a research program that is very costly overall that are themselves quick or cheap enough to be amenable to distributed development. [Benkler: granularity, modularity is relevant here.] Similarly, software development does entail some capital costs. At what point does the proportion of overall costs attributable to labour costs in any given enterprise cross the threshold from being too low for open source to be an appropriate mode of production to being high enough for the advantages of open source to outweigh disadvantages? It is unlikely that this question can never be answered in general terms, but in any case, we do not yet know.

A final obstacle worth mentioning here is that some projects may have such limited appeal, for example because the research tool in question is highly specialised, that there are too few potential contributors with the interest and ability to keep the project going. This will be true of some projects in software and in biotechnology, and in such cases the standard proprietary model may be more suitable.

Some potential obstacles to motivating participants in an open source project are real, but because they hinge on the specific circumstances of the case, they cannot be effectively addressed in general terms; further exploration of these issues must await interviews and case studies. However, one issue that can be at least partially addressed in general terms is that of how to structure a developer community that maximises the value of contributions to the project (and therefore indirectly to the contributor in terms of improving use value), to the contributor personally (e.g. reputation etc) relative to the effort involved in making contributions (friction costs). From the perspective of the prospective project leader, it is of course also desirable to keep the costs of receiving distributions down. The next section contains some observations about optimal community structure.

(b) structure and infrastructure

In conventional product development, management performs a number of functions, including defining goals, monitoring for gaps, motivating participants to do drudge work, organising deployment of people for maximum productivity and raising/marshalling funds. Eric Raymond argues that an open source approach makes these functions redundant, and Benkler argues that one advantage of the open source approach is that individual developers who self-select for a task will be more efficiently deployed for maximum productivity than employees acting under management direction.

It is not clear how far these arguments would go in the biotechnology context, but even in the software context, it has been suggested that a business planning to open source part of its commercial offering should have a dedicated team responsible for managing open source assets and keeping the project alive. A recommended strategy for getting started is to begin by generating some intellectual content, establish a small core set of potential contributors, then decide on a plan for the project and put it to that core set for feedback. If all goes well, the running of the project will be partially taken over by that small group and the project should begin to have a life of its own. The core set of potential contributors will most likely be a subset of current key customers for the product. If participants are expected to be motivated primarily or largely by the prospect of enhancing their reputation within the community, it is also advisable for this initial group to include some well-known members of the wider community with them other potential contributors might wish to be associated -- for example in the biotechnology sphere an eminent expert in the field would help attract junior researchers to the project.

In theory, there are a number of possible project structures. Small projects can be sustained by a single owner-maintainer; as the project becomes larger, it could become a benevolent dictatorship with several owner-maintainers each responsible for a subset of the project. It could involve a two-tiered contribution structure, with ordinary contributors distinct from codevelopers (the Alliance for Cellular Signalling is a cooperative effort, though not strictly an open source project, in the biotechnology sphere that has adopted this general structure). For very large projects, there might be a committee of voters who elect a leader for a term. Several companies with compatible interests could get together and rotate leadership among the group.

As noted in the previous section, there is a tension between keeping friction costs down and achieving tight enough organisation to reach goals within a useful timeframe. Both are necessary if motivation levels are to stay sufficiently high. There is also a tension between creating an effective infrastructure and keeping the costs associated with maintaining that infrastructure down to a level that allows the company that initiates the project to make a profit, or in the case of non-profit research and development, to stay within budget. Every project must strike its own balance, but the observations listed below, derived from real-world experience, may be helpful.

In the software context, the best-known real-world example of open source development is Linux -- though there are many others, including most bioinformatics software. As far as I am aware, there are not yet any real-world examples of open source biotechnology projects, but the Alliance for Cellular Signalling is a useful model with respect to the structuring of an effective cooperative research project in the life sciences. (The AfCS is not open source in a strict sense because intellectual property protection is not sought for information generated in the course of the research -- ie it is donated to the public domain rather than being owned and licensed on the open source terms -- and because intellectual property in research tools developed in the course of the project is retained by private companies according to the standard proprietary model.) The AfCS was one of the first projects to be funded by an NIH "glue grant", and its website deals in impressive details with structural issues, including providing communication channels for the exchange of technical information, project management including goal setting, discipline and conflict resolution, an intellectual property/data sharing plan that includes a uniform material transfer agreement that effectively applies open source principles to tangible property, and a "letter to the community" intended to inspire and motivate potential contributors. Other real-world examples of distributed development efforts in biotechnology include the Human Genome Project (again, not open source because of the policy against patenting sequences), the "Rice Gene Machine" (which has considered open source options) and some development efforts within the Australian Grains Research and Development Corporation.

These real-world examples demonstrate that in order to be effective, an open source project must have some mechanism for performing the following functions:

1. Rapid incorporation of suggested improvements into a new version of the research tool. Contributors will be more highly motivated if they can reap the benefits of their contributions in terms of improved use value soon after contributing. In a business context, they will also be more highly motivated if they have no reason to suspect project leaders of hoarding contributions and delaying the release of new versions for the sake of competitive advantage. In the software context, the relevant adage is "release early, release often".

2. Dispute resolution. One important role of property law is to provide some certainty in transactions, including state-backed dispute resolution mechanisms. Where it is difficult to see internal boundaries within a project, it may be difficult to avoid conflict among contributors or between contributors and project leaders. Informal ownership norms can replace law as a means of resolving disputes, but there must be some way of enforcing these norms. This need not be complex: if everyone's actions are open to scrutiny by other participants in the project, that will often be enough to deter bad behaviour.

3. Quality control. The Human Genome Project and the AfCS both have formal quality control mechanisms that provide examples of possible approaches in biotechnology. Quality screening should be rapid, for the reasons given in item 1.

4. Coordination and communication. A number of software tools are available that make it relatively easy to carry out these functions via the Internet, as in the Linux example and also the Human Genome Project and the AfCS. These include tools for chat facilitation, bug tracking, issue tracking, databases of changes and issues and a range of methods for setting up discussion fora that can run in parallel and can be easily searched by contributors for relevant threads. In the biotechnology context, it may not be possible to communicate entirely by Internet (e.g., it may be necessary to exchange materials by post or transfer technical skills in person). However, in general terms, the minimal infrastructure that any company seeking to run an open source business should be prepared to provide for external developers would comprise newsgroups, improvement repositories with quality control and special reporting systems for design flaws and other problems; it has also been suggested that the company's own developers should be customers of this infrastructure so they can tell whether it is operating efficiently and make improvements as necessary.

References:

Open Source Initiative, "Software secrets: do they help or hurt?" http://www.opensource.org/advocacy/secrets.php

Open Source Initiative, "Jobs for Hackers: Yes, you can eat open source" http://www.opensource.org/advocacy/jobs.php

Open Source Initiative, "Open Source Case for Hackers" http://www.opensource.org/advocacy/case_for_hackers.php

Hecker, Frank. 2003. Setting Up Shop: The Business of Open-Source Software [Internet]. hecker.org 2000 [cited 21 Jan 2003]. Available from http://www.hecker.org/writings/setting-up-shop.html.

Open Source Initiative, "Open Source Case for Business", http://www.opensource.org/advocacy/case_for_business.php

Alliance for Cellular Signaling 2003. [Internet]. Alliance for Cellular Signaling 2002 [cited 3 January 2003]. Available from http://www.cellularsignaling.org/.

Brennan, Geoffrey, and Philip Pettit. 2000. The Hidden Economy of Esteem. Economics and Philosophy 16:77-98.

Wellcome Trust. 1996. Summary of Principles Agreed at the International Strategy Meeting on Human Genome Sequencing. Paper read at International Strategy Meeting on Human Genome Sequencing, at Bermuda, 25 - 28 February 1996.

Wellcome Trust. 1997. Summary of the Report of the Second International Strategy Meeting on Human Genome Sequencing. Paper read at Second International Strategy Meeting on Human Genome Sequencing, at Bermuda, 27 February-2 March 1997.

The Cathedral and the Bazaar, in Raymond, Eric S. 2001. The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. 2001. Online version: O'Reilly. Available from http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ http://www.oreilly.com/catalog/cathbaz/

Homesteading the Noosphere, in Raymond, Eric S. 2001. The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. 2001. Online version: O'Reilly. Available from http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/. http://www.oreilly.com/catalog/cathbaz/

Burk, Dan. 2002. Open Source Genomics. Boston University Journal of Science and Technology Law 8 (Symposium on Bioinformatics and Intellectual Property Law

April 27, 2001, Boston, Mass. (Winter 2002)):254-.

Hecker, Frank. 2003. Setting Up Shop: The Business of Open-Source Software [Internet]. hecker.org 2000 [cited 21 Jan 2003]. Available from http://www.hecker.org/writings/setting-up-shop.html.

Thompson, Nicholas. 2002. May the Source Be With You. The Washington Monthly Online, 1-5.

Alliance for Cellular Signaling 2003. [Internet]. Alliance for Cellular Signaling 2002 [cited 3 January 2003]. Available from http://www.cellularsignaling.org/.

The Magic Cauldron, in The Cathedral and the Bazaar, in Raymond, Eric S. 2001. The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. 2001. Online version: O'Reilly. Available from http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ http://www.oreilly.com/catalog/cathbaz/ (the inverse commons)

Translating increased use value into economic value for the firm

Economic and sociological theories examined in the first part of this website suggest that the social value of a research tool is greatest when it is available to anyone who wants to use it. All else being equal, it follows that the open source approach to intellectual property management of research tools is to be preferred to the standard proprietary approach from a social welfare perspective. But what about the intellectual property owner's perspective?

Up to this point, these pages have explored how open source development methods can be used to maximise the use value of a research tool. Now we turn to the question of how use value can be converted into economic benefit for the company or institution that owns the tool. As discussed in an earlier section, the standard model is to obtain revenue through license fees, but this is precluded by the nature of open source licences, which prohibit the restrictions on access that are an inherent part of the IP-rent extracting model. As we have seen, this prohibition functions to increase motivation to contribute to the cooperative effort by guaranteeing that contributors can realise the improved use value of the tool.

The introduction to this part of the website noted that there are two possible audiences for a discussion of whether open source biotechnology is feasible: companies or institutions that derive revenue directly from making research tools available to others, and companies or institutions that use such tools in their own research programs. In the latter case, improving the use value of the research tool creates a direct economic benefit. In the software world, there are instances of open source business models based purely on improved use value, including cost sharing and risk spreading models (discussed in more detail below). In such cases, where the owner is the primary or only user of the tool, the question is whether the increased value of the tool to the owner through open source development outweighs the costs of making the tool available to competitors. Where the tool is intended mainly to be used by a firm's customers, on the other hand, improved use value alone will be unlikely to justify the loss of intellectual property licensing income involved in converting to an open source approach. In such cases, it is necessary to find other ways to recover some economic benefit from the improved use value of the research tool.

The next two sections deal with two aspects of this problem. The first lists in general terms some competitive advantages that firms might expect to gain by adopting an open source approach to management of some or all of their intellectual property. The second examines specific business models and corresponding licences that have been used in the open source software context, also noting some issues relating to translation of those licences from a copyright environment to a patent environment (of interest because patent protection is the dominant form of IP in biotechnology).

References:

Benkler. 2002. Coase's Penguin, or, Linux and The Nature of the Firm. 112 Yale L.J. (Winter 2002-03). Available at http://www.law.nyu.edu/benklery/.

Koman, Richard. 2002. An Angel for Open Source [internet]. The O'Reilly Network 2002 [cited 17 August 2002]. Available from http://www.oreillynet.com/pub/a/network/2002/07/22/pam.html.

Urban, Jennifer, and Deirdre Mulligan. 2002. Open Source Legal Questions. Paper read at O'Reilly Open Source Convention, July 22-26, 2002, at San Diego, CA July 22-26 2002. Available at: http://conferences.oreillynet.com/cs/os2002/view/e_sess/3322.

Hecker, Frank. 2003. Setting Up Shop: The Business of Open-Source Software [Internet]. hecker.org 2000 [cited 21 Jan 2003]. Available from http://www.hecker.org/writings/setting-up-shop.html.

General competitive advantages

[Note to myself: Word version GBC #2.doc contains further information yet to be incorporated in this section]

Apart from direct revenue-generating activities in secondary markets (discussed below), businesses that choose to adopt an open source approach to some or all of their intellectual property may reap other economic rewards.

These include preventing competitors from getting a choke-hold on the technology in question, redirecting competition from an area in which the company is weak to one in which is strong (for example, the company may be too small to provide a comprehensive package of tools for any given job, but strong at customising the tools it does own), overcoming resource constraints by creating an opportunity for several smaller firms to combine resources against a larger competitor or by lowering research and development overheads, attracting customers away from an established competitor (ie building "mindshare") and growing the market for closed products built on the open source platform.

This last point deserves closer attention. The concept of a technology "platform" is roughly equivalent to the concept of an "enabling technology" or "fundamental tool". In the short-term, a business plan based on ownership of a technology platform coupled with a standard proprietary approach to licensing of the platform is often successful. However, the broader the platform (and hence the more rent-for-access that can be extracted from ownership in the short-term), the greater the incentive for other businesses to invent around it, which means the business plan is vulnerable to ongoing innovation. (In the case of some biotechnology research tools, this may be less of a problem than in the case of many software tools because the conservation of biological functions at the molecular level means it may be more difficult for others to "invent around" or find substitutes for a proprietary tool.) In the longer term, therefore, it may be a better strategy to build on top of an open-source platform, so that changes and improvements in that platform cannot threaten the business's revenue stream.

A shared or common platform is a "standard". Standards facilitate interoperability, which is important in industries where there are significant network effects, including biotechnology. The open source approach to technology development can create and/or encourage the adoption of useful standards because the transparency of open source tools means it is obvious which technology is the best for any given platform function. In addition, open standards lower the barriers to entry of an industry because they are readily accessible to all players. For this reason, open source is a particularly suitable development mode for platforms/enabling technologies.

Tom Knight of the MIT AI lab has noted the need for standardised tools in biotechnology and aims to develop a suite of such tools. [Further information to be added.]

References:

Open Source Initiative, "Open Source Case for Business", http://www.opensource.org/advocacy/case_for_business.php

The Magic Cauldron, in Eric S. 2001. The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. 2001. Online version: O'Reilly. Available from http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ http://www.oreilly.com/catalog/cathbaz/

Specific business models

To start a successful open source business, or to convert from the standard proprietary model to the open source approach, it is necessary (as with any business) to make a detailed business plan. The following two sections deal with two aspects of this process: choosing a business model and choosing an appropriate open source license. The third section under this heading deals with several other issues that must be addressed before a business can "open source" its technology.

(a) Choosing a business model

In the software context, there exist a number of open source business models that have been successful in practice and several further models that so far remain speculative. Some of these software business models may be adaptable to the biotechnology context; some may not; and there may be yet others that would work in the biotechnology arena but not in software development. (The choice of an open source licence will depend on the overall business plan; specific licences are discussed in the next section.) An existing business model may be applied to all the activities of a firm, or only some of its activities: there is no reason why any particular firm should not "mix and match" between open source models, and even (depending on license provisions) between open source and standard proprietary models to create an overall business plan.

A number of businesses and institutions in the biotechnology field have already adopted business/institutional models that are not strictly "open source", but either consciously borrow from the open source model or have evolved independently to have some similar features. Kennedy (Kennedy, D. M., A Primer on Open Source Licensing Legal Issues: Copyright, Copyleft and Copyfuture. Available at http://www.denniskennedy.com/index.htm.) has analysed the range of possible "hybrid models" in terms of a relaxation of one or more key open source license provisions --source code availability, nondiscrimination among users, and nondiscrimination among types of use. Some of these license types are already in use in the biotechnology context (eg CAMBIA has scaled license fees depending on the type of licensee institution), and may provide easier access to intellectual property for users outside the firm than the usual proprietary model. However, these hybrid models are included in the list below for interest only; the purpose of this project is to determine whether open source in its strict sense is feasible in the biotechnology context.

[Note: the following list of open source business models and hybrid business models is a summary in note form, with some of my own comments added in relation to applicability to biotech, of a section of Kennedy's paper: (Kennedy, Dennis M. A Primer on Open Source Licensing Legal Issues: Copyright, Copyleft and Copyfuture. Available at http://www.denniskennedy.com/index.htm.)]

Open source business models include:

1. support seller

most if not all open source licences would work for this model
revenue is generated by selling two broad categories of items -- physical goods and/or services
vendors differentiate themselves by providing more complete and easier to use research tool distributions (e.g. kits) and by the quality and pricing of their service offerings
only limited ability to use value driven pricing because there is price competition from other vendors offering comparable goods and services and lemons to what users are willing to pay for those goods or services, but if vendors's reputation is good that can be used to justify higher prices

[seems most relevant to my unnamed established biotechnology business]

2. Loss leader/market positioner

no charge open source product is used as a loss leader for traditional commercial software
open source product generates little or no revenue part customers are attracted for other products sold using the traditional model
if the other products are built on the open source product, the open source license chosen must allow the intellectual property to be used in proprietary products using standard licences, therefore should avoid the use of GPL or other copy left style licences
BSD-style, Mozilla licences would be fine
click generates some revenue from the open source product as in the support sellers model, e.g. selling services, but typically the bulk of revenue generated would-be through sales of other close source products -- increased sales would be because of
- building overall vendors brand and reputation
- making the traditional products more functional and useful, i.e. adding value to them
- increasing the overall base of developers and uses familiar with and loyal to the vendor's total product line
vendors differentiate themselves based on the product in the traditional product line and can also employ value driven pricing with such products

[partially relevant to my unnamed established biotechnology business]

3. Widget frosting

intended for companies in business primarily to sell hardware but use the open source model for enabling tools distributed at no charge along with the hardware
most revenue is generated through sales of the hardware
hardware sales may be increased by open sourcing as in the loss leader scenario -- increases the base of developers familiar with the hardware and able to make it perform to full capacity
vendors can differentiate themselves based on the attributes of the underlying hardware
vendors is selling physical goods for which competitive products exist in most cases so the pricing is typically more cost driven than value driven

4. Accessorising

distributed physical items (ie not software or services) associated with and supportive of open source software
piggyback on the open source software developed and maintained by others

5. Service enabler (does not appear all that relevant to biotechnology)

6. sell it, free it

essentially the loss leader model repeated and extended through time
company deliberately structures its development and licensing practices so as to release research tools first under traditional right to use licences and then convert them to open source when they reach the point in their life cycle where the benefits of developing them in an open source environment outweighed the direct license revenue they produce new line-newly freed open source products still adding value to the remaining proprietary products as in the loss leader model
if you choose a BSD license or a Mozilla license, newer proprietary products can be based in part on the older products now released as open source
two main tactical problems to overcome:
- first, deciding exactly when in the product life cycle to convert it to open source
  - too early: unnecessarily forgoing significant license revenue
  - too late: fewer open source developers will be interested in contributing to the products for the development
- 2nd, is customers think the product is likely to go open source at some point it is more difficult to justify why they should buy now instead of waiting -- this is easier if product's sales cycle is short relative to the product life cycle and if product pricing is managed so as to plan for scheduled reductions in license price and at least partially compensate for such reductions with revenue from other sources such as technical support or professional services
- in a fully realised model, customers buying the product near the beginning of its life cycle are in essence paying a premium for the value of having the tool earlier rather than later; once the product converts to open source it becomes in essence a commodity but can still and value to newer proprietary products whose license pricing can reflect that added value
  
  [A thought: copyright is essentially forever in a fast turnover industry, whereas patent length is designed so that you get a limited ability to have exclusive rights anyway -- and you can decide to let your patent lapse at any point when it is no longer profitable to maintain it -- so is the sell it, free it strategy in fact built-in to anything that is patented?
  
  [relevant to my unnamed established biotechnology company]

7. Brand licensing

a company makes the research tool itself open source but retains the rights to its product trademarks and related intellectual property and charges other companies for the right to use those trademarks in creating derivative products distributed under the same brand name
this requires that the product exist in two different forms with two different names -- official (trademarked), e.g. Netscape and unofficial, e.g. Mozilla
e.g. unnamed established biotech company trademark would remain under the control of the company
the two versions would-be near identical, but from a market perspective they would be two different products with possibly different perceived value
third parties wishing to distribute a product based on your tool may also wish to separately pay you for a license to use your trademarks in association with their product and the price of the license CPU charge them reflect the brand value and reputation that your company has in the marketplace

[relevant to my unnamed established biotechnology company]

8. Research tool franchising

draws on the brand licensing and support sellers models
you are a support seller with a great reputation
you expand not through direct hiring and acquisition but through franchising -- i.e. authorising other developers to use your brand names and trademarks in creating associated organisations doing open source support and custom software development in particular geographic areas or vertical markets
you make money by licensing your brand and trademarks and also by supplying your franchisees with training and services; revenues come from sales of franchises and royalties based on franchisees' revenue

Hybrid business models [seems relevant to my unnamed start-up biotechnology company]

involve distributing research tools under licences that are not quite open source in the strict sense but also not as restrictive as traditional proprietary licences
explore the space of possible hybrids by going back to the open source definition and relaxing one or more of its requirements

1.change the availability of source code (not relevant for obtaining patents -- except that if you want to promote open source development you will properly need to disclose more than you have to in a patent, there will be questions of know-how and uncodified knowledge, so perhaps to do proper open source research tools you would need to have extra disclosure and to do a hybrid you would only need to have patent disclosure)

[I need to talk to lawyers about how the patents aspect changes things]

2. change the treatment of different users

3.change the treatment of different types of use

1. Change the availability of source code

an open source license grants at least four separate rights with regard to source code:
- the right to view the code
- the right to use the code
- the right to modify the code
- the right to redistribute the code in modified or unmodified forms; and the owner is not allowed to charge for any of these rights
however at least in theory these rights could be separated and made conditional on paying some sort of license fee
so e.g. you could give a low-cost or even know cost license to possess a copy, to internal things but you would be charged a high license fee if you want to redistribute a modified version -- might be of interest too many commercial organisations

2. Changing treatment of different users

true open source license is not allowed to discriminate between users based on fields of endeavour
you could distinguish, e.g., between commercial and non-commercial users (in practice this distinction is not always easily made) -- e.g. you could give non-commercial users a full set of rights to view, use, modify and redistribute but charge commercial users license fees to obtain all/ some of those rights

3. Change treatment of different types of use

An open source license does not discriminate between different uses
you could offer a license on different terms depending on the end use, e.g. for unnamed established biotech company you could allow use within an organisation but prohibit or require high license fees for use of the software to provide a service two of the users, or you could allow no charge use of the software with respect to particular plants (e.g. agricultural crops that are useful in the developing world) and not others

Viability of hybrid models:

can derive revenue and profits directly from the sale of licences as well as through indirect means as in the true open source model
but can you also derive other benefits of open source business models such as leveraging outside developers? Specifically, ward non-commercial developers object to the more restrictive terms of hybrid licences?

[End of notes from Kennedy.]

In order to choose an appropriate business model, a company needs to ask itself first, what specific value does the company seek to provide to its customers (ie what is its unique value proposition); what is it worth; and whether that worth is sufficient to provide an adequate return to (a) run the company (or in the case of non-profit research, fund the research) and (b) satisfy investor expectations? In relation to this final point, it has been suggested that investor expectations in the biotechnology context are higher than in the software context. This is a matter for investigation, but it would be surprising if every biotechnology company was required to provide the kind of return to shareholders that is expected from a Microsoft.

Supposing a business wishes to open-source some but not all of its technology. In analysing where the cut-off should be, it will be necessary to identify what is enabling technology and what isn't with respect to that company's business practices. [Refer to notes to clarify]

(b) Choosing a licence

Choosing a license for an open source project requires as much care as for any other development project. In the software context, low-cost legal advice on how to manage open source licences is now becoming available, but such help is presumably not yet available in the biotechnology context.

Existing open source software licences lie at different points along a spectrum that is characterised by the amount of freedom given to licensees, or users of the software, and correspondingly how restrictive the licence is in terms of how the copyright owner can make money from the software. Any business that wants to follow an open source licensing strategy must strike an appropriate balance between these two priorities. It is self-evident that businesses will value their own freedom to sell or lease their products in any way they choose. But freedom for users is also a priority for the software owner because the open-source licensing model relies on providing sufficient user access to the code, and sufficient freedom in the way it may be used, to facilitate and motivate contributions to its improvement.

Within the open source software community there is a community norm against proliferation of licences, so although it is always possible to write an entirely new licence that is perfectly tailored to any business plan, it is expected that new project leaders will model their chosen licence as closely as possible after an existing licence that has been accepted within the community and is demonstrably workable. It is therefore necessary when considering an open source strategy to decide what is important in a licence and identify which of the key existing licences comes closest to striking the appropriate balance between freedom for users and freedom for owners. For example, some licences mandate source code for modifications must be made available to the community as a whole, while others allow modifications to be taken private; some licences allow users to merge the licensed program with their own proprietary software, while others prohibit mixing with non-free or open source software; some licences contain special privileges for the original copyright holder over modifications made by other contributors; and finally, it is possible to dual licence a single program, such that customers have the option of buying commercial-licensed versions that are not open source.

If we imagine a spectrum bounded by no license at all at one extreme -- i.e. straight-out donation to the public domain -- and standard proprietary licences at the other, the open source license that lies closest to the public domain end (maximum freedom for users/contributors) is the GNU Public Licence, or GPL. In one sense the inclusion of public domain non-licensing at one end of the spectrum is misleading, because while it provides maximum freedom for users, the public domain also allows leaves open the possibility that developers might take the tool and use it as a base to create proprietary tools. The GPL is designed explicitly to prevent this by insisting that enhancements, derivatives and tools that incorporate the technique are also released under the GPL. As Behlendorf points out, this pretty much eliminates the option of making money through software value-adding, but the GPL could still be used as a competitive weapon to establish a platform that discourages competitive platforms from being created and protects the original developer's position as the leading provider of products and services that sit upon this platform. He also notes that the GPL could be used for business purposes is as a technology sentinel, with a non-GPL version of the same tool available for a price.

Further towards the proprietary end of the spectrum (maximum freedom for original intellectual property owners) lies the Mozilla Public Licence, or MPL, and slightly further on the Netscape Public Licence, or NPL. Like the GPL, the MPL requires that changes be released under the same licence, therefore making them available back to the development community. The NPL was developed by Netscape when they open sourced the Navigator Web browser, and contains special privileges that apply to Netscape, specifically the ability to re-licence modifications authored by other contributors under a closed licence. Even closer to the proprietary end lie the Berkeley Software Distribution Licence, the BSD, and other BSD-style licences like X and Apache. The BSD licence was originally developed to release noncommercial software developed as a byproduct of university research, it continues the academic tradition of insisting on proper credit for contributors, but imposes no real restrictions on use of the licence software, which means that a tool licensed under one of these licences can be used to create a closed proprietary product.

There are (at least) two reasons to be cautious in applying open source software licences to biotechnology research tools. The first is the number of potential legal problems with open source software licences have been identified. (The following discussion is drawn from Kennedy's paper: Kennedy, Dennis M. A Primer on Open Source Licensing Legal Issues: Copyright, Copyleft and Copyfuture. Available at http://www.denniskennedy.com/index.htm.) There are two major classes of problem, relating to ownership and to validity and enforceability of the licensing contract. These issues are obviously interconnected, because standard intellectual property licences are enforced by the intellectual property owner, so practical (as distinct from legal) problems may arise where ownership is diffuse, as in open source projects where each contributor retains ownership of intellectual property in his or her contribution. (Note that the Free Software Foundation response to this ownership/enforcement issue is to ask contributors to assign copyright to the FSF itself, which is then in a position to enforce the licence terms.)

With respect to ownership, questions arise in connection with ownership both of individual contributions -- for example, where the contributor's employer owns any intellectual property he or she creates by virtue of the employment contract -- and ownership of the project as a whole. With respect to enforcement, a major issue is that open source licences fall into the category of "shrink-wrap" licences (whose terms purport to apply without formal consent of the licensee). Shrink-wrap licences in general may not be enforceable, although recent legislative initiatives in the US appear to shore up their enforceability (see UCITA article 2B). As an aside, this controversy raises the interesting point that the stronger intellectual property protection becomes, the stronger open source becomes because it relies on intellectual property protection. This can be both a strength -- open source actually thrives on the expansion of intellectual property protection, instead of being threatened by it-- and a weakness -- working for open source and working to strengthen the public domain by attempting to turn back the tide of intellectual property expansion may be sometimes incompatible.)

[More details to be added from my notes.]

Even though open source licences have yet to be tested in court, concerns about enforceability may be exaggerated. Webbink suggests that open source licences may continue unchallenged for two reasons. First, open source exists only within a community, and challenging of open source licences is discouraged within the community. Second, and more important given that the ultimate purpose of this discussion is to explore the translation of these licences outside the community in which they evolved, a successful challenge would result in the challenger losing the right to access the licensed subject matter: if the licence fails, the intellectual property reverts to private ownership, not to the public domain.

The second reason to be cautious in applying open source software licences to biotechnology research tools is that existing open source licences are copyright licences, whereas most biotechnology research tools are protected by patents and other forms of intellectual and tangible property rights (e.g. materials transferred from one laboratory to another are treated legally as bailed property). Therefore, existing licences cannot be directly applied to biotechnology research tools; they must be translated into a different legal as well as technical context. The most notable difference between patent and copyright protection is, of course, that patent protection is much more costly to obtain and maintain.

Two points may be made in this connection. The first is that the differences between patent and copyright law may not always favour the feasibility of open source copyright licensing over open source patent licensing. For example, although patent protection is more expensive, it is also more absolute, in that exemptions from liability are much more narrowly defined; this may make patents more rather than less amenable to open source licensing, for the reason given above -- that stronger intellectual property protection strengthens the position of open source licensors just as it does that of closed source licensors.

The second point is that the problem of applying open source principles to the drafting of patent licences is not confined to the biotechnology context. Recent changes in intellectual property laws relating to software have made software patents increasingly common. Thus, over the next few years, the software community will be grappling with some of the same issues as must be addressed in the biotechnology context in relation to the drafting of licences. To date, responses to the patent issue within the software community include:

1. Building databases that include information about existing technologies in a form that can be recognised by the US PTO as "prior art". This strategy is essentially an attempt to defeat patenting of fundamental tools, as are policies adopted by the Human Genome Project and the AfCS that prohibit patenting of information by member researchers and insist instead of donation to the public domain to create prior art; in the biotechnology context, it has achieved only mixed success.

2. Defensive patenting. Institutions that need access to other people's patented technology may adopt a defensive patenting strategy that involves patenting their own research tools not as sources of licensing revenue but to use as a bargaining chip in negotiations for access to other technology. In the biotechnology context, this has led to an industry-wide explosion in patenting of research tools for which protection might not otherwise have been sought.

3. Patent pools. As discussed in relation to the theoretical background to this project, patent pools can have an anti-competitive purpose and effect and may be subject to

scrutiny by competition authorities. However, if a pool can be shown to have no such intention or effect, it may offer a mechanism for open source patent licensing. In the software context, at least one attempt to create an open source patent pool already exists (OPL), though it is still in the early stage of development. It may be possible for biotechnology industry players to learn from this effort.

4. Standard setting bodies may insist that standards not be patented, or that if patented they must be made available under open source licences (e.g., a recent W3C decision insisted that patented standards be licenced royalty-free). Similarly, other powerful bodies, such as funding agencies, may exercise influence to help develop patent licences and/or may provide funding for obtaining patent protection on condition that such protection is used for open source purposes only.

5. Mutual exclusion clause: [add details from notes]

As noted above, not all biotechnology research tools are protected by patents. In the biotechnology context, at least one effort has been made to construct an open source-style licence for non-patented biotechnology research tools. Tom Michaels' "GPL for plant germplasm" was first formulated in 1998. [Further information?]

Other issues relating to the application of open source licences to biotechnology research tools are noted in a later section of this website.

References:

Kennedy, Dennis M. A Primer on Open Source Licensing Legal Issues: Copyright, Copyleft and Copyfuture. Available at http://www.denniskennedy.com/index.htm.

Hecker, Frank. 2003. Setting Up Shop: The Business of Open-Source Software [Internet]. hecker.org 2000 [cited 21 Jan 2003]. Available from http://www.hecker.org/writings/setting-up-shop.html.

Michaels, Tom. 1999. General Public Release for Plant Germplasm: A proposal by Tom Michaels, Professor of Plant Agriculture, University of Guelph, v1.1, 26, February 1999, http://www.oac.uoguelph.ca/www/CRSC/pltag/1998-99/gnucrop2.htm

Webbink, Mark H. 2002. Open Source Software - Bridging the Chasm. Practising Law Institute Patents, Copyrights, Trademarks, and Literary Property Course Handbook Series 691:663.

Kennedy, Dennis M. A Primer on Open Source Licensing Legal Issues: Copyright, Copyleft and Copyfuture. Available at http://www.denniskennedy.com/index.htm.

Burk, Dan. 2002. Open Source Genomics. Boston University Journal of Science and Technology Law 8 (Symposium on Bioinformatics and Intellectual Property Law

April 27, 2001, Boston, Mass. (Winter 2002)):254-.

The Magic Cauldron, in The Cathedral and the Bazaar, in Raymond, Eric S. 2001. The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. 2001. Online version: O'Reilly. Available from http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/. http://www.oreilly.com/catalog/cathbaz/ (Chapter 9: indirect sale value business models)

Open Source Initiative, "Open Source Case for Business" http://www.opensource.org/advocacy/case_for_business.php

(c) Other tasks necessary for launching an open source project

[NB: This material may also be relevant to "building an infrastructure", espeically in connection with establishing base content.]

Beyond selecting a business model and appropriate license, there are a number of other tasks that are necessary in order to establish a new open source project.

First, tools that are to be open sourced may share some intellectual property elements with tools that are to be kept proprietary. Care must be taken to avoid licensing those elements in a way that inadvertently undermines intellectual property management of the tool as a whole.

Second, the operation of a tool that is to be open sourced may depend on proprietary third party technology. It may be necessary to obtain permission/licences from the third party, or modifications may need to be made to the licence, as in the case of the Netscape Public Licence.

Third, in the software context it is sometimes necessary to "sanitise" code before it is fit for public consumption; this may involve removing defamatory comments etc, but it also involves tidying up the code so that it is more user-friendly. Similar tasks in relation to biotechnology tools could include providing extra documentation on experimental protoco l-- which may in turn entail further experimentation -- to make it possible for researchers in other laboratories to reliably carry out crucial techniques.

Fourth, it may be necessary to deal with regulatory issues such as (in the biotechnology context) biosafety and biosecurity controls. Although these issues differ from the biotechnology context to the software context (at least in terms of the regulatory regimes that apply), they do exist in relation to open source software and have caused no major problems, so there is no reason to suppose they will necessarily be insurmountable in the biotechnology context.

References:

Hecker, Frank. 2003. Setting Up Shop: The Business of Open-Source Software [Internet]. hecker.org 2000 [cited 21 Jan 2003]. Available from http://www.hecker.org/writings/setting-up-shop.html.

The open source/closed source trade-off

The open source approach is not universally applicable, in software development or anywhere else. Where there are no obvious problems with a firm's current approach and/or no opportunities for improvement by adopting an open source approach, the open source approach is unlikely to bring any benefit.

Even where starting conditions are favourable and there is potential to make gains or avoid losses by adopting an open source approach, open source is not necessarily the best way to go. There are costs and risks associated with the open source strategy, including the costs of providing a community infrastructure, launching and maintaining the project, and the opportunity cost of foregoing licence fees and/or the competitive edge that may be gained by denying competitors free access to an important new technology.

In one sense the risk associated with open source is arguably higher than that associated with more standard business models because of the uncertainties involved in a novel approach (although there may also be opportunities that go with taking a novel approach -- e.g. the first biotechnology business to go open source with respect to a particular class of tool will have first pick of the talent pool of possible contributors). On the other hand, there are also costs and risks associated with the traditional approach. The decision whether to go open source is thus a trade-off, the outcome of which will depend on the specific circumstances of the case.

References:

Burk, Dan. 2002. Open Source Genomics. Boston University Journal of Science and Technology Law 8 (Symposium on Bioinformatics and Intellectual Property Law

April 27, 2001, Boston, Mass. (Winter 2002)):254-.

Everitt, Paul. 2003. Business Decision [Internet]. Zope Corporation, 2001 2001 [cited 21 Jan 2003]. Available from http://www.zope.org/Members/paul/BusinessDecision.

Hecker, Frank. 2003. Setting Up Shop: The Business of Open-Source Software [Internet]. hecker.org 2000 [cited 21 Jan 2003]. Available from http://www.hecker.org/writings/setting-up-shop.html.

General predictors of outcome

In order to analyse the specific cirumstances of any particular business, it is necessary to ask a range of questions which are effectively the same as those in any business plan (though the answers will be put to different use), and can be answered by much the same kind of research: for example, what is the company's "unique value proposition", what degree of demand exists for the company's offering, and what is the nature of the competition in a particular product or service market?

[Note to myself: when writing this up in more detail, include notes from Behlendorf on how to apply the answers to these questions in order to determine whether open source might be appropriate, and also refer to business planning guides].

Different considerations will apply depending on whether the firm in question is already established and is contemplating turning to an open source business model or is a new company. For example, a start-up might consider that open sourcing key proprietary technology could increase its user base rapidly, greatly improving the perceived value of the company in a short time, or even that the buzz of open source might attract attention from possible capital funding sources. An existing company might have a need to create new products or variations of existing products or to improve product quality; or it might want to attract better employees by providing interesting and exciting opportunities, including opportunities for peer recognition outside the company.

Although the outcome of the open-source/closed-source trade-off depends on the specific circumstances, in the software context Eric S. Raymond has identified a number of discriminators that may help predict the outcome in general terms. It is worth considering whether, and if so how, these may apply in the biotechnology context. In software, says Raymond, the presence of the following factors suggests the tool may be more likely to do well under open source conditions:

1. The tool establishes a common infrastructure. Another way to say this is that network effects in relation to the particular tool are strong.

2. The tool is business-critical to its users. This means customers will place a high value on the prospect of avoiding dependent on a particular supplier.

3. The reliability, stability or scalability of the tool is very important. The assumption here is that open source development methods tend to produce better tools than do traditional proprietary development methods.

4. Peer review is needed to verify the correctness of design or implementation.

5. Key methods or functional equivalents of key methods implemented by the tool are part of common technical knowledge in the field. This suggests the closed source approach would not necessarily be highly profitable in any case.

6. The tool is an enabling technology or a scientific resources that represents a non-substitutable standard. For example, the sequence of the human genome might be open sourced, while stand-alone "applications" may be better suited to a proprietary model. (Note that there is some tension between items five and six; this highlights the fact that the trade-off may be weighted heavily on both sides.)

The final item in the above list shows that the outcome of the trade-off may well change over the lifetime of the tool: early on, it may be better from an economic perspective to keep it proprietary; later it may be better to let it go open source, and the question will often be, as Raymond suggests, "when to let go". In this regard it is worth noting that many owners of patented research tools allow patent protection to lapse over the economic life of the tool; open source licensing could be seen as an alternative to allowing the tool to return straight into the public domain, and the question for the owner would then be whether the advantages expected from an open source approach would make up for the cost of the yearly patent fees.

References:

Return to Home

Open Source Biotechnology Project

Home

Theoretical Perspectives

Biotechnology Industry

Open Source

Project Design

Links

Revision history

Open Source as a Business Approach

Preliminary points

What biotechnology businesses do I have in mind?

What "standard of proof" is required in order to make out a successful case in favour of generalising the open source business approach to biotechnology?

How open source business models differ from standard business models in software and in biotechnology

Standard models emphasise end value

Open source models emphasise use value

Essential elements of an open source business model

Maximising use value

How can harnessing the input of many users improve the use value of a tool?

Building a user community

(a) motivating participants

(b) structure and infrastructure

Translating increased use value into economic value for the firm

General competitive advantages

Specific business models

(a) Choosing a business model

(b) Choosing a licence

(c) Other tasks necessary for launching an open source project

The open source/closed source trade-off

General predictors of outcome