And I'm not saying this in the "just let us hack" mindset either, because I pretty much despise that sloppy, careless mentality. It doesn't work in environments

And I'm not saying this in the "just let us hack" mindset either, because I pretty much despise that sloppy, careless mentality. It doesn't work in environments larger than a few people, much less genuinely large projects. There's a surprising low upper limit on the size of a closed-source codebase before which it becomes a lead weight. Why? Because large projects (beyond about 6 devs in 2 years) without modularity generate a lot of maintenance work. (Modular design is to pay that maintenance cost upfront, which most executives don't like.) Maintenance needs to be done well, but the only thing that motivates good people to do it (instead of hopping to another team, changing jobs, or demanding a $500k+ salary) is either (a) caring about the module as a client, which means they typically aren't more than 25%-time maintainers because their main project is whatever uses the module, or (b) the possibility of gaining a national reputation in OSS. The open-source ecosystem can motivate the kind of work that large codebases need. (That doesn't mean they never turn to crap. It means that it's not inexorable.) Corporate codebases don't have that. Twitter hasn't open-sourced, for one example, Storm because they're nice guys (not to rag on them; this is one of a million examples I could use). That may be a factor, but the main reason is that they don't want it to turn to crap, and the open-source ecosystem is more robust against that than anything in the closed-source world. If you rely on something but it's not extremely proprietary, you should probably open source it for its own health. Proprietary stuff should probably be kept as data, not code.