Open-source software

Open-source software is software with source code that is readily accessible that anyone can modify and freely share because its source code is publicly available under an open-source license. Source code refers to the part of software most software and computer users do not see, and is the code programmers can manipulate to change how a piece of software works or add or remove features.

Open-source software development is often done through the open collaboration of many software programmers in a public manner, through online platforms such as Github or SourceForge. These open-source software hubs are an example of open collaboration that can broaden design perspectives. Open-source practices can also lead to considerable savings, with many open-source offerings provided to consumers for free, and relying instead on diverse business models, including donations and shareware.

The Open Source Initiative, which maintains a library of open-source software licenses and is generally considered the main advocacy group for open-source software, defines open-source software and open-source licensing by ten criteria:

• Free distribution, in that third-parties can freely redistribute and resell the software
• Source code should be easily obtainable and unadulterated
• Derived works and modifications are permitted
• Integrity of the author's source code, in that the author may restrict the distribution of modified source code, but only if they allow the use of patch files
• No discrimination against persons or groups
• No discrimination against fields of endeavor
• Distribution of license applies to all third-parties
• License must not be specific to a product
• License must not restrict other software
• License must be technology-neutral

Open-source software is often considered the opposite of what is sometimes referred to as "closed-source" or proprietary software. The latter type of software has a source code that can only be maintained by the person, team, or organization who created it. By the licenses, only the authors of proprietary software can copy, inspect, and alter the software; to use the software, computer users must agree (often through a user agreement license) they will not do anything with the software beyond its intended use.

Open-source software is in this way different, that the authors make the source code available to those who would like to view the code, copy the code, learn from the code, alter the code, or share the code. In this case, users of open-source software still accept the terms of a license when they use the software, but the legal terms of the software differ from those of proprietary license.

The open-source development model is used by an open-source community to develop open-source software. This software is then released under an open-source license to allow others to view or modify the source code. There are many reasons why some choose open-source over proprietary source:

• Peer review as the source code is freely accessible and the open-source community is very active; open-source code is actively checked and improved upon by peer programmers
• Transparency, where open-source allows users to check and track those movements without having to rely on vendor promises
• Reliability, where proprietary code relies on a single author or company; open-source code outlives original authors because it is constantly updated through active open-source communities
• Flexibility, where the emphasis on modification, users can use open-source code to address problems unique to a business or community
• Lower cost, since open-source makes the code itself free, and users pay a company offering open-source support, security hardening, and help manage interoperability
• No vendor lock-in, where users can take an open-source code anywhere and use it for anything at any time
• Open collaboration, where the often active community around open-source software means a user can find help, resources, and perspectives that reach beyond one interest group or one company

As all types of software, there are advantages and disadvantages of open-source software. Considered by those using and developing or iterating open-source software, the advantages include the open-source licensing, which usually means open-source software does not require a license fee and the lower cost can be a key reason for its use, especially in the case of small businesses. And although the upfront cost can be considered lower, there are other associated costs of ownership to consider with open-source software, including the cost of support or lack of obvious support helplines with the software. However, the lower cost is generally considered a benefit of open-source software. There are a variety of other advantages:

Open-source software is generally considered to be more flexible than closed-source or proprietary software as it offers programmers multiple ways of solving problems, and tends to encourage creative solutions. Similarly, open-source software allows a program to take a standard software package and modify it to better suit business needs, and a user can further hire a programmer in order to develop or add a particular function to open-source software.

Open-source software often can be developed to be integrated or to work with various software vendors, especially proprietary software. Based on the license, open-source software often does not restrict users to using specific vendors, which can happen with proprietary software and the impetus to switch vendors to match a proprietary software vendor can incur further costs. However, an open-source project does not totally guarantee a user is independent of vendors. For some open-source projects and products there may be a limited number of vendors that can provide a user with services, upgrades, or security patches.

When looking at the quality of software, the products themselves have to be compared, whether that is between two different open-source software projects or between an open-source software and a proprietary software. And it is impossible to guarantee that open-source software is better than proprietary software in terms of reliability and quality, as both have a range of products. However, mature open-source software is generally viewed to be of good quality and reliability. And if a user is not familiar with open-source software, it may want to review some of those mature products.

Further, in the development of open-source software, often users can attract better or more talent than proprietary software. This means the software itself can benefit from the combined talents of those developers. And if a business is developing an open-source software project, the ability for programmers to view and modify the project allows an organization to recruit particularly talented employees.

Although open-source projects do not always have a single author or developer that can be reached for support for the product, there is often external technical support available for open-source packages. The more mature the software product and the more widely adopted, the more external support often available. Some of those vendors offer support contracts, and there are service providers capable of installing, configuring, and maintaining open-source software for businesses. Many open-source products also have online communities capable of supporting users and able to answer questions through online blogs or forums.

Furthermore, open-source software is generally thought of as improving and fixing bugs more quickly than proprietary software, in part because of the larger community of developers who work with an open-source software project compared to those working on maintaining and developing proprietary software. Open-source software not only allows, but tends to encourage collaboration, issue resolution, and improvements, and tends to implement these changes at a faster pace than proprietary software.

As each open-source software product is different, each can vary in its advantages, disadvantages, quality, and limitations. Many of the limitations can be overcome through training and support, although a disadvantage of open-source software can include a lack of personalized support.

While there are commercial service providers who can provide support, along with blogs and forums where frequently asked questions can be answered, open-source software does not come with the kind of phone support or personalized email support that can often be included with the cost of proprietary software. And if a user needs a lot of support, it could be beneficial and less costly to use a proprietary software product. Similarly, open-source software does not come with a warranty, as there is no single company or entity backing the product. This lack of a warranty could become a problem as open-source software may not provide any real protection from infringement.

While open-source software can be modified and developed to work with different software products, the compatibility of open-source software can be more restricted than initially believed, and issues can arise if the hardware used to create a piece of open-source software is not available to all programmers working on it. This can drive project costs up.

