But the same logic that applies to sweeping literal dirt under the rug doesn’t apply to writing code. Whereas a rug will always serve to cover the floor, applications evolve over time and code is often constantly reused and repurposed as customers’ needs change. Simply put, it’s impossible to predict today where your code is going to be a year from now and it’s in your best interest to plan accordingly.
Open source hedges this risk by distinguishing generic logic (say posting content online) from application-specific customization (say the use-case-specific presentation of that content). Yet when you’re writing with the intention of producing proprietary or one-off code, you do everything in one pass. The true challenge arises when the same problem emerges again in another department, another business unit, or more generally in an even slightly different context. You’re reinventing the wheel. You’re “open sourcing” (even if within your organization). The solution? Always assume your software is going to be open source, even if you know it’s never going to be, and here’s why:
- The same would apply when you’re buying software and the contractor is under the impression no one outside the organization will ever see the code, and more importantly, the code could never negatively impact the public’s perception of their overall work-product ↩
- Open-Source Alternatives to Proprietary Enterprise Software
- What’s Missing from CFPB’s Awesome New Source Code Policy
- Enterprise Open Source Usage Is Up, But Challenges Remain