ROS isn't really one thing. Per the "about"[1] it's really made up of several pieces:

Plumbing:

ROS is centered around a publish/subscribe messaging framework, with a central broker that ROS processes (called nodes) register with to advertise their publications and request subscriptions. Message definitions that are passed on the pub/sub "topics" are specified in language agnostic Interface Definition Language (IDL) files. There's an RPC service layer built on top of the messaging infrastructure, and the central broker also hosts a 'parameter server' database that nodes can use to query or update named values. ROS client libraries that provide APIs for topics/services/parameters are provided for several languages, primarily C++ and Python. A set of commonly used message definitions and conventions, which form de-facto standard interfaces, are used to establish interoperability and substitutability between ROS nodes.

Tools:

ROS provides build tools for individual software packages based on CMake and custom metadata embedded in an xml file. Packages can be grouped into workspaces, built with ROS tools, and workspaces can be layered on top of one another. Other ROS tools exist for process management (the launch system), introspection of running ROS processes, interaction with topics/services, and visualization of message data published with well-known message types. This list is by no means comprehensive

Capabilities:

Building on the concepts of publication/subscription with shared interface descriptions, and the package abstraction, various packages are publicly available that use ROS interfaces to accomplish various functions. These could include reading data from a sensor and converting the data to a ROS message, implementing robotic navigation algorithms, providing a visualization or UI, or controlling the behavior of a simulation. It's possible to build on and modify a lot of existing capabilities to build a system, which arguably speeds up the

Ecosystem:

ROS is widely used across industry and academia, and there's lots of people familiar with its workings. These people work together to advance the state of the art of the ROS framework and the capabilities implemented with it, the standards/conventions for interoperating with various components, and

ROS 2 is an evolution of ROS. It keeps a lot of the same concepts, but replaces the bespoke pub/sub messaging protocol with an abstraction to plug in lower-level messaging libraries (DDS is used by default). The reasons and motivations for starting over with ROS 2 are outlined here[2], but may require some familiarity with ROS 1 to get all of the nuance.

[1] https://www.ros.org/about-ros/ [2] https://design.ros2.org/articles/why_ros2.html