Open source software development has quietly become the default way software gets built: almost every commercial product now ships with frameworks, libraries and tools that someone else wrote in public. That makes open source a supply chain, not a side topic. In 2026 two things changed the risk picture at once: Black Duck's OSSRA 2026 report showed that the average number of known vulnerabilities per codebase more than doubled in a year, and the EU Cyber Resilience Act started requiring vendors to report actively exploited vulnerabilities from 11 September 2026.
Most teams we work with don't build from scratch: custom software development today means assembling and extending open-source frameworks, then writing the 10–30% of code that is truly yours. The open source part decides how fast you ship, how secure you are and which legal obligations you inherit, so it deserves the same engineering discipline as your own code.
This guide is written for CTOs, founders and product owners in the US and EU. It explains how open source is built and governed, what companies buy when they hire open source software development services, how licenses differ, what the latest security data shows, what the Cyber Resilience Act requires, what open source really costs over its lifetime, and how to choose a development partner who will not leave you maintaining a fork alone.
What is open source software development?
Open source software development is the practice of building software whose source code is published under a license that lets anyone use, study, modify and redistribute it. The work happens in public: code lives in shared repositories, changes arrive as pull requests from many contributors, and maintainers review and release them openly.
To count as open source, the license must meet the Open Source Definition maintained by the Open Source Initiative (OSI). In practice that means the four freedoms first described by the free software movement: the freedom to run the program for any purpose, to study and change how it works, to redistribute copies, and to distribute modified versions. A license that forbids commercial use, limits who may run the software or bans competing services is not open source, even if the code is public.
For a business, open source software development has two sides. You consume open source when your product depends on Linux, PostgreSQL, React, Kubernetes or thousands of smaller packages. You produce open source when your engineers contribute fixes upstream, publish internal tools or run a project of your own. Most companies do far more of the first than the second, and most of the risk sits there.
Open source vs free software vs source-available
Open source, free software and source-available describe different promises, even though all three let you read the code.
- Free software stresses user freedom as an ethical principle and is closely tied to copyleft licenses such as the GPL. Almost all free software is also open source.
- Open source stresses the practical benefits of open collaboration and covers both permissive and copyleft licenses approved by the OSI.
- Source-available software publishes the code but restricts use, typically banning competing hosted services. The Business Source License (BSL) and the Server Side Public License (SSPL) are common examples; neither is OSI-approved.
A brief history: from the cathedral to the bazaar
Open source grew out of the free software movement and became mainstream in the late 1990s. Richard Stallman announced the GNU project in 1983 to build a free operating system, and the GPL followed. Linus Torvalds released the Linux kernel in 1991, and the Apache HTTP Server appeared in 1995. In his essay The Cathedral and the Bazaar, Eric Raymond contrasted software built by a small closed group (the cathedral) with software built openly by many contributors (the bazaar). The term “open source” was coined in 1998, the same year the Open Source Initiative was founded, to present the bazaar model to businesses. Today foundations such as the Linux Foundation, the Apache Software Foundation and the Eclipse Foundation host thousands of projects that companies depend on.
Key principles of open source development
Open source development rests on six working principles that explain why the model scales across companies and time zones. They are worth copying even in closed codebases, where the practice is called inner source.
- Transparency. Code, issues, roadmaps and design discussions are public, so anyone can see what is changing and why.
- Peer review. Every change is reviewed before it is merged. “Given enough eyeballs, all bugs are shallow” only works when people actually review.
- Decentralized, merit-based collaboration. Contributors gain influence through the quality of their work, not through their employer or job title.
- Release early, release often. Small, frequent releases give users fixes quickly and keep feedback loops short.
- Reuse by default. Licenses allow building on existing work, so projects stand on each other instead of reinventing the same components.
- Community governance. Written rules decide who can merge, how decisions are made and how conflicts are resolved.
How does open source software development work?
Open source software development works as a public, repeatable lifecycle: a project starts, gets a license and contribution rules, collects work as issues, accepts changes through reviewed pull requests, tests them automatically, ships versioned releases and handles security reports privately. The steps are the same whether the project has three contributors or three thousand.
- Initiation. A project begins as a new idea, a fork of an existing project, or internal code a company decides to open up. Opening internal code needs a review first: secrets, customer data and third-party code with incompatible licenses must be removed.
- Public repository and ground rules. The repository gets a license file, a README, a CONTRIBUTING guide that explains how to propose changes, and a CODE_OF_CONDUCT that sets expectations for behavior.
- Issues and roadmap. Bugs, feature requests and design proposals are tracked as public issues. Labels such as “good first issue” help new contributors find a starting point.
- Pull requests and code review. Contributors fork or branch the code, make a change and open a pull request. Maintainers review it, ask for changes and merge it when it is ready. Our guide to pull requests in software development covers this step in detail.
- Continuous integration. Every pull request runs automated tests, linters and security checks before a human looks at it, which keeps quality consistent across hundreds of contributors.
- Releases and semantic versioning. Maintainers tag releases using semantic versioning (MAJOR.MINOR.PATCH) so users can tell at a glance whether an upgrade may break their code.
- Security disclosure. A SECURITY.md file tells researchers how to report vulnerabilities privately, so fixes can ship before details become public.
Governance models
Governance decides who has the final say in an open source project, and it matters to buyers because it predicts how stable the project will be in five years. Four models cover most projects:
| Model | Who decides | Typical examples | What it means for you |
|---|---|---|---|
| BDFL (benevolent dictator) | One founder or lead maintainer | Many smaller libraries; Python until 2018 | Fast decisions, but key-person risk |
| Core team / steering council | An elected or appointed group of maintainers | Python since 2019, Rust, Node.js | Balanced and predictable roadmaps |
| Foundation-hosted | Project committees under a neutral foundation | Apache Kafka, Kubernetes (CNCF), Eclipse projects | Vendor-neutral, lowest relicensing risk |
| Single-vendor | One company owns the trademark and copyright | Many open-core databases and dev tools | Strong funding, but license can change |
Who actually writes open source?
Much of the open source that businesses rely on is written by paid engineers, not only by volunteers. Large projects such as Linux and Kubernetes are driven by contributors employed by technology companies, while many small but critical libraries are still maintained by one or two unpaid people. Larger companies coordinate this work through an Open Source Program Office (OSPO): a small team that sets policy for using, contributing to and releasing open source, tracks license compliance and decides which upstream projects deserve engineering time.
Open source software development services: what companies actually buy
Open source software development services are engineering services that help a company build on, extend, secure or release open source code. Very few buyers want “open source” for its own sake; they want a product delivered faster and cheaper without inheriting hidden legal or security debt. The most common engagements are:
- Building products on open source stacks — web, mobile and data platforms assembled from proven frameworks with custom business logic on top.
- Customizing and extending open source — modules for Odoo, identity flows in Keycloak, Kubernetes operators, headless CMS integrations.
- Open-sourcing internal code — cleaning the codebase, choosing a license, writing documentation and setting up governance.
- OSPO setup — policies, approval workflows and tooling for large organizations.
- License and SBOM audits — finding every component you ship, its license and its known vulnerabilities.
- Long-term maintenance of forks — security patching, upstream syncs and upgrade planning.
- Migration off proprietary platforms — replacing expensive licensed software with open alternatives while keeping data and integrations intact.
Use cases: typical applications built on open source
Open source fits almost every application category; the choice of base project decides how much custom code is left to write. Typical patterns we see in delivery:
- ERP and CRM on Odoo or SuiteCRM, extended with industry-specific modules and integrations.
- Web applications on React or Next.js with Node.js or Python backends and PostgreSQL.
- Data platforms on Apache Kafka, Apache Spark and open table formats for streaming and analytics.
- Identity and access on Keycloak for single sign-on across internal and customer-facing apps.
- AI features on open-weight models served on your own infrastructure when data residency or cost rules out hosted APIs.
Benefits of open source for software development
The main benefits of open source for software development are lower licensing cost, faster delivery and freedom from vendor lock-in, followed by transparency, a larger talent pool and faster innovation. “Free” means free of license fees, not free of cost: the savings are real only when maintenance is planned.
- No license fees. You pay for engineering, not for seats or cores. IBM Think cites market estimates of $41.83 billion in 2024 and $48.92 billion in 2025 for the open source services market, a 16.9% annual growth rate — money that flows into services rather than licenses.
- Speed. Mature frameworks cover authentication, routing, data access and UI components, so teams spend their time on the features customers pay for.
- No vendor lock-in. If a provider raises prices or disappears, you or another team can keep running and changing the code.
- Transparency and auditability. You can read the code that handles your data, which matters for security reviews and regulated industries.
- Talent pool. Engineers already know popular open source stacks, which shortens hiring and onboarding.
- Innovation. New ideas in cloud-native infrastructure, data tooling and AI usually appear first as open source projects.
The scale of the value is hard to overstate. A 2024 Harvard Business School working paper by Hoffmann, Nagle and Zhou estimated the demand-side value of widely used open source at about $8.8 trillion and concluded that firms would spend roughly 3.5 times more on software if open source did not exist.
Open source vs proprietary software: comparison
Open source wins on cost, flexibility and lock-in; proprietary software wins on packaged support and a single accountable vendor. The table compares them on the criteria that usually decide a purchase.
| Criterion | Open source | Proprietary / commercial |
|---|---|---|
| Licensing cost | None; optional paid support | Per user, per core or subscription |
| Source access | Full | None or under NDA |
| Customization | Unlimited, within the license | Limited to APIs and settings |
| Support | Community, vendor subscription or your partner | Vendor SLA included |
| Security model | Public review; you must track and patch | Vendor patches; you trust a black box |
| Vendor lock-in | Low | High |
| Compliance responsibility | On you as the manufacturer of the product | Shared with the vendor by contract |
| Total cost of ownership | Lower if maintenance is planned | Predictable, rises with scale |
Verdict: choose per component, not per project. Most products mix both, and the best architecture keeps commodity layers open and buys or builds only where there is a clear reason. Our comparison of custom software vs off-the-shelf applies the same logic at product level.
Open source licenses explained: which one fits your product?
The right open source license depends on one question: do you need to keep your own code closed when you ship it? Permissive licenses allow that, weak copyleft licenses allow it with conditions, and strong copyleft licenses generally do not.
| License | Type | Can you keep your code closed? | Typical use |
|---|---|---|---|
| MIT | Permissive | Yes, keep the notice | JavaScript libraries, small tools |
| Apache 2.0 | Permissive, with patent grant | Yes, keep notices and state changes | Enterprise and cloud-native projects |
| BSD (2- and 3-clause) | Permissive | Yes | Operating system and network code |
| MPL 2.0 | Weak copyleft (file level) | Yes; changed MPL files must stay open | Browsers, infrastructure tools |
| LGPL | Weak copyleft (library level) | Usually, if you link and allow relinking | Shared libraries |
| GPLv3 | Strong copyleft | No, if you distribute a combined work | Applications, developer tools |
| AGPLv3 | Strong copyleft with network clause | No, even for SaaS users over a network | Server software; highest SaaS risk |
| BSL / SSPL | Source-available (not OSI-approved) | Depends; competing hosted services are restricted | Databases and dev tools that relicensed |
Relicensing is a real business risk. When HashiCorp moved Terraform to the Business Source License in 2023, the community forked it as OpenTofu under the Linux Foundation, and many users had to decide which branch to follow. Projects owned by a single vendor can change terms; foundation-hosted projects rarely do.
This section is general information, not legal advice. Involve counsel before you distribute software that combines copyleft components with proprietary code.
Is open source software secure? Risks and how to manage them
Open source software is as secure as your maintenance process. Public code is not inherently safer or weaker than closed code; the risk comes from components that nobody tracks, updates or replaces. Black Duck's OSSRA 2026 report, based on 947 commercial codebases across 17 industries, shows how widespread that problem is:
- 98% of codebases contained open source.
- The average codebase had 581 known vulnerabilities, 107% more than a year earlier.
- 87% contained at least one vulnerability, 78% contained high-risk vulnerabilities and 44% had critical-risk issues.
- 93% contained components with no development activity for two or more years, and 92% had components four or more years out of date. Only 7% of teams were on the latest versions.
- 65% of organizations experienced a software supply chain attack in the past year, and 66% of those attacks involved malicious packages.
Software supply chain attacks
A software supply chain attack compromises a dependency instead of your own code, so the malicious code arrives through a normal install or update. Common techniques include typosquatting (publishing a package with a name one letter off a popular one), dependency confusion (tricking a build into pulling a public package instead of an internal one) and taking over a maintainer's account. The best-known recent case is the xz-utils backdoor discovered in March 2024: a contributor who had spent about two years earning maintainer trust inserted a backdoor into versions 5.6.0 and 5.6.1 of the compression library. An engineer noticed unusual SSH latency and reported it before the affected versions reached most stable Linux distributions.
A practical open source security checklist
A practical open source security program needs seven controls, most of which can run automatically in your CI pipeline:
- Keep an SBOM. Generate a software bill of materials in CycloneDX or SPDX format for every release.
- Run software composition analysis (SCA) in CI. Fail builds on new critical vulnerabilities and forbidden licenses.
- Pin versions and commit lockfiles. Builds should be reproducible, and upgrades should be deliberate.
- Automate dependency updates. Bots that open small upgrade pull requests keep you from drifting years behind.
- Vet new dependencies. Check maintenance activity and security practices with the OpenSSF Scorecard before adopting a package.
- Sign and verify artifacts. Use Sigstore or similar tooling so you can prove what you built and where it came from.
- Publish a vulnerability disclosure policy. Tell researchers how to reach you and how fast you respond.
These controls fit naturally into a secure software development lifecycle, where dependency risk is reviewed at design time, not after an incident.
EU Cyber Resilience Act: what changes for open source in 2026
From 11 September 2026, companies that place software with open source components on the EU market must report actively exploited vulnerabilities and severe security incidents through ENISA's Single Reporting Platform. Under Article 14 of the Cyber Resilience Act (CRA), that means an early warning within 24 hours, a notification within 72 hours and a final report within 14 days of a fix being available (one month for severe incidents). The full set of CRA obligations, including secure-by-design requirements and conformity assessment, applies from 11 December 2027, according to the European Commission's CRA reporting page.
The CRA assigns duties by role, so the first step is to know which role you play:
- Manufacturer. A company that ships a product with digital elements on the EU market in the course of a commercial activity. If you embed open source in that product, you are responsible for it as if you had written it, including vulnerability handling for those components.
- Open-source software steward. A legal person, such as a foundation or company, that systematically supports the development of open source intended for commercial use (Article 24). Stewards need a documented cybersecurity policy and must cooperate with market surveillance authorities. They report only to the extent they are involved, for example when they run the project's infrastructure or signing keys.
- Non-commercial maintainer. Individuals and projects developing open source outside a commercial activity are out of scope.
In practice an SBOM becomes effectively mandatory: you cannot report on or fix vulnerabilities in components you do not know you ship. The plain-language CRA guide for maintainers from openresource.dev explains the steward role in more detail. US-focused teams will find a similar logic in the NIST Secure Software Development Framework and the attestation requirements that followed Executive Order 14028.
This summary is general information, not legal advice. Confirm your role and obligations with counsel familiar with the CRA.
How much does open source software development cost?
The license for open source software is free; the total cost of ownership is not. You pay for the engineering needed to integrate, customize, secure, upgrade and support open source components for as long as your product runs. In our projects, ongoing patching and upgrades typically take 15–25% of the initial build cost per year — an estimate from our delivery experience, not an industry statistic, and it varies with the size of the dependency tree.
| Cost item | One-off or recurring | What it covers |
|---|---|---|
| Integration and customization | One-off, then per feature | Wiring components together, extensions, business logic |
| Security patching and upgrades | Recurring | Version bumps, breaking-change fixes, regression testing |
| Support subscriptions | Recurring, optional | Vendor-backed SLAs for critical components (the Red Hat model) |
| Compliance tooling | Recurring | SCA scanners, SBOM generation, license review, CRA reporting |
| Upstream contributions | Recurring | Getting your patches merged so you never maintain a private fork |
| Talent and training | One-off and recurring | Engineers who understand the stack and its community |
The biggest hidden cost is a private fork. Every change you keep only in your copy has to be re-applied on each upstream release, and the gap grows until upgrading becomes a project in its own right. Contributing fixes back costs a little more today and saves far more later. For full budget ranges by project type, see our breakdown of custom software development cost in 2026.
How to choose an open source software development partner
The right open source software development partner proves they can manage licenses, security and upstream relationships, not just write code on popular frameworks. Use this seven-point checklist when you compare vendors:
- License audit capability. Ask how they identify licenses in your current codebase and what they do when they find a conflict.
- SBOM and SCA in their CI. Ask to see a sample SBOM and the pipeline step that blocks vulnerable or forbidden dependencies.
- Upstream contribution track record. Merged pull requests in the projects you depend on are better evidence than a logo slide.
- Maintenance SLA for forks. Agree in writing how fast critical vulnerabilities in your dependencies will be patched.
- CRA and SSDF awareness. A partner selling into the EU or US public sector should already work this way.
- IP ownership of custom code. The contract must state that you own the code written for you and how open source components are licensed to you. Our software development contract guide covers the clauses to check.
- Exit plan. Documentation, build scripts and access must let another team take over without the original vendor.
Open source and AI in 2026
AI has added two new open source questions to every project. The first is open-weight models: models whose weights are published, often under custom licenses that restrict some uses, so they need the same license review as any other dependency. The second is AI-generated code: assistants can reproduce snippets from licensed code without attribution. With 85% of organizations using AI coding assistants and only 54% reviewing their output for licensing risk (Black Duck OSSRA 2026), scanning AI-written code belongs in the same pipeline as your SCA checks.
Frequently asked questions
What is open source software development?
Open source software development is the practice of building software whose source code is published under a license that lets anyone use, study, modify and redistribute it. Work happens in public repositories: contributors propose changes through pull requests, maintainers review and merge them, and releases are versioned and shared openly. Companies take part by using open source components, contributing fixes upstream and sometimes publishing their own projects.
What do open source software development services include?
Open source software development services usually include building products on open source stacks, customizing and extending existing projects such as Odoo, Keycloak or Kubernetes, open-sourcing internal code, setting up an Open Source Program Office, license and SBOM audits, long-term maintenance and security patching of forks, and migrating off proprietary platforms. A good provider also contributes fixes upstream so you do not end up maintaining a private fork forever.
Can I use open source code in a commercial, closed-source product?
Yes, in most cases. Permissive licenses such as MIT, Apache 2.0 and BSD let you ship open source code inside a closed-source product as long as you keep copyright and license notices. Weak copyleft licenses such as LGPL and MPL 2.0 require you to share changes to the licensed component only. Strong copyleft licenses such as GPLv3 and AGPLv3 can require you to release your own source code, so check them with counsel before distribution.
Is open source software safe for enterprise use?
Open source software is safe for enterprise use when it is maintained like any other critical dependency. The risk lies in unmanaged components: Black Duck's OSSRA 2026 report found an average of 581 vulnerabilities per commercial codebase and components with no development activity for two or more years in 93% of codebases. Enterprises that keep an SBOM, scan dependencies in CI, pin versions and patch on a schedule run open source safely at scale.
Does the EU Cyber Resilience Act apply to open source projects?
The EU Cyber Resilience Act applies to open source when it is part of a product placed on the EU market in the course of a commercial activity. A company that ships open source inside its product is the manufacturer and carries the full obligations. Organizations that systematically support open source used commercially are open-source software stewards with lighter duties. Hobby, non-commercial projects are out of scope. Vulnerability reporting duties start on 11 September 2026.
Is open source software development cheaper than proprietary?
Open source software development is usually cheaper up front because there are no license fees, and it avoids vendor lock-in. Total cost of ownership is not zero: you pay for integration, customization, upgrades, security patching, compliance tooling and skilled engineers. A 2024 Harvard Business School working paper estimated that firms would spend about 3.5 times more on software if open source did not exist, which shows how large the savings can be when it is managed well.
Published 16 October 2026. Sources: Black Duck, Open Source Security and Risk Analysis (OSSRA) report 2026 and press release, 25 February 2026; European Commission, Cyber Resilience Act reporting obligations; openresource.dev, Cyber Resilience Act for maintainers; IBM Think, What is open source software?; GitHub, What is open source software; Hoffmann, Nagle and Zhou, “The Value of Open Source Software”, Harvard Business School working paper, 2024.