Similarly, while there are many open-source projects, there may be restricted choice with fewer versions of a given piece of open-source software compared to a proprietary version of the same software. The speed of change of open-source software can be an issue, especially as the modification of open-source software is ongoing. This can make it difficult to ensure that the software is compatible with other applications.

When considering the advantages or disadvantages of open-source software, a common example is the Ubuntu distribution Linux, which is based on Debian and composed of free and open-source software. Ubuntu Linux is often compared to Windows, as Ubuntu can be had for free, can be installed and distributed as often as wanted, and has been particularly popular with servers where a user can easily duplicate a single Ubuntu server without worrying about licensing and how many instances of Linux users can run.

The Windows 8 interface which disappointed users.

An open-source program is also considered more flexible. This was especially evident in the launch of Windows 8 and the operating system's interface, which disappointed many Windows desktop users. And since Windows is a closed source, Windows users could not take a preferred interface and modify it to work properly on Windows 8.

Ubuntu MATE, a user developed interface for the Linux distribution.

In comparison, when Ubuntu Linux introduced a new desktop interface that users were not fans of, the users had more options. For example, when GNOME 3 was released, many Linux desktop users did not like the new interface. Some took the code to the old version, GNOME 2, and modified it to make it run on the latest Linux distributions, called MATE. Some took the code to GNOME 3 and modified it to run in a preferred way, also called Cinnamon. While other users switched to other distributions of Linux. If Windows had been open source, Windows 8 users would have been able to modify their interface to something users preferred. This would be similar to CyanogenMod, a popular community-driven version of Android that adds features and support for new devices.

Open-source software, in the case of Linux and other software, allows developers to "stand on the shoulders of giants" and create software with strong code bases, often learning how to develop software projects from the lessons of open-source software. Examples are Android and Chrome OS, which are both operating systems built on Linux and other open-source software. The core of Apple's OS X and iOS was built on open-source code as well. Valve also worked to port the Steam gaming platform to Linux, allowing Valve to create their own hardware and control their own destiny in a way that is not possible on Windows.

The open-source license is owned by the Open Source Initiative and is granted to anyone willing to conform to the Open Source Initiative's terms of free distribution. Under an open-source license, the copyright holder allows people to freely view, modify, use, and share their software to anyone for any purpose. These licenses affect the way people can use, modify, and distribute software. These licenses, generally, grant computer users permission to use open-source software for any purpose they wish. Some licenses, often called copyleft licenses, stipulate that anyone who releases a modified open-source program must also release the source code for that program alongside it.

Some open-source licenses stipulate that anyone who alters and shares a program with others must also share that program's license without charging a licensing fee for it. Overall, these licenses are designed to promote collaboration and sharing because they permit other people to make modifications and incorporate those changes into their own projects. This encourages computer programmers to access, view, and modify open-source software, as long as they share their work.

Graphic exploring the often contrasted copyleft or permissive licenses.

The idea behind the copyleft licenses, as explored above, is that anything that is built from the use of free content is required to be free as well, with the intention to keep companies from incorporating open-source projects into their software and content and profiting from it, without giving back to the larger open-source community. Often proponents of copyleft licenses argue that free content should always be free, regardless of who changes it. Others argue that the use of copyleft licenses creates more restrictive scenarios in which the software may be less free than it otherwise could be. For example, if a user wants to develop a program that uses a software library under a copyleft license and a proprietary library, they would not be allowed to do so. Additionally, copyleft licenses, while they allow work to be copied and mutated, do not necessarily allow the software to be recombined and can create walls between open-source and proprietary software.

• GNU GPL v3
• GNU LGPL v3
• Mozilla Public License
• CC-BY-SA 4.0

Permissive licenses, on the other hand, allow users to copy, modify, recombine, and redistribute the work with minimal restrictions. Often the only restriction is that an attribution is required. Permissive licenses, especially when compared to copyleft licenses, are generally easier to understand and are much shorter. For example, the MIT license, a permissive license, is approximately 150 words long, while the GNU Public License v3, a copyleft license, contains approximately 5,500 words. Proponents of copyleft licenses can argue that permissive licenses allow proprietary software companies to take advantage of the work under the permissive license without needing to contribute anything to the open-source community.

• MIT License
• BSD 3-Clause
• Apache License 2.0
• CC-BY 4.0

Licenses tend to be approved by the Open Source Initiative, and these end up being the most popular and widely used licenses. Of the licenses included in OSI's library, the following are the most popular and widely used:

• Apache License 2.0
• BSD 3-Clause "New" or "Revised" license
• BSD 2-Clause "Simplified" or "FreeBSD" license
• GNU General Public License (GPL)
• GNU Library or "Lesser" General Public License (LGPL)
• MIT License
• Mozilla Public License 2.0
• Common Development and Distribution License
• Eclipse Public License version 2.0

Free and open-source licenses are frequently confused. Even the terms "open-source" and "free software" are often confused, with a lot of software released as free software and with proponents who insist this is not the same as open-source. Understanding the difference between these software and the related licenses can be important, especially to avoid legal trouble. The term FOSS (free and open-source software) can be used to cover both, with the "and" meaning it includes both kinds of software, rather than all FOSS being both free and open-source. There are a number of features common to all free and open-source licenses:

• A user has free access to the source code and should be able to build a working version of the software
• A user can run it without paying anyone
• A user can modify the software for their own use
• A user can distribute the modified version, although there may be restrictions on how this is done
• A user can distribute software of their creation, which incorporates the code, although there can be some restrictions

The biggest proponent of free software is the Free Software Foundation, which has published several licenses. These are generally called GNU licenses, after the GNU family of software products. The GNU General Public Library (GPL) is the archetype for free software licenses. The key point of the GPL is that it can stick. If users include GPL-licensed software in a modified form or incorporate it into a product, a user has to make it available under the same terms. This means a developer can sell the software, but also have to make the source code freely available. Free software advocates call granting rights this way "copyleft," and some consider open-source licenses generally not having these restrictions. They often place other requirements on the code, such as identifying clearly modified versions.

