A large software project is about communication more than anything else. Inside a company, a large codebase is often extremely hard to navigate. There will be different coding styles, redundant library usage, outdated comments, obsolete &#x2F; unused code, code written by people who left long ago, ugly workarounds for OS &#x2F; api bugs that may no longer exist.<p>You may find pieces of beautiful code written by enthusiastic new employees next to files written by jaded, checked-out veterans ready to move on. Coffee-fueled bug fixes checked in right after the tests passed, to be documented later (never). There may not be a person in the organization who knows how to fully build and deploy an entire codebase from scratch.<p>You&#x27;d think this only happens at &quot;bad&quot; companies, but any company that grew fast and became hugely successful will have lingering technical debt, some of which does not need to be paid.<p>If you want to experience this, pick a relatively unpopular and large codebase open sourced by some company and try to understand it. Imagine someone had just asked you to add a new feature with an arbitrary deadline. Now realize that this code is probably much better than a comparable closed-source system, after all the company wasn&#x27;t embarrassed about sharing it with the world.