Open-Source Software vs. Proprietary Software: What to Know | Heavybit - The first knowledge sharing application in Vietnam

Andrew Park

Editorial Lead
Heavybit

APR 13, 2023

24 min

Open Source vs. Proprietary: Development, Licensing, Business Models, Security, and More

Open-source software (OSS) is gaining incredible traction in the modern software marketplace, despite a massive field of proprietary software products continuing to see considerable success. This article will briefly touch on the topline differences between the types of software, and dive deeply into what startup founders and technical leads need to know about the differences in how to develop, license, and go to market with OSS vs. closed-source software products.

For more insights on the challenges and trends in modern OSS, join the DevGuild: Open Source event to learn from leading startup founders and investors in the space.

Key Differences Between Open-Source Software and Proprietary Software

Open-source software is distributed with its source code, and lets users freely inspect, modify, and enhance it per its licensing agreement, while proprietary software is the copyrighted property of an individual or company that limits its use, distribution, and modification by way of a proprietary license.

Prominent examples of open-source software include the web browser Firefox, the content management system WordPress (and its many, many plugins), and the open-source operating systems Android and Linux (including the popular Ubuntu distribution for Linux).

Most (though not all) closed-source projects tend to be commercial apps–some examples of proprietary software include Microsoft’s Office productivity suite, Adobe’s creative suite, and commercial operating systems such as MacOS and Windows.

Key Differences for Users:

Open-Source Software for Users:

Development: Community based
Licensing: Copyleft or permissive, allowing some level of modification and distribution
Security: Dependent upon open-source community participation and upkeep
Flexibility: Significant flexibility with the freedom to inspect and modify OSS
Maintenance: Community-driven across the software’s lifetime per the community’s priorities (with bug fixes potentially being provided by only a handful of dedicated community members)
Support: Not provided as a service, and generally requires independently checking the documentation or crowdsourcing across the community
Cost to Use: OSS generally has no initial fee, except in the case of companies using a SaaS model–see below. Over time, relying on OSS may incur ongoing costs in developer maintenance.
Ease of Use: Getting started working with a new OSS project for the first time may depend entirely on how much clear community documentation is available for beginners

Proprietary Software for Users:

Development: Closed-source, usually by a professional team
Licensing: Restrictive, usually forbidding modification and distribution
Security: Usually company-driven and requires professional development resources
Flexibility: A more-restrictive license generally prevents inspecting and modifying code
Maintenance: Provided by the software’s publisher across its lifetime in response to customer needs and market conditions
Support: Provided by the software’s publisher in direct response to customer needs
Cost to Use: Typically requires purchase/subscription, particularly for commercial apps
Ease of Use: Particularly in the case of commercial products, software vendors are incentivized to focus on usability, as user-friendly software will encourage continued use

The Rise of OSS

It’s impossible to ignore the increasing popularity of open-source software (OSS) despite the enormous market share of well-known proprietary software brands. As of 2015, 66% of companies reportedly created software for customers built on OSS, with 78% of companies running at least part of their infrastructure on OSS components. More-recent reports suggest that developers build up to 70%-90% of modern software on OSS.

So, why is open-source software ascendant? As we cover in our article on the benefits of open-source software, OSS offers many important advantages to developers and startup founders, including faster project start time, community-driven collaboration, no initial contract lock-in to a vendor, and lower initial costs including a typical lack of licensing fees–though over time, relying on OSS rather than homegrown code will tend to cost additional developer hours as teams invest extra cycles to improve compatibility by adapting OSS projects to their own specific use cases and infrastructure.

For all its benefits, OSS may not always inherently be a “better” way to deliver software for every possible use case. There is still a place for proprietary software in the modern business landscape–reportedly, about 45% of all software tools that companies use are proprietary. Next, we’ll cover some of the most significant differences between the two software models, and what they potentially mean for tech leaders and startup founders.

Differences: Development