Generally, a user should open-source a project when they feel comfortable having others view and give feedback on their work. Regardless of the stage of the work when a user decides to open-source a project, every project should include the following documentation: one of the above open-source licenses, a README, contributing guidelines, and a code of conduct. These components help communicate expectations, manage contributions, and protect everyone's legal rights. And if the project is on GitHub, putting these files in the root directory with recommended filenames help GitHub recognize and automatically surface them to readers.

Choosing a license helps protect users from difficult legal situations, and as such an open-source project has to include a license when launched. And users, while they have a lot of choice, can copy and paste the license into a repository once they have a license they prefer. In the case of a README, the README does more than explain how to use a project; it also works to explain why a project matters and what users can do with the project. In order to do this, a README should try to answer a few questions:

• What the project does
• Why the project is useful
• How to get started with a project
• Where help can be found if needed

The README can also include information such as how contributions are handled and what the projects goals are, as well as information about the license and attributions. To fully establish how contributions are handled, a contributing guidelines section is suggested if not required, as it tells an audience how to participate with a project, how to file a bug report, how to suggest a new feature, and how to set up an environment and run tests. In addition to technical details, a contributing file is also a place where the project developer can communicate the expectations for contributions, such as the types of contributions a project is looking for, a roadmap or vision for the project, and how contributors should (or should not) get in touch. Over time, a contributing file can also include information on frequently asked questions to reduce communication times.

Establishing a code of conduct can help set the ground rules for the behavior of a project's participants. This can be useful when launching an open-source project for a community or company. A code of conduct can help users develop a healthy and constructive community, and reduce the overall stress of a maintainer. On top of communicating how users expect participants to behave, it can also describe who the expectations apply to, when they apply, and what is done or what should be done in the case of a violation.

Whether in the initial phases of development of an open-source project, or even in the development of proprietary software, there are various tools for developing the software. These development tools can include communication tools, such as email, real-time messaging, forums, and wikis to help developers find solutions or collaborate on solutions; distributed revision control systems, such as the systems which manage the different versions and updates on a project; bug trackers and task lists, which can help large-scale projects monitor issues and keep track of fixes; testing and debugging tools, such as features that automate testing during integration and work to debug other programs.

Many of these tools are themselves open-source. For example, one of the most popular of these development tools are the repositories that are hosted and published on source-code-hosting facilities, such as Launchpad, GitHub, GitLab, and SourceForge. For revision control systems, which can help manage the source code files and the changes to those files, open-source tools such as Concurrent Versions System (CVS) and Subversion (SVN) and Git exist for users. And popular utilities such as issue trackers and bug trackers also have open-source solutions, such as Redmine, Bugzilla, Trac, and Mantis. Popular open-source development tools include the following:

When developing open-source software, or in the case of companies which use an open-source software development model, the question of a business model or else an approach to developing a revenue stream around the software without losing the essence of the open-source software has led to the development of various business models around open-source projects. These include, but are not limited to, business models such as open-core, professional services (proserv), hybrid licensing, hosting, support, restrictive licensing, marketplaces, voluntary donations, crowdsourcing, and advertising-supported software.

The open-core model has been viewed with suspicion, with developers worried about companies building commercial products on-top of open-source cores that would, over time, seek to weaken the open-source product in order to make the commercial offering more attractive. However, as more commercial open-source companies have strived to be good stewards of open-source projects, and chose to build products that extend their open-core without conflicting with open-source projects, has seen the model be viewed less negatively. Especially as some companies have chosen to take the open-core of their project and place it under the governance or auspices of non-profit open-source software foundations. This saw more open-core companies offering complement rather than conflict with the open-source software offering at the "core" of the company.

This has seen open-core emerge as one of the more popular ways for open-source companies to make money. Often, the proprietary, or paid-for part of the software, is offered either as a package of separate modules or services that interface with the open-source base, or they can be distributed in a forked version of the open-source base. Typically, the features offered in the model are those needed for production deployments and/or at scale. This allows the open-source company to license the core with a permissive license, while retaining the ability to charge for proprietary features, and defend against free-loading participants by keeping certain features in the proprietary code base. The challenge with this model, however, is balancing open-source values with the proprietary software, such that if a company gives away too much it sacrifices an opportunity for increased revenue; but if it gives away too little, the open-source portion of the software becomes effectively useless.

Early open-source models built on professional services, with users paying for support and consultancy. While a number of companies were able to scale with this model, it has offered its own challenges, with service revenue often highly-unpredictable, and the service model often requires a large head-count which can leave a company exposed when revenues shift. As well, the margins with professional services are often thinner than those with product-based companies.

For example, in the case of Red Hat, the margin on services the company saw in a given year was 31 percent, whereas revenues were 93 percent on the company' subscriptions. This means to hire an additional developer, Red Hat had to make three times the revenue from consulting compared to their subscriptions. This disparity has meant consulting-based open-source businesses have been consultant-heavy with limited resources to spend on developing the open-source product. While there are some examples of companies that have had significant revenue through pure-support subscription models, such as Hortonworks the industry has largely shifted to bundling support with additional product offerings due to the lack of defensibility.

This is a newer model, initially popularized by CockroachDB, and adopted by Elastic. Hybrid licensing takes the open-core approach but works to improve upon it. This includes intermingling open-source and proprietary software in the same repository, and then making the code for the entire repository available. That is, the entire repository is "open code" or source available, but not all of it is licensed under an OSI-approved open-source license. Users can choose to use a binary with just the open-source bits, or use a binary with both the open-source and proprietary bits. The proprietary licensed binary will often have paid functionality that is off by default, and can be unlocked through a license key.

The advantages of this approach include the advantages of an open-core business model, plus having everything in the same code base, which can decrease the engineering complexity and the development process; it enables entire teams to work on a project; it allows users to upgrade from free to paid in-place and often without any need for significant downtime or needing to interact with a salesperson; and it allows external community members to comment on, file issues on, and contribute to proprietary features using the same workflow used for open-source features.

