2

Background Materials

2.1 DEFINITIONS

The committee collected a list of definitions for terms used in this report that are not necessarily defined, or contextualized, when used. The definitions below are aimed at a broad audience. Some references are provided for those interested in a more thorough treatment.

___________________

¹ See https://prod.nais.nasa.gov/pub/pub_library/grcover.htm.

² See http://opensource.org/docs/osd.

2.2 CATEGORIES OF SOFTWARE

Similar to data, different types of software will require different policy approaches. These different software types are defined in Table 2.1. To understand the complexity involved and how software may evolve over time, the committee considered three general scenarios.

1. A community exists around an open source software (OSS) project: it includes users, developers, and community leaders. Typical examples are the various libraries or tools developed to extend functionality and capabilities of a programming language (e.g., the numerous libraries, such as AstroPy,⁶ SunPy,⁷ that extend the analysis capabilities of the Python⁸ programming language). Researchers who use these libraries may not cite or acknowledge them in research papers, because they are ubiquitous or considered standard. Their open source community empowers researchers at any level in their career to develop software that they may use to conduct their science, enabling more science to be conducted than if the libraries were not available to the community.
2. A large institution, such as a national laboratory or university, supports development of a substantial modeling framework over many years. The framework implements intricately connected source code that calculates equations and descriptions of processes, such that small changes in how one process is formulated may have far-reaching effects in other areas. The team of software developers has in place a rigorous testing and vetting process for incorporating changes into the publicly available version of the software. Community members can download and use the software, but in order to make “official” changes to it, they must work directly with the software development team.

___________________

³ CFR Ch. 37, Sec. 202.1(e).

⁴ See also D.L. Donoho, A. Maleki, I. Ur Rahman, M. Shahram, and V. Stodden, 2009, Reproducible research in computational harmonic analysis, Computing in Science and Engineering 11:8-18.

⁵ See also R.D. Peng, F. Dominici, and S.L. Zeger, 2006, Reproducible epidemiologic research, American Journal of Epidemiology 163(9):783-789.

⁶ See http://www.astropy.org/.

⁷ See http://sunpy.org/.

⁸ See https://www.python.org/.

TABLE 2.1 General Software Categories to Consider When Developing Policy

^a Models are equations that represent a physical process. In some communities, the term model has been used to describe the particular implementation of a set of equations within software.

3. A close-knit group of researchers, or even an individual researcher, develops and routinely modifies some software over a period of several years. The software may be available to the public for download and use (in executable form, i.e., without the source) or may not be publicly available at all. The developers have invested a large amount of time and resources developing the software. They benefit from their intellectual property and choose to develop and use their software exclusively to retain a competitive advantage and advance their careers. A concern exists that if the software is released, others may take it, make changes, and claim ownership, without involving or crediting the original developers. Additionally, developers see the possibility that improper use of the software could negatively impact their academic reputations.

The scenarios above demonstrate some of the different software development pathways that would be affected by an OSS policy. Additionally, NASA formally defines different software types in Appendix D of NASA Procedural Requirements (NPR 7150.2B) “Software Classifications.”⁹ This appendix defines eight broad classes that

___________________

⁹ See https://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7150_002B_&page_name=AppendixD.

range from various types of mission-critical, spacecraft-operations software to general-purpose business and desktop software. Based on guidance from NASA and the policy goals described in Section 1.2, this report considers policy for portions of the following three of the eight NASA software classes:

• Class C: Mission Support Software or Aeronautic Vehicles, or Major Engineering/Research Facility Software
• Class D: Basic Science/Engineering Design and Research and Technology Software
• Class E: Design Concept and Research and Technology Software

Software related to operating a spacecraft is out of scope for this report (Classes A, B, and part of C) because of clear safety and national security concerns with their publication (see Section 2.3). Day-to-day software that supports the routine administrative business of NASA (Classes F, G, and H), such as proposal submission systems and basic office software, is also out of scope. The committee thus focused on “science software,” as discussed below, because it is most relevant to the policy goals.

Within the scope of science software, such as the global magnetosphere model depicted in Figure 2.1, it is still pertinent to consider different types. A complete or definitive classification scheme for software categories is impractical, and it may be useful to consider multiple schemes when developing a discipline-specific policy implementation. For the purposes of this report, the committee puts forward one possible classification scheme, detailed in Table 2.1.¹⁰ It is important to note that any of these categories can be considered “community software” when developed by a collective effort following open source best practices.