As you might expect, software development for OSS projects differs drastically from development processes for proprietary software, particularly since the majority of closed-source products come from commercial, for-profit businesses.

Open-Source Software Development

OSS development tends to:

Offer a faster, lower-friction start: While established open-source projects have many important aspects (including project documentation and a highly-engaged community), to start a new project, you don’t need much more than:
- Your project’s license – Which stipulates usage, distribution, and modification
- Your project’s README file – Which acts as an initial set of documentation and guidelines for the project
- Guidelines for contribution – To specify how people can contribute to your project
- Code of conduct – To establish expectations for how participants should conduct themselves in what will hopefully become a vibrant community
Offer a lower-cost entry: Over time, long-lived OSS projects that organizations pivot into commercial projects incur the kinds of business expenses you’d expect, including incorporation and hiring. Separately, incorporating OSS projects into your existing startup’s operations also carries a lifetime cost of ownership as your team adapts and maintains those projects to play nicely with your infrastructure. However, starting a new open-source project technically does not require any initial investment–no hired team of developers, no workstations, and likely no commercial software.
Offer potentially faster development cycles: Over time, development on OSS projects can frequently quickly as members of a growing community continuously make improvements and innovations independent of any formal product roadmap.
Depend on building a community: A foundational, non-negotiable step is building an open-source community for open collaboration. A strong, vibrant community serves many important purposes in an open-source project, acting not only as contributors, but as testers, QA experts, documenters, product managers who may actively determine the development of new features, and even as evangelists who bring new contributors into the fold.

Proprietary Software Development

Proprietary software development tends to:

Begin with potentially fewer resources: Some of the biggest success stories in proprietary software famously began inside basements as the result of conversations between a few genius computer programmers. Without a massive open-source community, or additional partners who are either directly compensated or on the hook for equity in an eventual startup built around the product, proprietary software projects tend to begin their lives as a minimum viable product (MVP) lovingly crafted by a small but dedicated group of developers (or a single, lone developer), creating everything–code, documentation, logs–by themselves.
Have a relatively small team for some time: The most successful open-source communities grow to massive sizes over the years. GitHub reportedly has more than 100M users. A proprietary software project, particularly a commercial one, will have a much smaller initial team that will likely not grow much bigger for some time. Having more developers gives teams the bandwidth to not only create more code faster but also the ability to improve their projects in multiple ways by assigning team specialists to important areas such as security, testing, and managing tools and infrastructure. Having fewer developers means less flexibility, with more team members wearing multiple hats and potentially slower going in terms of product development.
Require an investment up front: Technical teams adding proprietary commercial tools to their stack can expect to pay upfront costs for contracts/seats. Founders looking to build a commercial proprietary software project may eventually need to build a company around said project, and will need to invest in traditional corporate overhead, such as incorporation and legal fees to protect their intellectual property. Founders that go the route of founding a startup will need to raise capital.

More Resources on Development

Learn more about open-source software development in the Heavybit Library:

Differences: Licensing

Given the relatively restrictive distribution and modification requirements, particularly for commercial apps, licensing tends to be a bit more straightforward for proprietary software projects. In contrast, there’s a variety of popular open-source licenses already in use, and for developers who pivot an OSS project into a commercial product, licensing can become more complicated.

Open-Source Software Licensing

Open-source licenses are usually either copyleft–meaning they inherit the licensing terms of the previously-existing OSS project on which their project is based; or permissive–which provides more flexibility for distribution, modification, and reuse. (To briefly make the distinction, free and open-source software are not exactly identical, as free software is completely free to inspect, modify, and do with as users see fit, without any type of license restriction.)

Regardless of the specific licensing model its creators choose, open-source licenses generally tend to share a few common points:

Storage in a publicly-shared repository: Generally speaking, open-source licenses require storing the source code in a publicly-accessible location.
Document changes in source code: Open-source licenses also generally require documentation of any changes made to source code, and by what methods.

Examples of Copyleft Licenses:

