Our team develops a .NET class library. As a game platform, we have the luxury of breaking binary and source compatability between releases because games are at

Our team develops a .NET class library. As a game platform, we have the luxury of breaking binary and source compatability between releases because games are atypically short-lived applications. We provide side-by-side frameworks on both Windows and Xbox, so you don't need to upgrade to the latest framework before you release your game. But that won't stop people from doing it and still complaining. When Microsoft releases a new version of a library, some subset of users upgrade instantly. They expect that all of their code to keep working. When we break source compatability (something most teams NEVER do), we do it very carefully. We only break things where there is a clear, large win and the upgrade path is straightforward. Customers have complained when we do this every single time because it is not what they inherently expect. So now back to the original topic at hand: the "After all, we're all consenting adults here." mentality. Yeah, that's great and all, but it requires an incredible amount of discipline. See, for example, how the Django project handles this: <http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges> http://code.djangoproject.com/wiki/BackwardsIncompatibleChan.... Personally, I love doing things this way. However, consider a large non-software company. They created some internal app and ran into a small bug or shortcoming of a class library. They find out that the new version fixes their problem, so they they upgrade. BAMN. 10 other things break. Ugh, oh. that's not good. They already laid off the dev team that made this program, they have one vendor making a couple quick fixes to handle their new 2010 business rules. This used to work, why are you breaking me? I just want that one new fix! In order to prevent situations like this, you need to carefully monitor your public surface area. This is why the _foo naming convention exists in Python. It lets you say "We explicitly do not promise not to change this." Believe me, if you make a type public or a method virtual, some one will instantiate it or override it. I've seen it many times. If you didn't explicitly plan for them to do that, you've still got a backwards compatability bug should you change it. Even if you have it private, someone might call it with reflection and STILL get annoyed when you break them, although this is far more rare. So in summary: this cultural distinction is a meaningful difference in requirements between open source developers and commercial developers. The respective languages have evolved to meet the needs of their respective customers. One is not necessarily better than the other. This is why C# 3 and Python are tied for my favorite language :-)