Other conditions that may affect software policy include the following: the funding source, the parties involved, the development history, and the size and complexity of the software and computational requirements. NASA may fund software development in various ways through research grants, through contracts, or through in-house development at NASA centers. Each of these funding mechanisms may incur different intellectual property rights and legal obligations. Where NASA is a partial funder of software, policy options may be constrained by requirements from other contributors. In some cases, collaborative relationships with other agencies may be in place to develop large modeling frameworks. For example, NASA, the National Science Foundation (NSF), and the Department of Defense (DOD) have jointly funded development of solar and space physics frameworks. Large community software projects may involve contributions from different institutions, agencies, and countries. Some software projects rely on components developed elsewhere, possibly including commercial software. Large legacy software projects, developed over extended periods, often have a complex history. For example, a project could include contributions from many developers, some of whom may have passed away but still retain copyright or who may not wish to apply an OSS license, all rights reserved copyrighted software, or software that has a restrictive license. Opening the source code for these projects could be complicated, expensive, and not significantly advance science unless the software is still broadly used. Similarly, “software as a service” or machine-learning software may require different policy implementation (see Section 5.2.4).

Software is not static. Software reuse can increase risk when a package falls into disuse due to lack of maintenance. Single-use software can evolve, mature, and become more broadly useful over time. An analysis tool could evolve to become a library and later become a community-developed and maintained library. When developing policy, it is important to recognize and potentially encourage this evolving maturity of software.

Finding: The range of software types and development scenarios is vast. Policies will need to account for this diversity.

2.3 LEGAL ISSUES

Developing and implementing an open source code policy requires an understanding of the legal framework within which open source code is created and distributed. This framework includes the following:

___________________

¹⁰ Policy options and how they affect different categories of software are discussed in Section 5.4 and Table 5.1.

• Copyright law and ownership,
• The public domain,
• Patent law,
• Export controls,
• Grant and contract terms, and
• Considerations for institutional grantees.

2.3.1 Copyright Law and Ownership

Copyright gives creators the exclusive right to make copies of an original creative work such as computer software. It also prohibits anyone else from using some or all of the work in another new work, among other exclusive rights. Some uses of copyrighted works are allowed without the holder’s permission, such as uses that fall under the doctrine of fair use in the United States. Unless an exception applies, however, in the absence of a license, a user¹¹ of someone else’s copyrighted work infringes copyright and may be subject to fines and penalties. Copyright in the United States generally expires 70 years after the creator’s death;¹² therefore, there is little if any software not subject to copyright, and this is expected to hold true for the foreseeable future.

Unless otherwise excepted by law, copyright exists from the moment authors express an original idea in tangible form (e.g., the moment they write an original poem on paper or on a computer). An author need not follow

___________________

¹¹ A user in this context is someone running or potentially modifying the software.

¹² Important nuance, because copyright of works made for hire have a different term.

any formalities to claim copyright, such as registering or applying a copyright notice on the work. Generally, when a person creates a copyrighted work within the scope of that person’s employment, the work is deemed “made for hire” and the employer owns and controls the copyright. When a person creates a work as a contractor, on the other hand, that person usually owns and controls the copyright unless the contract includes terms saying otherwise. Some works have more than one copyright holder—for example, if two or more people create the work or if different people contribute to the work. Community software projects often have multiple copyright owners, unless the contributors have agreed to assign their copyright to a single organization or individual to manage.

Owners of copyrighted works may grant permissions to others for using the work on certain terms under a copyright license. Licenses may be specifically negotiated, but a copyright holder may also use a public license to grant use permissions to the public at large. Anyone can rely on the public license provided they abide by the license terms.

2.3.2 The Public Domain

Generally, the public domain consists of works free of copyright. This is the case if the copyright term expired, the holder of copyright relinquished their copyright before the term expired, or the work was never protected by copyright. For example, facts and laws of nature are not subject to copyright.

Works by the U.S. government (works created by U.S. civil servants in the course of their official duties) are not protected by U.S. copyright law and are thus public domain in the United States.¹³ The U.S. government may hold copyright in those same works under the laws of other countries, however, and it can hold copyrights that are transferred to it (e.g., by contractors). Works that are produced jointly between U.S. government employees and others may be protected by copyright, depending on the terms of collaboration. Note that even where a work is in the public domain, the custodian of the work is not obligated to distribute it or otherwise provide access to it without a law or regulation that requires it be made available. Laws applying to the public domain vary from country to country, creating a complex legal landscape in the internet age. Licenses or dedications (like the Creative Commons CC0 dedication) that make clear how a work may be used worldwide, provide clarity in this complicated landscape.