This has grown to be a common offering from open-source companies, especially in the data space, which works to enable end-users to use infrastructure components in a similar way to software-as-as-service offering and without having to be concerned with the operational overhead of managing the infrastructure. Public open-source companies have avoided disclosing margins for hosted service, some calculations have suggested that a business such as MongoDB's cloud business operates at roughly 65 percent and Elastic's at roughly 40 percent. This places it above services margins, but lower than a typical product margin.

The economics of hosting are driven by the willingness for users to pay, meaning if the price is significantly higher than the cost of the underlying infrastructure companies can choose to host for themselves, which is especially true for larger customers who often have in-house development teams. This model has also been challenged by cloud hosting providers that have begun offering hosting solutions for common open-source packages, which has further squeezed margins for open-source products, such as Redis or MongoDB, both of whom have notably changed the terms of their licenses to neuter the competition from cloud vendors.

A separate strategy, used by notable companies such as Confluent and Elastic, has been to offer exclusive features in their hosted services not available in the open-source, and thereby creating a blended hosting-open-core model. It is noteworthy that while hosting is often a significant revenue generator for these companies, it is also often a secondary revenue generator rather than primary.

The support model includes selling deployment and integration services, production-oriented "insurance policies," certified binaries, training, bug fixes, and more to businesses that have deployed the project in product. The model becomes limiting over a longer term for the following reasons: support often requires a lot of manual work, which in turn reduces business margins; scaling can prove difficult as often support work is non-repeatable (if a bug is fixed, a bug is fixed); and it creates incentives on the part of the open-source company where a easy-to-use product cannibalizes support revenue. Often this is a revenue model that works best with a project that requires complex deployments with sprawling ecosystems, which often goes against building the best user experience.

This model has also been notoriously inefficient, typically converting less than 1 percent of users into paying customers. This is not surprising, as open-source software is itself free, and in order to feel the need for support, the software has to be relied on for a company's critical system. Yet over time, a company that does rely on the project will invest its own engineering efforts to understand the project and reduce the overall need for external support.

The restrictive licensing model creates a legal reason for users of open-source software to pay. This is done by providing an open-source license with onerous terms, which means that anyone using the software is incentivized to strike a commercial deal with the vendor. The GPL and AGPL licenses, as well as the Commons Clause, are examples of this model. In particular, the AGPL and Commons Clause are licenses designed to defend against public cloud providers.

This approach, as all approaches, has limitations. The GPL-based license restrictions do not restrict unmodified usage and only applies if a user makes modifications and does not want to open-source them. While the Commons Clause contains ambiguity in its language that makes its application legally dubious. And the largest drawback of the approach is the license hurts adoption of the software and can turn off potential users. There have been examples of a few large companies with explicit policies against using restrictive licenses, and because of the inherent friction of the approach, many rule it out.

Although it is often overlooked, one of the larger commercial success stories of open-source software has been Android. While Google does not breakout revenue and margin from the Play Store in their financial reports, they are expected to be higher than those of Red Hat, which previously held the title. Mozilla similarly generates the bulk of the company's annual $500 million revenue by providing lead generation to search engines. While the marketplace model is a relatively rare model in open-source software, it allows open-source software to be an intermediary between parties that interact with a product, and it is a model that open-source companies and startups are increasingly exploring.

Many open-source projects, especially those developed by individual developers rather than larger companies, work through voluntary donations in order to fund the development of the software. This has been done with varying success, and can depend on the hosting site. For example, in 2011 SourceForge began allowing users to donate to hosted projects. These projects had to opt in to accept the donations. While in 2019, GitHub made a similar move to SourceForge and launched a Sponsors program that allowed open-source projects hosted on GitHub to receive donations. And while this is generally used by individual developers, there have been examples of fundraising campaigns, such as the one held in 2004 by the Mozilla Foundation, which was carried out to support the launch of Firefox 1.0 web browsers. This campaign included a two-page ad in the December 16th edition of the New York Times and listed the names of the thousands who had donated to the project.

Crowdsourcing is similar to voluntary donations, as it involves a participative community to undertake a voluntary action to help an organization or individual. This activity does not always have to be voluntary, but can include the undertaking of tasks, the provision of knowledge, the offer of financial support, or the use of experience, and often entails a mutual benefit. This benefit could include the user's satisfaction or development of a skill or it can be undertaken for social recognition, but that will depend on the individual, in much the same way the crowdsourcing activities will depend on the organization or individual. An example of crowdsourcing projects have included Linux, Google's Android, the Pirate Party movement, and Wikipedia.

In order to commercialize open-source software, many companies, which have included products offered by Google, Mozilla, and Canonical, have used an advertising-supported software model. For instance, the open-source application AdBlock Plus receives payments from Google for whitelisting Acceptable Ads past the adblocker. Or, in the case of SourceForge, the site uses banner advertising on its website, and this business model brought SourceForge a reported quarterly revenue of $23 million in 2009.

Open-source applications are freely available, although there is nothing stopping a developer from charging for copies of the software if they allow redistribution of the application and its source code afterwards. Whereas the "free" in "free software" refers to freedom rather than free in price. Free software is led by Richard Stallman and the Free Software Foundation, which focuses on the ethics and morals of using software that can be controlled and modified by the user, and means free software focuses on user freedoms.

Whereas open-source software was created to focus on more pragmatic reasons for choosing the type of software. Open-source advocates tend to focus on the benefits of using open-source software that would appeal more to businesses, rather than to ethics and morals. Free software, which is also considered freeware, and shareware, are both considered alternatives to open-source software. Often the determination of whether software is open-source, free software, freeware, shareware, source available, or open-core has less to do with the software, and more to do with the licensing and the philosophy of the software developers.

