There are two kinds of software: cludgy software and open source. Think about it logically. When you (or your organization) is the only person that’s ever going to see something, you’re a lot more likely to “just make it work.” After all, who would ever know? 1
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:
Continue reading Why You Should Always Write Software as Open Source, Even When It’s Never Going to Be by Benjamin J. Balter →
Notes:
- 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 ↩
Related posts:
Leave a Reply
You must be logged in to post a comment.