Background
In page 100 of PPP Robert Martin says
"Closed for modification"
Extending the behavior of a module does not result in changes to the source or binary code of the module. The binary executable version of the module, whether a linkable library, a DLL, or a Java .jar, remains untouched.
Also on page 103 he discusses an example, written in C, where a non-OCP design results in recompiling the existing classes:
So, not only must we change the source code of all witch/case statements or if/else chains, but we also must alter the binary files (via recompilation) of all the modules that use any of the Shape data structures. Changing the binary files means that any DLLs, shared libraries, or other kinds of binary components must be redeployed.
It's good to remember that this book was published in 2003 and many of the examples use C++, which is a language notorious for long compile times (unless header file dependencies are handled well - developers from Remedy mentioned in one presentation that Alan Wake's full build takes only about 2 minutes).
So when discussing binary compatibility in the small scale (i.e. within one project), one benefit of OCP (and DIP) is faster compile times, which is less of an issue with modern languages and machines. But in the large scale, when a library is used by many other projects, especially if their code is not in our control, the benefits of not having to release new versions of the software still apply.
Example
As an example of an open source library which follows OCP in binary compatibility, look at JUnit. There are tens of testing frameworks which rely on JUnit's @RunWith annotation and Runner interface, so that they can be run with the JUnit test runner - without having to change JUnit, Maven, IDEs etc.
Also JUnit's recently added @Rule annotation allows test writers to plug into standard JUnit tests custom behavior, which would before have required a custom test runner. Once more an example of library-level OCP.
To contrast, TestNG does not follow OCP, but contains JUnit specific checks to execute TestNG and JUnit tests differently. A representative line can be found from the TestRunner.run() method:
if(test.isJUnit()) {
privateRunJUnit(test);
}
else {
privateRun(test);
}
As a result, even tough the TestNG test runner has in some aspects more features (for example is supports running tests in parallel), other testing frameworks do not use it, because it's not extensible to support other testing frameworks without modifying TestNG. (TestNG has a way to plug in custom test runners using the -testrunfactory argument, but AFAIK it allows only one type of runner per suite. So it would not be possible to use many different testing frameworks in one project, unlike with JUnit.)
Conclusion
However, in most situations OCP is used within an application or library, in which case both the base module and its extensions are packaged inside the same binary. In that situation OCP is used to improve the maintainablity of the source code, and not to avoid redeploys and new releases. The possible benefit of not having to recompile an unchanged file is still there, but since compile times are so low with most modern languages, that's not very important.
The thing to always keep in mind is that following OCP is expensive, as it makes the system more complex. Robert Martin talks about this on PPP page 105 and the conclusion of the chapter. OCP should be applied carefully, for only the most probable changes. You should not preemptively put in the hooks to follow OCP, but you should put in the hooks only after a change happens that needs them. Thus it is unlikely to find a project where all new features would have been added without changing existing classes - unless somebody does it as an academic exercise (my intuition says that it would be very hard and the resulting code would not be clean).