Freeware is free software that is made available for use for an unlimited time. It is not "free software" as described by Richard Stallman. In contrast to OSS, freeware does not always make its source code available to users. Users are often prohibited from altering the program, repackaging it, or selling it. Because the source code is not accessible, there is no community or development infrastructure around freeware like there is for OSS. Though it comes at no cost, users should remain mindful that freeware does not offer chances to customize the software and there are often limited support or updates available.

Shareware is a method of distributing software based on a trial model, where authors can give users a license to try out the software for a specific period of time. If users wish to continue using the software after the trial period, they are required to pay a fee. If users do not wish to continue using the software after the trial period, they are expected to discontinue use. Shareware is distributed on the basis of an honor system, and often once the trial period ends, shareware will have updates and will require the user to pay a small fee for additional functionality. Unlike OSS, shareware does not involve the release of the source code or allow for modifications and redistribution by users. Shareware is usually written by a professional developer or small software company, but does not often have a community or development infrastructure similar to OSS.

Similar to open-source, source available is a term used to refer to software where the source is available for viewing, but is legally available for modification or redistribution. The term was coined by Microsoft in 2001. While in 2007, two of Microsoft's Shared Source Initiative licenses were certified y the OSI, the licenses were never truly open-source and rather remained source-available only.

MongoDB, in another version of source available, developed the Server Side Public License (SSPL) which was proposed as an open-source license patterned after the GNU General Public License and the Affero General Pubic License by MongoDB. SSPL does not prohibit software from being run as a service, but requires those running the software open-source all programs used to make the software available.

Source available software further gained traction in 2018, when Amazon Web Service used open-source code to develop commercial services, which resulted in a proliferation of source available licenses such as SSPL, the Confluent Community License, Redis Source Available License, Neo4J Commons Clause, Cockroach Community License, Dgraph, Elastic License, Sourcegraph Fair SourceLicense, MariaDB Business Source License. The trend toward source available was expected to provide open-source software developers protection from cloud infrastructure providers and allow users to mix and match limitations.

Open-core software, which is similar to open-source software, is better understood as a business model used to monetize open-source software. The idea behind open-core is to build an open-source product, but offer additional functionality at a premium. This can include the repackaging of the open-source with new features or providing those features in the form of ancillary products and services.

These additional functionalities do not adhere to the criteria of open-source and are never produced under open-source licenses. The source code for these services is rarely, if ever, made public, and even if it is, it is licensed under a commercial license that restricts modification and redistribution.

As a business model, open-core offers a middle ground between the fully open-source and fully closed-source extremes. It allows organizations to share code with the community, which can in turn drive awareness and encourage third-party contributions, without foregoing the revenue potential of a new product. And with the wider acceptance of open-source software in enterprises and governments, many traditional proprietary software companies have felt compelled in some cases to engage with open communities. This has been done in some cases by applying a veneer of open-source business practices and pricing practices that hearken back to a different era, and instead of creating open-core software providers.

Often, the open-core development model is seen as a chance for vendors to only open portions of their software while surrounding the remainder with proprietary-by-vendor offerings and offering a narrowly cast version of open-source that does not offer the benefits of true open-source software, while offering convenience for technology providers to continue to hold on to proprietary offerings.

Open-source software in enterprise applications is often considered more than the use of open-source software, but is often an integration of permissively licensed open-source libraries or software. But to be used in an enterprise operation, this software is often tested, adjusted, and examined for security flaws by teams capable of responding to any security or vulnerability flaws in the original software. These software packages, whether used internally or offered to other users, often also include useful integrations, such as single sign-on (SSO) integrations and directory management.

While the use of open-source software in enterprise requires additional training and certifications, and can require more investment and planning for IT environments, they also tend to have a predictable lifecycle with information and components capable of being developed at different speeds. Similarly, the software tends to have longer lifespans for important applications. For example, Red Hat's Enterprise Linux has a lifecycle of ten years. For these reasons, and many of the advantages listed above, many companies and individuals prefer to use open-source software.

Since the growth in popularity of open-source software, several types of support services have emerged to assist users and businesses, which can be roughly broken down into commercial and free software. Commercial support can be again subdivided into sponsoring vendors and consultants. For sponsoring vendors, there are several popular open-source software packages used by businesses where commercial support is available. For example, Red Hat and Canonical offer commercial support for their Linux distributions. Similarly, some vendors offer training and certification courses, such as Oracle for MySQL.

For consultants, there is a large amount of open-software specialists, each with different levels and types of experience, knowledge, and certifications. This can make it difficult to choose a specialist with particular expertise in the open-source software for which a user requires assistance. Some sponsoring vendors will provide directories of service providers with expertise in a specific open-source software. For example, Apache provides a global consultancy directory for those with expert support services for OpenOffice.

Free support can be subdivided into sponsoring vendors and online community resources. For sponsoring vendors, many offer initiatives in which experienced users are encouraged to help those having trouble with an open-source software. For example, Mozilla Firefox has an Army of Awesome support service in which Firefox users can login to Twitter and tweet support solutions to other users with questions. And for online community resources, these include community forums, free documentation and tutorials, and mailing lists that provide information and assistance from the user community and experienced users.

Depending on who is asked, open-source software is either more secure than proprietary software because its source code is in the "open" for anyone to analyze and discover vulnerabilities and provide fixes for those vulnerabilities, or less secure because anyone can discover and easily access a vulnerability in the source code. Data from Synopsys has suggested that 84 percent of codebases contain at least one open-source vulnerability.

There remains, in either open-source or proprietary software, the risk of cyberattacks; and while the risk for a cyberattack or cybercriminal to try and leverage the openness of open-source software remains, most users have found the advantages to outweigh the risks. And the community around a piece of software can be increasingly important in this respect, as a good community can be quick to respond to security vulnerabilities, and contributors amass support to patch these kinds of vulnerability.

