Atomate2 is intended to be a successor to atomate1. The library itself will NOT be backwards compatible, and default parameter values may change, although the format / schema of the database generated by atomate and atomate2 may remain mostly consistent. The main reason for atomate2 is to increase clarity / usability / reusability versus the steeper learning curve and greater amount of idiosyncracies in atomate. We expect a gradual fadeout of atomate in favor of atomate2 over the next couple of years.
The org is changing to materialsproject to reflect historical (atomate1 trends) and projected future trends that this code will be developed collaboratively by many people involved with Materials Project, used by Materials Project, and likely promoted and supported by Materials Project. However, the “hackingmaterials” organization has been and will remain very actively involved. We do not expect to have a competing fork in hackingmaterials, rather to develop in the materialsproject organization.
(please note - the above response was edited to indicate that atomate2 will NOT be backwards compatible with atomate1 in terms of syntax for developing workflows, although both will continue to be based upon FireWorks).