All items include fields to track the repository of origin, and fields for hierarchical organization of repositories. SortingHat provides a unified view of all contributors, by merging identities in different **data** sources, mapping all of them to the same uuid which is used in enriched indexes. When **data** sources are similar, common fields are identified, so that **data** can be merged and to some extent compared. For example, for issue trackers there are fields with opening and closing dates. Finally, the fact that **data** is stored in Elasticsearch may allow for merging directly when querying, such as "all **data** for all projects from date A to date B, authored by person P". Consumer-agnostic. It is very difficult to know how some person will exploit the **data** in the future. Since our approach is "retrieve and store", stored **data** may be useful even long after it was retrieved, or by a different team. GrimoireLab makes as few assumptions about analysis or visualization tools as possible. Enriched indexes are usually flat because then they are easier to import in visualization and analysis tools (for example, import into a Pandas **data** frame), but this is most of it. Thanks to this approach, we have tested the exploitation of **data** with several visualization tools, and the most common toolsets used for analysis. Anything that can consume JSON documents from Elasticsearch can be easily used to visualize or further analyze **data** produced by GrimoireLab. Performance and efficiency. When retrieving **data** from many repositories, performance is an issue. From one point of view, **data** sources should be used efficiently to avoid unnecessary stress. From another, we want the **data** as soon as possible. To address the first approach, GrimoireLab builds on an extensive research of **data** source APIs and retrieval options, to avoid those that could cause trouble. This is one of the reasons for using a toolset like this if you are not familiar enough with the details of **data** retrieval: avoiding causing unnecessary pain to the **data** source. Incremental access, and storage of **data** in raw indexes to avoid recurrent retrievals are a consequence of this goal.