Now, that doesn't mean that there won't be anything new added over time, of course security fixes and critical bugfixes get backported from new versions into these various packages and a good number of enhancements/features also get backported over the years. Very much so on the kernel side but in some cases or in a number of cases also in the various userspace packages. However for the most part the focus is on stability and consistency. This is also the case with the different tools and compiler/languages. A concrete example would be, OL7 provides Python 2.7.5. This base release of python will not change in OL7 in newer updates, doing a big chance would break compatibility etc so it's kept stable at 2.7.5.
A very important thing to keep reminding people of, however, again, is the fact that CVEs do get backported into these versions. I often hear someone ask if we ship a newer version of, say, openssl, because some CVE or other is fixed in that newer version - but typically that CVE would also be fixed in the versions we ship with OL. There is a difference between openssl the open source project and CVE's fixed 'upstream' and openssl shipped as part of Oracle Linux versions and maintained and bug fixed overtime with backports from upstream. We take care of critical bugs and security fixes in the current shipping versions.
Anyway - there are other Linux distributions out there that 'evolve' much more frequently and by doing so, out of the box tend to come with newer versions of libraries and tools and packages and that makes it very attractive for developers that are not bound to longer term stability and compatibility. So the developer goes off and installs the latest version of everything and writes their apps using that. That's a fine model in some cases but when you have enterprise apps that might be deployed for many years and have a dependency on certain versions of scripting languages or libraries or what have you, you can't just replace those with something that's much newer, in particular much newer major versions. I am sure many people will agree that if you have an application written in python using 2.7.5 and run that in production, you're not going to let the sysadmin or so just go rip that out and replace it with python 3.5 and assume it all just works and is transparently compatible....
So does that mean we are stuck? No... there is a yum repository called Software Collections Library which we make available to everyone on our freely accessible yum server. That Library gets updated on a regular basis, we are at version 2.3 right now, and it containers newer versions of many popular packages, typically newer compilers, toolkits etc, (such as GCC, Python, PHP, Ruby...) Things that developers want to use and are looking for more recent versions.
The channel is not enabled by default, you have to go in and edit /etc/yum.repos.d/public-yum-ol7.repo and set the ol7_software_collections' repo to enabled=1. When you do that, you can then go and install the different versions that are offered. You can just browse the repo using yum or just look online. (similar channels exist for Oracle Linux 6). When you go and install these different versions, they get installed in /opt and they won't replace the existing versions. So if you have python installed by default with OL7 (2.7.5) and install Python 3.5 from the software collections, this new version goes into /opt/rh/rh-python35. You can then use the scl utility to selectively enable which application uses which version.
An example :
scl enable rh-python35 -- bash
One little caveat to keep in mind, if you have an early version of OL7 or OL6 installed, we do not modify the /etc/yum.repo.d/public-yum-ol7.repo file after initial installation (because we might overwrite changes you made) so it is always a good idea to get the latest version from our yum server. (You can find them here.) The channel/repo name might have changed or a new one could have been added or so...
As you can see, Oracle Linux is/can be a very current developer platform. The packages are there, they are just provided in a model that keeps stability and consistency. There is no need to go download upstream package source code and compile it yourself and replacing system toolkits/compilers that can cause incompatibilities.