Linux Foundation Report Reveals Why Companies Fork Open Source Projects and Maintain Internal Patches
A recent Linux Foundation Research survey of 567 specialists examines how organizations handle modifications to open source components they depend on. The February report titled ROI for Open Source Software Contribution reveals that companies rarely leave external code untouched once it enters production systems.
Many teams add missing functionality, improve integration with internal systems, or accelerate security fixes that upstream maintainers cannot deliver on schedule. Some of these changes are contributed back, while others remain in long-lived private branches. The study focuses on practical patterns of contribution, forking, and the resulting security and maintenance challenges.
Survey Participants and Methodology
The research was conducted in October and November 2025 among subscribers, participants, and partner communities of the Linux Foundation. After validation, 567 respondents remained. Participants averaged 12 years of open source experience and 14 years in IT overall. Developers, engineers, and architects made up 28% of the sample, while 19% worked in systems administration and infrastructure.
Company sizes varied: 29% from organizations with fewer than 250 employees, 31% from mid-sized firms (250–4,999), and 40% from enterprises with 5,000 or more staff. Fifty-one percent represented IT vendors, 35% came from non-IT businesses, and 14% worked in government, non-profit, or educational institutions.
Contribution Patterns and Forking Practices
Seventy-two percent of organizations that use open source also contribute to it. Contributions extend beyond code to documentation, testing, user support, event organization, and project governance. Technical changes show clear business motivations: organizations most often fix components their products already rely on, yet a substantial share also implement new features.
Common working models include using components unchanged (68%), returning patches upstream (49%), maintaining internal forks (45%), hiring external specialists (28%), and participating in project governance (26%). Many organizations apply different strategies to different components.
Reasons for Internal Forks
Among 238 respondents who answered questions about forking, 54% cited development of proprietary features and 44% mentioned integration with internal systems. Security fixes and regulatory requirements were noted by 37%. Additional drivers included slow or abandoned upstream projects (34%), bug fixes (32%), faster release cycles (29%), quality and stability concerns (28%), performance optimization (25%), and license compatibility (18%).
The average organization maintains 86 internal forks, spending 60 hours on each per release cycle. Larger companies show significantly higher numbers: enterprises with 5,000+ employees average 136 forks and 11,152 total hours per cycle.
Security and Supply-Chain Implications
Internal forks create new vulnerability management challenges. A private security patch may leave the component appearing vulnerable in standard scanners if the public version number is retained. Conversely, a fork may miss subsequent upstream fixes. Proper tracking requires recording the exact upstream commit, the list of internal patches, and an owner responsible for synchronization.
The report also shows the largest gaps between business-critical technologies and actual contributions in programming languages and runtimes (53% critical vs 17% contributing), databases (56% vs 25%), and operating systems (59% vs 29%). Thirty-six percent of respondents reported frequent product delays due to missing features or fixes, rising to 54% among the largest organizations.
Active participation yields measurable benefits: 44% of contributors frequently secure desired features in project roadmaps, 55% receive faster responses on bugs and security issues, and 66% report accelerated product development. The study underscores that sustained engagement with upstream projects reduces long-term technical debt when internal branches would otherwise become permanent, untracked products.
Related articles
Where Secrets Really End Up in Docker Images: Testing 8 Common Methods
A detailed analysis of eight different approaches for handling secrets during Docker image builds reveals that most methods leave sensitive data exposed in layers, configuration files, or build history. Experiments conducted on Ubuntu 24.04.1 LTS with Docker Engine 29.1.3 and BuildKit v0.26.2 showed that simply using RUN rm after COPY or overwriting files fails to remove secrets from immutable layers. Environment variables via ENV and build arguments via ARG both persist in image metadata and history. Only BuildKit Secrets with --mount=type=secret and multi-stage builds that avoid copying secrets into the final stage successfully prevent leakage. The study demonstrates that secrets can be extracted from saved images without running any containers. Developers are advised to adopt these two secure patterns to protect credentials in container supply chains.
Mozilla Revokes GPG Signing Key After Accidental Upload to Private GitHub Repository
Mozilla has replaced the GPG key used to sign certain Firefox and Thunderbird builds following an accidental exposure of the unencrypted secret key in a private GitHub repository. The key was intended for signing Linux archives, RPM packages, and checksum files, raising theoretical risks of supply-chain attacks through forged installers. Company audits found no evidence of external misuse, as repository access was limited to a small group of employees who already held legitimate access to the key. Most users require no action, though those manually verifying GPG signatures must import the new key along with revocation data for the old one. Linux administrators installing Firefox via RPM packages on distributions such as Fedora, RHEL, Rocky Linux, AlmaLinux, openSUSE, and SUSE may need to manually update the key to avoid installation failures. Thunderbird users are unaffected by the RPM issue since no official RPM packages are released for the email client. The new key remains valid until August 5, 2028, with public details available in updated KEY files and on keys.openpgp.org.
ChainDrop Malware Infects Over 1,300 npm Packages in Record Supply Chain Poisoning Campaign
Security researchers have uncovered a massive supply chain attack involving the ChainDrop malware that compromised more than 1,300 npm packages with a combined 2 billion monthly downloads. The malicious code silently steals npm tokens, GitHub credentials, and SSH keys before using stolen tokens to infect additional packages in a self-propagating loop. In a parallel incident, the Open VSX marketplace removed 77 malicious extensions that impersonated popular developer tools and harvested host and repository data. Attackers have also begun exploiting AI coding assistants through a technique called HalluSquatting, registering packages that match hallucinated names suggested by tools such as GitHub Copilot and Claude Code. The incidents highlight how modern supply chain threats now extend beyond direct dependencies to include AI-generated recommendations and automated publishing pipelines. Experts recommend strict lockfile usage, minimal token permissions, and manual verification of any package suggested by AI assistants.
Malicious VS Code Extensions Masquerading as Solidity Tools Steal Crypto Wallets, API Keys and Credentials
Two malicious Visual Studio Code extensions promoted as Solidity development utilities have been used to steal cryptocurrency wallet data from browsers along with API keys and stored credentials. The extensions, identified as helper-beeps.solidity-pro and web3devtoolsx.solidity-pro, target developers working with smart contracts and Web3 environments where sensitive tokens and sessions are commonly present. Attackers rely on the trusted VS Code marketplace to deliver the payload through a simple installation rather than any complex exploit. Once active, the extensions harvest browser-based crypto wallet information, saved credentials, environment files, SSH keys and API tokens. A single compromised workstation can therefore expose repositories, cloud services and directly drain cryptocurrency funds. Security researchers recommend immediate removal of both extensions, rotation of all accessible secrets and adoption of stricter extension allow-list policies. The incident highlights ongoing supply-chain risks in developer tooling ecosystems.