GNU General Public License (GPL): The original copyleft license crafted by open-source pioneer Richard Stallman, the GPL stipulates that when distributing any software built on GNU-licensed OSS, creators must also distribute the source code of their projects together.
GPL variants, including Affero GPL (AGPL) and Lesser GPL (LGPL): AGPL closes a distribution loophole in the original GPL, making its restrictions apply to software made available via network as well as through general distribution. LGPL is largely similar to GPL and AGPL but relaxes distribution requirements for smaller projects accessed via licensed projects.
Mozilla Public License (MPL): The MPL is perhaps the least restrictive copyleft license since it lets developers modify and use any code from MPL-licensed projects, so long as those developers keep the modified files separate and distribute them along with their software project.

Examples of Permissive Licenses:

Apache License: The Apache License requires copyright and license notices, but otherwise allows for different licensing terms in derivative projects and doesn’t require creators to provide the source code of their work.
MIT License: One of the most popular permissive OSS licenses, the MIT License simply requires that developers include the original license and copyright notice in any derivative products.Berkeley Source Distribution (BSD) License: BSD Licenses also require copyright and license notices but do not require source code distribution, with various additional restrictions in the 2-Clause, 3-Clause, and 4-Clause variants.

Proprietary Software Licenses

Proprietary software licenses usually restrict modification, inspection, and distribution. Creators of proprietary software projects usually don’t distribute the source code for their projects, and attempting to distribute commercial proprietary software without a reselling or distribution license is usually illegal. Proprietary software licenses are standard for commercial apps. Here are some of the more-common variants:

End-User License Agreements (EULA): A software EULA tends to be a “clickwrap” agreement that users accept during the setup process that requires users to accept privacy and copyright policies before use. The primary purpose of a commercial app’s EULA is to set forth guidelines on what users can and can’t do with the app; in specific, to ensure they do not duplicate, reverse-engineer, or distribute copies of it. The EULA tends to be most relevant for single-user consumer applications, rather than for developer-first apps that provide ongoing service.
Terms of Service (ToS) / Terms of Use (ToU) / Terms and Conditions (T&C): A ToS agreement is more common among business and developer-first software apps, and stipulates services a software publisher will provide to an end-user, provided users also comply. A ToS might include terms such as eligibility, content contained with the app and scope of services, billing and payment, liability, and dispute resolution.
Service-Level Agreements (SLA): An SLA acts as a commitment from a software publisher to a customer that focuses on the service that the publisher provides, particularly in terms of quality and reliability. SLA agreements might include terms such as uptime, the length of time for an issue resolution window, and monitoring and reporting.

More Resources on Licensing

Learn more about software licensing in the Heavybit Library:

Differences: Business Models (and Additional Considerations)

The “software business” as we know it consists primarily of companies selling commercial versions of proprietary software apps. And while traditionally, open-source projects don’t begin their lives as commercial products, several have pivoted or spun off into commercial software offerings with their own ways to generate revenue. As you might expect, a great many of the thousands of net-new software products each year come from startup companies built around bringing them to market.

Open-Source Business Models

Since open-source software typically starts as a non-commercial, community-based project, OSS startups will frequently pivot from open source to a commercial business model.

These are some of the most common business models for OSS startups:

Professional services (ProServ): Companies such as Red Hat, IBM, and Chef offer professional services, which include for-pay training, technical support, and consulting to enhance a customer’s ability to use an open-source product.
Open core / “freemium”: Companies such as Docker, GitLab, and MongoDB use the open core model, which requires publishers to maintain multiple codebases, including a “core” codebase that remains open source, and a gated commercial codebase that offers additional premium functionality as “upgrades” for paying customers.
SaaS: Companies such as GitHub and Automattic (the vendor of WordPress) use the SaaS business model, which requires customers to accept a binding contract, but also tends to offer robust technical support for their open-source solutions.
Donations/Foundation: Perhaps the most well-known examples of companies that use the charitable foundation model are the Mozilla Foundation and Wikimedia (provider of Wikipedia). Rather than charge any fees for products or services, such organizations rely on charitable donations to continue their operations.

