The White Elephant Problem: Why Free Software Becomes a Security Liability
Volunteer-built software follows the ancient White Elephant pattern: free to acquire, ruinous to maintain. When the builder leaves, nonprofits inherit Forever-Day vulnerabilities they cannot fix.
In ancient Siam, if a king wanted to destroy a rival without the appearance of hostility, he gave them a gift: a rare white elephant. The animal was sacred—it could not be refused, could not be put to work, and could not be given away. The recipient had no choice but to feed and house it at enormous expense. The white elephant was a curse disguised as a blessing, a gift designed to bankrupt through the obligation of maintenance.
Today, nonprofits accept white elephants constantly. They arrive not as sacred animals but as custom donation forms, bespoke websites, and specialized applications—all built by well-meaning volunteers who eventually move on. The moment the volunteer walks away, the organization inherits a system they cannot maintain, cannot update, and cannot secure. The gift becomes a liability, and the liability becomes a breach waiting to happen.
The Volunteer Curse
The pattern is familiar to any nonprofit leader. A skilled volunteer—perhaps a developer, a designer, or a technically-inclined board member—offers to build something custom. They donate their expertise, creating a donation page, a member portal, or an event registration system tailored precisely to the organization's needs. The work is excellent, the price is free, and everyone celebrates the contribution.
The Volunteer Curse
The phenomenon where donated software becomes a liability the moment its creator leaves. The organization gains a system it cannot modify, cannot debug, and cannot secure—transforming a gift into an ongoing obligation with no exit strategy.
The trouble begins when the volunteer's circumstances change. They take a new job, move to a different city, or simply lose interest. The code remains, but the knowledge of how it works—its architecture, its dependencies, its quirks—walks out the door. When something breaks, there is no one to call. When a security vulnerability emerges, there is no one to patch it. The organization is left feeding a white elephant they never asked to own.
From Zero-Day to Forever-Day
In cybersecurity, a "zero-day" vulnerability refers to a flaw discovered by attackers before the software vendor knows it exists. The term captures the urgency: from the moment of discovery, the vendor has zero days to respond before exploitation begins. In commercial software, this triggers an immediate response—engineers are mobilized, patches are developed, and updates are pushed to users worldwide.
Volunteer-built software operates under different rules. When no one is monitoring the code, no one detects the vulnerability. When no one maintains the system, no one writes the patch. A zero-day vulnerability in abandoned software becomes something far worse.
Forever-Day Vulnerability (iDay)
A security flaw in unmaintained software that remains exploitable indefinitely because no developer exists to create a fix. Unlike zero-day vulnerabilities that get patched, forever-day vulnerabilities persist until the software is retired entirely.
The cybersecurity industry uses the term "forever-day" (sometimes "iDay" for "infinite day") to describe this condition. It is not a theoretical concern. Research indicates that 60% of data breaches involve vulnerabilities where patches were available but not applied. In volunteer-built systems, the situation is categorically worse: the patch does not exist and never will. The vulnerability is not a temporary exposure waiting for a fix—it is a permanent opening.
The Mathematics of Maintenance
The appeal of custom-built software is obvious: it costs nothing upfront and does exactly what you need. The hidden cost is maintenance, and that cost compounds over time in ways that are easy to underestimate.
Ownership Model
Acquire custom software for free. Bear full responsibility for updates, security patches, compatibility fixes, and eventual replacement. When the builder leaves, inherit unmaintainable code. Security vulnerabilities become permanent liabilities.
Service Model
Subscribe to maintained software. The provider handles updates, security patches, compliance changes, and infrastructure. When vulnerabilities are discovered, patches deploy automatically to all users. Security is the provider's problem, not yours.
The average time to exploit a newly discovered vulnerability has dropped to approximately five days. If a volunteer takes a month to respond to a security alert—assuming they respond at all—the window for exploitation has already closed six times over. The math does not favor ownership. It favors delegation.
Obsolescence as a Service
The solution to the white elephant problem is not to find better volunteers or to train staff in software maintenance. The solution is to stop accepting white elephants altogether. This requires a fundamental shift in how nonprofits think about technology: from ownership to subscription, from assets to services, from building to buying.
Software-as-a-Service (SaaS) platforms externalize the maintenance burden entirely. When you subscribe to a service rather than own a system, you are not just paying for features—you are paying for someone else to manage obsolescence on your behalf. Security patches, compliance updates, infrastructure scaling, and eventually the transition to whatever comes next: all of these become the provider's responsibility rather than yours.
This is particularly critical in an era where technology evolves at what might be called the "speed of thought." The systems that process donor data today will be obsolete within years, perhaps months. Owning static, unmaintained code in this environment is not frugal—it is dangerous. The only sustainable position is to rent capability from providers who have the scale, expertise, and incentive to keep that capability current.
Key Insight
The true cost of "free" software is not the build—it's the maintenance. When you accept volunteer-built code, you accept responsibility for security vulnerabilities you cannot fix, compliance requirements you cannot meet, and technical debt you cannot pay. The cheapest software is often the software you do not own.
Evaluating Your Technology Portfolio
Every nonprofit should audit its technology portfolio for white elephants. The questions are straightforward: Who built this system? Are they still available? When was it last updated? What happens if a security vulnerability is discovered tomorrow? If the answers reveal orphaned code maintained by no one, the organization faces a choice between investing in remediation or accepting ongoing risk.
For systems that handle donor data—payment processing, contact management, communication platforms—the stakes are particularly high. A breach does not just expose information; it exposes the organization to regulatory penalties, reputational damage, and the very real possibility of losing donor trust permanently. The cost of a single breach typically exceeds years of subscription fees for properly maintained alternatives.
The path forward involves three steps. First, inventory all custom-built systems and identify their maintainers. Second, assess each system's security posture and determine whether patches are current. Third, develop a migration plan that moves critical functions to maintained platforms before the next volunteer departure forces a crisis.
Summary
The white elephant metaphor illuminates a pattern that repeats across the nonprofit sector: gifts that become burdens, savings that become costs, solutions that become problems. Volunteer-built software embodies all three transformations. It arrives as a blessing, remains as an obligation, and eventually departs as a breach—or, if the organization is lucky, as a costly migration to something sustainable.
| Dimension | Owned Software | Subscribed Service |
|---|---|---|
| Upfront Cost | Low or free | Monthly/annual fee |
| Maintenance | Your responsibility | Provider's responsibility |
| Security Patches | Dependent on volunteer availability | Automatic deployment |
| Vulnerability Response | Forever-day risk | Zero-day response |
| Long-term Trajectory | Accumulating technical debt | Continuous improvement |
The kings of Siam understood something fundamental about gifts: their value depends entirely on what they demand from the recipient. A white elephant was worthless not because of what it was, but because of what it required. The same calculus applies to software. Before accepting the next generous offer of custom development, ask what the gift will demand—not today, but for every day that follows.
References
- Ponemon Institute. (2024). Cost of a Data Breach Report. IBM Security. IBM →
- Ablon, L., & Bogart, A. (2017). Zero Days, Thousands of Nights: The Life and Times of Zero-Day Vulnerabilities and Their Exploits. RAND Corporation. RAND →
- Bilge, L., & Dumitraș, T. (2012). Before We Knew It: An Empirical Study of Zero-Day Attacks in the Real World. ACM Conference on Computer and Communications Security. DOI →
- NTEN. (2023). Technology Staffing and Investments Report. Nonprofit Technology Network. NTEN →
The White Elephant & The Volunteer Curse
Hear this research discussed in depth on the Fundraising Command Center Podcast.