The community, in this and other cases, can be integral to any open-source project. The number of active contributors is indicative of any project's overall health. Especially as some consider a project being open-source inherently meaning that it is more secure than proprietary software. But if a project is not maintained or has not been updated in a significant period of time, such as two years, it is often less secure than a proprietary equivalent that is regularly updated and less likely to have an active community. And the principle applies the other way around—with open source having the potential to be more secure than proprietary software. If taken together, and if both are receiving updates, the open-source software may be more secure by virtue of its community, which can count into the thousands who are actively inspecting the source code.

Especially when used by an enterprise or government, an open-source management program provides a structure around aspects of open-source software. This can include a strategy and process around software selection, approval, use, distribution, audit, inventory, training, community engagement, and public communication. However, there remains the common assumption that open-source code is innately safe, or safer than proprietary software, because the code is developed and maintained by many people who can identify problems in the software; there is safety in numbers. However, as explored above, this can also increase the vulnerabilities in an open-source library. Attackers or potential cybercriminals can disguise themselves as contributors to the open-source library and work to sneak malware or vulnerabilities into the project. However, for as many potential cybercriminals that could be working on the library, there are as many non-threatening eyes watching and going over the source code that can find those vulnerabilities.

Another difficulty for a larger organization is that proprietary software will push updates to users, but often open-source libraries require manual updating. These manual updates mean users are responsible for tracking and applying updates and patches as they are developed. This is where an organization can benefit from established processes or strategies to maintain open-source components. This can be less of an issue when there are only a few open-source components in an application. But when the amount of open-source components grow, the project of tracking these updates can be overwhelming, which means inevitably updates are missed and portions of the application can move from secure to vulnerable.

Some risk from open-source libraries comes from applications an organization uses that they do not know is present in a piece of software. Some of the most commonly included libraries are present in over 75 percent of applications per language, and most flawed libraries find their way into code indirectly, with some suggesting 47 percent of those flawed libraries in applications are transitive, or not pulled in by developers but pulled in by upstream libraries. Some of these flaws can be fixed with a minor version update. At the same time, not all libraries have common vulnerabilities and exposures (CVEs), which means developers cannot rely on CVEs to understand library flaws. For example, more than 61 percent of flawed libraries in JavaScript contain vulnerabilities without corresponding CVEs. Which brings the problems back to organizations needing to develop processes or programs for identifying and updating for vulnerabilities.

Organizations, despite these risks existing in any open-source library, tend to assume that most risks come from public-facing web applications. However, the dozens of small components are in any given application, and risks can come from anywhere in the codebase. Bugs like Heartbleed, ShellShock, and the DROWN attack have made headlines, but most bugs found in dependencies go unnoticed. There are several reasons for these going unnoticed, first being that most organizations do not have accurate inventories of software dependencies used by applications. As well, many organizations do not have a reliable way to be notified when zero-day vulnerabilities are found or when patches are made available, other than notifications from the community supporting the project.

Organizations will not stop using open-source software, and the ideal way is to bridge any gaps between DevOps and SecOps teams to make their job manageable and automate the finding of security vulnerabilities and for finding updates and bug fixes in open-source software. Most organizations start by searching the CVE and NIST Vulnerability Database for vulnerability information, but these sources often do not provide the best information on open-source vulnerabilities. Another issue is that many of the libraries that track these kinds of vulnerabilities in open-source have closed, and others are distributed or specific to larger projects, such as Node.js and Ruby-specific vulnerabilities—meaning a lot of projects and ecosystems are not well covered.

And part of the difficulty for organizations is that they often still believe that open-source code is more secure than proprietary code. Which is not to say that it is less secure, but rather that intentional efforts need to exist in order to secure a piece of code, rather than the assumption that the code is secure because it is open source. This intentional effort, other than more organization activities described above, can further include specific activities such as code inspection, dynamic security scanning, and penetration scanning, among others.

This can include the use of good security software that works to monitor all risks across applications and provide expert remediation advice, which can provide insight to help teams mitigate potential risks before they are exploited. Further, users can use continuous monitoring and integrate tools directly into a continuous integration and continuous delivery (CI/CD) pipeline or a source control repository, like GitHub or Bitbucket to track changes and monitor those applications. The integration can make it easier to detect vulnerable components early and prevent such vulnerabilities from reaching the production environment.

And there are different open-source and commercial tools have emerged to tackle the problems within the management of open-source software. Each tool or service tackles the problem differently, and these tools include the following:

Arguably, the history of open-source software starts with operating systems, especially in the case of Unix, based on the Berkeley Software Distribution (BSD) Unix. Since then, more proprietary operating systems have emerged and gained market dominance, but there remain many popular open-source operating systems, and open-source operating systems have also served as the groundwork for more well-known proprietary operating systems, such as Android or macOS.

One of the most popular open-source operating systems is the Linux operating system, which has various versions, also known as distributions, intended to suit users with different levels of computer literacy, and different use-case goals for the operating systems. Some of the most popular Linux distributions include Ubuntu Linux, Arch Linux, Fedora, Linux Mint, Debian, and openSUSE. FreeBSD is a free open-source OS, based on the Unix operating system, and is one of the most popular BSD operating systems. Websites of companies such as Netflix, Hacker News, Yahoo!, and Netcraft use it.

A web server is a computer system that distributes data from web pages to end users over the Internet using HyperText Transfer Protocol (HTTP). One of the most popular open-source web servers is the Apache HTTP Server with 45 percent of websites using it as of November 2018 according to W3Techs, while BuiltWith Internet Services has counted 62 million live websites using Apache. NGINX comes in second in the open-source web server popularity contest with approximately 40.2 percent, or 43 million, websites using it.

The capabilities of open-source databases have reached the level of proprietary solutions due to the number of companies that have begun to and continue to use them for large-scale projects. Popular open-source databases have included MySQL, PostgreSQL, and MariaDB. And review of platforms has shown the rising popularity and satisfaction companies have using open-source databases, and an increasing research frequency for these databases by potential buyers.