Additional OSS Business Considerations:

Managing multiple codebases with open core: Open-core projects eventually require their publishers to maintain separate core and commercial codebases, increasing the workload for development, testing, and deployment across two or more separate repositories while ensuring that gated features don’t accidentally end up in the core code.
Maintaining robust core and commercial versions with open core: Organizations that do manage multiple codebases may find themselves making difficult decisions about which features to “gate” within commercial offerings and which to keep as part of the core codebase. “Giving away too much functionality” in the core offering arguably keeps the community vibrant but potentially devalues the commercial offering, while gating too many features may make the commercial offering seem more valuable, but potentially jeopardizes the health of a community that dislikes being denied important functionality behind a paywall.
Potentially challenging pricing and packaging: Pricing for COSS products can be anything but straightforward, especially as a COSS startup scales and potentially scales and begins selling to larger, enterprise customers in deals that bring in more revenue, but also may need to invest significantly into staffing up with additional hires to provide pre-sales and post-sales support.
Growing and maintaining a community: In all cases, OSS startups must keep the community alive to ensure the project remains relevant and that potential users can discover it both through traditional marketing and developer relations as well as through community word-of-mouth, forums, chat channels, or even live events. While some OSS communities are enormous, in many cases, much of the maintenance and updates come from a handful of engaged users who are the key to keeping the project alive.

Proprietary Software Business Models

While successfully selling proprietary software is by no means easy, it tends to have a more-straightforward path to market as it goes commercial. Even early-stage proprietary software companies will start with a basic sales function (even if the founders themselves have to perform double-duty as salespeople), and may also add early-stage marketing teams to attract more potential customers. You’ll generally find startups selling proprietary software products following one (or both) of these two paths for their go-to-market (GTM) motion:

Inbound: The inbound model relies on bringing interest to your business. For early-stage startups, it’s common to use your website as a center of gravity for inbound and attempt to attract interested leads via search engine optimization (SEO) of content on your website and promotion through other channels, including social media, video, and podcasts.
Outbound: As the name suggests, this model relies on having sales professionals perform outreach to pitch their products to prospects. In the earliest stages, it’s common for software companies to focus on closing early sales deals via networks and references, and eventually scale up to having coverage across all stages of their sales funnel, including marketing supporting the top-of-funnel (TOFU); “inside sales,” also known as business development representatives (BDR) or sales development representatives (SDR) to qualify leads around the middle-of-funnel (MOFU); and “outside sales,” also known as account executives (AE), who manage active discovery, demo, and closing deals (hopefully as “closed won deals”) at the bottom-of-funnel (BOFU).

Additional Proprietary Software Business Considerations

Scaling can depend on your ability to hire: Those looking to create new commercial closed-source products not only need to budget for the salaries and benefits of new developers to employ on their projects, but also for the sourcing, interviewing, and hiring of said developers.
Finding “product-market fit” may depend on design partners: The most successful commercial open-source projects tend to begin as clear, distinctive, and valuable solutions to a significant problem many people experience. In a best-case scenario, an OSS community forges a robust project over time with continuous iteration to create something that real human beings genuinely need. Startups launching proprietary software apps don’t benefit from the communal testing and feedback OSS projects typically provide, so they may benefit from working with design partners–trusted early adopters that can provide clear feedback on how to create a better, more-usable product while honing in on the business problem your software should solve.

Learn more about business models and other software startup challenges in the Heavybit library:

Conclusion and Takeaways

If you’re a startup founder, or considering starting a new project, you probably already have a fairly clear idea about whether going open source or proprietary is “right” for you. With any luck, this article should hopefully provide more clarity into how each path differs in terms of development, licensing, and GTM strategy.

Learn more about the state of open source and future opportunities and challenges at the DevGuild: Open Source event.