2.3.3 Patent Law

Whereas copyright protects the expression of an original idea, a patent protects original inventions, including original solutions to engineering problems. A patent gives the owner the exclusive right to prohibit others from making, using, or selling the invention, among other things. Unlike copyrights, patents require filing an application and approval by a national patent office. A patent typically lasts 20 years in the United States. Algorithms and scientific laws cannot be patented, but devices implementing them can be. Software is unique because it is protectable by both copyright and patents. Unlike copyright, the U.S. government can obtain and enforce its patents in the United States and elsewhere, if registered.

The Bayh-Dole Act (1980) allows small businesses, nonprofit organizations, and universities under federal research contracts to own patent rights in inventions they may develop using federal research funding. Previously, the government owned such rights. The act aimed to stimulate the economy by motivating research entities to license and commercialize their patents. This act applies to NASA.

2.3.4 International Copyright and Patent Law

Copyright and patent rights are territorial, which means that every country has its own laws that protect (or do not protect) rights in software, including how long any copyright and any patent rights endure. Most open source licenses apply—that is, require compliance with their terms and conditions—only if the licensed work is protected by applicable copyright or patent law. What is under copyright or protected by patent rights in one

___________________

¹³ 17 U.S. Code § 105, https://www.law.cornell.edu/uscode/text/17/105.

country may not be protected in another, and it may or may not require compliance with a public license when the work is reused. As a consequence, a work in the public domain in the United States as a matter of U.S. copyright law, including software created by U.S. government employees within the scope of their duties, may be subject to copyright under the laws of other countries. This means that a software license applied to such a work applies only when another country’s laws applies. Further implications for the development of an open software policy for NASA are detailed in Section 3.3.6.

2.3.5 Export Controls

While most software created by NASA scientists may be released without any restrictions if desired, some software cannot be distributed outside the United States because doing so is prohibited by U.S. export laws and regulations. Throughout this report, the term export controlled refers to a number of federal laws and regulations that relate to releasing technology (including software) that may impact national security. The list of policies, laws, and regulations below is not exhaustive, but represents the most common regulations that scientists may encounter.

The International Traffic in Arms Regulations (ITAR) prohibit the export of munitions to enemies of the United States.¹⁴ At least two kinds of software are ITAR munitions: strong encryption and nuclear-reaction simulation. Once software has been labeled ITAR-restricted, it is illegal for anyone in possession of a copy of the software to allow its transport out of the United States. Posting ITAR-restricted software online without sufficient protection against unauthorized copying is also illegal. Software may be published under an open source license and still be ITAR-restricted preventing its distribution outside of the United States.

The Federal Acquisition Regulation (FAR),¹⁵ as supplemented by the NASA FAR Supplement¹⁶ (NFS), establishes “uniform policies and procedures” for acquisitions made by NASA, including software created by contractors. These regulations include provisions that can impact the release of that software by contractors, among other things. Additionally, the Office of Foreign Asset Control (OFAC) of the U.S. Treasury Department enforces sanctions imposed by the United States against other countries.¹⁷ Depending on where and to whom software is distributed, an OFAC license may be required. Similarly, the U.S. Department of Commerce issues Export Administration Regulations (EAR) that regulate the export of certain products from the United States.¹⁸ EAR and ITAR have subtle differences in how they interpret what information is publicly accessible and therefore not subject to export controls. For more information regarding guidance on legal issues, see Section 4.2.2.

2.3.6 Grant and Contract Terms

NASA grants include terms giving the government the nonexclusive right to use the results of research without paying royalties, and even to sublicense those rights. However, research organizations retain ownership of the intellectual property. This means that in the absence of specific terms requiring that software be developed and released under open source licensing terms, the decision about releasing software may be left to university technology transfer offices, or similar entities. Some grant programs, however, specify that software must be released under an open source license—for example, the NASA Earth Science Data Systems program.¹⁹

Contractors may be subject to contract conditions that place high barriers for open source release. NASA FAR Supplement 1852.227-14²⁰ “Rights in Data: General” (April 2015), paragraph (4)(i), states the following: “The Contractor agrees not to assert claim to copyright, publish or release to others any computer software first produced in the performance of this contract unless the Contracting Officer authorizes through a contract modification.” To apply an open source license to software requires the contractor to assert copyright. In the absence of default