There have been various open-source mobile software and application development platforms or frameworks that have been developed, including popular open-source software development kits (SDK) such as Ionic, or open-source multi-platform's SDK's developed by the mobile operating system providers themselves, such as Flutter developed by Google or Xamarin for Microsoft.

There are various open-source software testing automation tools. These can support mobile testing, often support numerous programming language, and support multiple operating systems and browsers.

User and graphical interface design software includes any user experience and user design software, including products for digital product design, visual design, and web design.

Open-source artificial intelligence and machine learning refers to any technology that is publicly available for commercial and non-commercial use for artificial intelligence, including technologies for product teams, application developers, and enterprise. These technologies can include open-source datasets for training AI datasets; open-source algorithms, which can offer core statistical models and algorithm libraries that can be deployed as is or further trained using open-source or enterprise data; and open-source UI, which can include developer interface which can help open-source AI be available and can range from command line interfaces to sophisticated GUIs.

Robotics and automation platforms include software tools or platforms for developing, designing, and using robotics, especially in the case of repetitive manufacturing processes, medical uses, dangerous or hazardous environments, and in the care of elderly people.

This includes open-source software for big data applications, such as big data frameworks for the distributed processing of large volumes of data and storage for applications running in computer clusters, or for platforms that can analyze streaming data and use the analysis to develop machine learning algorithms.

An e-commerce platform can include any software or software platform a used to build an e-commerce sight. This can include entire platforms, payment gateways, or related software.

Content management systems and software allow users to create, manage, edit, and publish digital content. WordPress is one of the most popular open-source CMSs for building blogs, websites, and applications based on the PHP scripting language and MySQL database system, and capable of being extended with more than 45,000 plugins. Django is another CMS, which allows for publishing content on the internet and over intranets. And these are two of the more popular examples.

Library management software includes tools used to manage the in-house functioning of a library, including the management, handling, and maintenance of the books in a library. Often this software allows users to find books quickly, issue and reissue them, and manage all the related data.

Productivity software includes word processing, presentation, graphic, and spreadsheet software, including software suites that allow users to read and write files from other common software packages. It allows a user to work with text documents, databases, spreadsheets, draw flowcharts, vector graphics, and edit formulas. Often this software is available for various operating systems, and can read, edit, and export in various file types. Productivity software is often also called office software, for its use in business and office applications.

Personal information management software offers a single place to collect and manage information for several different places, events, documents, calendars, and other related software. This can include dedicated personal information management applications, or extensive personal information management tools that can help users structure the complex relationships and information they must manage. This includes features such as email, calendars, contact books, and note taking features.

ERP tools and services are comprehensive systems including numerous modules to enable information management across all of an organization's departments. There are various open-source ERP tools that can provide extensible products, which include HR management, collaboration tools, enterprise asset management, project management, and CRM functionality. The solutions can be built for different levels of software literacy and for different sizes of organizations.

What could also be considered financial software, open-source accounting software includes systems that are often included in enterprise resource planning, but may also be broken into simple accounting software for budgets, human resources, payrolls, and logistics.

File and document management systems offer organizations and individual users a chance to manage files and documents across larger networks, or for individual computers or servers. These software systems help store, track, manage, and secure important files.

Editing and conversion software allows users to edit video, images, and in some cases audio, and convert those files to various file types. This allows users to transform a video or audio format into any other video or audio format, including upscaling, downscaling, or removing video or audio shortcomings to offer a smooth playback experience.

Open-source programming languages are programming languages that have been in development and in use since the first digital computers. These programming languages are often used for programming or coding, are used to solve problems in laboratories and research centers, and have been used to continue to develop programs and teach people how to code.

Computer-aided design software are software products that work throughout the product development lifecycle to develop pieces of or entire structure of manufactured products—for example, aircraft or automobiles. This software helps users design or draw a product while reducing the time and technological challenges of the designer.

Game engines are any software that provides game architecture, game frameworks, and/or game-frames to developers with different sets of features to build video games. Often a game developer will import the core functionality provided by a game engine that includes a rendering engine for either 2D or 3D graphics, a physics engine or collision detection, lighting, audio, special effects, animations, networking, memory management, scene graphs, and interactive gameplay logic. This software also allows developers to edit, debug, and optimize content for gaming development.

Media software includes any software that allows users to playback audio, video, or other multimedia files. This typically includes media server software that includes these capabilities, and also offers file discovery and allows file sharing and users to manage playlists. This can further include offering storage and retrieval services, with network access, and can include any hardware that can store music, images, and videos, and can be accessed over a network through Wi-Fi.

Educational software can include any software that helps digitize education through virtual universities, online courses, education portals, and courseware. Virtual universities are generally one of the more well-known forms of online education, with programs delivered through a digital university, similar to online courses, which can be provided through a variety of sources. Educational portals, not directly connected to the curriculum, allow for administrative functions, courseware, and other administrative tools. And courseware is often outsourced to both academic and corporate institutions for online and offline study materials, including training programs.

Assistive technology software can include any program or operating system, or related feature, designed to let a user with cognitive, sensory, or physically impairments use a computer system. Often these pieces of software are not cross-platform as the technology is closely integrated with the operating system and display subsystems.

Open-source cybersecurity programs include malware detection, antivirus software, data loss prevention, data recovery, data forensics, data anti-forensics, disk erasing, disk encryption, network and security monitoring secure shell, password management, access, and identity management.

The history of open-source software arguably stretches back to 1969, with the development or Unix at AT&T Bell Labs as a proprietary but licensable product. Over the following ten years, the development of Unix had multiple versions, including V6, which became the first available outside of Bell Labs. Previous to this, most software worked as free or open-source software (FOSS) and were shared among people who took care of computers. Only a few companies manufactured computers at the time, with IBM being the market leader, and for those computers software was seen as a companion to the hardware, such that by paying for maintenance on the machine, the user had access to the software catalog of the manufacturer. And prior to 1970, software was considered an add-on to the hardware, and not considered something valuable in and off itself.

Example of early Unix build.

