Cruft is inevitable. Whether you're working around a bug in Internet Explorer, Heroku or Ruby 1.8, our libraries and applications quickly diverge from the platonic ideal of software. In the short-term, there's no point in fretting. Rather than an indication of a development process gone awry, the technical debt merely reflects the messy reality of the surrounding ecosystem that our code lives in.
For projects that last for years, though, this can lead to a resistance to re-evaluating the original assumptions that introduced the cruft to begin with. In this talk, I will give some examples of good and bad attempts to deal with this issue in the world of open source, and make some suggestions for how you can make your projects, both open-source and proprietary, more able to cope with the slow but steady long-term shifts that surround our projects.