___________________

¹⁴ See https://www.pmddtc.state.gov/regulations_laws/itar.html.

¹⁵ See https://www.acquisition.gov/browsefar.

¹⁶ See https://www.hq.nasa.gov/office/procurement/regs/nfstoc.htm.

¹⁷ See https://www.treasury.gov/about/organizational-structure/offices/Pages/Office-of-Foreign-Assets-Control.aspx.

¹⁸ See https://www.bis.doc.gov/index.php/regulations/export-administration-regulations-ear.

¹⁹ See https://earthdata.nasa.gov/earth-science-data-systems-program/policies/esds-open-source-policy.

²⁰ See https://www.law.cornell.edu/cfr/text/48/1852.227-14.

contract modifications that can be applied when NASA implements an OSS policy, the FAR supplement language will remain an impediment to policy implementation.

Finding: The community sees current NASA acquisition regulations as a barrier for open source release of software created under contracts to NASA.

2.3.7 Considerations for Institutional Grantees

NASA funds are generally granted to institutions that in turn distribute the funds to investigators and others while handling financial reports and legal compliance themselves. Generally, in the absence of an agreement between the individual and the institution stating otherwise, all intellectual property created by the recipient resulting from the grant is owned by the institution as a work made for hire. The Bayh-Dole Act prevents the institution from charging the U.S. government for using patented inventions for federal purposes. Some institutions, notably universities, have employment agreements giving researchers ownership rights in the intellectual property they create on the condition that commercialization is handled through the university under a profit-sharing agreement.

2.4 LICENSES—SPECTRUM OF OPENNESS

The Copyright Act of 1976 ensures that any original creative work, including computer source code, is automatically protected by copyright once created, except for works created by the federal government that are excluded by 17 U.S. Code Section 105. When sharing software with the public on a code-sharing platform such as GitHub,²¹ copyright still applies and will generally restrict the software’s use, unless the owner has granted a license to the user.

Finding: Unless public domain applies, source code without a license is considered “all rights reserved.” Opening source code means both making it public and attaching an open source license.

2.4.1 Open Licenses

A copyright license grants others the right to do something with a protected work that copyright would otherwise prohibit. A software license contains a set of permissions and conditions allowing use of the software legally, without infringing copyright. Standardized public licenses have become a popular way to share software openly and broadly. The license options are many, but their terms must comply with standards established by one or more organizations in order to be characterized as open. The dominant open standard is the Open Source Definition, as defined by OSI, an organization that promotes and codifies OSS and licenses.²² This definition requires that a license contain certain minimum terms and conditions to ensure basic freedoms for users in order to be called an open license. These terms include the rights to redistribute the software, access the source code, and make derivative works, as well as the ability to require that unofficial changes be distinguished from the work of the original author.

Beyond the basic terms and conditions necessary to be considered open, licenses contain other terms that give the public still more permissions. The degree of permissiveness—what users can do with the software under the license and not violate copyright—is often described as falling on a spectrum from most permissive to most restrictive (Figure 2.2).

The most permissive licenses place the least conditions on use beyond the minimum basic freedoms. They often restate the permissions in the Open Source Definition plus some marking and attribution requirements. Examples include the Berkeley Software Distribution (BSD) license, the Massachusetts Institute of Technology (MIT) license, and the Apache license.

___________________

²¹ A website that hosts version-controlled repositories and provides structured collaboration tools around those repositories, https://github.com/.

²² See https://opensource.org/definition.

The most restrictive licenses require that derivative works, if distributed publicly, be released under the same license as the original. This ensures improvements and changes are shared back with the public. The term copyleft is often used in this case. These licenses are considered restrictive (while still being open) because they limit the conditions under which the derivative can be distributed. Examples include the GNU²³ General Public License (GPL), the GNU Lesser General Public License (LGPL), and the Mozilla Public License (MPL). Of these, GPL is generally considered “strong” copyleft and the most restrictive because all derivatives must be GPL, while the other two allow some uses of the original within other software without requiring all components be licensed under the same license.

2.4.2 Other Licenses and Compatibility

Other nonstandard public and custom software licenses exist. Some are compliant with the Open Source Definition or other definitions of open but may be incompatible with the most widely used open licenses. Generally, licenses are compatible if software under different licenses can be combined and distributed under terms that meet the requirements of both licenses (see Figure 2.3). Compatibility is important if software components under different licenses will be combined and distributed together. When combining code under different open licenses, the resulting software can usually be distributed and reused if the terms and conditions of the most restrictive of the licenses are respected.