But in 1969, with the development of Unix, and with IBM announcing the unbundling of their software from its hardware, software slowly began to be something that needed to be purchased separate from the hardware. And around this time, around 1972, Unix became available and was adopted by the academic community due to the nature of the language of the software. The University of California, Berkeley started the development of its own Unix and developed an academic version called the Berkeley Software Distribution, which later gave name to the BSD License. AT around the same time, AT&T evolved their version of Unix into System V, and the two versions were eventually merged to create the seventh edition of Unix, which again further evolved into such programs as Sun Solaris, FreeBSD, NetBSD, and OpenBSD.

Example of SPICE, still in use 40 years after its development.

In 1973, SPICE and related source code were placed in the public domain by its author, Donald O. Pederson. The program was a tool for learning integrated circuit design, and was adopted by several universities. Over time, SPICE, and its derivatives evolved into the industry's preferred tool to design integrated circuits and was an early example of how a free or open-source software strategy could lead to a strong market position.

Richard Stallman

In 1983, Richard Stallman announced the GNU Project, which aimed to produce a Unix-like system composed only of free software. At the time, Richard Stallman was a programmer at MIT's Artificial Intelligence Lab, and later quit his job to ensure he had full ownership over the software he wrote. Stallman believed software should be accessible to programmers, to allow those programmers to modify it as they wished, with the goal of understanding the software, learning about the software, and improving a given piece of software. Stallman began releasing software under his own license, the GNU Public License.

Stallman's GNU Project began with an editor (Emacs) and some other tools were under development. By 1987, the GNU Project delivered a compiler (GNU Compiler Collection), a debugger (GNU Debugger), and other utilities. On the road to developing these software projects, Stallman founded the Free Software Foundation in 1985 to support and foster the GNU Project and free software in general. Part of this included the establishment of the philosophical principles of free software, which included a definition of the concept.

By the end of the 1980s, FOSS communities had grown in size and complexity, with people and companies collaborating to share software and resources. They were using several sustainability models, including public funding, donations through nonprofits, direct funding from companies, and the direct involvement of companies through neutral consortiums, pure volunteer work, and any combination of these strategies. This led to the establishment of a legal infrastructure centered on two families of FOSS licenses, which continue to be used. These were based on the principles of the GNU GPL, BSD, and MIT licenses, with similar philosophical basis, that were formalized in documents throughout the communities.

The early 1990s saw the developments of the previous decades converge in some of the first complete systems composed of only FOSS components: BSD and Linux. In the BSD Unix group, the CSRG implemented most missing components to produce a complete Unix-like system under the BSD license which was distributed as Net/2. In 1992, 386BSD was released with an implementation of the small pieces that Net/2 needed and resulted in the first full FOSS system, and resulted in later evolutions such as NetBSD, FreeBSD, and OpenBSD.

Linus Torvalds

In 1991, Linus Torvalds announced a project to write an operating system kernel, later named Linux. It gained traction and contributions from other developers until Torvalds was able to release Linux 1.0 in 1994, which was the first "stable" version, despite Linux being available as early as 1992. Many tools, including GNU and BSD, were ported to Linux, and different groups started to produce Linux-based distributions, such as Slackware, Debian, or Red Hat.

Example of the Linux kernel

The group of developers working to produce the Linux kernel became one of the first major software development communities. From the beginning, the project was directed by Torvalds, with few formal governing rules, and although no companies had direct involvement, many Linux developers were hired. This led to the founding in 2000 of the Linux Foundation, which worked to organize contributions from these companies and support the project, while technical decisions of specific distributions maintained relatively separate. The Linux Foundation extended the model to other projects that eventually came under its umbrella.

In the late 1990s, a series of events drew a lot of attention, which led to an increase in the professionalization of free and open-source software. These included the IPOs of VA Linux and Red Hat in 1999, both of which shared gains in share price on their opening days. Another was the 1999 announcement of IBM supporting Linux with a $1 billion investment in development to reduce the risk of using it for traditional enterprise users. And in 2000, Sun Microsystems released the source code to the company's cross-platform office suite, StarOffice, and created the OpenOffice.org project.

Eric S. Raymond

In 1997, Eric S. Raymond published an essay titled "The Cathedral and the Bazaar" which compared and contrasted development methodologies and social structure of GCC and the Linux Kernel, and talked about his personal experiences with a "bazaar" development model. Many of the principles described in the essay became central to agile development and DevOps, including consistent releases, refactoring of code, and treating users as co-developers. The essay has also been credited with bringing the ideas of free software to a broader audience, and convincing executives at software companies that releasing software under a free license was the right thing to do.

Christine Peterson

Raymond further went on to be instrumental in coining the term "open-source" and was key in the development of the Open Source Initiative. The essay was also credited as a key document in the 1998 release of the source code for the Netscape web browser Mozilla. With the release of the Netscape source code, the term "open-source" was coined during a strategy session held on February 3rd, 1998, in Palo Alto, California. The term was originally suggested by Christine Peterson.

The strategy session grew from a realization that the Netscape announcement created an opportunity to educate and advocate for the superiority of an open development process. The conferees believed that, to help people engage with potential software developers and users, they needed a single label to identify the approach and distinguish it from the, arguably, more philosophical and politically-focused label "free software" and this developed the "open-source" label. This strategy session also led to the development of the Open Source Initiative (OSI) which was conceived as a general education and advocacy organization to focus on explaining and protecting the "open-source" label. Some of the group's early activism included supporting petitions for the United States government to use open-source software.

One of the first tasks undertaken by OSI was to draft the Open Source Definition (OSD), and used it to create a list of OSI-approved licenses, with the OSI offering some assurances to open-source software developers of the usefulness or applicability of the license, and offering a searchable library of those licenses. The Open Source Definition was originally derived from the Debian Free Software Guidelines (DFSG). The Open Source Definition was created during the launch of the OSI in February 1998 in a revision of DFSG, which, in part, removed Debian-specific references.