Working on rosbag back at Willow Garage was a career-defining opportunity that put me on a life-long journey of thinking about developer productivity. I think the evolution of rosbag really exemplifies the power of use-case-driven incremental design, and I wanted to share the story of some of that original development process.
Very nice writeup! This should become a part of the ROS 1 bag wiki 
I’m missing one important point in the future ideas - making sure that when replaying the bag, the nodes will receive the messages in the exact same order they did during runtime. I’m not saying this is achievable with ROS 1/2 at all, but I think it is an important point. For some people I know, this is a showstopper for using ROS (1).
1 Like
Ah yes, the determinism aspect is another great point. This was actually a major focus of a ROS-like framework I built at another company (sadly not open sourced). For what it’s worth, I think all variants of rosbag / rosbag2 format technically support deterministic replay. The singular time-based index means messages will always be read from the bag in the same order – you just don’t have a guarantee they will be received by nodes and processed in a specific order. This kind of deterministic execution scheduling brings in a lot of complexity in cases outside of trivial single-process jobs.
ROS2 features such as executures and WaitSets might be sufficient to get things executing deterministically in a sufficiently constrained environment though.