User:Ernstkm/sandbox/Business Models for Free and Open Source Software

In the last two decades, a shift in the philosophy and economics of software production has occurred: the notion of "open source" or free (as in _libre_) software development as a viable strategy in a commercial context. It is now feasible for for-profit software companies, under a broadening set of circumstances, to profit from the development of a product in plain sight of their competitors by releasing the source code (the programming instructions which create the program's user-facing behavior) to the public, and furthermore, by enabling public _contributions_ to the same body of source code. Although this mode of collaborative software development had long been utilized in research and academic environments, it has only recently gained commercial acceptance.

Background and Concepts
While the idea of software development "in the open" was not unheard of, the notion of exposing the inner workings of a commercial software product to the public (and one's competitors) would have been anathema to a for-profit developer just two decades ago. The protocols and software services which form the basis for the modern Internet were developed this way in the 1970s and 80s, but most software used in businesses was bought and sold at a premium, albeit dwarfed by the costs of hardware in those days. (Goldman, p.3)

While the ethos surrounding free software or open source (hereafter referred to as "FOSS," or "free and/or open-source software") projects and the communities which sustain them can be fundamentally viewed as a pre-capitalist, meritocratic, high-tech gift culture, releasing a software component or project under a permissive license is now an accepted strategy employed by some of the largest commercial software development companies (Goldman, p.4) to capture market share for their server products and other services. (Goldman, p. 6) The expected benefits resulting from this business model are attained by attracting a critical mass of users and outside developers, which in turn provide usability testing, quality assurance (in the form of bug reports), design input and innovation, and word-of-mouth marketing.

Releasing the source instruction set for computer software alone is not enough to ensure the success of a free or open source project. Some all-volunteer efforts, notably the GNU/Linux operating system and the Apache web server, are coordinated through large, well-organized nonprofit foundations with contributions of capital (both human and financial) from interested third parties. For-profit entities wishing to launch a successful FOSS project will need to invest substantial time and resources into matters such as licensing, intellectual property protection, attracting an initial community of users and developers, and formulating a means of governance over that community. (Goldman, p.8)

Licensing
The GNU Project is an example of a body of free software which is developed out in the open among a loosely affiliated group of collaborators using the Internet. The license used for the GNU Project, the GNU General Public License, maximizes code re-use by prohibiting any contributor from taking her contributions away from the community. In this sense, the GPL is often (derisively) referred to as being "viral"—once applied to code (Berry 2008, p. 113), the GPL cannot be revoked unless all copyright holders can be contacted and are in agreement to change the licensing. When first applied to the Emacs text editor in the 1980s, this particular aspect of the license was not particularly contentious (Berry 2008, p.113); in recent years MIT-compatible and BSD-derived licenses have gained popularity for certain types of projects owing to their compatibility with commercial, closed-source software development which increases the attractiveness of these projects to companies who are not fully invested in free software development in the purest philosophical sense.

The selection of a FOSS license is a key decision which is typically made early in the inception of a free/open software project. License changes do occur, but typically require contacting all contributors (where copyright was not assigned to the entity through a preexisting community agreement) for permission to relicense the code, which may be a lengthy process. There currently exist over (# of OSI-approved licenses) licenses which meet the "open source" definition set forth by the Open Source Initiative, and over (# of FSF-approved licenses) approved by the Free Software Foundation, stewards of the GNU Project. While there are many subtle differences in the specific terms and provisions of these licenses, most will adhere to these general conditions:


 * establishing users' freedoms to copy, distribute, incorporate the available code into other products (often subject to restrictions arising from "commercial," closed-source uses of the code), or even sell the source code covered by the license to others
 * establishing terms for copyright-protected use of outside contributions
 * indemnifying the entity responsible for distributing the source code from any legal responsibility deriving from intended or unintended uses of the software, or damages which may result from defects in the software

The FSF and GNU Project's favored GNU General Public License, and similar "copyleft" licenses will add to the above a provision which prevents the incorporation of modifications to the software into non-free software which is then publicly released or sold _without_ also sharing the source code to these modifications.

Assigning Copyright
Due to the potentially large number of present and past contributors, assignment of intellectual property to a single individual or organization prior to the release of the project with a FOSS license can be problematic. Often a company may desire to release the source code for a product in its entirety but may not due to patents or other intellectual property agreements (such as non-disclosure agreements, or NDAs) with other software development firms or contractors.

Some projects choose to simplify the assignment of copyrights by requesting that all contributors to the project "sign" a copyright assignment agreement which gives the parent company or project's leader exclusive control over all intellectual property rights associated with the project. However, these rights can (and have been) abused by the corporate entity to the harm of the open source community:

"Like any copyright holder, the project leader of an open source project may exercise an exclusive right to control the work by issuing a new version of a license to cover a preexisting open source product. If the new version of the license were a proprietary software license, rather than an open source or free software license, then the project owner would inflict a serious blow to the goals of open source.[^dixon]"

Sustaining a community of users and developers around a product
This is one of the most grave challenges facing the new release of a product or software component as open source. If the parent organization takes too much of a "hands-off" approach, the release of the source may fail to generate enough interest among outside developers to sustain future development.

"Engaging in an open-source project requires understanding the community, its culture and customs, its tools, and its way of working. Open-source projects are distributed and work through email, websites, and other written documents. There are standard versioning tools, compilers, bug-tracking tools, and customs for using them. Building, testing, support, and releases are handled in particular ways. There is a sort of hierarchy to the developers centered on module owners and the concept of a meritocracy, where rights are expanded only after abilities have been demonstrated.[^goldman]"

A minimum list of features required to launch a FOSS software community project may be considered as (Goldman 2005, p.138):


 * an online repository for publishing the source code and accepting contributions from outside developers (_e.g._, a source code management system such as SVN or git) (Goldman 2005, p.38)
 * a `-dev` mailing list, or some other efficient means of communicating with collaborators (Goldman 2005, p.36)
 * a standards body, steering committee, or other way of voting on feature and standards implementation in future versions of the software/product and integrating contributions (Goldman 2005, p.150)
 * a bug tracking database
 * a repository of documentation for your software's application program interfaces (APIs), to be used as a starting point for outside developers or contributors to the project (Goldman 2005, p.139)

Enforcing License Compliance among Competitors
The enforcement of licensing terms among competing interests in the context of a FOSS development project are traditionally fixed within the legal framework surrounding copyright (or in some cases, when assigned to the steward organization, patent) infringement. Derivative free or open-source licenses are often created to address concerns the parent organization may have about these circumstances, and more aggressive wording may be added to these licenses in order to allow prosecution of "breach of contract" violations in these circumstances.

A widely-publicized example of such a dispute occurred in 1997 when Sun Microsystems, creator of the Java programming language, sued Microsoft Corporation for alleged infringement of the Java copyrights and trademarks and breach of contract due to their incomplete implementation of the Java standard for the Microsoft Java Virtual Machine (JVM).[^dixon]

Leadership and Decision-making
One unique challenge faced by the existing corporate management structure surrounding a software project seeking to go open-source is the question of governance: how to release enough control over process and progress to the community so as not to hamper innovation or drive away contributors, but such that milestones and deliverables can still be extracted from the efforts of the wider community. The process of establishing rules for governance of a FOSS project should bear in mind and attempt to respect the "gift culture" origins of free software development while prescribing a unifying set of guidelines and goals for the community. (Goldman 2005, p.151)

Proposed Methodologies
Many strategies for sustaining a software project using an open or collaborative development model have emerged in the past decade, but none is perfectly suited for every project great or small. Some suggestions that could be considered to form the "common denominator" requirements include:

Selling services, training, proprietary extensions, or consulting
MySQL AB, now a subsidiary of Oracle Corporation, formerly employed this strategy for its database product, MySQL. The MySQL database product under Oracle has been subsequently dual-licensed for commercial use, with proprietary extensions, available on a paid subscription basis with technical support provided for enterprise users.

WordPress and Drupal, two popular web content management systems (CMS), also operate on this model, the core of the software being provided for free under the GPL, while both parent companies offer either hosted solutions or custom software development for their products as separate, paid services.

Dual-licensing
VirtualBox and the Mozilla Firefox web browser are two notable examples of mainstream software products which are released under multiple licenses. Contributors to these projects must agree to having their contributions assigned to the (corporate) copyright holder, and grant the copyright holder perpetual sublicensing right to release their contributed code, along with the rest of the product, under one or more licenses.

The core of the VirtualBox product is released as GNU GPL Version 2, having been released under this license in 2007 just prior to the parent company's (Innotek's) acquisition by Sun Microsystems. Proprietary extensions, which add functionality required by certain users but may have been developed under various industry NDAs, are released under a closed-source Personal Use and Evaluation License (PUEL) for home users and a commercial (paid) license for business users.

Soliciting donations or crowd-funding
Facilitated by online payment services such as PayPal, many smaller FOSS projects rely on donations directly from their user base (or occasional corporate sponsorships) to sustain their development. Web-based crowd-funding services have also emerged in recent years (Kickstarter, Indiegogo among them) which are popularly used to raise capital for initial development of software products, libraries, or creative works, to be released under a permissive license at some later point. Often, Some notable examples include the "git-annex" front-end to the git revision control system and the Geary email client (most notable for its failure to reach the audacious funding goal of $100,000[^omg1][^yorba1]).

Releasing old(er) versions as source
This strategy is employed by the popular open-source PostScript interpreter, Ghostscript, currently developed by Artifex Software. The parent corporation maintains control of the intellectual property associated with the project and the most recent version of the product is released under a commercial-friendly, paid, proprietary license. Older versions are released to the free software community under the GNU Affero GPL, a variant of the GPL which includes special provisions for software-as-a-service (SaaS) and cloud computing applications.

Notable Examples
The following software projects may be considered among the most high-profile and successful FOSS endeavors, in terms of longevity, utility to the greater development community, or consumer market share.


 * The K Desktop Environment
 * Mozilla Corporation
 * The Document Foundation (which oversees development of the LibreOffice fork of OpenOffice)
 * The Apache Foundation
 * The Eclipse Foundation
 * The Java Community Process
 * The GNU Project

Failed Projects
Below are examples of FOSS development projects which failed to achieve a sizable enough community of users and developers to sustain the open development model. These projects have either disbanded, forked or been subsumed by another project, or lie essentially dormant in their present state.


 * _some failed projects here_