OpenELA
 

Hello,
OpenELA is not a Linux distribution and is not intended to be. Is it right?

Thank you.

https://openela.org/about/
what is unclear on that page?

Hello,
Thank you so much for your reply.
This is source, but I want to know if it will become a distribution?

You might be interested in this:

It looks like OpenELA is not intended to ever become a single distro, but rather a source for enterprise distros as a class.

This seems to be a response to Red Hat making its sources more difficult to use.

Hello,
Thank you much for your reply.
Can it be said that this is some kind of a repository?

What is the goal of this question?
Obviously you can say whatever you want. The word "repository" has no any meaning without context, we have a huge amount of different kind of repositories. Therefore, "some kind of repository" means nothing, at most, "something".

Only in the sense of providing source code to allow others (developers) to build/support RHEL-compatible distributions. To quote the page Hazel linked to...

Hello,
Thank you so much for your reply.
This is my question. What source code? Packages?

Not packages, rather the source code used to make the completed packages (as in the software is not compiled or packaged for distribution yet). From OpenELA's site: What this means is that OpenELA would provide source code (most likely including all patches, bugfixes & security updates) that a project could then use to compile & package said software for distribution (e.g. RPM or DEB files). This would be open & unencumbered, with no restrictions, as we've seen with what Red Hat has done.

Hello,
Thank you so much for you reply.
Can you show me an example? I think there are quite a few apps that haven't been turned into packages yet!!

Best examples I can think of are components that are required for the system to run or basic system utilties, like the kernel, GNU binutils & coreutils, + desktop environments like GNOME or KDE, development tools, things like that. Packages used by a large majority of a distros userbase that also fit in the context of the vision of a distro.

On seeing apps not turned into packaged for (insert preferred distro here): If you're talking about Enterprise Linux (EL), EL users have generally a smaller package subset that they require, being that most EL distros are going to be used more for servers or general workstation desktops for work getting done vs a general user's home PC. There's also only so much time & resources that can be dedicated toward packaging & upkeep of the main distro packages & extra packages, so careful consideration is required when it comes to what gets packaged so that resources aren't spread too thin on packages that may not be used by a large enough user base to justify those resources. There's also storage space on mirrors to consider. Debian has a package that helps with this, popcon, that can be enabled by the user during the installation process to help the developers understand what packages are widely used by sending a report of packages installed back to Debian so resources can be distributed accordingly for packages that are widely used. There's also 3rd party repos you can check as well, like RPMFusion, ELRepo & EPEL on RHEL based distros, external repos for Debian & Ubuntu that can be added to your sources.list, Slackware has SlackBuilds + AlienBoB's repo, Arch has the Arch User Repository (AUR), & there are others depending on what distro you use.

If all else fails, if there's a package you want that doesn't exist, you could always consult your distro documentation for instructions on how to make packages yourself as well. On Debian checkinstall is an example of this, though I don't know if this is still current (haven't used Debian for a while now). There's simply just too many programs out there to package everything, so it has to be narrowed down to what will see the most use & fits with the goals of a distro is what it really boils down to.