NASA releases some software developed by civil servants under the NASA Open Source Agreement (NOSA 1.3),²⁴ which was developed to address the software’s lack of copyright under 17 U.S. Code Section 105 of the U.S. Copyright Act.²⁵ As mentioned in Section 2.3.2, this law states that works of the U.S. government (which includes civil servant-developed software) are not entitled to copyright protection under U.S. law. The existing OSI-approved licenses dominantly rely on the existence of an underlying copyright and its infringement to enforce their terms and conditions. This severely, if not completely, limits their utility in connection with U.S. government-created software in countries like the United States where no copyright is recognized for such works. NOSA 1.3 relies on contract law wherever copyright law is unavailable as a means by which to enforce the agreement’s terms and conditions.

___________________

²³ GNU is a recursive acronym for GNU’s Not Unix.

²⁴ See https://opensource.org/licenses/NASA-1.3.

²⁵ See https://gpo.gov/fdsys/granule/USCODE-2010-title17/USCODE-2010-title17-chap1-sec105.

The OSI agreed that NOSA met the Open Source Definition and approved the license. However, some controversy about specific provisions in the agreement subsequently ensued, and it was determined to be incompatible with GPL. NOSA 1.3 provision 3G states, “Each Contributor represents that its Modification is believed to be Contributor’s original creation and does not violate any existing agreements, regulations, statutes or rules, and further that Contributor has sufficient rights to grant the rights conveyed by this Agreement.”²⁶ Provision 3G has been interpreted by some as prohibiting users from including software created by others in their contributions to modified NOSA-licensed software.

This may preclude an individual or organization from modifying the software using portions of code written by others and may limit the utility and potential reuse and improvement, and therefore the impact of software licensed under NOSA 1.3.²⁷ Others disagree with this conclusion and point to their experience contributing on NOSA projects that include third-party OSS.²⁸ Provision 3I states, “A Recipient may create a Larger Work by combining Subject Software with separate software not governed by the terms of this agreement and distribute the Larger Work as a single product. In such case, the Recipient must make sure Subject Software, or portions thereof, included in the Larger Work is subject to this Agreement.”²⁹ Hence, there is confusion regarding how this license does or does not allow for software reuse and compatibility with other licenses. There appears to be lack

___________________

²⁶ See https://nasa.github.io/CertWare/collateral/2016276-NOSAP3PL.pdf, p. 4.

²⁷ See also White Paper 28 in Appendix C and Arfon Smith’s presentation to the committee.

²⁸ See http://www.crynwr.com/cgi-bin/ezmlm-cgi/3/17056.

²⁹ See https://nasa.github.io/CertWare/collateral/2016276-NOSAP3PL.pdf, p. 4.

of mutual understanding between the open source community and NASA patent authorities regarding the interpretation of and need for NOSA 1.3. NOSA 2.0 is an update to NOSA 1.3, developed to be more understandable and to address some of the concerns raised about NOSA 1.3. NOSA 2.0 was submitted to the OSI approximately 5 years ago, but, for unclear reasons, approval is still pending.³⁰

Finding: There exists a lack of understanding and clarity within the open source community about the need, desirability, and utility of applying NOSA 1.3 to NASA-funded software, and whether and when other well-accepted and standard OSI-approved licenses may be used instead.

Finding: The community sees NOSA 1.3 Provision 3G as a barrier to contributing to NOSA-licensed software.

Conclusion: If NASA chooses to pursue the development of NOSA, it is important to clarify to the community why NOSA is necessary and why other licenses are inadequate.

2.4.3 Public Domain Versus Licensing for Software

As discussed in Section 2.3.3, software written solely by U.S. civil servants within the scope of their employment is public domain in the United States. Works produced by civil servants in collaboration with nongovernmental employees, on the other hand, may be subject to copyright, depending on the terms of collaboration. Confusion on these points is widespread. The committee found several examples where the U.S. government has asserted copyright over software (e.g., the Common Data Format³¹), but it is unclear whether these works were created in collaboration with nongovernment employees. A common misconception is that software written by federal employees cannot have a license attached: in fact, an open source license is not only allowed but also desirable. It gives permissions globally in those countries where the U.S. government employee’s work is protected by copyright. It also signals to other software developers that they are legally permitted to reuse the source code.

