Subscribe to GEN
Login to GEN
Add a Comment
Let's be absolutely clear from the outset: Free and Open Source Software is one of the most important developments in the history of computing. Open source powers the modern internet, enables innovation at a pace that proprietary development cannot match, and provides organisations with capabilities that would be impossible to develop in-house. The benefits are substantial and genuine.
Data Sovereignty: With open source, your data remains entirely under your control. There's no vendor lock-in, no forced cloud dependencies, and no third party with access to your information. You can host it where you want, migrate it when you need to, and maintain complete ownership throughout.
Code Control: You can inspect every line of code running in your environment. You can audit it for security, modify it for your specific needs, and understand exactly what the software does. No black boxes, no hidden telemetry, no surprises.
Integration Flexibility: Open source typically offers superior integration capabilities through well-documented APIs and standards-based approaches. You're not restricted to whatever integrations a vendor decides to support or charge extra for.
Universal Support: Popular open source projects often have larger, more knowledgeable support communities than commercial alternatives. Forums, documentation, and community expertise are available regardless of your budget or vendor relationship.
These benefits are real and substantial. The problem isn't open source itself - it's how organisations select and deploy it.
The issue we see repeatedly is what we call the 'Google Shopper' approach to FOSS selection. An organisation has a requirement, someone Googles it, finds a project that 'kinda does what we need', and deploys it into production. Repeat this process a dozen times and you've got a frankenstein infrastructure of unrelated projects, each with different maintenance cycles, different security practices, and different levels of ongoing support.
The statistics are sobering: approximately 95% of open source projects are abandoned within their first year. That means for every twenty projects you might casually deploy, nineteen will likely be unmaintained by the time you've integrated them into your infrastructure. The Google Shopper approach treats this lottery as acceptable risk, when it's actually a recipe for accumulating massive technical debt.
At GEN, we spend a significant portion of our time migrating clients from abandoned systems to active alternatives. These migrations have real economic impact - often costing far more than thoughtful initial selection would have. The 'free' solution that saved £50,000 upfront frequently costs far more to migrate away from three years later when it's full of data and having accumulated ongoing maintenance costs throughout.
Here's something that too many organisations fail to understand: most open source projects are funded by donations and volunteer labour. The software you're deploying to run your business is often maintained by individuals in their spare time, unpaid, while large corporations profit from their work.
This is not sustainable, and it's not ethical. If your organisation uses open source software, you have an obligation to support it. This can take several forms:
The alternative - taking without giving - is precisely what leads to maintainer burnout and project abandonment. When developers see their unpaid work generating profits for corporations who contribute nothing back, they understandably lose motivation. The colors.js incident, where a frustrated maintainer deliberately corrupted his own package, was an extreme response to a genuine problem: the open source contribution model is broken when organisations treat 'free' as meaning 'no obligation'.
When you deploy a FOSS solution, you haven't acquired free software - you've taken on responsibility for security management, vulnerability patching, compatibility testing, and ongoing maintenance. Every deployment becomes your responsibility to secure. Every CVE that's published requires your assessment, testing, and deployment of patches. When maintainers cannot continue - whether from burnout, career changes, or lack of support - you become the maintainer whether prepared for it or not.
Some of our clients operate relatively straightforward setups - perhaps a NextCloud installation handling file sharing, calendar, and contacts. Even this single system requires constant attention: security updates, PHP version compatibility, database maintenance, and integration testing after each update. But organisations running the Google Shopper approach have dozens of containers, each with modifications, each requiring individual attention.
For every modification you make to an open source project, you've created a maintenance burden that compounds with every release. Your customisations must be merged into each new version, tested for compatibility, checked for security implications, and validated against your specific use case. A seemingly minor modification today becomes hours of development time with every upstream release.
The consequences of poor FOSS selection, inadequate security management, and insufficient project support have been demonstrated through high-profile incidents:
In March 2024, a sophisticated backdoor was discovered in XZ Utils, a compression library used by virtually every Linux distribution. The attacker spent years building trust within the project, eventually becoming a co-maintainer before inserting malicious code. This incident highlighted how under-resourced projects become vulnerable to social engineering - the original maintainer was suffering burnout and welcomed help that turned out to be malicious.
The Log4j vulnerability affected millions of applications worldwide, allowing remote code execution with trivial exploitation. Organisations scrambled for months to identify and patch all instances. The incident highlighted both how deeply open source penetrates enterprise infrastructure and how few organisations actually know what they're running.
The Equifax breach, which exposed personal information of 147 million people, stemmed from an unpatched Apache Struts vulnerability. The patch had been available for months. This incident cost over £500 million in settlements and demonstrated what happens when organisations deploy FOSS without proper security management.
A maintainer handed over control of the popular event-stream package to a new contributor who then inserted malicious code targeting cryptocurrency wallets. The original maintainer, exhausted from unpaid work, handed over the project to whoever volunteered - a predictable outcome when the open source model fails to support those who do the work.
Beyond security vulnerabilities, open source projects face unique risks from political and ideological controversies that can destabilise them in ways commercial software rarely experiences.
Perhaps the most significant ongoing political issue in open source is the hard-left ideological capture of projects like GNOME and Debian. These projects have increasingly prioritised political conformity over technical excellence, implementing codes of conduct that function as ideological purity tests and excluding contributors who don't subscribe to particular political viewpoints.
The results are predictable and measurable. GNOME has seen declining adoption and community engagement whilst KDE, which has maintained focus on technical merit, continues to grow. Debian's governance controversies have driven contributors to other distributions. When projects prioritise politics over code quality and treat contributors as problematic unless they publicly affirm certain beliefs, talented developers simply go elsewhere.
This isn't about whether those political positions are right or wrong - it's about project sustainability. A project that actively constrains its contributor pool based on ideology will always lose ground to competitors that welcome contributions based on code quality alone.
The node-ipc incident of 2022, where a maintainer weaponised his package against users in certain countries, and the colors.js/faker.js sabotage where another frustrated maintainer corrupted his own packages, demonstrate that individual maintainers can and do inject their personal politics into software that millions depend on. These incidents break the fundamental trust model that open source relies upon.
Projects like Chef faced intense pressure when their commercial relationships with government agencies became public. The Lerna project modified its license to exclude contractors working with certain agencies. These incidents demonstrate that FOSS projects can become entangled in controversies that have nothing to do with their technical merits.
Selecting FOSS for enterprise deployment should be a thorough process encompassing multiple dimensions:
Open source, deployed thoughtfully, offers genuine advantages that commercial software often cannot match. The key is approaching it strategically:
At GEN, we're strong advocates for open source when deployed appropriately. The data sovereignty, transparency, and flexibility benefits are real and substantial. But we maintain strict criteria for any FOSS deployment in client environments, assessing projects across technical quality, governance health, financial sustainability, and community dynamics.
We also practice what we preach regarding contribution. We contribute to projects we depend on, report bugs properly, and participate in communities. Sustainable open source requires this from everyone who benefits from it.
The organisations that gain most from FOSS are those that approach it with clear eyes, proper processes, realistic budgets, and a commitment to contributing back. Those that treat 'free' as meaning 'no cost and no obligation' eventually learn otherwise - usually at the worst possible moment.
Free and Open Source Software is powerful, beneficial, and essential to modern computing. It offers data sovereignty, code transparency, integration flexibility, and community support that commercial alternatives often cannot match. The problem isn't open source - it's careless selection, inadequate support, and the mistaken belief that 'free' means 'without obligation'.
Select thoughtfully, support generously, maintain diligently, and open source will serve you well. Google your way to a dozen random projects, contribute nothing back, and you'll accumulate technical debt that costs far more than thoughtful selection ever would have.
If you're evaluating FOSS for your organisation, struggling with accumulated technical debt, or want to develop a sustainable open source strategy that captures the benefits while managing the risks, we're here to help.
--- This content is not legal or financial advice & Solely the opinions of the author ---