The CC0 Public Domain Dedication is a tool that can be used to eliminate any foreign copyrights that apply to a U.S. government work under other countries’ laws.³² CC0 does not license or waive patent rights and is not approved by the OSI. Thus, it is still useful to apply an open source license to software even if it is public domain in one or more countries. This specifies rights regarding patent rights everywhere, and it specifies rights regarding copyrights outside the United States and conveys a preference for how the software is to be used and distributed within the United States. Open source licenses generally help clarify intent and remove ambiguity in the complex global legal framework.

Some federal employees still are convinced that software developed as part of their official duties can only be public domain or released under a CC0 dedication, and some agencies enforce this per policy. The Federal Source Code Policy (Section 7.5), however, clearly recommends the following: “When agencies release custom-developed code as OSS, they shall append appropriate OSS licenses to the source code.” ³³ Another example is the DOD code.mil initiative. It states: “Even if the code was completely written by U.S. federal employees, it is still good practice to attach a license to the project.”³⁴

2.5 OPEN SOURCE AS A DEVELOPMENT MODEL

As defined in Section 2.1, OSS refers to software whose source code is under an open source license. From the legal perspective, open source is a licensing model, and this is what enables basic research transparency. However, software reuse requires more than an open license, so any member of an open source community will be quick

___________________

³⁰ Per. Comm. Rob Padilla, Chief Patent Counsel/Deputy Chief Counsel, NASA Ames Research Center, and Bryan Geurts, NASA Goddard Chief Patent Counsel.

³¹ Common Data Format copyright notice: https://cdf.gsfc.nasa.gov/html/cdf_copyright.htm.

³² See https://creativecommons.org/publicdomain/zero/1.0/legalcode.

³³ See https://sourcecode.cio.gov/Implementation/#licensing.

³⁴ See https://www.code.mil/how-to-open-source.html.

to note that open source can also be a development model. The OSS licensing model would do little to enhance reuse without good-quality software in the first place. The OSS development model is behind the creation of that good-quality software.

The essay “The Cathedral and the Bazaar,”³⁵ by Eric Raymond, is the classic portrayal of the open development model and its capacity for value creation. Its hero, Linux, is the paragon of world-class software developed fully in the open. While the “cathedral” metaphor refers to a closed team writing software and making sporadic releases, the “bazaar” pictures the organized ruckus of true open source development. A simple precondition of having a “plausible promise” of a solution to a problem, one that could be crude and incomplete, is enough to release software under this model (“release early, release often”). By cultivating users as co-developers and taking advantage of the Internet for distributed collaboration, the quality of the software rises quickly. Expressed as Linus’s law (for Linus Torvalds): “Given enough eyeballs, all bugs are shallow.” Experience shows that bug reports are more useful if the user is source-aware: the developers and the users (or beta testers) have a common language and combine their efforts in identifying the issue and proposing a solution. Raymond declares the triumph of OSS: “the closed-source world cannot win an evolutionary arms race with open-source communities that can put orders of magnitude more skilled time into a problem.” Box 2.1 details the evolution of NASA’s open source Nebula software project into a collaboration with Rackspace, Inc., which then grew into a globally adopted technology resulting in significant financial benefits and job creation.

Open source projects nurture a community, where users are invited to play an active part. This does not mean that anyone can make changes to the official version of the source code—a typical misconception. Users or testers can become co-developers by submitting code changes to be reviewed and approved by a merit-based group: the maintainers and the core developers. To facilitate review, core developers build tests and use technology to continuously apply those tests to any submitted code. Open source projects also have governance processes, and appoint leaders that oversee decision making, steward the project, and promote trust. Transparent peer review is at the center of quality assurance and trust building. Ideally, the open development model is highly collaborative, fully transparent, merit-based, and democratic.

Research software—that is, the software that researchers develop to aid their science—often remains of interest to only a small group of people. Such specialized software may not reach a critical mass of users that gels into a community. Even when just a handful of people may use the software, however, the practices that help larger projects manage cooperative development still offer benefits. Technologies and methods such as testing, version control, and code review improve the quality of software irrespective of its scale. In some cases, research software or libraries that begin as tools for a special science workflow do become useful beyond the creators. Over time, they may mobilize new users to become contributors, the need for governance arises, and the project becomes community software.

Finding: The open source development model involves a community of users, but code contributions are sanctioned via peer review and approved by maintainers or core developers. Software can be openly licensed yet not follow the open development model—in this case, it is not considered community software.

___________________

³⁵ E.S. Raymond, 1999, The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, O’Reilly Media.